25 ms·

What GP means is that the stack traces will often just point you to React’s runtime code. This is a general debugability problem that all runtimes have-you now

What GP means is that the stack traces will often just point you to React’s runtime code. This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.

dragonwriter 6y ago
> What GP means is that the stack traces will often just point you to React’s runtime code. I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings. Now, getting the stack trace to only point you to some part of a component library's code seems more common.
- jiofih 6y ago
  I run into this daily. There isn’t a single JS error in our monitoring that has a useful stack trace. It would have to extend another 30 layers down to start going into actual application components or code. They all look the same going through different bits of React internals.
  - TrevorLee 6y ago
    I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. Usually it’s always the same error anyways. Something is undefined or typed wrong.
    - onion2k 6y ago
      I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. This highlights one of the biggest issues with React: usually it works really well, but if you're unlucky enough that it doesn't then there's almost no way to work out why. I've been developing with React for about 4 years and I just don't upgrade things in the ecosystem unless I absolutely have to, because debugging the tooling is a massive pain. This is also why it's very unhelpful to say that it works. Yes, it usually does, but not always and failing to understand that comes across as somewhat antagonistic.
      - hackerfromthefu 6y ago
        I completely understand what you mean about not upgrading things in the working ecosystem, it's the pragmatic choice in the short term. But then the churn in the interdependent platform and packages means your project is moving towards a state that it cannot be upgraded without significant risk and rewriting around the deprecated packages. In my opinion this is a major issue with React in the landscape of businesses that have a halflife of more than a few years.. ie most long term businesses. Yet despite the long term fragility and maintenance issues it's a topic that is missing in most discussions about React. The React conversations tend to be 'how can we keep up with the latest churn' instead of recognising the churn itself is a problem and stability provides realworld business value in the medium and long term.
    - jiofih 6y ago
      That’s sourcemaps. For simple errors like you mentioned it might be enough, but your stack is still useless for more complex issues. Usually it’s dominated by hooks / batch rendering code.

dragonwriter 6y ago

> What GP means is that the stack traces will often just point you to React’s runtime code. I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings. Now, getting the stack trace to only point you to some part of a component library's code seems more common.

jiofih 6y ago
I run into this daily. There isn’t a single JS error in our monitoring that has a useful stack trace. It would have to extend another 30 layers down to start going into actual application components or code. They all look the same going through different bits of React internals.
- TrevorLee 6y ago
  I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. Usually it’s always the same error anyways. Something is undefined or typed wrong.
  - onion2k 6y ago
    I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. This highlights one of the biggest issues with React: usually it works really well, but if you're unlucky enough that it doesn't then there's almost no way to work out why. I've been developing with React for about 4 years and I just don't upgrade things in the ecosystem unless I absolutely have to, because debugging the tooling is a massive pain. This is also why it's very unhelpful to say that it works. Yes, it usually does, but not always and failing to understand that comes across as somewhat antagonistic.
    - hackerfromthefu 6y ago
      I completely understand what you mean about not upgrading things in the working ecosystem, it's the pragmatic choice in the short term. But then the churn in the interdependent platform and packages means your project is moving towards a state that it cannot be upgraded without significant risk and rewriting around the deprecated packages. In my opinion this is a major issue with React in the landscape of businesses that have a halflife of more than a few years.. ie most long term businesses. Yet despite the long term fragility and maintenance issues it's a topic that is missing in most discussions about React. The React conversations tend to be 'how can we keep up with the latest churn' instead of recognising the churn itself is a problem and stability provides realworld business value in the medium and long term.
  - jiofih 6y ago
    That’s sourcemaps. For simple errors like you mentioned it might be enough, but your stack is still useless for more complex issues. Usually it’s dominated by hooks / batch rendering code.