Suggestion: Don't display error iframe

[fwh1990]

Sometimes, the Promise reject data which is expected, but this plugin report error message by create an iframe#react-refresh-overlay element to html.body. That's boring, because I can see error message in Console.

This behavior will interrupted my mind and I have to close iframe by hand.

[pmmmwh]

Sometimes, the Promise reject data which is expected, but this plugin report error message by create an iframe#react-refresh-overlay element to html.body. That's boring, because I can see error message in Console.

This behavior will interrupted my mind and I have to close iframe by hand.

I thought the overlay only shows up when there are unhandled promise rejections? That's an Error by definition, isn't it? Or are you saying that it shows up even when the rejection is handled?

[fwh1990]

I didn't handle promise rejection, that's my purpose. The program work well without handle rejection. Would you please add an option to disable this behavior?

[fwh1990]

I just tested Promise.reject in RN 0.61, it's reported as a warning display at the bottom of screen. You recognize it as error.

Whatever, I also want to have an option to disable showing error.

[pmmmwh]

My thoughts on this:

• Unhandled promise rejection should be warned as it is being warned in the console anyways. I can tune it down to be an error, but I wouldn't want to allow someone to switch of unhandled rejections independently in the error overlay
• Realistically, I can allow an option to make the plugin not inject the error overlay runtime code, which will effectively disable the overlay. I can see this useful in a few ways, for example custom HMR implementations or custom error logic. (also would be useful for CRA since they have both of these)

CC @gaearon your thoughts?

[fwh1990]

Any progress?

[pmmmwh]

Any progress?

I'm currently on vacation and don't have much free time to do anything yet. You can submit a PR if you want this done quicker.

[mattfwood]

For cases where you need to ignore a thrown exception, you should have something in your user code that is catching it and doing something with it (you could also use an Error Boundary):

try {
  const res = await api.post('data');
  return res.data;
} catch (error) {
  // if the promise is rejected
  console.log(error); // log out the error, but catching here prevents this from being an uncaught exception
  // do something to display error message
}

Keep in mind that in React, if you hit an uncaught exception it will crash the entire app. From the React Docs:

This change has an important implication. As of React 16, errors that were not caught by any error boundary will result in unmounting of the whole React component tree.

This feature you are asking for is not just about development experience. It means that even if you ignored the error in development mode, it will still crash the React component tree.

[fwh1990]

Keep in mind that in React, if you hit an uncaught exception it will crash the entire app.

My project run well when I am using react-hot-loader, and never ever crash when I uncaught rejection. I don't think Promise.reject can crash React component tree, it's async and out of control for react

[mattfwood]

Ahh, my mistake, i was confusing rejected promises with uncaught exceptions.

[gaearon]

Error overlay should display unhandled rejections. It is easy to intentionally handle it by adding catch() if you don't want to treat it as an error.

It is also true that we should offer a way to customize the error overlay to "redirect" it to another module. We'll need need this for opinionated integrations like Next. Seems like that would cover the use case for a "noop" overlay too anyway.

[SimenB]

Using the builtin error overlay in webpack creates duplicate overlays with this plugin active. I don't think it's a single plugins responsibility to provide an overlay, it should be explicitly configured or provided as part of an abstraction like CRA, Next etc.

[gaearon]

Using the builtin error overlay in webpack creates duplicate overlays with this plugin active.

Are you talking about the compile-time or runtime overlay?

[SimenB]

Compile-time.

EDIT: Wait, I get double error overlay for both

[OneCyrus]

yes, please let us disable it. the visualization is not that great. we already use error-overlay-webpack-plugin which give better errors.

this is far better for us:

[githoniel]

webpack-dev-server provide builtin overlay already.
https://webpack.js.org/configuration/dev-server/#devserveroverlay
I think it is enough for most case, and this plugin should have an options to disable the layout to avoid duplicate

[mmhand123]

I made a PR to make the overlay default off and added an option to add it back in. Wonder though if it might be better for the plugin to not worry about the overlay at all.

[SimenB]

I think it shouldn't be here at all, but as long as it's not forced upon me it doesn't really bother me

[IronSean]

We just hit a situation where the overlay makes our app unusable and prevents testing and development. I think maybe it shouldn't sorry about it at all, but even if you're unsure about that please merge the pr defaulting it to off while you decide.

[IronSean]

@pmmmwh ^^

[pmmmwh]

We just hit a situation where the overlay makes our app unusable and prevents testing and development. I think maybe it shouldn't sorry about it at all, but even if you're unsure about that please merge the pr defaulting it to off while you decide.

Hi, sorry that I have been very busy lately. I'll take a look at it tomorrow and provide my thoughts on that.

[cameronscottseequent]

For anyone that stumbles upon this.

supply this setting in your webpack config file

plugins: [new ReactRefreshWebpackPlugin({overlay: false})],

[globad]

cameronscottseequent Thank you! That helped me.

[okovalov]

@cameronscottseequent thank you so much! that worked!