00:00 Alright, let's go to our username and we're going to swap this with the generic general error boundary So like pretty much all this stuff can be removed in favor of the general error boundary But you know what? I kind of removed that prematurely

00:14 Let's back it up a little bit because I want to get this right there. So let's put it all back and then we'll say Status handlers and for 404. Yep. That's kind of the idea But we need to get the params right there and this is complaining because We're not returning. There we go. Tada

00:37 Awesome. So same exact behavior. Everything's working just the way it was before but what's nice is now we're getting The benefit of being able to apply this to other places. So let's go to the notes route and let's apply this here as well in fact, it's going to be pretty similar so we're going to grab that and stick it right here and Bring in the general error boundary and

01:00 Instead of no user with the username, we're going to say Yeah, well, let's see. I guess that that is going to still be That so we could say no owner note owner, whatever. We will just leave it that way Here we'll say users not found slash notes and we're going to get the exact same thing. So no note

01:21 Owner with the username. There we go. Now we can tell the difference. So that's great We're all set there and then of course if we had Maybe we add a feature in the future to say People can have their notes be private. And so then you'd be able to have a 401 or 403

01:39 For that particular use case there and we just add more handlers. Alright, so let's keep on going let's go to our note ID and We'll add Handler here. Now. This is actually interesting before we add this. We're going to go to Cody's notes And then I'm going to go to a note that doesn't exist. So there you go

02:00 We've got actually a 404 with an error message that isn't quite right No note owner with the username Cody exists, but that's not the reason we had the 404 So the interesting thing here is that these errors will bubble to their least common parent or to the nearest parent that has an error

02:16 Boundary and that's the error boundary that will get rendered. So there's a reason we want to put an error boundary here Even though it's actually being handled by its parent. We'll talk about that in a second But the the reason that there is a 404 handled here is actually because of the child so if I wasn't going to add a

02:36 Error boundary to this child then I might consider improving this error message to handle or to consider this use case But because I'm going to add an error boundary I'm not going to bother with that The only reason that I showed you this was to give you an idea that

02:52 Yes, these error boundaries do bubble up and you can have like one general one that's going to handle everything But the more general you make it the worse it's going to be and so let me show you what why it's such a good idea to put error boundaries on maybe most of your routes and That is going to require a copy paste of this

03:13 So let's bring in the general error boundary and then we have the 404 and in this case It's not the note owner. That's going to be the 404. I it's going to instead be No note with the ID params dot note ID exists So now look at that. Did you see what happened before the error covered the entire screen?

03:35 But now the error just covers the part of the screen that the note ID is responsible for and that is why it's a good Idea to add error boundaries to these routes because now the user is able to say oh, yeah I guess that note was deleted or something. I'll just go over to this one and the app still works. So that is fabulous

03:53 That's super super cool that we can actually make everything continue to work Even if one of the routes has some sort of problem and so that's why we add error boundaries Lower down in our tree But the cool thing is if we forget or or something it will bubble and so we can have at least some sort of

04:12 Level of error handling. Okay, great. So let's continue then and we'll go to our edit route and We're going to have something that looks exactly like this one actually And the reason that we're doing this here, I won't save it So that we can observe this behavior But the reason that we're doing this is if I have another error

04:35 Like the note ID is incorrect or something. This will bubble again, but I want to keep it local and the reason that we have to do this is because These are sibling routes as indicated by that under that trailing underscore And so because the edit route is a sibling route to the note ID route

04:55 We are not going to get the note IDs error boundary. So we have to have one of our own So that's why we add this and now poof we get more of the UI that is functional which is fabulous and That is adding error boundaries all over the place. So the general error boundary. It's cool

05:12 There should probably be a library of this eventually. I'll probably put a library together I suppose if I do I'll put it in the notes in the instructions but the the main point of this exercise was to show you the relationships between Parent routes and nested routing and and the ability to have those all bubble

05:32 So I hope that wasn't it was instructive to you. And I yeah, I hope that was fun