In the last section we establish that we're going to be line figuring out whether or not the current
user is logged in.
We then spoke a little bit about how our server already has an API route put together for telling us
whether or not the user is logged in.
So essentially we need to make an Ajax request to our backend and that will tell our re-act application
whether or not we are authenticated.
Now going into this process I'm doing a lot of build up here because we are going to very quickly touch
on several different libraries and we're going to touch on a lot of different topics within our re-act
application.
And so this is something that really does deserve a little bit of buildup because once we start going
through it we're going to be really covering like 4 or 5 different important concepts at the same time.
So with that in mind let's take a look at a diagram that very clearly describes exactly how we're going
to pull this off.
So when our re-act application boots up we are going to make sure that our app component which is our
essentially root component calls an action creator and this action creator is going to be responsible
for figuring out who I should say making an API request to our backend and asking whether or not the
current user is logged in.
So we're going to imagine that this action creator has a function called fetch user or something like
that inside of that action creator.
We are going to use the actual library to make an Ajax request to our back end API.
So specifically to the route API slash current user so that request is going to go out to the Express
API and then we're going to get a response back presumably containing the user if the user is logged
in.
Once we get the request back we are then going to use a library called redux thunk to dispatch an action
off to all the different reducers inside of our application.
And so once we dispatched this action the action which contains the information of whether or not the
user is logged in is then going to be sent to our author douceur our author reducers will be responsible
for looking at that action and then updating some internal flag inside of it to say yes the user is
logged in or no they are not.
Once we have that new updated piece of states were then going to update the content inside of our head
or by setting up the header to communicate directly with our redux store.
So again this is a pretty complicated pretty involved process.
The good news is that we are going to repeat it several times throughout this course essentially for
every API request we put together.
We're going to go through this exact same process.
So we definitely will get a lot of practice with it.
OK.
So let's get started.
Really no reason to dawdle any more.
The first thing we're going to do is install the Axel's library and the redux thunked library ASIO's
is responsible for helping us make API requests or Ajax requests to our back end API and redux thung
is something that we use to helpfully maintain or kind of make asynchronous action creators behave the
way we expect.
So let's install these and then we'll start wiring all this stuff up over my terminal.
I will change on over to the server.
I'm going to kill the server and then change into the client directory.
Because these are both client modules that we want to install.
We will NPM install dash dash save axioms and then also redux oops redux dash phunk like some.
OK so while that installs we're going to flip back over to our application and we will first start off
by wiring up redux Thuc.
Now we're not going to say right away exactly what redux thunked is all about but we will very shortly
once we start working on the action creedo We will talk about exactly what it's doing.
OK.
So inside of my client SIRC index dot J.S. file I'm going to import the redux thung and hook it up to
our create store call right here as a middleware.
Now again we'll talk about exactly what redux thunk is doing but we're going to hold off on discussing
it in depth for right now.
So I'm going to import redux thung from redux dash sunk and then we're going to pass that thing to the
applied middleware call right here.
So passen redux Thank like so okay.
Next we're going to create an action creator inside of our project.
Remember action creators are where we somehow initiate change inside of the redux side of our application.
So they are used to kind of modify the state that is contained inside of a redux store.
Again if you're here kind of assuming that these terms are familiar at least somewhat I am going to
assume that you may not be familiar with redux thunk if you're not that's totally fine we'll be going
over that from scratch.
But for these general the redux terms just kind of assuming that you are familiar with them.
So to create an action Creator I'm going to make a new folder inside of my SIRC directory that's going
to be responsible for housing all the code around all of our different action creators.
So inside the sarcy directory I'll make a new folder called actions.
And then inside if you're going to create our first action creator inside of a file called index Geass
now for this first action creator we put together we're going to put it right into this file.
But immediately after we finish this entire like Hetter thing we're going to come back here and do a
little bit of a refactor to make sure that all of our different action creators are well organized inside
the actions directory.
So for right now everything inside of index not just.
But very shortly we will come back and refactor this stuff.
OK.
So at the very top I'm first going to import the access library.
Remember we use X to make Ajax requests.
So import Axel's from Axel's and then I'm going to define our action creator.
I'm going to call this thing fetch user like so
now right now.
Just like I said that we're going to place all of our action creator code inside this index file and
then refactor it later.
We're going to do something not quite similar with the action types.
So we are going to declare our action types in a separate file inside of our actions directory still.
So inside the actions directory will make a new file called types J us and then inside of here I'm going
to create an X for a new action type called fetch user.
So say export Konst fetch user tools fetch user.
So now we'll immediately import this type into our index file inside the actions directory.
So back inside of index on J.S. we will import fetch user from types like so OK this is looking pretty
good at this point.
Now again we're going to be making use of x to make this network request.
So inside of art the actual crater and side effects user I would call X-posts dot get because we want
to make a get request to our back and then we're going to pass in the route that we care about.
So the route to our API.
Remember we just looked at that route that route that route handler in the last section.
If we go back to our route route directory and find the author route start G-S file at the bottom of
that thing.
We found that we had that route handler right here that could automatically return the current user
if we made a get type request to API slash current user.
So back inside the SIRC actions index touchiest file we will make a get type request to API slash current
user like so.
Now really important.
Remember we're only putting the relative path to our backend server here.
This goes back to that whole discussion we had about how relative paths are working inside of our application
in the development environment.
We make use of our proxy for the request on the API and then the proxy will send a response back to
the re-act application.
And then in production there is no proxy.
There is no Create react up server that whole proxy thing falls away and a request to API slash current
user would go directly to our express backend.
So before we go any further than this I want to make sure that we change over to our package not just
on file inside of our client project and make sure that we've already got a proxy rule put together
for handling this request right here and Simeonoff to our real express backend.
So inside of our client directory I'll find the package not just some file inside of here.
I should already see our existing proxy rule.
So there it is right there.
So we're going to add on one additional proxy rule to make sure that any request to our API successfully
gets forwarded on to localhost.
5000 OK.
Now I am going to say that I don't really want to have to add on a separate proxy rule for every last
API we API route that we tried to make requests to.
I really want to just set up like as few rules as possible and kind of have everything just figure itself
out from there.
So keeping that in mind we're going to add a second rule to the proxy object the route that we're going
to watch for.
We'll be slash API slash star.
And so with this rule right here with this rule saying start here that means if any request whatsoever
comes from the reac saw the application looking for API slash current user or API slash surveys or API
slash anything else at all just go ahead and forward it on to the Express API.
So we'll instruct the rule.
That is what it should happen.
By adding on target of HTP slash slash localhost Colan 5000 like so.
So with this single rule right here we don't have to worry about coming and adding on and additional
proxy rule for every API request we make just this one right here will catch everything that goes to
API slash anything.
OK.
So that definitely is going to save us some time in the future because we don't have to worry about
all this proxy stuff again for essentially the entire course which is definitely a big help.
So let's close out the package.
It's on file and then we're back at our action creator right here now very shortly we're going to start
talking about that redux thunked library.
We're also going to make sure that this request that we're making here makes use of that async await
syntax that we spoke about very previously in a many videos ago.
So again there's like a lot of topics that we're covering here simultaneously.
So with that in mind I want to take a quick break.
When we come back we're going to start talking about some of the basics of redux thunk and we're also
going to talk about how we use redux thunked.
Along with that async await syntax for handling asynchronous requests or handling promises like what's
returned from this thing right here.
So let's continue in the next section and start talking about those two additional topics.