React’s ErrorBoundary. Are You Using It Yet?

It has been available since 2017, but nobody knows about it.

Have you recently been through the React documentation? As developers, we should do our best to always stay up to date. Going through documentation is the perfect way to learn something new. This is how we can discover React’s error boundaries.

Why Should I Use It?

Before you close this article, wait! Yes, Error Boundaries are from 2017. However, React very recently introduced a new feature for the React DevTools!

This feature will allow developers to test how different components will act upon errors. It will allow you to simulate a React Component as “crashed” using the DevTools.

Sure, you should implement error handling logic, like any other application. However, having something in place, just in case something does break is never a bad idea. Remember Murphy’s law? As driven developers, we want to avoid anything that could negatively impact our users.

Anything that can go wrong will go wrong.
~ Murphy’s Law

ErrorBoundary? What is that?

The ErrorBoundary component has been there since React 16. Which is actually… since 2017! Yet a lot of developers are unaware of its existence, and I don’t see it being used often.

Going through the React Documentation we can find the Error Boundaries definition.

A JavaScript error in a part of the UI shouldn’t break the whole app. To solve this problem for React users, React 16 introduces a new concept of an “error boundary”.
~ React Documentation

As the documentation states, the ErrorBoundary component will not catch any event handler and asynchronous code errors.

Okay, but what does it do?

It limits the area of the UI that can get broken due to an error. Imagine having the following React application.

function App() {
return <div>
<Header />
<Content />
<ReadMore />
<Footer />
</div>;
}

If any of these components break, the UI could be broken for the entire application. We don’t want that. Instead, we can scope errors to specific blocks of the application. For example, let’s say the Content and ReadMore should only affect each other, but not the Header and Footer components.

function App() {
return <div>
<Header />
<ErrorBoundary>
<Content />
<ReadMore />
</ErrorBoundary>
<Footer />
</div>;
}

Quite easy, right? Simply define the error boundary over the components you want to isolate for errors.

Give me a live demo!

Yes, definitely! React’s team has made a beautiful demo for this. Play around by clicking until 5 clicks, which will break the UI. The top components do not have error boundaries set up, so we can see both of them break at the same time. However, for the bottom two components, error boundaries have been used. If one component breaks, the other will still be running.

Where does this ErrorBoundary component come from?

There’s a gotcha. You have to make this component yourself. The good news is, it’s incredibly easy and will allow for full customization in case of errors! You can even base yourself on the example given in the React documentation.

// From https://reactjs.org/docs/error-boundaries.html
class ErrorBoundary extends React.Component {
constructor(props) {
super(props);
this.state = { hasError: false };
}
static getDerivedStateFromError(error) {
// Update state so the next render will show the fallback UI.
return { hasError: true };
}
componentDidCatch(error, errorInfo) {
// You can also log the error to an error reporting service
logErrorToMyService(error, errorInfo);
}
render() {
if (this.state.hasError) {
// You can render any custom fallback UI
return <h1>Something went wrong.</h1>;
}
return this.props.children;
}
}

As you can see, an error boundary component is nothing more than a React component, with extra lifecycle methods. We have getDerivedStateFromError() and componentDidCatch() which can be used to modify the UI, depending on the error, or log the error. These are some examples, but there is an infinite amount of possibilities.

As you can see, React’s documentation suggests keeping the error status inside the state, and using this to render an error instead of an actual component.

What about functional components?

Nice catch, it is indeed a class component! Support for error boundary lifecycle is not yet available for functional components. This will possibly be added in the future since the React team is pushing out updates regarding this for the DevTools.

So is this radically new?

No, of course not. It’s an improvement of the DevTools that allows for easier debugging and testing of these error boundaries, however, error boundaries have been there since 2017 in React! This update will likely bring more attention to the error boundaries toward developers.

Tell me more about this update!

Brian Vaughn has tweeted a gif of the new update in action. We can see a new option to “crash” a specific component on purpose. In turn, this lets us test the error boundaries, without having to actually make a component crash.

What’s next?

Now you are ready to go, dive into your own adventure, start building amazing applications. Just don’t forget about error boundaries!

PS: don’t forget to take a look at the React documentation from time to time!

Kevin Van Ryckegem

Kevin Van Ryckegem