WEBVTT 00:00.020 --> 00:05.360 Okay, now let's take a look at what happens when we encounter a server side error that we cannot check 00:05.360 --> 00:06.590 on the client side. 00:06.590 --> 00:08.990 So I'm just going to log out of this user. 00:09.290 --> 00:15.380 And this should take us back to the home page and remove the user or the user menu from the top right. 00:15.380 --> 00:17.480 And let's click on the register button. 00:17.480 --> 00:22.580 And let's try and log in with Bob or Register I should say Bob at test.com. 00:22.580 --> 00:24.590 And I'll give a valid password. 00:24.590 --> 00:29.000 And if we try and register then what's going to happen. 00:29.000 --> 00:31.070 Well nothing. 00:31.070 --> 00:32.510 We haven't got the success. 00:32.510 --> 00:38.480 So we know it failed, but we didn't notify the user that something's not quite right here. 00:38.690 --> 00:43.550 And if we take a look at the console, do we get any errors inside here when we do this. 00:43.580 --> 00:44.900 Well let's take a look. 00:44.930 --> 00:47.900 And we can see that we do have errors in the console. 00:47.900 --> 00:49.760 We've got a 400 bad request. 00:49.760 --> 00:54.590 And we can see that the error is available from somewhere. 00:54.620 --> 00:57.890 Saying that username Bob at test.com is already taken. 00:57.890 --> 01:03.360 And we get that information in the Account API and in the base API. 01:03.390 --> 01:07.650 Actually, we're logging it out there as well, but we don't get it in our component where it would 01:07.680 --> 01:12.060 be useful to show that information to the user, of course. 01:12.120 --> 01:16.020 And let's go and take a look at our code that we're using in the register form. 01:16.020 --> 01:17.370 And for the submit. 01:17.370 --> 01:19.080 We're not doing any error handling in here. 01:19.080 --> 01:21.300 So let's add a try. 01:21.330 --> 01:29.640 Catch inside here and see if we can log the error at least and get it from the component itself. 01:29.640 --> 01:33.210 And I'll just console log the error here. 01:33.210 --> 01:40.050 And if we go back to the browser and we try and repeat that behavior and use Bob at Test.com again with 01:40.050 --> 01:45.630 a valid password that meets the complexity requirements, then we don't see anything coming back to 01:45.660 --> 01:46.800 our register form. 01:46.830 --> 01:51.420 Actually, this is all coming from our account API or our base API, but our console log. 01:51.450 --> 01:53.220 Well, that didn't make it to our form. 01:53.220 --> 01:56.250 That's being caught and handled elsewhere. 01:56.250 --> 02:00.300 So it doesn't make it all the way into our register component. 02:00.300 --> 02:06.710 So let's go back to the account API and where we've got our register where we've got the on query started. 02:06.710 --> 02:08.420 We are catching the error here. 02:08.420 --> 02:12.980 But we also need to throw this back to our component. 02:12.980 --> 02:15.530 So we'll also throw the error. 02:15.530 --> 02:20.420 And if we go back to our browser and just test to make sure that we do have access to the error, because 02:20.420 --> 02:24.110 that will be a requirement for what we need to do with the error. 02:24.140 --> 02:31.430 Then this time we can see that we're still getting nothing from our register component. 02:32.180 --> 02:32.510 Hmm. 02:32.540 --> 02:33.320 Interesting. 02:33.320 --> 02:38.540 So let's go back to our browser again and in our register form. 02:38.810 --> 02:44.900 Then when we use this await register user, we need to use the unwrap functionality so that we do get 02:44.930 --> 02:50.330 access to the response coming back from our query. 02:50.360 --> 02:57.680 And now if we try this one more time, what we should see if I use Bob at test.com and password again, 02:58.430 --> 03:02.220 what we should see is the register form now displaying the error. 03:02.220 --> 03:04.200 And we can see this in the message here. 03:04.230 --> 03:08.010 Email bob at test.com is already taken, etc. etc.. 03:08.280 --> 03:12.060 Now we've got something that we can handle inside our register form. 03:12.060 --> 03:17.010 So let's go back to the register form and we can use something that we get from react hook form. 03:17.010 --> 03:21.780 We can also set errors inside our form states as well. 03:21.780 --> 03:28.740 And then we can use them from our form state errors and display the helper message in the field that's 03:28.740 --> 03:30.270 relevant to the error. 03:31.050 --> 03:33.840 So we know that we're getting an error related to the email. 03:33.840 --> 03:35.250 We're also getting it from the username. 03:35.250 --> 03:39.630 But since that's the same property we're using, we're going to ignore that one and just use the one 03:39.630 --> 03:41.010 from the email. 03:41.010 --> 03:45.450 So inside the catch then let's make use of what we get back. 03:45.870 --> 03:51.720 And I'm going to say const API error equals and error. 03:51.930 --> 03:59.790 But we're going to specify as because we saw this coming back in an object with a message property which 03:59.790 --> 04:00.810 was a type of string. 04:00.810 --> 04:00.820 strings. 04:00.820 --> 04:04.810 So let's give it that type and we'll say if API. 04:04.840 --> 04:06.580 Errormessage. 04:07.330 --> 04:18.130 And the type of API Errormessage is equal to a string. 04:19.300 --> 04:22.060 Then we'll do something with that error. 04:22.690 --> 04:29.110 Now we want this to be an array, because this API error is coming back as a string with a comma separated 04:29.110 --> 04:30.250 list of values. 04:30.250 --> 04:38.260 So we'll create a const called error array equals and we'll use API Errormessage dot split. 04:38.500 --> 04:41.200 And we'll use in quotes a comma. 04:41.200 --> 04:48.340 And now that we have this as an array we can use the error array and use for each. 04:48.370 --> 04:50.740 And we'll just specify E for error. 04:52.390 --> 04:56.620 Add the arrow and we'll check to see what kind of error it is. 04:56.650 --> 05:02.640 And we'll check to see if e includes And in quotes, the password. 05:02.640 --> 05:08.310 That's going to be one of the keys of the properties that our API can send back. 05:08.310 --> 05:09.690 We saw that before in postman. 05:09.690 --> 05:14.520 When we received an error response, we saw that we had the password validation inside there. 05:14.520 --> 05:18.720 And then we can use the set error and we can specify the fields. 05:18.720 --> 05:21.030 In this case it's going to be the password field. 05:21.030 --> 05:27.180 And then we can use the message property that we have from our error and set it to E. 05:27.360 --> 05:33.870 And we'll add an else if because we'll also handle the email type of error in here as well. 05:33.870 --> 05:40.980 And because it's an else if I need to specify the E includes and we're going to look for email inside 05:40.980 --> 05:41.670 here. 05:42.540 --> 05:45.510 And then we'll use the set error once again. 05:45.870 --> 05:52.290 And this time we'll target the email property, open curly brackets and we'll specify the message and 05:52.320 --> 05:52.650 E. 05:52.950 --> 06:00.150 So if we go and repeat the behavior that we just looked at, then what we should find is that this functionality 06:00.150 --> 06:04.090 is going to give us our API server side validation inside there. 06:04.090 --> 06:07.150 So let's go take a look and see what happens. 06:07.150 --> 06:10.360 If I once again try and repeat the behavior I looked at before. 06:10.360 --> 06:15.490 So I'll say Bob at test.com with the password and I'll press return. 06:15.490 --> 06:22.630 And what we should find this time is that email Bob at test.com is already taken perfect. 06:22.630 --> 06:25.810 That's the functionality we're looking for. 06:25.810 --> 06:29.110 We should also have the password functionality as well. 06:29.110 --> 06:32.020 But we've got Zod taking care of that kind of validation. 06:32.020 --> 06:36.970 But let's just give it a quick test to make sure that it's doing what we'd expect it to. 06:37.000 --> 06:41.800 So if we go back to our register schema, then let's comment out. 06:42.490 --> 06:52.000 Or just to make it easy, I'll copy this and paste it below, then comment out the password above and 06:52.000 --> 06:55.480 I'll take out the regex stuff. 06:55.480 --> 07:00.780 So we're only going to check to make sure it's a string, and that will pass password validation on 07:00.780 --> 07:03.630 the client side, but of course we'd expect it to fail. 07:03.660 --> 07:04.560 On the server side. 07:04.560 --> 07:14.250 So if I say bob@test.com again and use a weak password like let me in or whatever, whatever's a weak 07:14.250 --> 07:16.200 password and try and click register. 07:16.200 --> 07:23.250 Then this time we get the password must have at least one non-alphanumeric character. 07:23.340 --> 07:28.590 So even though this returns more than one error, we can only actually set one error at a time inside 07:28.590 --> 07:29.070 here. 07:29.070 --> 07:30.870 So they'd get this error back. 07:30.900 --> 07:37.860 Then they'd if they still tried to use a weak password, but with one non-alphanumeric character. 07:37.860 --> 07:39.270 So I use pass. 07:39.300 --> 07:40.710 Let me in one, for instance. 07:40.710 --> 07:43.020 Then we'll probably get a different kind of error back. 07:43.020 --> 07:45.750 Or in this case it's looking for a special character. 07:45.960 --> 07:47.880 So I'll try adding a special character. 07:47.880 --> 07:50.790 Then we should see a different error coming back from here. 07:50.790 --> 07:55.860 So now it tells us we need at least one uppercase, etc. so that functionality is working as well. 07:55.860 --> 07:58.710 But obviously that's not the approach we'll take. 07:58.740 --> 08:02.050 We'll catch that on the client side because we can. 08:02.230 --> 08:07.540 The email, whether or not this is a duplicate email, we cannot tell from the client side that has 08:07.540 --> 08:12.100 to go to the server for the server to say, nope, that email address is already taken. 08:12.100 --> 08:12.790 So great. 08:12.790 --> 08:17.590 That's how we handle the server side validation in our client side. 08:17.620 --> 08:19.990 Now one more task to go to do with identity. 08:20.020 --> 08:20.680 Just now. 08:20.680 --> 08:24.280 We will come back to it as we progress through building this application. 08:24.280 --> 08:30.730 But the one more task that we're going to look at before we move forward is the fact that I can get 08:30.730 --> 08:35.410 to, and I'll need to add something to my basket first to be able to demonstrate this. 08:36.400 --> 08:42.070 It's the fact that I can get to my basket and click checkout and see this page without being logged 08:42.070 --> 08:42.550 in. 08:42.550 --> 08:45.850 We need to take a look at how we can. 08:46.450 --> 08:52.240 I'm going to loosely say add some kind of security into our client side app so that we prevent this 08:52.240 --> 08:55.690 behavior and we redirect them to the login page if they are not logged in. 08:55.690 --> 08:58.900 When they try to get to this area of our application. 08:58.900 --> 09:01.300 And we'll take a look at that next.