Instructor: We are now able to make authenticated
API requests from our fetchMessage action creator.
I would really like to make sure that we can show
the message that we get back from the server
inside of our feature component
just to kinda pull everything together.
So let's go through the process of wiring it up
and catching this response inside of our reducer.
To catch some new data inside of our reducer,
I'm gonna add a new action type to our types file,
and we're gonna call this one FETCH_MESSAGE.
So here's our new type.
Inside of our action creators file,
we will import that new type.
So I'm gonna import FETCH_MESSAGE.
Then when we get the response back from our API,
so that's this response object right here,
we're gonna make use of Redux Thunk again.
So we will immediately dispatch our own action with a type
of FETCH_MESSAGE and a payload of action.payload.data.
And let's just throw the entire message in there.
So the payload is gonna be the actual message itself,
the actual text string.
Now we need to pick this up inside the reducer.
So in the reducer, we need to add our type
at the top as well, FETCH_MESSAGE.
And then we'll add a case for it.
Finally, we'll say take all of our state
and add a message of action.payload in there as well.
So now on our application state,
we should have this message property under the auth_reducer.
That means inside of our feature component,
we can now define our function mapStateToProps.
It's gonna take in some state,
and we'll just return a message: state.auth.message like so.
Make sure to wire it up to our connect call
'cause, again, I've been forgetting that lately,
mapStateToProps.
And the very last step is inside the render method.
We'll just say render this.props.message.
There we go.
So let's save this.
Let's refresh the page.
Looks like dispatch is not defined.
I probably have a typo somewhere.
Let's go check real quick
inside of our action creators file.
Here's my dispatch.
Do I have, oh dispath, dispatch, missed a C, dispatch.
Hopefully, I didn't misspell it anywhere else as well.
Nope, looks I didn't.
All right, so dispatch, dispatch, very good.
Looks like still have, oh totally my mistake here.
I said action.payload.message.
It should be just response.data.
I'm totally used to doing this stuff inside the reducer,
response.data.message. There we go.
There we go, all right, so we made our authenticated request
to super secret code is 123, is ABC123.
And so, again, keep in mind
that this is just a very simple example here.
This could have very trivially turned into something
like, hey, fetch me my list of posts, or my list of tweets,
or my list of emails, or whatever other resource
I'm trying to resource or retrieve from the backend.
And then the key there is that we're always gonna include
the header, our JWT token inside the header,
to make our authenticated request.
Then with that JWT token, our server's going to know,
oh, alright, you know this is coming from the user
with email test123@example.com.
I need to pull up that very specific user's emails,
or tweets, or posts, or whatever it might be,
whatever different resource.
So this little chunk of code right here
is very easily repeatable all over the place.
By the way, this is also one great time
for me to mention exactly why, you know,
after all this time, exactly why we learned
to use Redux Promise instead of Redux Thunk.
We learned to use Redux Promise first
because with Redux Promise, requests are so easily readable,
just a hundred percent legible.
Let's look at what this might look like
with Redux Promise real quick.
It would be fetchmessage,
and then we would have some request right here,
and then we would just return an object of type:
FETCH_MESSAGE and a payload of request, and that's it.
This would be our entire action creator
if we were using Redux Promise here instead.
So even though Redux Thunk gives us a lot of power,
man, I feel very strongly that it is just a lot easier
to read code with Redux Promise than Redux Thunk.
With Redux Thunk, it is just really hard to glance
at this structure right here and have an immediate idea
of exactly what's going on.
Much easier, much more clear with Redux Promise instead.
So, again, that's why I really like
to use Redux Promise, but to each his own.
If you really like Redux Thunk instead,
certainly go with that approach.
All right, so this looks pretty great.
Let's do some wrap-up inside the next section.