WEBVTT 00:00.000 --> 00:00.270 Okay. 00:00.300 --> 00:02.460 So we do have some basic validation in here. 00:02.460 --> 00:08.220 But we did install Zod for a reason and that's to take advantage of its validation functionality. 00:08.250 --> 00:11.430 So let's go take a look at using that in our form. 00:11.430 --> 00:16.530 And we'll also complete the functionality to submit this to the server as well. 00:16.560 --> 00:21.660 So in order to use Zod then we give our use form some options. 00:21.660 --> 00:28.020 And inside the parentheses here we'll just open curly brackets and move on to the next line. 00:28.020 --> 00:29.130 We can give this a mode. 00:29.130 --> 00:34.260 And currently the mode that it runs in, it only validates when we submit our form. 00:34.260 --> 00:37.140 But we can change that to untouched. 00:37.140 --> 00:42.900 And that means if we touch the inputs and move out then validation will kick in. 00:42.900 --> 00:46.800 And we'll also add a resolver and we'll add a colon. 00:46.800 --> 00:53.010 And here we can use the Zod resolver that we get from hook form resolvers. 00:53.040 --> 00:53.430 Zod. 00:53.430 --> 00:55.590 So do make sure we bring that in. 00:55.590 --> 01:00.030 And then we can give this its argument of the login schema. 01:00.060 --> 01:03.450 And this will take care of validating our input fields. 01:03.450 --> 01:10.160 So that means we do not need the required validation here that can be removed. 01:10.310 --> 01:14.660 And we can also do the same for the password as well. 01:14.660 --> 01:17.810 And just leave it to Zod to handle the validation here. 01:17.840 --> 01:23.150 If we go back and take a look, then what we should find, if we click in and click out, we can see 01:23.180 --> 01:28.940 we've got an invalid email this time, and we've got our validator for the password that says it must 01:28.940 --> 01:30.680 be at least six characters. 01:30.680 --> 01:40.430 So if I start typing test@test.com, then only when I've got a valid email will we pass the validation. 01:40.430 --> 01:43.100 And the same with the password as well. 01:43.100 --> 01:46.790 Only when we meet the validation requirements can we submit the form. 01:46.790 --> 01:51.410 And sure enough, now we can see what we have inside those fields. 01:51.470 --> 01:52.550 So that's great. 01:52.550 --> 01:54.230 We've got validation working. 01:54.260 --> 01:56.660 So now let's hook it up to our API server. 01:56.660 --> 01:58.160 And let's head back to VS code. 01:58.160 --> 02:04.760 And let's use the hook that we generated from our account API. 02:04.790 --> 02:11.270 So I'll specify const open square brackets I'm going to call this just simply login and open curly brackets. 02:11.270 --> 02:15.170 And we can use the isloading that we get from our hook. 02:15.200 --> 02:18.650 And we'll say also use login mutation. 02:18.650 --> 02:21.320 And we've got two different options for loading, by the way. 02:21.320 --> 02:26.150 We can use the one that we get from form state with our form. 02:26.210 --> 02:29.120 Or we could use the one that we get from here as well. 02:29.120 --> 02:30.800 Either way is going to do the same thing. 02:30.800 --> 02:36.860 It's going to effectively let us know in our component if loading is taking place, but I'm just going 02:36.890 --> 02:40.400 to use the one from the login mutation for this example. 02:40.400 --> 02:45.470 And then we've got our method login which will allow us to of course log in. 02:45.470 --> 02:49.940 So we'll make this an async function because we're making a request to our API. 02:49.940 --> 02:51.920 And we need to wait for the response. 02:51.920 --> 03:00.260 And I'll replace console log data with await and say login and pass up the data. 03:00.440 --> 03:07.430 Now what we can also do because we now have a type for our login schema, we can also go across to our 03:07.430 --> 03:11.810 account API and give it the appropriate type inside here as well. 03:11.810 --> 03:20.690 So instead of just objects we can use as the type, the login schema doesn't make any difference. 03:20.690 --> 03:25.300 We didn't have a type problems in there anyway, but it's just a bit more correct because that is what 03:25.300 --> 03:28.360 we're receiving into the argument for our login method. 03:28.360 --> 03:30.250 So back to our login form then. 03:31.180 --> 03:37.090 And we've got the is loading the buttons we're using from material UI do not have a loading property 03:37.090 --> 03:38.200 as such. 03:38.200 --> 03:43.720 But what we can do we can just disable the button to prevent it being clicked on whilst loading is taking 03:43.720 --> 03:44.230 place. 03:44.230 --> 03:48.100 So it's kind of an indicator in itself that something is happening. 03:48.100 --> 03:53.530 But because we've got centralized loading indicators, we're also going to see the loading bar at the 03:53.530 --> 03:54.970 top as well. 03:55.000 --> 03:58.450 So with that in place, we should be able to go test. 03:58.480 --> 04:02.380 Now we haven't done anything with our user interface after a user is logged in. 04:02.380 --> 04:08.440 So please keep the expectations quite low about what it is we're going to see after we are successfully 04:08.440 --> 04:08.830 logged in. 04:08.830 --> 04:16.360 But let's put in Bob at test.com into the email with the correct password first of all, and we'll click 04:16.360 --> 04:16.900 sign in. 04:16.900 --> 04:22.360 We should see the button being disabled and the loading indicator and everything looks like it worked. 04:22.390 --> 04:31.030 And if I click on the network tab and we take a look and let's see I've got the fetch enabled there. 04:31.060 --> 04:37.240 Let's just clear this window and I'll click sign in again so we can see actually what's going on. 04:37.240 --> 04:40.270 And we can see our login has taken place. 04:40.570 --> 04:42.610 And we get the 200 okay. 04:42.610 --> 04:48.520 And what we should also see inside our application cookies is we've got our cookie being returned from 04:48.520 --> 04:51.970 our API and being set in the browser. 04:52.000 --> 04:57.370 Now the way that we have everything configured, then this cookie is going to go up with every single 04:57.370 --> 04:57.910 request. 04:57.910 --> 05:01.630 So our API is going to be able to authenticate this request. 05:01.630 --> 05:05.170 So what happens if we do not send up a good password. 05:05.170 --> 05:10.570 So let's just change this or add a character on so that password will not match what's in our database. 05:10.570 --> 05:11.650 I'll click sign in. 05:11.650 --> 05:14.980 And what we should see is the unauthorized. 05:15.130 --> 05:15.970 That's fine. 05:15.970 --> 05:20.440 If they put in a bad password or a bad username, then that is what we would expect to see. 05:20.470 --> 05:23.440 They're not authorized to log in with those credentials. 05:23.440 --> 05:27.730 So after a user has logged in, I would like something to happen. 05:27.730 --> 05:31.030 I'd like them to be redirected away from the login form, of course. 05:31.030 --> 05:36.190 And I'd also like to update the navbar once they have successfully logged in as well. 05:36.190 --> 05:39.670 And we'll take a look at the approach we're going to use for that next.