As of React 16, any error not caught by an error boundary will cause the entire React component tree to be uninstalled.
For large projects that have been in development for a long time and where Code Review is not as stringent, upgrading to React 16 may reveal that exceptions that were previously only occasionally localized and did not receive enough attention may now occasionally cause the entire application to collapse.
React 16 introduces Error Boundaries to address this situation.
Basic usage of Error Boundaries
If a class component defines any or all of the following lifecycle methods, the class component will become an error boundary.
This static method is called during the render phase when a child component throws an error, and the received parameter err is the error thrown by the child component. The return value of the method is the updated state of the component for the
render method to render the alternate UI. example.
Called when a child component throws an error, it takes two main parameters.
error: the error message thrown
info: an object with the component error stack, containing information about which component threw the error
This lifecycle method is called during the commit phase and therefore allows for side effects. Example.
- Error bounds can only catch errors of child components in the tree, not the component itself
- Error boundaries can only be used to catch or recover from exceptions
- Error bounds cannot be used to control processes
Define global default Error Boundaries handling functions
Considering the robustness of the entire application, designing Error Boundaries policies for each major component is necessary after React 16.
Define the HOC component for Error Boundaries processing
A simple way to do this is to design a
HOC component and then apply it to the business component to be wrapped using the decorator pattern.
Global compatibility: defining the default componentDidCatch method
For large applications with hundreds or thousands of components that have been developed for a long time, adding error boundary logic to the main components can still be cumbersome, and setting it only for the main module components can make local component exceptions magnified throughout the module.
A simple way to handle this would be to define a default lifecycle method
Component, all components inherit the default lifecycle method
componentDidCatch, so components with rendering exceptions are intercepted and handled in their parent component. Of course React will still throw a
Warning warning for not updating the UI in the
componentDidCatch method itself or defining the
static getDerivedStateFromError method, but at least it won’t cause the whole app to be uninstalled.
Of course, the bottom line is that we should not rely only on the regular format of input data, and we should require component development to take exceptions and handling into account as much as possible to ensure the robustness of the component itself.