In last video we ran into a real big nasty error message.
After we implemented a network request inside of our action creator called fecche posts.
So in this video we're going to start to dig a part or pull part this error message and really understand
what's going on.
Now as I mentioned at the end of the last video understanding this error message is really key to understand
a lot of stuff in the world of redux.
It's incredibly likely that at some point you might be asked an interview question about what we're
going to discuss around this error message as well.
So we're going to spend a little bit of time to dive into this error message and really help you understand
exactly what's going on.
All right.
So first off a diagram.
So what's wrong with our fecche post action creator.
Well in reality there's not one thing that is wrong with it.
There's actually two things that are wrong.
We're going to first focus on item number one right here.
So item number one this is the first thing that is wrong with our action creator are action creators
and cider redux are supposed to return plain javascript objects that had a type property and optionally
a payload as well.
But at present we are not returning an action from our action creator.
Now when I say that to you when I say we are not returning a plain javascript object you might flip
back over to your code editor and look at the section creator and say Stephen are we looking at the
same action creator.
You might be thinking.
It sure looks like it to me.
It sure looks like we are returning an object with that type property.
Well in fact no we're not.
Even though it really really looks like.
Any time that we call fecche post right here we are going to return a javascript object that is not
the case even though it really really really really looks like it.
So let me tell you why.
Remember we spoke much earlier in this course about how all of the code that we'd write inside of our
code editor is.
Yes 2015 2016 2017 2018 and so on.
Code the code that you and I write gets transpired down to yes 2015 syntax and that yes 20:15 syntax
is what actually gets executed inside the browser.
So even though this function really really looks like it is returning an object with a type property.
In fact after we transported this to yes 20:15 code we are not.
Let me prove that to you.
All right I'm going to remove that comment right here and then I'm going to highlight everything from
Konst that posts down to the bottom of the file some getting just the function right there and I'm going
to copy that.
Then I'm going to flip back over to my browser and I'm going to open up that tool that we looked at
very briefly much earlier called Babel J US DOT IO.
So this is what is actually transpiring.
Our code down to E.S. 2015 code at the top I'm going to find the.
Try it out button and then I'm going to paste my code on the left hand side.
Now this is really important.
Please make sure that you open up the sidebar over here and Nabl every single preset that you see just
turn every single one of them on like so.
All right then I get a clap set sidebar and I'm going to zoom in just a little bit here.
So inside of our code editor you think that this is the code that we are executing but in fact because
we have specifically the async away syntax here the entire function gets expanded to what you see on
the right hand side.
This tremendously large chunk of code.
And again this is all because we are using that async await syntax.
If you remove the async await like so you see that all that stuff goes away and we essentially condense
down to just the function by itself.
So when I say to you that our action creator is not returning a plain javascript object it is because
we have that async await syntax.
That is why our action creator is not working as expected not going to undo that change and bring that
back up.
I want to show you why it's not working as expected on the right hand side.
You can scroll down a little bit.
I know that this is a real mash of code but I just want you to take a glance at something in particular
inside of your.
So inside of your you'll see a switch statement and you'll see that it has cases 0 and Case 2.
Right here there are some other cases but I just want to focus on cases so in case toof right now noticed
around case 0.
We return the results of calling J some placeholder get and then in case 2 we're going to eventually
kind of return something that looks like it eventually kind of returns are objects that we actually
care about the action that we want to eventually send off to all of our different reducers.
So I'm going to kind of imagine taking this code chunk right here.
I'm going to put it into a diagram and help you understand exactly why this is leading us to a bad result
and eventually that your message that we see inside of our browser.
OK.
So the exam is a little bit confusing but it's a diagram of what is going on when we run our application.
I've got a couple of chunks of code inside of each of these boxes.
First off over here we start at the post list component.
We've got that component did mt life cycle method any time that thing is invoked it calls this Propst
fetch posts.
Now behind the scenes this step right here is probably happening in the reactor redux library.
Remember that anytime that we call an action Creator it returns an action and we must take that action
and send it to the dispatch function on our redux store.
And we did that manually back when we were working in that code Penn. instance.
But then in the last application we worked on we introduced reactor redux and we had said that re-act
redux is going to take our action creators when we pass them off to the connect function and kind of
wrap them up.
So any time that they get calls they're going to essentially return the action and immediately for that
automatically into the dispatch function.
So like I said this separate year probably happening somewhere inside the reactor redux library.
So we call our action Krater fetch posts and then whatever that thing returns we immediately dispatch
it.
And so as far as you and I are concerned when we look at just our code editor and we see just this function
right here you and I are probably thinking oh ok you know reactor redux probably calls this function
and then we make a request right here.
And you know a way a keyword does something you know we don't really know.
But it does something and then basically right after that we return an object that is the ideal flow
and that might be what you think is happening.
But in fact it's not based upon what we just saw over here.
Here is what is actually happening.
Now on the right hand side you'll notice I dramatically simplified the code here in just kind of broke
it down to that case 0 and case 1.
And I think it actually was called Case 2 but you get the idea.
So this is what is really occurring behind the scenes component and now it gets called we call fetch
posts that calls this kind of imaginary code chunk right here inside of the reactor redux library our
action creator gets called So this action creator is invoked and then inside of that super super super
nasty code chunk at some point in time we come across that line of code that says return based on placeholder
don't get.
So we return not our action object when this thing is initially called when our action creator gets
called The very first time.
Like initially gets called We do not return the action object.
Instead as you just saw we have some code inside there that's going to return our request object.
That is what gets returned the request.
So we return the request from our action creator and that goes into the store dispatch method.
Then the store looks at what we returned and it says OK is this a plain javascript object with only
a type property.
Well in this case no because we just returned that request object we did not return our action and that's
why we ended up seeing this nasty error message over here.
It says actions must be plain objects.
Use custom middleware for async actions.
So the real thing right here is actions must be plane objects.
We did not return a plane object we returned a request object that probably has a bunch of fancy methods
assigned to it and probably not a type property.
We definitely did not dispatch what we thought we were dispatching.
And again this is all because of the async away syntax that we are using.
OK so that's kind of issue number one with our action creator.
Issue number one is that because we're using the async syntax and that gets transpired down to E.S.
2015.
Or me yes.
5 code.
What actually runs inside of our browser is not what you think actually runs.
And so we currently are running into this issue where we are dispatching a not redux action we are dispatching
some random object that redux definitely doesn't care about.
So now that we understand that part.
Take a quick policy here.
When we come back the next section.
Let's talk about the second issue over here.
That's going to help you understand why some very easy workaround that you might think would work out
is not going to quite work out as well.
Yes a quick pause I'll see you in just a minute.