search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.5k stars 4.2k forks source link

React Error Boundaries #8628

Closed tomjn closed 6 years ago

tomjn commented 6 years ago

Are react error boundaries in use? What is the expected result if I build a GB block that has a fatal error in it?

swissspidy commented 6 years ago

If your block produces an error the block will be replaced by a read-only error message à la "This block has encountered an error." or "This block has encountered an error and cannot be previewed."

There's at least an ErrorBoundary component for that and also BlockCrashBoundary

tomjn commented 6 years ago

Is the same true of other gutenberg components? E.g. from my testing with frontenberg, the div GB uses to load has no styling by default, perhaps some CSS based text that gets overriden once the JS applies classes would help alleviate the WSOD some are seeing with non-GB JS errors

noisysocks commented 6 years ago

BlockCrashBoundary catches exceptions that occur within a block and displays the message that @swissspidy described. We also wrap the editor with an ErrorBoundary which catches more general Gutenberg exceptions and displays a message with a prompt to reload the editor.

My understanding is that the WSOD was happening because of a race condition that stops Gutenberg from ever initialising. There's no exception to be caught when this happens.

A CSS failsafe error message is an interesting idea. I'd worry that folks on slow connections would see the error message and reload the page before Gutenberg has had a chance to load, though.

tomjn commented 6 years ago

Then perhaps a placeholder of sorts would be better? To indicate that something happened or is happening. A WSOD implies a PHP error

kevinwhoffman commented 6 years ago

In https://github.com/WordPress/gutenberg/issues/8637 I just outlined a potential use case for window.onerror that may be helpful in catching errors and communicating back to the end user. That might be a better alternative to a CSS failsafe since window.onerror would only trigger on an actual error (for better or worse).

youknowriad commented 6 years ago

We do have a global error boundary to catch all JS errors happening in the gutenberg editor but some errors are happening "outside" the Gutenberg editor (metaboxes) so maybe window.onerror are a better choice in that case. I'd close #8637 and conslidate these discussions in one issue.

kevinwhoffman commented 6 years ago

I tested each of these incompatible plugins from @danielbachhuber's site. These specifically mention JS errors as the reason for incompatibility, but I was not able to trigger a WSOD with any of them. They definitely had broken functionality, but the editor still renders and only a few of them actually display errors in the console. I assume this is because many of the errors are being caught and suppressed.

If we knew of an existing plugin that reliably triggered a WSOD, I think we could work out a solution faster.

danielbachhuber commented 6 years ago

Closing in favor of #8637, which has a specific proposed implementation.