Add “red box” on any JavaScript errors in development

[gaearon]

This is likely to cause some controversy so I’d love to hear the arguments against doing this.

I want to enable “red box” on any JavaScript error in development, similar to the proposal in facebook/react#1753. When an uncaught exception is thrown, an error is shown full screen similar to our syntax overlay (#744). It shows the error message and the stack. The full-screen message can be dismissed by pressing “Escape” in case you still want to interact with a broken app. The error is also printed in the console, like before.

We can use https://github.com/commissure/redbox-react although I’d prefer to have full control over this box in our monorepo to quickly patch bugs and improve the output.

Why I want to do this:

• React is currently not tolerant to errors thrown inside components. Its internal state often gets corrupted by this, so we want to surface errors early and prominently.
• We already do this on React Native to great success.
• In CRA we control the environment and we can do this.
• This is a part of my plan to bring hot reloading to CRA: Status/Roadmap of the project gaearon/react-hot-boilerplate#97 (comment).

Open questions:

• How to capture all errors with stacks in development. Does window.onerror provide Error objects in modern browsers now?
• What to do about unhandled Promise rejections. Ideally we want to surface them given how common this problem and misunderstanding is.
• What do do about errors inside React that accidentally get caught, like No error is shown when use a undefined variable react#7617 (comment). Even if the code is technically valid, React just doesn’t support this pattern. Any error inside setState() or ReactDOM.render() is going to mess it up. We could monkey-patch them to report errors, or add some hooks in React itself to surface them.

Feedback and thoughts welcome.

[gaelollivier]

First: I love the idea and the overall "master plan" to build a fully integrated developer experience, that's the reason I'm using CRA and its future seems bright ☀️

I just have one use case where I wouldn't want unhandled Promise rejections to throw a big red error:
In my app, I have middlewares that handle some side effects such as fetching data to the server and globally handling "fatal errors" such as 500 errors (in this case we just explain the user something unexpectedly went wrong).
The middleware responsible for fetching the data also allows the caller to get the request Promise in case he wants to do something with it. So I may request data like this:

componentDidMount() {
   this.props.dispatch({ type: 'FETCH_USER' }).then((result) => {
     // Might want to do someting here, or simply let reducers handle the result
   })
}

However, if FETCH_USER fails with a "fatal error", the promise will reject and the rejection won't be handled anywhere. A middleware will handle the error and display a message, but I don't want to manually catch the error here because the handling of "unexpected errors" is the responsibility of the middleware.

Is there something wrong with this pattern ? To me it's seems ok that some promises get rejected.

[dlebedynskyi]

Open questions:
Does window.onerror provide Error objects in modern browsers now?

Don't think so. Since it is by spec https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror. Also there is CORS issues there.

What to do about unhandled Promise rejections. Ideally we want to surface them given how common this problem and misunderstanding is.

Check this http://www.2ality.com/2016/04/unhandled-rejections.html. Chrome ( at least https://googlechrome.github.io/samples/promise-rejection-events/) has support for unhandled rejections.

What do do about errors inside React that accidentally get caught,...

they are caught for a reason( probably). So can be considered handled. otherwise we can get a redbox for expected code.

[davidpfahler]

Regarding the question of using redbox-react or something custom stored in this monorepo:

I would be glad to help in any way I can to make this solution based on redbox-react. Monorepo or not, I don't think that fragmenting solutions for exactly the same problem is good for the community. Whatever steps we need to take to keep this solution universal, I'm willing to take (add contributors, etc.). Please let everybody benefit from the improvements redbox will receive from being integrated into CRA.

What would you deem necessary to make this work?

[gaearon]

I think redbox-react might be a good start, and we can potentially look at other solutions if we find issues. One thing I‘m not confident about is whether we want the redbox to be based on React itself.

At this point it’s best if somebody can come up with a prototype for the integration that handle uncaught errors in browsers. I‘m not sure how to implement this without window.onerror. Do people use “zones” for it these days?

[agrcrobles]

@gaearon do you think that will it be possible to pre-render before emitting the error event in a similar way they do it in the storybook?
https://github.com/kadirahq/react-storybook/blob/master/src/client/preview/render.js#L23

[gaearon]

@agrcrobles I'm not entirely sure what you are asking, can you clarify the question?

[agrcrobles]

I am just thinking ( not sure if possible ) that instead of subscribing to a window error event, wrap the component that is attempting to be rendered

const WrappedComponent = (...args) => {
    try {
        return renderComponentFunctionHere(...args);
    } catch (error) {
        return <RedBox {...props} error={error}/>;
    }
};
return <WrappedComponent />;
};

[gaearon]

We want to surface all errors, not just ones that occurred during component rendering. It's also hard to statically find all components (I tried it before, and I don't think it's a good approach).

[volkanunsal]

Redbox can be very obnoxious. The color aside, I'd prefer to see the errors in the console and step through them. With Redbox, all I get is the line numbers, which aren't even right since cheap source maps devtool doesn't work in Chrome currently.

[davidpfahler]

@volkanunsal We'll be adding additional logging to the console commissure/redbox-react#77