Instructor: So this is it.
Our moment of truth, we've got our middleware
we are making AJAX request
and we think that we're doing the right thing.
Whenever the request resolves, I'm gonna open
up my browser and give it a shot.
Let's refresh and we don't get anything here
but that's not necessarily bad.
Let's go ahead and put a console log in our reducer.
I'm gonna flip over to our users reducer
and in the case that we are under the fetch user's type
let's console log our action.payload.
Now I will refresh the document and, okay
so we don't necessarily have a list of users
we've got a response object.
So the data that we actually care about
our list of users that is on this .data property.
So let's go ahead and fix up our reducer
so instead, references.data instead of just action.payload
cuz the data that we actually care
about is on action.payload.data.
I'm also gonna remove the console log.
Let's refresh and awesome.
There it is.
We've got our big old list of users.
So to get our app working
I think there's only one last thing we need to do.
We said that the company names needed to be appropriate
and we could also put in the user's emails as well.
So I'm gonna open up our user list.
We've got a hard coded cheese factory right here.
I'll change it to user.company.name
and for the email we'll put on an href.
You know, how about instead of email
let's do all these users actually have a website property.
Let's do website instead.
That makes a little bit more sense perhaps.
So we'll say that the href is gonna come from user.website.
And if you're curious
where I'm getting these property names from.
These property names are all a part
of the user object on this fake JSON API.
Let's look at the JSON really quick.
You can see on here that each user has a name.
There is the email we were going to use.
Here's the website and here's company.name.
Okay, so with those property names in there
let's do another refresh and yep, this is looking good.
So we got blah, blah, blah, blah, blah, blah, blah.
All the company names that are all goof ballish
got this overlap V right here.
That's kinda, ah, there we are.
That's better.
Okay, so this looks great, but this isn't really important
to the app we were building.
Let's actually review the middleware that we put together.
So the first thing that's really important that we need to
do whenever we're using custom middleware is we made sure
that inside our top level index.js file
we applied our middleware.
So we imported it into this file and then we applied it.
That just tells Redux,
"Hey, whenever an action gets dispatched
make sure it flows through this middleware."
If we had many middleware, we'd just add them
on into this applied middleware call with commas.
So we could say async and maybe log
or middleware or whatever else we might have.
But in our case, we just had the one.
So the really important thing to remember
about middleware and probably the most
important part is this diagram right here.
Is that any action that flows
into our middleware we need to handle in some fashion.
We wrote a middleware where we said
if the action does not contain a promise
just send it on to the next middleware.
If it does contain a promise, we waited for it to resolve.
Once it was resolved
we got the data and forwarded on into our action
which ran through all of the middlewares all over again.
We made sure
that the new action that we created got dispatched to
or got sent through, I should say, all of our middlewares
again from the very top of the stack by sending the action
into the dispatch method instead of the next method.
So again, dispatch is what starts
from the top of this chain or top of the stack.
Next just literally means go to the next middleware.
The other thing that we did was kind of interesting
is we wrote some code in here to
actually decide really, really make sure
that the action that we were working with here
was one that we cared about.
So we needed to kind of plumb
through the actions that we were making use of.
We had to make sure,
there was some level of filtering there and we were
only touching the actions that actually contained a promise.
If we had gotten down here with every single action
maybe an action doesn't contain a payload at all.
And so when we called dot then
on basically what could be undefined, boom
it would've just thrown an error.
So when you're writing your middlewares,
if you ever make a custom middleware, do make sure
that you're handling strange cases like this cases
in which your action might not have a payload at all.
After our action got dispatched
from the top of the chain, again
it did flow through this middleware a second time
but the second time through it no longer had a promise
on its payload property and so it just went
on to the next middleware, or in this case our reducers.
So that's pretty much it for custom middleware in general
when you're writing your own, all you really gotta
remember is this crazy town function signature up here.
As far as the body
it really is up to you as to what you want to do.
This is just one very particular example that I
modeled after another existing middleware
called Redux Promise.
You can build middlewares to do many different things
and I've used them in many different applications.
One application that always stands out to me
one where I saved a ton of time was when I had
a API response that had a real...
It was just a real jumbled mess of response.
There was just a lot of extraneous properties.
The response was formatted really strange.
A lot of the property names didn't really match
up with what my app was already using.
And so I used a middleware to intercept any action that came
from that very particular API endpoint.
And if it did, I stuck a bunch of logic into kind
of transcribe or mutate the response that we got back
into something that was a lot more palatable.
So it had very consistent property names
it had consistent structure
and so I basically just used a middleware to
massage the response I got back from this API.
And so that's not always, you know, the best solution
but it was a solution
in which I didn't have control over the actual API.
So the only option was to build a middleware
to kind of massage that response a little bit
into something that I really liked.
All right, so this is fantastic.
I hope you've learned a lot about middleware.
Let's go ahead and get continued in the next section.