All right.
And now it's set up the entire functionality, and this is going to be the case since there's so many
similarities.
There will be copying, purchasing.
I really don't see the point of setting up everything from scratch.
If you take a look at the register of the register, use their function.
You'll notice that the only difference is the dispatch type, meaning in there we use a register and
then the URL and the same is going to be in the reducer where instead of action type register, we go
with a login.
And then when it comes to the user, we just change here the alert text.
And I really don't see the point of typing everything from scratch because I do believe that when we
were setting up register, I spent quite enough time on explaining every small detail.
So let's go to our app context and we simply want to grab this register one.
And you're not just going to grab everything that I have inside of the function body.
So I want to do any renaming here.
So I'm going to copy and paste.
And again, we are looking for these three dispatchers.
And again, I'm going to do that using my cursor, and we're just going to look for a log in one.
That's step number one.
Van, we want to change this one around where it's not going to be a register.
It's going to be a login.
We're still passing in the current user.
So it is still post request and it's going through our backend that stays the same.
And here, though, we already know that there's a giant object and I'm just looking for the data,
correct?
So I don't need to go with that response.
Now, I also don't want to log it.
Like I said, that was just with our initial request.
I pull out user token and location, and I want to dispatch login user success.
And what is the payload?
Same user token and location.
I want to add it right away to a local storage because it's important for me when it comes to a page
refresh.
So I want to access those values and I don't want a logged response here.
That said, again, we did that with our first request.
And then when it comes to payload, we go to message and again, the arrow is going to be sitting in
our response data and message.
No, well, test out some error responses as well.
Clear alert.
Why?
Well, because we set up the alert and it's my preference to remove it.
Let's save this and I'll go to our producer.
Let's keep on scrolling where we have registered user begin and error.
Let's copy and paste all three of them.
And don't worry, the future functionality is not going to be just copying thing.
But this is the case where I definitely don't see the point of setting up everything from scratch.
So let's select all three of them.
What are we looking for?
We're looking for a log in one, correct?
Now, when we start fetching, what do we do?
We go.
Is loading.
True.
We set up the loading ramp.
If we're successful, what are we doing?
Is loading false?
One token user user location, driver location.
They get the same values.
Charlotte is true.
So we're successful.
The only thing that we can change is the string here.
Correct.
And I believe I went with log in, successful excel.
So if you want, you're going to retype it in my case or saved myself a little bit of time and copy
and paste.
So again, I'm still saying redirecting because the user will be redirected to the dashboard.
Why?
Because we set up the user.
Initially, there's going to be no user and then we add it to the state and remember user fact.
Well, we were checking for that user, correct.
And as far as the error?
Well, same deal as lowering false color.
True and then alert type will be danger instead of the success.
So let's try it out.
I mean, everything should work because we already tested everything in a manner.
So let me navigate here.
Let me make sure that there's nothing in the local storage.
So we start from scratch here.
Yep, there are no values over there.
And then let's go then some type of user that you already have.
In my case, not as John.
And then I'm going to go with my secret one.
So once I added notice how everything is correct, so we add that to the local storage.
We also add the user to our context.
So now I have the user token and all that.
In this case, yeah, we do have a few more properties, but it's not a big deal, as well as user location
and geolocation.
And then because of our user effect, we check for the user.
And if the user exists, then beautiful, we navigate to a dashboard page.
Now let's also test out the error.
So in my case, when I go back to.
Application, again, I want to remove it, because remember, we have to set up enregistre if there
is a user will navigate away.
That's our setup.
And therefore, since we don't have to log on functionality yet, I'm going to remove it from my local
storage.
Basically, refresher so I don't have anything in the state as well.
And then let's go back to the register and let's try out the error.
So let's go here with John at gmail.com and I'm going to mess up my password.
So let's say I'll add one extra character and what do I c order invalid credentials?
Now, if I'll fix the error and I'll provide the correct password, then we should see logging successful
redirecting.
And then again, in whatever seconds, we'll get to the dashboard page and that's how we can set up
log in functionality in our application.