Okay.
So we do have some basic validation in here.
But we did install Zod for a reason and that's to take advantage of its validation functionality.
So let's go take a look at using that in our form.
And we'll also complete the functionality to submit this to the server as well.
So in order to use Zod then we give our use form some options.
And inside the parentheses here we'll just open curly brackets and move on to the next line.
We can give this a mode.
And currently the mode that it runs in, it only validates when we submit our form.
But we can change that to untouched.
And that means if we touch the inputs and move out then validation will kick in.
And we'll also add a resolver and we'll add a colon.
And here we can use the Zod resolver that we get from hook form resolvers.
Zod.
So do make sure we bring that in.
And then we can give this its argument of the login schema.
And this will take care of validating our input fields.
So that means we do not need the required validation here that can be removed.
And we can also do the same for the password as well.
And just leave it to Zod to handle the validation here.
If we go back and take a look, then what we should find, if we click in and click out, we can see
we've got an invalid email this time, and we've got our validator for the password that says it must
be at least six characters.
So if I start typing test@test.com, then only when I've got a valid email will we pass the validation.
And the same with the password as well.
Only when we meet the validation requirements can we submit the form.
And sure enough, now we can see what we have inside those fields.
So that's great.
We've got validation working.
So now let's hook it up to our API server.
And let's head back to VS code.
And let's use the hook that we generated from our account API.
So I'll specify const open square brackets I'm going to call this just simply login and open curly brackets.
And we can use the isloading that we get from our hook.
And we'll say also use login mutation.
And we've got two different options for loading, by the way.
We can use the one that we get from form state with our form.
Or we could use the one that we get from here as well.
Either way is going to do the same thing.
It's going to effectively let us know in our component if loading is taking place, but I'm just going
to use the one from the login mutation for this example.
And then we've got our method login which will allow us to of course log in.
So we'll make this an async function because we're making a request to our API.
And we need to wait for the response.
And I'll replace console log data with await and say login and pass up the data.
Now what we can also do because we now have a type for our login schema, we can also go across to our
account API and give it the appropriate type inside here as well.
So instead of just objects we can use as the type, the login schema doesn't make any difference.
We didn't have a type problems in there anyway, but it's just a bit more correct because that is what
we're receiving into the argument for our login method.
So back to our login form then.
And we've got the is loading the buttons we're using from material UI do not have a loading property
as such.
But what we can do we can just disable the button to prevent it being clicked on whilst loading is taking
place.
So it's kind of an indicator in itself that something is happening.
But because we've got centralized loading indicators, we're also going to see the loading bar at the
top as well.
So with that in place, we should be able to go test.
Now we haven't done anything with our user interface after a user is logged in.
So please keep the expectations quite low about what it is we're going to see after we are successfully
logged in.
But let's put in Bob at test.com into the email with the correct password first of all, and we'll click
sign in.
We should see the button being disabled and the loading indicator and everything looks like it worked.
And if I click on the network tab and we take a look and let's see I've got the fetch enabled there.
Let's just clear this window and I'll click sign in again so we can see actually what's going on.
And we can see our login has taken place.
And we get the 200 okay.
And what we should also see inside our application cookies is we've got our cookie being returned from
our API and being set in the browser.
Now the way that we have everything configured, then this cookie is going to go up with every single
request.
So our API is going to be able to authenticate this request.
So what happens if we do not send up a good password.
So let's just change this or add a character on so that password will not match what's in our database.
I'll click sign in.
And what we should see is the unauthorized.
That's fine.
If they put in a bad password or a bad username, then that is what we would expect to see.
They're not authorized to log in with those credentials.
So after a user has logged in, I would like something to happen.
I'd like them to be redirected away from the login form, of course.
And I'd also like to update the navbar once they have successfully logged in as well.
And we'll take a look at the approach we're going to use for that next.