WEBVTT 00:00.290 --> 00:00.830 Okay. 00:00.830 --> 00:05.540 So for some of these errors we might want to redirect them such as a 404 error. 00:05.540 --> 00:09.320 Then we might want to redirect them to a not found page. 00:09.350 --> 00:14.990 In the case of a 500 error, we might want to redirect them to a server error page and display something 00:14.990 --> 00:19.100 there that tells them that something's gone wrong with our server side. 00:19.310 --> 00:21.650 Well, we wouldn't be specific about what went wrong. 00:21.650 --> 00:28.070 We would just tell them that an unexpected problem has occurred, for example, the validation error. 00:28.100 --> 00:29.630 We'd probably want to display. 00:29.660 --> 00:33.590 Typically, we encounter a validation error with a form. 00:33.590 --> 00:37.460 So we might want to display that on the component itself. 00:37.460 --> 00:42.620 But things like the 400 error for a bad request or an unauthorized, we might want to just display a 00:42.620 --> 00:48.050 toast to the user that something has happened and keep them on the same component that they're on. 00:48.050 --> 00:53.630 So we'll do that for a couple of the errors and the package we'll use this to help us with toasts is 00:53.630 --> 00:55.220 called react testify. 00:55.250 --> 00:59.390 And if I take a look at NPM then this is the kind of thing that it gives us. 00:59.390 --> 01:00.770 Very simple to use. 01:01.330 --> 01:06.460 and we can use these toasts anywhere we want and display a notification to the user. 01:06.460 --> 01:11.620 So we're going to go ahead and install this into our project. 01:11.620 --> 01:19.030 So installation is just npm install react to justify this save flag by the way. 01:19.030 --> 01:19.990 It's no longer required. 01:19.990 --> 01:22.090 It doesn't do any harm if we do use it. 01:22.090 --> 01:30.100 But once upon a time we did have to specify save if we wanted our package.json to be updated after we 01:30.130 --> 01:31.420 npm install something. 01:31.420 --> 01:37.450 So you still see this sometimes, but it's not required when we use npm install to add a package. 01:37.450 --> 01:44.470 So let's go back to vs code and we'll go to the third tab I'm using to install things into the client. 01:44.800 --> 01:47.830 And I'll just paste in the npm install. 01:47.950 --> 01:49.870 And like I say we don't need that save. 01:49.900 --> 01:51.130 But it doesn't do any harm. 01:51.130 --> 01:56.800 But what will probably happen, let's see, is I've still got to use the legacy peer dependency, which 01:56.800 --> 02:01.020 seems to be a common thing, and it will probably be for every single package. 02:01.050 --> 02:05.610 We just need to add the legacy peer dependencies switch here. 02:05.610 --> 02:11.310 So I'll just repeat the command and paste on the legacy peer deps and press return. 02:11.790 --> 02:19.080 And like I've said before, of course if you're on a stable version of react 19 or you're using react 02:19.110 --> 02:22.110 18, then you won't need that switch. 02:22.110 --> 02:27.780 So now that is available to us, we will first of all set up our toast provider. 02:27.780 --> 02:30.540 We want to use toasts from anywhere. 02:30.540 --> 02:38.970 So I'll close this stuff down and let's open up our main dot TSX, the entry point for our application. 02:38.970 --> 02:46.200 And we add this at the highest level so that we've got access to toasts and can use them from anywhere 02:46.200 --> 02:48.030 in our react application. 02:48.300 --> 02:54.840 So just above the router provider here I'm going to specify toast container which we get from react 02:54.870 --> 02:57.750 to justify and make it self-closing. 02:57.750 --> 02:59.880 And we can give this a position property. 02:59.880 --> 03:02.310 Where do we want the toasts to display? 03:02.310 --> 03:05.340 And I'm going to say bottom dash. 03:05.340 --> 03:06.570 Right. 03:07.110 --> 03:10.410 And it typically comes with a progress bar. 03:10.410 --> 03:12.660 How long is the toast going to be on the screen for? 03:12.690 --> 03:13.920 I don't particularly like that. 03:13.920 --> 03:18.990 So I'm going to hide the progress bar and I'm going to give it a theme of colored. 03:19.530 --> 03:24.900 So an error would be colored in red, a success would be colored in green. 03:25.320 --> 03:27.330 So that's what I'm going to go for there. 03:27.330 --> 03:29.820 So where are we going to use these toasts. 03:29.820 --> 03:38.100 Well we're going to go to our central place, the base API TS and where we've got our check to see if 03:38.100 --> 03:41.730 we've got an error, any errors that come back from our API. 03:41.760 --> 03:49.200 We're going to use this condition to check what kind of error it is, and then do something based on 03:49.230 --> 03:50.220 that error. 03:50.220 --> 03:56.250 So instead of this console.log here that's below this we'll add a switch. 03:56.820 --> 04:01.760 So let's use the switch statement snippets and we can give it a key. 04:01.760 --> 04:04.610 And the key is going to be on the status. 04:04.700 --> 04:11.690 And in the case of a 400 then we can specify toast dot error. 04:11.690 --> 04:15.290 And we can pass in the data as the error message. 04:15.290 --> 04:21.710 And we've got a warning here saying argument of type unknown is not assignable to parameter of type 04:21.740 --> 04:23.030 toast content. 04:23.330 --> 04:29.120 Our toast expects a string and it doesn't know what format this data is in, but it should be a string, 04:29.120 --> 04:32.720 so we can just specify as string to take away the warning there. 04:32.750 --> 04:40.910 Now, I know based on how we saw the format of this 400 error in the logs, this is not going to do 04:40.940 --> 04:42.260 what we expect it to do. 04:42.710 --> 04:50.540 And in fact, I'm just going to add back in the console dot log the status and the data, because I 04:50.540 --> 04:56.240 think we're going to need to go and take a look at what we do get back from this, and in fact, not 04:56.240 --> 04:57.260 the object there. 04:57.260 --> 05:01.060 I'm actually going to console dot log the results dot Don't error. 05:01.060 --> 05:07.960 I want to take a look at the whole object of what happens when we encounter an error in RTK query, 05:07.960 --> 05:09.580 and just for comparison. 05:09.580 --> 05:11.110 So we've got something to compare it to. 05:11.140 --> 05:13.330 I'm just going to add the case of a 401. 05:13.480 --> 05:21.820 I'm going to add the total error and again say data as string because that one didn't have. 05:21.850 --> 05:26.980 And I'm missing a semicolon at the end there because the 401 didn't have the same parsing error that 05:26.980 --> 05:27.730 we saw before. 05:27.730 --> 05:32.980 And I'll just add a break statement there and that should be fine. 05:33.010 --> 05:33.370 Okay. 05:33.400 --> 05:35.590 So that gives us enough to start testing with. 05:35.590 --> 05:39.370 So let's head back to the browser and go back to our application. 05:39.370 --> 05:41.230 I'll just refresh the page. 05:41.380 --> 05:47.590 And first of all, if we click on the test 400, error doesn't seem to happen or we certainly don't 05:47.590 --> 05:49.090 see the toast I should say. 05:49.090 --> 05:52.990 And if I click on the test 401 error, we still don't see the toast. 05:52.990 --> 05:59.620 But I have forgotten to add something crucial into our main TSX where we added the toast provider. 05:59.740 --> 06:04.380 This does come with CSS that we need to include in our application. 06:04.380 --> 06:07.530 So below the toast container I'm just going to import. 06:07.560 --> 06:12.090 And we need react dash testify forward slash dist. 06:12.090 --> 06:13.560 And that's interesting. 06:13.560 --> 06:15.630 It used to come from a dist folder. 06:15.630 --> 06:21.630 But my intellisense here or autocomplete is telling me it comes from somewhere else. 06:21.630 --> 06:27.120 So this is going to be one of those few occasions where I want to double check what's going on in node 06:27.120 --> 06:34.830 modules to see the physical file path of the CSS, because VSCode is telling me one thing, and previously 06:34.830 --> 06:37.710 this was in a different location, this CSS file. 06:37.710 --> 06:43.680 So I'm just going to go into node modules huge folder and find react testify. 06:44.040 --> 06:52.080 And sure it is in a dist folder and it's in the dist folder we need to get the CSS from. 06:52.080 --> 07:01.700 So VSCode is wrong, my notes are correct and I need to specify forward slash dist Fast forward slash. 07:02.330 --> 07:06.920 And then we're going to use react to defeat CSS there. 07:07.280 --> 07:07.670 Okay. 07:07.700 --> 07:10.640 So let's go back to the browser and give this another go. 07:11.240 --> 07:16.250 I was expecting a problem with the 400 error one anyway and not display the toast. 07:16.250 --> 07:20.150 And if I do the 401 error then I'm still not seeing the toast. 07:20.150 --> 07:22.730 But if I go and take a look at the data. 07:22.730 --> 07:27.860 Well, data is an object and our toast cannot handle an object. 07:27.860 --> 07:28.700 It has to be a string. 07:28.700 --> 07:30.350 So we need to go and get the title from this. 07:30.350 --> 07:32.840 So one more trip back to VS code. 07:32.840 --> 07:37.940 And this needs to be data dot title and not as string. 07:37.940 --> 07:39.680 And we're getting some warnings here. 07:39.680 --> 07:44.060 So we've got some TypeScript shenanigans that we need to deal with with this. 07:44.060 --> 07:46.310 But this should still work even with the warning. 07:46.310 --> 07:49.010 It's just telling us that data is unknown. 07:49.010 --> 07:53.600 So we've got some TypeScript stuff to deal with here with how the responses are coming back from our 07:53.600 --> 07:53.960 API. 07:53.990 --> 07:56.180 But this should work regardless of the warning. 07:56.360 --> 07:57.590 So let's give this another go. 07:57.590 --> 08:03.190 If I test the 401 error, then this time I do see the unauthorized popping in. 08:03.580 --> 08:06.850 But if I check the 400 error, then what do we see? 08:06.880 --> 08:07.720 Nothing. 08:07.750 --> 08:13.180 Okay, so we've got some work to do here, but we can confirm, at the very least, that our test package 08:13.180 --> 08:14.500 is working. 08:15.040 --> 08:19.210 What we'll need to look at next is this status of parsing error. 08:19.690 --> 08:24.520 And what we get back from react query for this particular type of error. 08:24.520 --> 08:29.290 And we're going to need to do some TypeScript jiggery pokery to get this to work. 08:29.320 --> 08:34.330 So if we take a look at what we've got coming back for the 400, let's just take a quick look at how 08:34.330 --> 08:41.620 we can deal with this, because this is what we're logging out for the resulting error in our base API 08:41.620 --> 08:42.460 query. 08:42.490 --> 08:43.690 So we've got the data. 08:43.690 --> 08:44.680 That's fine. 08:44.800 --> 08:49.000 We've got the error saying that this is not valid JSON. 08:49.000 --> 08:51.190 And we've got a status of parsing error. 08:51.190 --> 08:54.310 But we do have the original status of 400. 08:54.310 --> 08:56.830 So we could use that to check. 08:56.830 --> 09:03.160 And if it is the original status of 400, then we can use a combination of that number and the data 09:03.160 --> 09:05.050 to get the result that we're looking for. 09:05.080 --> 09:10.210 So let's just head back to VS code and make another small change inside here just to correct that particular 09:10.210 --> 09:10.930 issue. 09:11.410 --> 09:17.080 And instead of using const and destructuring the status and the data inside here let's do something 09:17.080 --> 09:18.010 slightly different. 09:18.040 --> 09:29.140 So I'm going to say const original status equals results dot error dot status is equal to passing error. 09:29.440 --> 09:35.530 And we have a result dot error dot original status. 09:35.560 --> 09:43.780 If both of those conditions are true then we'll just use a ternary and we'll say results dot error dot 09:43.810 --> 09:45.370 original status. 09:45.670 --> 09:47.950 Because we don't want the status with passing error. 09:47.950 --> 09:50.260 We want the 400 contained there. 09:50.290 --> 09:59.050 Otherwise we don't have a passing error and we can set the original status to result dot error dot status. 09:59.380 --> 10:07.770 And then instead of using status here, we can use the original status as we've got it above and we 10:07.770 --> 10:10.080 can get the data. 10:10.110 --> 10:20.520 So just above the switch there I'm going to say const response data equals result dot error dot data. 10:20.520 --> 10:26.040 And then I will use the response data inside here. 10:26.040 --> 10:31.980 And for the 401 instead we'll use response data dot title. 10:32.010 --> 10:35.430 We're still going to have the same warning but it should have the correct functionality now. 10:35.430 --> 10:37.110 So let's just go back take a look. 10:37.140 --> 10:38.430 I'll just refresh the page. 10:38.430 --> 10:44.430 What we should find is we get the toast for the bad request, correctly saying this is not a good request, 10:44.430 --> 10:49.680 and we should still have the 401 error functionality working as well. 10:49.680 --> 10:50.430 So great. 10:50.430 --> 10:52.410 But we've got a bit of awkward code in here. 10:52.410 --> 10:57.720 We've got a TypeScript warning, and we're going to need to enhance our usage of TypeScript here to 10:57.750 --> 10:58.980 handle this a bit better. 10:58.980 --> 11:01.260 And we'll take a look at that next.