Using Error Boundaries

[00:00:00]
>> Brian Holt: So that's enough on class component, we shall never speak of it again. Let's go actually use it though.
>> Brian Holt: Let's go to pass order route. We're gonna import our error boundary at the top, import error boundary from error boundary. One interesting thing about error boundaries, because of the way that the the errors work that you can't put the error boundary here.

[00:00:33]
So I can't just say error boundary here, why? Because if this component has an error, the whole component blows up, right? So I need to put it in a function component above it, right? So that I can catch things inside of it, does that make sense? It's like you have to put things inside of the try for the catch to work, that's essentially what I'm saying.

[00:00:54]
So let me show you what I mean, and then you can give me those perplexed glass glances again. So, let's just do it above, I think I have it above, so it's a little bit more clear. So, I'm gonna write another function here called error BoundaryWrappedPastOrderRoutes, and you're just gonna say return.

[00:01:20]
Error boundary, and then inside of that past order route, and then error boundary is gonna be the thing that we actually export.
>> Brian Holt: So the error boundary can only catch things that are being rendered inside of it. And so if it's on the same level of this, so if it was actually inside of password or, it won't get the opportunity to catch the error, so it has to be outside of it.

[00:01:52]
>> Brian Holt: Which is why we have two components here and then we are actually shipping the error boundary one.
>> Brian Holt: Now, some of you might say, but Brian, what if there's being props passed into this? In this case, we're not passing any props into it, but what if we were, right?

[00:02:11]
So, all you'd have to do here is we've taken props here at this level, and then there's this something here called the Spread Operator that works. And we're gonna say whatever props we got here, just pass them on through. Now, why didn't I teach you this earlier? You're probably thinking, that Spread Operator looks pretty cool.

[00:02:31]
Why don't we, use that a lot of places? And I intentionally do that, because I don't want you to use it that frequently, right? It is nice that it's just saying, here's a grab bag of things kinda spread them out. So imagine this props, for example, was something I don't even comment this, it could be like stuff, cool, other stuff,
>> Brian Holt: Not cool, right?

[00:03:01]
And you could come in here and actually just do stuff = props.stuff and otherStuff = props.otherstuff, right? And you could go be more explicit about that, that's totally fine as well. But it looks nicer to do just the spread operator, this makes it so opaque to read, though.

[00:03:28]
So, for things that you're actually passing stuff into explicitly, I want to see this because it makes me know this is the API that I'm gonna adhering to, where the data from is coming from and where it's going. Again, the explicitness of react is one of its superpowers, and so by hiding it behind dot, dot, dot props like this, you make it pretty opaque, of what is coming from where and where is it going?

[00:04:01]
The only reason in this particular case, that I am okay with the spread operator is that this particular component is meant to be a pass through. It's actually not meant to know about what's coming into it and where it's going, right? It's literally just meant to be going from like connecting two pipe together, and so this actually makes this less clear, right?

[00:04:23]
And this is a clear communication to the future developer, they're reading this, which is likely yourself, right? That this isn't supposed to know where it's coming through it, right? It's just supposed to be the past.
>> Speaker 2: Do you know why there are boundaries were left out of the new react or why they were still require the classical component?

[00:04:46]
>> Brian Holt: It's a good question, my reading on the situation which is pride reading between the lines is they didn't really have a elegant way to handle it, that was better than doing it in the class component way. Because it doesn't have a get derived state from pro, it doesn't have all the things that a class will have.

[00:05:07]
And so because of that, they decided, well, we're gonna leave in class components. They didn't have any intent to deprecate class components anyway, so they left it that, because, yeah, they would have made the library worse by trying to force it into this other pattern. And because they published that, react error boundary component, everyone can just use that.

[00:05:34]
>> Speaker 2: And can I just put an error boundary in my root?
>> Brian Holt: Sure you can.
>> Speaker 2: Route and just people do it on air boundary, handle everything?
>> Brian Holt: Yeah, I would put it here, probably at root, yeah, I would put it here, and you could just do air boundary, right there, catch everything, if that was appropriate for you?

[00:05:53]
Yeah, hell yeah, absolutely. So let's actually, make it work because of our try it,
>> Brian Holt: There you go OMG LOL WTF, is that is that our air boundary?
>> Brian Holt: There you go. So, there was an error with this page, click here to go back to the home page, right?

[00:06:26]
So what you saw before my page had reloaded, was feet catching my error boundary. This actually makes sense, right? This actually is a nice error page, there was an error. Click here to go back to the homepage and you caught everything. And now it's caught in the flow of the app and everything looks like it works, okay?

[00:06:49]
Yeah, one of the advantages of putting this around the app is I think it would catch 404s, which would be nice, right?