So far, we’ve been able to capture errors, log them to the console, and show a fallback UI. This makes it possible for the rest of our application to continue running - but how do we recover the broken component beyond refreshing the page?

Our <ErrorBoundary> component determines whether to render the child component or the fallback UI based on its own internal this.state.error value. If we change this error state value back to null, the ErrorBoundary component will re-render along with the child component wrapped by the error boundary.

While there are many ways to do this, in this exercise we’ll walk through one fairly basic approach — adding a button that the user can press to reset the broken component. Take a look at the example below:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { error: null };
    this.reset = this.reset.bind(this);
  }

  reset() {
    this.setState({ error: null });
  }

  static getDerivedStateFromError() { //... }

  componentDidCatch() { //... }

  render() {
    if (this.state.error) {
      return (
        <div>
          <h2>Something went wrong.</h2>

          <button onClick={this.reset}>
            Reset
          </button>
        </div>
      );
    }
    return this.props.children;
  } 
}

In this example, we:

• Modified the constructor() function to bind the reset() method to the class component’s this value. This step is necessary to ensure that the this.setState() call within reset() has the proper this reference. You can read more about why this is necessary in the React docs.
• Created a new event handler function, reset(). When called, it will set the error state value to null.
• Created a new button element in the fallback UI with this.reset assigned to the onClick prop.

When the user clicks on the button element in the fallback UI, the reset() function will be called and the error state value will be reset to null. As a result, the ErrorBoundary component will re-render and will render this.props.children.

In production applications, the reset() logic may be more involved. We may attempt to recover unsaved data, make an API call to reset state on a server or database, or log out a user to avoid undesired access to protected features. This example paints a high-level picture of what needs to be done to get our application back to a running state.

Let’s try it out ourselves!