In the last section we started putting together our fetch user action creator which is intended to make
a request to our back and API and then somehow communicate to our authentic author douceur whether or
not the user is currently signed in.
So in this section we're going to again we're going be covering some challenging topics here.
We're going to talk about redux stunk.
We are also going to be talking about how to refactor this auction creator to use the async 08 syntax.
Now very likely that this will take two separate sections but that's totally fine.
We'll take our time and make sure we really understand this because again we're going to be repeating
this process several times throughout the course.
Now at this point I again I'm going to assume that you are passingly familiar with action creators.
Remember the purpose of an action creator is to return an action that action gets sent to all the different
reducers inside of our application which then produce new values for state and updates that state inside
of a redux store the redux store then sends the newly updated state back to all the different re-act
components.
Now the key inside this process is that with vanilla redux like redux as we've installed it with no
further configuration expects that any action creator that we call will instantly and immediately return
an action.
And remember we define an action as a javascript object with a type property and optionally with a payload
as well.
So the key thing to remember here is that an action creator always expects us to return in action.
So what's redux thunk and what does redux thunk have to do with all this stuff.
The entire purpose of redux stunk is to allow us to write action creators that break this rule right
here that break specifically the requirement that we have to immediately return an action from every
action creator we create.
So take a look at a diagram that's going to help us understand a little bit more about what redux thunk
is really doing for us.
OK so this is essentially the same diagram but obviously one with one very large change right here right
in the middle so you can think of this as being essentially what redux thunk is giving us access to.
I want you to think of this thing as like a big funnel.
That is just sitting out there waiting for actions to be passed into it.
So let's go through this flow.
We'll talk about exactly what the funnel is meant to represent.
So again on the very far left hand side we have our re-act component the Riak component will call an
action creator and then this time.
Rather than saying returns in action I said produces an action.
So that's what the action creator is really responsible for the action creator somehow produces an action.
The real question is about how the action creator communicates that action back to the redux store.
So this time around we're saying that the action creator is known is going to be returning it.
Instead the action creator is going to be passing the action to what we call the dispatch function the
dispatch function is a function that belongs to the redux store.
If we call the dispatch function with an action the action will be automatically forwarded on to all
the different reducers inside the application and those reducers will run like normal.
They will produce a new value for state and they'll pass all that state back to the store.
Now to be 100 percent clear this dispatch function is already where this action is being sent to.
So in that last diagram we were looking at just two seconds ago.
In this one right here when I had said the action Krater returns an action and that is sent to all the
reducers there really is an invisible step right here.
So when it says send two already that is.
We are like looking at what the dispatch function is really doing.
The dispatch functions purpose is to send these actions off to the producers.
That step is already happening with three ducks whenever we use it.
The only thing that redux thung is really doing for us is that it's giving us direct access to the dispatch
function.
So it says OK I understand that in your action Kreator you do not want to follow the rules.
You do not want to just return in action like usual.
Instead I'm going to give you direct access to this dispatch function and then at any time at any point
after doing whatever you want.
If you want to manually return or you want to me manually dispatch an action just pass the action to
this dispatch function.
So again redux thunk is really allowing us to bend the rules here and allowing us to manually dispatch
an action at any point in time that we wish from an action creator rather than requiring us to just
flat out return it from the action creator.
Again I can't say that enough the dispatch function is already really being used behind the scenes right
now so all we really get out of using that redux thing thunked thing is we just get the ability to get
a handle directly onto the dispatch function.
Ok so with that in mind we are now going to complete our action create or at least a kind of first run
through with it and with this first run through we're going to kind of take a very rough approach.
We're going to get everything working but we're going to say that this is like the one or version one.
Once we get to version 1 and we understand how it works we're then going to come back and implement
version 2 and in version 2 we're going to have the real like completed syntax where we use a lot of
fancy.
Yes 20:17 stuff and all that kind of good stuff.
OK.
So first time.
You know let's get through it understand what's going on and then we'll come back and refactor everything.
So let's flip on over to our action creator.
So remember usually how we would usually put this stuff together as we would say something like Konst
request equals the requests that we just made and then we would return an action with a type of something
like Fettes user.
And then on the payload property property we would have a request like so.
So I'm saying that we're no longer going to exactly follow this right here.
Instead we are going to get direct access to the dispatch function.
So I need to clean this up.
I'm not going to immediately return that action.
And I'm also not going to assign the request object to anything we're going to let the request hang
for just a second.
So the first thing we're going to do is we're going to re factor this action creator to really use redux
thunk.
Now when we do this refactor it will look a little bit weird but just bear with me.
So I'm going to add in the body of this function right here.
I'm going to return a function and when this function is executed it's going to make the actual request
like so.
So now rather than returning an action from this action creator when ever the action creator gets called
it will instantly return a function.
Now here's the key.
When we wired up the redux thung middleware just like two seconds ago inside of our source index not
G-S file we wired it up as a middleware.
The purpose of this middleware the purpose of relex thone is to inspect what ever value we return from
this action creator if redux thunked sees that we return a function instead of a normal action redux
thunked will automatically call this function and pass in that dispatch function as an argument.
So dispatch right here.
This is a function.
This is the same function we were just looking at inside this diagram.
So it's the thing that we can think of as like a big funnel and anything we toss into it any action
we toss into it will be automatically forwarded off to all the different reducers in our application.
And so now that we have access to this dispatch function we don't have to immediately return an action
or anything like that we don't have to do anything in here.
We can say at any given point in time oh you know what I now somewhat feel like dispatching action so
I guess now I will.
And so where is that really relevant for us in this code snippet.
Well we want to dispatch an action after this request has been successfully completed.
That's the whole point of all this.
We do not want to dispatch an action until this API request has been completed.
So we want to treat this thing like an asynchronous little piece of code because that's what it is we're
going to chain on a then statement because X don't get returns a promise and then once the promise is
resolved only then will we actually dispatch an action and have that be sent off to all of our different
reducers.
So let's give this a shot.
I'm going to remove the semi-clean onions and chain on the then statement that then we'll be called
with our response from the API.
And so whenever we get that response back then I am ready to actually dispatch an action.
So I will say dispatch I don't get a pass in the action that I want to dispatch.
So I have a type of fetch user and a payload of the response so we just got back.
So payload of reps like so.
OK.
So this right here is essentially V-1 of our code whenever the action creators called it will return
a function redux thunk will see that we return to function and it will automatically call it with the
dispatch.
We then make a request.
We wait until we get the response back from our API.
And then once we have the response only at that point in time will we actually dispatch our action.
OK.
So that's pretty much it.
That is our first action creator using both reducto thunk and using Axelson side of it.
Again we're going to repeat this process many times.
So at this point we're going to take a quick break.
We're going to wire this action creator up to our application so that it's actually being called We
will then be able to test it out and verify that it's working the way we expect.
And then after we are able to verify that it's working as we expect we're going to come back to it and
do that refactor to make it look really nice and pretty much better than it looks right now.
OK.
So let's take a quick break.
We're going to come back and wire up the action crater to our actual application.