Error boundaries are React components that catch JavaScript errors and display a Fallback UI. Learn how they work under the hood and how to use a popular implementation — the `react-error-boundary` package!

React Error Boundaries

Rendering a fallback UI is a valuable upgrade to the user experience. However, when an error occurs, it's important for developers (and those brave users who submit bug reports) to be able to see the error information and make a plan for preventing those errors from happening again.

Error logging is implemented in an ErrorBoundary component using the `componentDidCatch()` lifecycle method:

```js
componentDidCatch(error, errorInfo) {
  console.log(error);
  console.log(errorInfo.componentStack); 
}
```

This lifecycle method is called by React after an error has been thrown by one of its descendants. When called, it receives an `error` object representing the thrown error. It also receives an `errorInfo` object with a `.componentStack` property. This property is incredibly useful as it contains a [stack trace](https://reactjs.org/docs/error-boundaries.html#component-stack-traces) showing the history of rendered components that led to the error. 

```error
Error: Why do we even have this switch?
in LightSwitch (created by App)
in ErrorBoundary (created by App)
in div (created by App)
in App
```

By logging this stack trace, we can more accurately hunt down the source of the error. 

How your team decides to use the `componentDidCatch()` method to log the error information can vary widely. When testing out this feature, you may decide to simply print the error to the console. However, in production applications, this info is often sent to a server for monitoring, alerting, and debugging. 

Now it's your turn to try!

Logging Errors

Well done! You've successfully created your own `ErrorBoundary` components and you've used the popular `react-error-boundary` package to keep your application running in the face of errors. Error boundaries are essential defenders of our React applications that allow our users to have the most seamless experience possible. 

Let's recap what we've learned so far:
* Error boundaries are React components that wrap sections of a React application, catching runtime errors anywhere in their child component tree. They can render a fallback UI and log errors instead of just showing a blank screen. Error boundaries allow you to recover in the event of an error which leads to a better user experience. 
* React components become error boundaries once they implement one (or both) of the lifecycle methods `static getDerivedStateFromError()` and/or `componentDidCatch()`. In order to use these lifecycle methods, _the error boundary must be a class component_.
* The `static getDerivedStateFromError()` lifecycle method receives the thrown `error` value and should return the error boundary’s next `this.state`. The error boundary's new `this.state` value may be used to determine what to render: the fallback UI or the wrapped component tree. The `this.state` value can be reset to reset the error boundary and its children.
* The `componentDidCatch()`  lifecycle method is used to log the thrown error. It receives the thrown `error` and an `errorInfo` object as parameters. `errorInfo` has a `.componentStack` property containing the history of rendered components that led to the error.
* Typically, Error boundaries are created once and used multiple times throughout the application. It's common to use third-party error boundary implementations such as `react-error-boundary`.
* The `react-error-boundary` package exports an `<ErrorBoundary>` component that can receive the props `onError` (which can be assigned a function for logging errors), and `FallbackComponent` (which can be assigned a fallback UI component).
* We can provide an inline function for the `FallbackComponent` prop to pass additional props to the fallback UI.
* Error boundaries should be kept as close to the source of the error as possible. Common places to use error boundaries are around new features that have not been thoroughly tested. 

Congrats again on finishing this lesson!

Review

Typically error boundary components are created once and then used throughout the entire application where needed. Once the error boundary component has been set up, there isn't much need to modify its code. As a result, it's not common for programmers to create their own `ErrorBoundary` components in the first place. Instead, they will often turn to implementations such as the popular [`react-error-boundary` package](https://github.com/bvaughn/react-error-boundary/).

This package exports an `ErrorBoundary` component that does all of what our `ErrorBoundary` component can do plus more! To replicate the basic fallback UI behavior of our own custom ErrorBoundary component, we could write:

```js
import { ErrorBoundary } from 'react-error-boundary';
 
function ErrorFallback() {
  return (
    <div>
      <h2>An error was detected!!</h2>
    </div>
  );
}
 
function App() {
  return (
    <ErrorBoundary FallbackComponent={ErrorFallback}>
      <MyComponent />
    </ErrorBoundary>
  );
}
```

In this example, we:
* Import the `ErrorBoundary` component from `'react-error-boundary'`.
* Define an `ErrorFallback()` component with UI to render if the ErrorBoundary catches an error.
* Render the `ErrorBoundary` with our component nested inside. 
* Pass a `FallbackComponent={ErrorFallback}` prop to `ErrorBoundary`. When the `ErrorBoundary` catches an error, the `ErrorFallback` component renders instead!

At this point, this `ErrorBoundary` doesn't have any logging or resetting behavior, but we'll get to that in the next exercise. For now, let's add the basic `ErrorBoundary` to the lightswitch application!


react-error-boundary I

In the last exercise, we practiced rendering a fallback using the `FallbackComponent` prop assigned to an `<ErrorFallback>` component. The `<ErrorFallback>` component received two props itself: `error` and `resetErrorBoundary`:

```js
function ErrorFallback({ error, resetErrorBoundary }) {
  // Handle the error / resetErrorBoundary logic...
}

// Later in some rendered JSX...
<ErrorBoundary FallbackComponent={ErrorFallback}>
  <ProtectedComponent />
</ErrorBoundary>
```

The two values, `error` and `resetErrorBoundary`, are automatically passed as props to whatever component is provided as the `FallbackComponent`. But if we needed to pass in additional props to `<ErrorFallback>`, how might we do that?

Passing additional props to our fallback UI allows us much greater flexibility in _how_ we render that fallback. We may want to provide more details about the thrown error or switch between different UIs depending on the error. For any of these scenarios, the solution can be achieved using the basics of React! 

Rather than providing `ErrorFallback` as the value of the `FallbackComponent` prop, we can provide an inline anonymous function component like so:

```jsx
function ErrorFallback({ error, resetErrorBoundary, newProp }) {
  // Handle the error / resetErrorBoundary logic...
  // But now we also have the newProp value!
}

// Later in some rendered JSX...
<ErrorBoundary
  FallbackComponent={(props) => (
    <ErrorFallback {...props} newProp={"foo"} />
  )}
>
```

Let's break it down:
* The `<ErrorBoundary>` component is still rendered with the `FallbackComponent` prop
* The component passed as the `FallbackComponent` is an inline anonymous function component with a `props` argument. We know that this `props` argument is an object with two values: `error` and `resetErrorBoundary`.
* The inline anonymous function component returns the `<ErrorFallback>` component with the original `props` values (`error` and `resetErrorBoundary`) along with a `newProp` value (in this case `"foo"`). 

Passing in a value like `"foo"` is quite silly but it illustrates the point: we can pass any additional props to our fallback UI using this approach! Let's see how this may be more useful in our example application.

Passing Props to Fallback Components

Before we wrap up, we should discuss when and where to use error boundaries to maximize their potential impact, as well as their limitations. 

#### Keep It Focused
Error boundaries isolate a component tree from the rest of the application and render a fallback UI when an error occurs. However, if our error boundary is too far from the source of the error, then other nearby components will be swallowed up by the error. 

For example, imagine if we were to put a single error boundary wrapped around the root component. An error is thrown somewhere in the application and the error boundary replaces the root component with a fallback UI. While the application hasn't crashed, the user only sees the fallback UI and nothing else. This isn't a great experience.

Instead, we want to try to put our error boundaries as close to the source of potential errors as possible. Often, this means placing our error boundaries around new features that have not been thoroughly tested yet. As our users interact with these new features, errors will be caught and, with detailed logging, we can hone in the location of our error boundaries over time.

#### Limitations
There are some key limitations of error boundaries that should be noted however. According to the [React docs](https://reactjs.org/docs/error-boundaries.html):

> Error boundaries can catch errors that occur during rendering, in lifecycle methods, and in constructors of the whole tree below them. Error boundaries **do not** catch errors for **event handlers**, **asynchronous code**, **server side rendering**, or **errors thrown in the error boundary itself** (rather than its children).

When & Where to Use Error Boundaries

At this point in your learning journey, you've likely come across the `try`/`catch` block. As the names of the keywords suggest, `try` blocks allow programmers to attempt to execute some code. If a runtime error is thrown, `catch` blocks intercept and handle the error.

```js
try {
  thisMightThrowAnError();
} 
catch (error) {
  thatsOkWeCanHandleIt(error);
}
```

Backup plans like `try`/`catch` blocks allow programmers to respond to, and hopefully fix, errors rather than letting them crash the entire application. React uses a similar technique to handle errors within its component tree — [error boundary components](https://reactjs.org/docs/error-boundaries.html).

**Error boundaries** are React components that catch runtime errors anywhere in their child component tree. The error boundary can log those errors and display a backup user-interface (a "fallback UI") instead of a blank screen. Error boundaries are commonly used around new features that have not been thoroughly tested as they allow you to recover in the event of an error.

We'll dive deeper into the syntax later, but here's a quick example of an error boundary component protecting an error-prone component: 

```HTML
<ErrorBoundary FallbackComponent={FallbackUI}>
  <MyErrorProneComponent />
</ErrorBoundary>
```

In this lesson, we'll learn how to build a simple `ErrorBoundary` component to protect our application. Then we'll look at a popular implementation that you can use in your projects rather than having to create it from scratch each time. By the end of this lesson, you will be able to:
* Create an `ErrorBoundary` class component that wraps other components
* Use `static getDerivedStateFromError()` to render a fallback UI after an error has been thrown
* Use `componentDidCatch()` to log error information
* Reset the broken components to a good state
* List examples of which errors that error boundaries can be used for (and those that they can't be used for)
* Use the `ErrorBoundary` component from the `react-error-boundary` package

Let's get started!

Introduction

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: 

```js
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](https://reactjs.org/docs/handling-events.html).
* 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!


Resetting the Component

At this point, our `ErrorBoundary` component isn't truly an error boundary. It still is letting errors through that cause the entire application to break. To make our error boundary actually protect our application, we need to:

* Identify when an error has occurred
* Store the error internally
* Render a fallback UI 

First, we can keep track of whether or not an error is present using the `ErrorBoundary` component's internal state. In the `constructor()`, we'll add some state:

```js
constructor(props) {
   super(props);
   // New code
   this.state = { error: null };
}
```

Notice that our state starts with `error` having a `null` value, i.e. there is no error. Next, to update this value when an error occurs we define the special [static](https://www.codecademy.com/courses/learn-intermediate-javascript/lessons/classes/exercises/static-methods) lifecycle method `static getDerivedStateFromError()`:

```js
constructor(props) { //… }
 
// New code
static getDerivedStateFromError(error) {
   return { error }; 
}
 
render() { //… }
```

This lifecycle method is invoked after an error has been thrown by a descendant component. It receives the `error` that was thrown as a parameter and should return the error boundary's next state. In this case, we want to return the `error` that the component received. 

> Note: We use [ES6 shorthand](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer) here. `{ error }` is equivalent to `{ error: error }`.

Finally, we can use the error boundary's `this.state.error` value to determine what to render: the wrapped component tree or the fallback UI.

```js
render() {
  // New code
  if (this.state.error) {  // Render a fallback if an error occurred
    return (
      <div>
        <h2>An error was detected!</h2>
      </div>
    );
  }
  return this.props.children;  // Otherwise, render the children!
} 
```

Now, our error boundary first checks its own internal `this.state.error` value before rendering its children. If an error is found, the fallback UI is displayed instead.

Let's try it out!

Rendering a Fallback UI

We are now able to replace our custom `ErrorBoundary` with the `ErrorBoundary` component from `react-error-boundary` — but there are some features that we lost. Specifically, we don't have error logging and the reset component feature!

Thankfully, `react-error-boundary` has built-in implementations for adding in these important features. Let's take a look.

First, we can see how to add error logging with the `onError` prop:

```js
<ErrorBoundary onError={logError} FallbackComponent={ErrorFallback}>
  <MyComponent/>
</ErrorBoundary>
```

In this example, we add the `onError` prop with our logging function `logError` as the value. `onError` will send along two familiar values to the provided function: `error` and `errorInfo`. Notice that these are the same arguments passed to the `componentDidCatch()` lifecycle method.

Next, we can look at resetting the ErrorBoundary with the `resetErrorBoundary` prop:

```js
function ErrorFallback({ error, resetErrorBoundary }) {
  return (
    <div>
      <h2>An error occurred in the app!!</h2>
      <p>Error: {error.message}</p>
      <button onClick={resetErrorBoundary}>
        Reset
      </button>
    </div>
  );
}
```

When our `ErrorBoundary` renders a fallback component, it will pass in two values as props: `error` and `resetErrorBoundary`. 
* `error` is the Error object itself which can be useful if we want to display the `error.message`. 
* `resetErrorBoundary` is a callback function that will reset the internal error state of the `ErrorBoundary` itself. This callback can be assigned to the `onClick` prop of the button element in our fallback UI.

With this code in place, when the user clicks on the "Reset" button in our fallback UI, the `ErrorBoundary` will reset and attempt to re-render the broken child component.

> Note: If you take a look at the [source code](https://github.com/bvaughn/react-error-boundary/blob/master/src/index.tsx#L78) for this feature, you can see that it's basically the same as our own implementation!


react-error-boundary II

As we learned in the introduction, error boundaries are React components that do a few key things:

1. Wrap around other components
2. Render their children if no errors are detected
3. Render a fallback UI if an error is detected
4. Log the error in some way if an error is detected

Over the next few exercises, we'll implement each of these features. For this exercise, let's start small and focus on those first two steps. We can create an `ErrorBoundary` that wraps around other components and renders its children when no errors are present like so: 

```js
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
  }
  render() {
    return this.props.children;
  }
}
```

In this example, we create an `ErrorBoundary` class component whose `render()` function returns `this.props.children` — the descendents that the `ErrorBoundary` wraps around. 

We could then start using this `ErrorBoundary`in an application like so:

```js
<ErrorBoundary>
  <MyErrorProneComponent />
</ErrorBoundary>
```

At this point, our `ErrorBoundary` component just acts as a pass-through component for `MyErrorProneComponent`. This is ideal! When no errors are present we want our `ErrorBoundary` to stay out of the way.  But what if an error occurs? We'll handle that in the next exercise!

Note that we are creating this `ErrorBoundary` as a class component, not as a function component. This is intentional. In fact, _error boundaries must be created as class components_. Why? 

React components become error boundaries once they implement one (or both) of the lifecycle methods `static getDerivedStateFromError()` and/or `componentDidCatch()`. We'll look at how to implement these methods in the next exercise, but for now remember that [lifecycle methods](https://www.codecademy.com/courses/react-101/lessons/component-lifecycle-methods) can only be accessed from class components.

Now it's your turn to try making an `ErrorBoundary` of your own. Take a look at the code in `index.js` in the provided editor. It's a light switch application with four switches. Each switch has an on/off button and a button labeled "Bad Switch" that will throw an error. Confirm that each switch controls its own section of the app and that pressing the error button will break the application. Refresh the application to try each error button.