-: Our applications definitely still
has one big deficiency to it.
If I click the sign in link
and then I sign in
I can now get access to my feature route
and I can even see inside of my console
I can check local storage for my token.
And yep, sure enough, my JWT token is definitely here
so I'm definitely considered to be logged in
at this point in time.
Now let's do something a little bit interesting
something that definitely our users
will be doing all the time.
I'm gonna refresh the page
and all of a sudden I get kicked back to the root route
and my header has now changed to say sign in and sign up.
So I'm definitely no longer considered
to be authenticated inside our application.
Let's see, I still got the token around
so I kinda have a reasonable expectation
that I should be signed in.
But our application really has absolutely
no logic to say, "Hey, if the user has a token
they're probably still authenticated.
We should consider them to be signed in."
So the key here is that we're going to consider
the existence of a token to mean
that the user should be signed in.
And when we say signed in, or you know
when we say signed in
what I really mean is we should show them
like the sign out button here
and they should also have access
to the feature route as well.
So when our application first boots up
we need some way of checking to see
whether or not the user is currently,
currently has a token saved.
And if they do, we need to make sure
that we update our application state to say,
"Yes this person is now authenticated."
So let's give it a shot.
The key is that we want to make this check
and we want to kind of update our state
before anything has been rendered to the DOM.
Because by the time something has been rendered to the DOM
we might have already tried rendering
the require off or the feature route here,
which would've already navigated
the user back to the root route.
So we can't just kind of stash something
inside of a component will mount and assume,
"Hey, like this is gonna take care of everything for us."
Because by the time that something
is about to be rendered to the DOM,
it's probably already too late to log a user in
in a way that's gonna have a really meaningful effect.
So instead what we have to do
is somehow update our application state
before we start to render anything at all.
In other words, we want to dispatch an action
to our AUTH USER before we start to render anything.
So to do this, we're gonna, you know,
there's gonna be another instance where we put a little bit
of code down the screen
and then we talk about exactly what's going on.
So let's put the code in first
and then do a little bit of discussion.
First thing I'm gonna do is inside of our provider tag
I'm going to cut out
the create store with middleware call.
So I'm gonna cut out the entire thing.
So the only thing I have now is provider with the store.
Then right above the react DOM that render call
I'm gonna make a new variable called store
and I'm gonna paste the create store with middleware call.
Now right below we're gonna add const token,
local storage, get item, token.
And so this is really the key here.
If we have a token, consider the user to be signed in.
So if token,
we need to update application state.
So this is it, this is the key right here.
Basically what we're doing
is we're creating an instance of our Redux store ahead time.
And remember, the Redux store is what contains all
of the state inside of our application.
So if we create the store first
then we can do this little check to see
if we have our token.
If they are, we need to update our application state.
So all we have to do in here
on this line right here is we need to figure
out some way of up updating our application state.
So I've, we've definitely gone over this many times.
There is absolutely one way to update our application state.
What is it?
We dispatch an action or we call an action creator.
So essentially what we need access
to right here is the dispatch, dispatch method.
The same one that we get from using Redux Thunk.
So here's the really big surprise
the big reveal at the end.
That dispatch method that we've been using
is a property of the store.
So store.dispatch is our dispatch method.
If we put any type of action in here,
it's gonna be sent off
to all the different reducers inside our application.
And so that's really the big solution here
for kind of updating our application
before it's already been rendered.
So here's the key.
If we have a token, we're going to dispatch
an action and we want
that action specifically to be of type AUTH_USER.
And if you recall the only thing
that AUTH_USER does is change that signed in
or that authenticated flag from true to false.
One last piece of bookkeeping here.
We have not imported this type here.
So up on it by all of our import statements.
I'm just going to import AUTH_USER
from actions types like so.
Then the very last thing we need to do is make sure
that this store that now has
this updated state actually gets passed to the provider.
So down here at our provider call,
we're gonna make sure we have store, store like so.
So let's test this out in the browser
and then do a quick review on what we just did.
I'm gonna refresh the page.
In this case, I've already got a token.
And so you can notice that when I refresh the page
I automatically see a sign out link
instead of sign in and sign up.
And I should also be able to make direct access
to feature as well.
And so again, I have access to feature here
without having to go through the sign up or sign in process.
So now the real test is if I sign out
and then refresh
I still see sign in and sign up.
And I should also not have access
to the feature route as well when I definitely don't.
So awesome.
So this definitely works out and it's all predicated
on the idea that we're gonna pull out the token first
and if we have a token
we consider our user to still be authenticated.
We did that update
to application state by declaring our store beforehand.
Remember, the store is what contains our Redux state
and we are, we were able to automatically
dispatch an action that signed our user in.
Remember this action right here.
We mapped up to the AUTH_USER.
So here's our case AUTH_USER
If they are, if we see this action come across
then we consider our user to be authenticated.
Cool. So this is definitely looking pretty darn good.
One step closer to finishing up our application.
I think there's one last big thing we need to do.
We need to make sure that once we have our JWT token
we are able to make requests
to protected routes on our back end.
So let's take care of that in the next section.