Original subtitles

Let me introduce you to error boundaries.

Sometimes something goes wrong in your applications.

And I'm not talking about bugs

you introduced as a developer.

Of course, you should simply fix them,

but sometimes there are errors which you can't prevent

or which are simply being used to transport information

that something went wrong

from one part of the application to another part.

Consider an HTTP request which is being sent.

If the server is temporarily not responding,

the request can't complete

and you will likely end up with an error being generated

in your application.

Now, there is nothing you can do about that as a developer,

servers can be offline.

And there are in general, errors which can't be prevented.

Here, I built a little dummy example.

In the users component,

I added the component that update lifecycle method,

and in there I check if my users prop, which I'm getting,

which is an array of users,

has a length of zero,

which means there are no users.

In which case, I throw a new error.

And that is, of course, a technical thing in JavaScript.

By doing this, by executing this line,

I'm generating an error

and I let this error bubble up the call stack.

So I pass it through all these components,

and if it's not handled anywhere,

this will crash my application.

And you can see this if you add this code

if you run your application.

As long as there are users, everything is fine,

but if I search for something

which is not part of any username,

like in S,

this will crash.

And it crashes with the error I specified

because it's my error which is not being handled.

Now, of course I could just simply not throw an error,

but instead handle this case differently,

but it's also quite common to use errors,

not as a bad thing,

but simply as a way of transporting the information

that something went wrong

from place A to place B in your application.

You can learn more about that, by the way,

learn more about embracing errors in my clean code course

if you want to,

but that's just a side note.

So here I generate an error and I want to generate an error.

Of course, I don't want the entire application to crush,

so what can we do?

In regular JavaScript,

we use, try, catch for this.

We can try some code,

which might fail,

and we catch potential errors when that code executes

to then handle that error and run alternative code.

That's what we can do in JavaScript.

And with react, of course,

we are just writing JavaScript code.

Nonetheless, if an error is generated inside of a component

and we can't handle it in that component though,

let's say we don't wanna handle this error

in the users component,

but in a parent component, instead,

then we can't use try, catch,

because that only works in places

where we write regular JavaScript statements,

and if we throw an error

and we wanna handle it in a parent component,

our problem is that in this case here

the users component is generating that error,

but that is not a regular JavaScript statement here.

Instead here, we have JSX code

and the error is generated inside of that JSX code,

inside of the users component.

Now, we can't wrap this JSX code with try, catch.

Something like this doesn't work,

so that's not an option.

Instead in such a case,

you can build and utilize an error boundary,

and that's what we're going to do now.

For this, I'll add a new component

and I will name it error boundary,

though the name is up to you,

it doesn't have to be named like this.

It's a JavaScript file

and in there I will create a regular component,

which I'll name error boundary.

So let's import component from react

because I will build it as a class-based component

as you can already tell, like this.

And now in there, I'll do something special.

The error boundary component

is a regular class-based component,

but it is a class-based component

which implements the componentDidCatch lifecycle method.

The componentDidCatch lifecycle method can be added

to any class-based component,

and whenever you do add it to a class-based component,

it makes that class-based component an error boundary.

It's just a term which we use to refer to

when we talk about components

that have this lifecycle method.

You can't edit two functional components,

and there is no equivalent for functional components

at the moment.

So if you wanna build an error boundary,

it needs to be a class-based component,

and then it is a class-based component,

which implements this lifecycle method.

Now, what's this special thing about this lifecycle method?

Well, this lifecycle method will be triggered

whenever one of the child components throws an error

or generates an error.

Therefore, what we do in the error boundary as well

is we add a render method, like an all components,

and we return this props children,

and that's special now.

Here I return this props children

because I want to wrap my error boundary component

around components

which should be protected by that component.

So here, for example, in the user finder,

I could wrap the error boundary around my users component.

Of course, we now need to import it also.

So we import error boundary from error boundary.

And then we wrap it around any components

which might throw errors which we wanna handle.

And of course, you can wrap it around

more than one component,

it's totally up to you.

Now, back to the error boundary.

In there or in this file,

of course, also we want to export error boundary,

but then instead of this class,

I now wanna do something when an error occurs.

For that, we get the error object here as a parameter,

automatically passed in by it react,

and we can then, of course,

look into that error to find out what went wrong,

and maybe run different logic based on different errors,

though you could also consider

creating different error boundaries for different errors,

but then, of course, we can do whatever we wanna do

because it is a regular class-based component in the end.

So we can also add a constructor called super,

and then set our state equal to,

has error false, for example.

And that's totally up to you,

it doesn't have to be named, has error.

You can manage any state you want here

because it is just a regular

class-based component in the end.

But then when we catch an error here,

we can call this set state and set has error to true.

And then in the render method,

we could check if this state has error is true,

and if that's the case,

we return something went wrong like this.

And that's how we could handle the error.

We can, of course, also lock the error

or send it to a server for analytics

or whatever we wanna do.

But now with that, we built an error boundary,

and here's the result.

If I now reload this, if I now enter an S,

you will see something went wrong,

only briefly though, and then we see this screen again.

Now, that's only a development thing though,

as you can also tell by the message down there.

This is still shown

by the react development server here in the end

to make it clear to us that an error did occur.

If you build your application for production and deploy it,

something we'll also do later in the course, of course,

this would not visible.

And you can close it here as well, this overlay.

So this is what you would have in your real app,

in your production app

without that development error message.

And therefore, here we can see that

the error boundary does work.

Of course, it's unstyled

because I haven't added any styling here

to my error boundary,

but you could do that.

And the idea behind error boundaries

really is that you can ensure that

not your entire application crashes if something goes wrong,

but that instead you can catch those errors

and then handle them in an elegant way,

just as you would do it

with try catch in regular JavaScript.

And for error boundaries, if you add them,

you need class-based components.

This is currently not possible with functional components.