-: In the last section, we added a whole bunch
of code without being really clear
about exactly what we were doing and why.
So I want to take a second just to clarify
on exactly what we were doing in the last section
and all the different code that we added.
So I'm gonna pull a diagram on the screen
very similar to one that we
were looking at earlier.
It's just illustrating what we want to do
when the user enters the correct
authentication info.
So, if they do not enter the correct info,
we want to show them an error message
which we're going to eventually do
by updating the error piece of
state inside of our auth reducer.
Then our sign-in form can just show
that error message that we
get back from the server.
And poof, there's our error handling.
In the case that a user does enter
the correct information, we want to
dispatch an action to flip the
authenticated piece of state to true.
And so that's what what's gonna tell the rest
of our application,
'Hey, they just enter the correct info here.
They are currently authenticated.
Everything is good to go.'
Notice that we don't really have to store the JWT
on our application state.
No part of our application
really needs to make use of the JWT.
The only thing that really does is Axios when
we go to make an ajax request
cuz remember we set up our servers
authentication to work by looking for
JWT in the header of any request.
So we don't really need to store the JWT inside
of our application state.
Instead, we just store this Boolean that says
whether or not they are currently authenticated.
The second thing we need to do is navigate the
user to slash feature.
And finally we need to,
and this is the part we haven't done yet,
we need to actually save the JWT token
for future requests.
And we're definitely gonna talk about, you know
you might be thinking, 'Hey Steven
can't people just kind of go into their JavaScript console
and somehow flip authenticated to true?'
And the answer to that is yes, absolutely.
And you might be thinking,
'Isn't that a security hole?'
Well, uh, not, not quite
but that is a topic that we will
talk about very soon.
So hold that thought.
So again, we need to accomplish these
three features here
or these three kind of actions.
Let's walk through the code that we added
in the last section to dispatch the action to
flip the authenticated piece of state to true.
So back in the code editor, I'm not gonna go
through the code in the order that we added it.
Instead I'm gonna go through in the order
that the code is actually going to execute.
So whenever we call the sign-in
user action creator, we're going to return
a function that's going to be automatically
called by the redux thunk middleware.
And the redux thunk middleware is gonna
call that function with the dispatch method.
We make our ajax request
attempting to sign our user in.
If the request is successful,
and so if it returns a like 200 in response
or 204 depending on how our server is responding
we're gonna hit, hit our then case.
So everything inside of our then case means hey
the user was just successfully authenticated
on the back end.
So we need to respond to that by
doing our three very good things.
The first thing that we're gonna do is update our
state to indicate that the user
is currently authenticated.
So we immediately dispatch an action
of type auth user.
This is redux thunk in action right here.
Again, we've got direct access
to the dispatch method.
It is the all powerful function
within redux that gives us total control
over the redux pipeline.
If we call it and we pass an action in
that is the exact same as when we
had previously been calling an action creator
and returning just a plain object as an action.
In this case, however,
we don't really get the benefit
of being able to kind of return an action
from inside this promise in
any meaningful way, right?
If I return something in here,
if I return an object, it's not gonna end
up being what gets returned from sign-in user.
No. The function gets returned from sign-in user.
So instead at this point, to dispatch an action
we have to call the dispatch method directly.
We set up our auth reducer inside
of auth reducer JS
to handle an action of type auth user right here.
Whenever we got that action of type auth user,
we flipped our authenticated flag to true.
We also set up a case in here to handle
unauthenticated user or helping them log out
by flipping that authenticated flag to false.
Going back over to our action creators file,
we've not yet done the logic for
saving our GWT token.
So we're gonna handle that
inside the next section.
The third thing that's happening is we are
redirecting our user to the route slash
feature right here.
And so we are doing that navigation
by using the browser history object
and pushing a new route onto the stack.
So this push method right here is what does some forcible
or programmatic navigation for our users.
Okay, so nice little quick review.
Again, I know that we're kind of approaching this
on many different fronts at once
but unfortunately it's kind of a
unavoidable aspect of authentication
to have to kind of juggle a bunch of
different topics at the same time.
So in the next section we're gonna continue being
productive, writing some code.
We need to save our JWT token.
We also need to handle,
whenever our request is bad,
we need to show an error to our user.
So we'll take care of that very soon as well.
So let's continue in the next section
by working with our JWT token.
I'll see you there.