-: In the last section, we added some code
to our Middleware to handle the case
in which we didn't have a promise.
I also just realized that I made a big typo here.
I said, we don't have a promise.
In fact, we would be reaching this area
of our Middleware only if we did have a promise.
So it would've been more appropriate to write,
we have a promise here, just to be clear.
So let's handle the case in which we do have a promise.
If we have a promise, we wanna wait until it resolves.
And then we wanna dispatch a new action
with the successfully resolved promise.
So this is gonna be one of those areas where
it's just a little bit of a gotcha.
It's just one line of code basically,
and it's just something that's a, I dunno, very clever.
Let's give it a shot and see what happens.
So key number one, the first thing we wanna do is,
make sure the action's promise resolves.
Basically, we have to wait
until that promise successfully fetches our list of users.
That's step number one.
So let's write some code that's going to basically tap
into that situation.
Action dot payload. So that's our promise.
Dot then.
So boom, that's it. The dot then.
Any function that we pass to dot then
is only gonna be called after the action has been resolved.
And specifically any function that we pass here,
is going to be resolved with the response,
from the promise.
So now we can add in a fat arrow function,
for handling this case.
Okay, so now, we've handled the case,
or we've kind of handled this much.
We're saying that yes, we're waiting until the promise
resolves and we do have access to the response data.
So now comes the step in our diagram here, where we say
okay, we've got the, we've resolved,
we've got the data.
That's steps one and two right here.
Now we just need to create a new action and send it
through all of, all our Middlewares again.
So, we need to create a new action, as step number one.
To do this, let's uh, let's break it out to a,
we'll just do this in one single line to start.
And then maybe we'll, can expand it out
to a full length function
just to make sure everything's clear.
Actually, you know what?
Let's just do everything with a full, full size function
rather than try to be fancy from the get go.
So, that will use the long function keyword.
This will be resolved with our response from the server.
And then once we get here, we want to craft a new action.
Okay? We want a, this is like our replacement.
This is like the, hey, here's the copy of our action
that has all the data that we actually care about.
So inside this function, we'll say, take everything
that the current action contains,
but extend over it, our response.
So take whatever data our action already contains
and extend over it this new payload, which is the response.
So, in the original action, we had a type and a payload.
So, this line of code right here is making sure
that we preserve the existing type onto our new action.
And this second little bit here says,
okay the old action, you know what?
It's got that junk, that junk promise on it.
We don't care about the promise anymore,
all we care about is the data.
So let's just knock off that entire promise.
We don't, we don't need that promise anymore.
Let's just knock it off and we will replace it
with our response.
So this line of code right here,
is what creates our new action.
Let's specifically label it as such.
So I'll say const new action.
And we'll say create a new action with the old type,
but replace the promise with the response data.
So let's go back to our diagram.
We've now accomplished what I would probably refer
to as step number three on here.
We have created a new action
with all the data except the, the, excuse me
with all the data that was contained in the action
except for we don't have the promise anymore.
So now just one last step.
We have to somehow send it through all the Middlewares again
we have to go all the way back up to the top of the stack.
And let's say we've got five other Middlewares in here.
We wanna make sure that the action flows
through all those different Middlewares.
So, to make that happen,
we don't wanna call next with the action.
Next just forwards it, forwards our action
onto the next Middleware.
And we don't want that.
We wanna make sure that our action goes through all
of the Middlewares again.
And I'll talk about exactly why in just a second.
So to make sure that our action flows through all
of our Middleware.
We use the dispatch method up here at the top, so again,
this dispatch is a function. Let's go ahead and add it in.
We'll say just dispatch new action.
Dispatch literally means take this action,
and send it through a very topmost reducer again.
Just pretend like it's a brand new action,
send it through everything again.
That's the purpose of dispatch,
and that's how it differs from next.
Next just goes to the next Middleware,
dispatch means run the entire cycle over again.
Go up to the very top and run this action,
through everything again.
Now there's two follow up points here I wanna make.
First, your question might be, okay, well Steven
I understand like we're gonna dispatch this action
from the very top again.
But when we hit this Middleware again, cause we are,
when we hit this Middleware again, aren't we just going to
like try to chain on to the promise again, right?
Aren't we just gonna be in this infinite loop?
So, my response to that is that, no
not on the next time through.
The next time through our payload,
is not gonna be a promise anymore.
It's gonna be our response object
our data from the back end.
And so we're gonna catch on this early return
case where we just go onto the next Middleware.
So anytime we return a promise in an action,
and it hits this Middleware, it's gonna hit it one time
hit the dispatch, go all the way to the top again
and then come in again. But that second time,
it'll hit the early return case.
So, that's a question that you might have, number one.
Question you might have, number two is,
why are we using dispatch here?
Why aren't we just using the next queue?
Why don't we just pass it on to the, you know,
next Middleware we have in the chain.
And so this is something that's actually really important
especially when you're writing custom Middleware
for your own applications.
Let's go back to this earlier diagram again
where we had several Middleware, in a chain,
several Middleware, Middleware in a row.
Let's say that the Middleware that we just wrote,
you know our async one is number three.
Let's say we're the last one on the chain.
But let's also say that maybe Middleware number one,
wants to be responsible for logging every single action
that comes through before they hit the reducers.
Or maybe there's some other action or some operation
that we have on this other Middleware that must always
happen a hundred percent of the time
with every action before it hits the reducers.
If we got into our Middleware, number three
and we said, okay, just forward on to the next one.
Like, here's the response we're done.
It would skip number one Middleware,
it would skip that first one.
Now we can reorder our Middleware,
but the goal here is to make sure
that we always write our Middleware in such a manner
that it doesn't matter what order they execute in.
That's the key. We never want to make an assumption about,
oh my action is first gonna hit this very particular
Middleware, and then it's going to definitely always next
hit this other one right after it.
So again, the goal is to make sure
that we write Middleware that is completely oblivious
as to what order it's being ran in.
And so that's why whenever we make a modification
to an action or we change it in some very fundamental way
we always dispatch the action again.
So, it goes up to the top and flows in again,
as opposed to just going to the next Middleware.
Okay, so this looks great right here,
but I've also been talking for a long time
so I'm gonna save this and let's go ahead
and give it a test inside of the next section.