React errors UI appears differently
See original GitHub issueI see we recently updated to v5.0.0 and there were some changes to the react-error-overlay
. Can we revert back to the old version?
This new one has less information, features, and is much harder to read. What happened here?
New – worse UI:
Old – better UI:
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:6
Top Results From Across the Web
Error Boundaries - React
Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI...
Read more >8 common React error messages and how to address them
Learn about the most common error messages in React Development and the meaning behind them, the error itself, and how to fix it....
Read more >How to Handle Errors in React - AppSignal Blog
In today's post, we'll go through different ways to handle errors in React applications. The Classic 'Try and Catch' Method in React. If...
Read more >React error overlay - show for one error then throw a different ...
Is there a way to show the error that was originally thrown and then return a different one to be handled by the...
Read more >React Error Handling and Logging Best Practices
If an error occurs outside of an error boundary, the entire React ... use react-error-boundary to eliminate the need for two different error...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@RichardLindhout That’s a very subjective analysis and the initial example is skewed.
Objectively, here are the two side by side (using the stock CRA example, both images at native resolution):
First off, “can be closed” is completely irrelevant since it’s a build error, and second, the only objective difference is the additional stack trace on the new overlay, which arguably isn’t important for a build error anyways. It comes down to which UI looks more visually pleasing to the developer, which isn’t worth arguing over.
What is worth arguing over is that the new error overlay does not report runtime errors. This is a huge difference and unless the new UI implements this, the old UI is objectively superior.
For runtime errors, the new overlay is a blank screen, unreported, forcing the developer to rely on console output, whereas the old overlay has the error message, a stack trace (clickable, taking you to the the file and line in your IDE), and (since it is a runtime error) the overlay is closable:
New overlay in runtime error scenario (console output provided since there is no overlay in this case):
Old overlay in runtime error scenario:
I agree with @xnukernel (although for a different reason) that the new overlay is not yet a sufficient replacement for the old one.
It’s a lot better error message and can be closed, so I don’t see why it should be changed back?