2 ms·

Great release but forcing the capturing of errors seems to violate the JS value of forgiveness. Worse, this "forcing" actually seems to hinder debugging. For e

Great release but forcing the capturing of errors seems to violate the JS value of forgiveness. Worse, this "forcing" actually seems to hinder debugging. For example, I have one component that throws an exception. Previously, React would print the stack trace in console and carry on. Now, it destroys the entire DOM, spews three times as many errors, without even letting me see what the visual result was of that error. To debug, I need to write a componentDidCatch method in the parent class of the erroring class, because the root componentDidCatch error handler can't reconstruct the DOM, because of that one sub-sub-sub-sub-sub-child state error. Even after writing all this new code, React still removes the erroring element from the DOM, leaving ambiguous what its impact was on the end-user experience. Does anyone else feel that the new version of React is fault-intolerant? While I do enjoy Java, I would argue that Null-Pointer-Exception hell does not belong in JS scripting.

jchw 9y ago
No, that's the opposite in my opinion. You should be catching errors. Ideally as early as possible. Most ideally when compiling your app, least ideally on a user's computer. I think a previous article on HN elegantly put it as, "move errors to the left." While this is more of a lateral move, it's an important one. Before, an error during render left your app in an undefined, potentially unstable state. Then, you might find some unrelated junk errors in your Sentry or whatever you use, and on top of that the user is wondering why when they click nothing happens. Now, you can recover from an error completely, even if you don't have control over the code running in other components. That's a big deal when you might want to have third party components or something to that effect.
raquo 9y ago
Everyone with a legacy codebase will probably update their components to extend a common class that handles errors in some very generic way without propagating them up the tree. I'm not sure how I feel about this change, but at least there's an escape hatch.
- superplussed 9y ago
  Do you mean wrapping all components with a HOC?
  - raquo 9y ago
    No, I mean ES6 class inheritance: class MyButton extends MyBaseComponent { // Render a button } Class MyBaseComponent extends React.Component { // Include error handling lifecycle hook here }
danabramov 9y ago
Can you please file an issue? We can discuss specific pain points and concerns there. It's a bit hard to reply to a comment here with technical points :-) The valuable discussion will get buried. As explained in the blog post about error handling, the recommendation is to add error boundaries in "strategic places" (e.g. around main UI blocks) so that they fail gracefully. But it requires some design input on how it should work. It means error states should be part of your app's design, and I understand this might seem unusual. Still, let's please continue this in the issue tracker.

jchw 9y ago

No, that's the opposite in my opinion. You should be catching errors. Ideally as early as possible. Most ideally when compiling your app, least ideally on a user's computer. I think a previous article on HN elegantly put it as, "move errors to the left." While this is more of a lateral move, it's an important one. Before, an error during render left your app in an undefined, potentially unstable state. Then, you might find some unrelated junk errors in your Sentry or whatever you use, and on top of that the user is wondering why when they click nothing happens. Now, you can recover from an error completely, even if you don't have control over the code running in other components. That's a big deal when you might want to have third party components or something to that effect.

raquo 9y ago

Everyone with a legacy codebase will probably update their components to extend a common class that handles errors in some very generic way without propagating them up the tree. I'm not sure how I feel about this change, but at least there's an escape hatch.

superplussed 9y ago
Do you mean wrapping all components with a HOC?
- raquo 9y ago
  No, I mean ES6 class inheritance: class MyButton extends MyBaseComponent { // Render a button } Class MyBaseComponent extends React.Component { // Include error handling lifecycle hook here }

danabramov 9y ago

Can you please file an issue? We can discuss specific pain points and concerns there. It's a bit hard to reply to a comment here with technical points :-) The valuable discussion will get buried. As explained in the blog post about error handling, the recommendation is to add error boundaries in "strategic places" (e.g. around main UI blocks) so that they fail gracefully. But it requires some design input on how it should work. It means error states should be part of your app's design, and I understand this might seem unusual. Still, let's please continue this in the issue tracker.