Error Boundaries in Practice

Multiple nested error boundaries

We now know how to implement an Error Boundary by adding either static getDerivedStateFromError() or componentDidCatch() to our components. Error boundaries should not implement their own logic, should not be too tightly coupled to other components, and should be as independent as possible. It is at the developer’s discretion to decide how granular the error boundary should be according to the specific use case.

It’s a good idea to implement different and nested error boundaries to cater to various errors, such as one error boundary that wraps around the whole application and one that wraps only optional components in the component tree.

Nested error boundaries example

Let’s look at an example:

import React from 'react';
import ReactDOM from 'react-dom';

const App = () => {
  return (
    <ErrorBoundary>
      <ApplicationLogic />
      <ServiceUnavailableBoundary>
        <WeatherWidget />
      </ServiceUnavailableBoundary>
    </ErrorBoundary>
  );
};

ReactDOM.render(<App />, document.querySelector('#root'));

Two Error Boundaries are used in the above example:

1. ErrorBoundary
2. ServiceUnavailableBoundary

While the outer boundary will catch errors that might occur in the ApplicationLogic component, the ServiceUnavailableBoundary could catch errors in the WeatherWidget component and display a more granular error message like “The service requested cannot be reached at the moment. Please try again later.”

If the WeatherWidget component throws an error, the ServiceUnavailableBoundary will catch it, and everything that is currently used in the ApplicationLogic component will remain intact. If we omitted the WeatherWidget in its own error boundary, the outer error boundary would be used instead, and the ApplicationLogic component would not be shown.

Generally, it is good practice to have at least one error boundary as high up as possible in the component hierarchy. This will catch most unexpected errors like a 500 Internal Server Error page would and log them. If needed, further error boundaries should be added to encompass useful logic in further component trees. This depends entirely on how error-prone a specific area of the tree is (due to unknown or changing data) or if a particular area of the tree has been neglected.

Note: Since React version 16, components will be unmounted and removed from the tree if a serious error occurred or an exception was thrown. This is important as it ensures that the user interface does not suddenly stop working or returns incorrect data. It is especially critical to ensure working with online banking data. Imagine the consequences of sending money to the wrong recipient or transferring an incorrect amount.

To deal with these errors and risks correctly, error boundaries were introduced. They allow developers to inform users that the application is currently in an erroneous state. As errors and mistakes can never be entirely avoided in an application, using error boundaries is highly recommended.