Now were successfully dispatching action every single time we make a request off to this end point.
We need to make sure that this action right here gets picked up inside of our cloth reducer.
Now before we flip over to the author douceur and start working on that I want to remind you that this
rez object right here is the output from X-posts.
It represents the underline request that was made to the back end server.
Now if we look at the console log of that response that we still have in cyber consul over here.
So here's the payload in here all the different properties that are tied to that response object.
Now you look at this thing and we've got some config we've got headers we've got requests status blah
blah blah but at the end of the day the only real piece of data that we care about here at all is really
this data property just this data property nothing else on this response object.
So back inside of our action creator rather than returning an object that passes along the entire response.
I think that we should pass back as a payload just the rez dot data property.
So just rez dot data just the user model because that's really the only thing that our application and
especially our producer cares about at all.
Nothing else really cares about the headers or requests or anything like that.
So back inside of our action creator I mean to say that when we dispatch this action we're going to
pass along.
RAZ dot data like so.
So just the response data property.
OK so now we can flip over to our reducers author reducer G-S file.
So here is where we put together some boilerplate.
Earlier on inside the course just to kind of get this reducers put together.
We're now going to import the fetch user action type and then set up an additional case on our switch
statement to watch for that action to come into this reducer.
So at the top of the file we will import our action type which is Fettes user from up one directory
into actions.
Type start ups so up into actions slash types.
Now we can add on a case statement inside of the switch statement.
So here's a case that user.
So if we see an action with type fetch user then we want to do this thing right here.
Now before we start to return the actions payload or anything like that I want to think very carefully
about the life cycle of this reducer and some of the different values that it's going to produce.
And let me tell you why.
Let's go back to our mockup really quick.
It's the mockup that includes the header right here.
So when we look at this header remember the content on the right hand side is going to change depending
on whether or not the user is logged in.
Now let me send out or let me like provide you a sequence sequence of events that might make the header
behave slightly unexpectedly.
I want you to imagine for a second that when our application first boots up and we make an Ajax request
to our back end server.
So essentially a thing that decides whether or not we are currently logged in.
What would happen if that request took a very long time to complete.
So maybe our user is on a 3G network connection or just some kind of connection that is very slow and
it might take some amount of time for this request to actually complete and get back to the current
user.
If that were to happen we might temporarily see some content inside the header.
That would be like not quite what we expect.
For example if we say that by default show the logging with Google button and then that long running
request eventually finishes and we find out that we in fact are logged in.
All of a sudden the content up in the header would change over to the content that we would expect to
see when the user is actually logged in.
So we don't want to fall into this very easy trap to fall into where we kind of assume that the user
is or is not logged in and then show the UI according to that flag because it just means that as soon
as it takes a long time to decide whether or not the user is logged in the user is going to see one
state of the UI and then suddenly see it change over to the other state.
Once we find out that they are in fact logged in.
So with that in mind we need to be kind of very careful here when we think about the different return
values from this reducer.
So let me give you a summary of how we're going to tackle this.
Here's what we're going to do.
OK.
So we really have three different situations of our application.
Three different cases.
Case number one is the case in which we make a request to our back end to get the current user and the
request does not instantly resolve.
So essentially we make the request to find out if the user is logged in and then we kind of sit there
and we're just twiddling your thumbs waiting to hear back to see whether or not the users actually logged
in.
Now I'm going to suggest that while that is the case while we are waiting for that request to finish
our producer should return.
We're going to say that inside of our application our return value of no means we don't really know
if the user is logged in right now.
We don't know if they are or we don't know if they're not.
So we're going to say no we don't know.
We're still making a request.
The request is still pending.
We're waiting to find out if the user is logged in.
Then if the user is logged in.
So at this point in time we can say that the request is complete diot the author Duzer can return the
entire user model.
But if the user is not logged in so the request is complete and it turns out they are not logged in
then we should instead just return the value false.
So this gives us three distinct values coming out of our reducer that we can use to decide the exact
state of the authentication flow.
Either the user is logged in they're not logged in or we are still waiting to find out if they are or
aren't so let's make sure that our author douceur conforms to these different cases right here.
The first one that will take care of is the base case which is to return NULL while our request is still
pending.
While we are still trying to figure out whether or not the user is logged in so handling that case is
actually pretty straightforward inside of our douceur we are currently defaulting our stock value to
be an empty object rather than always returning an empty object.
We could instead return.
No.
So if we are turning like this that means OK first time there are douceur runs on our application first
boot up.
We are going to immediately return all which indicates that by default we have no clue as to whether
or not the user is actually logged in.
Then when we actually hear back from our request only at this point in time when we actually hear from
that Fettes user action will we return a new value that will be either the user model or false.
So we will say that we will return action payload and remember action payload is the user model.
Now there's one more little gotcha kind of tucked away in this line right here.
When we see our console log right now.
So here's the console log for the action that comes into the producer.
We have verified a couple of times now and I've got to pull the app back up.
Here we go.
So when the user is logged in action not payload is now the actual user model.
However this doesn't really accommodate for the case that the user is not logged in.
So really quick let me log out and I want to show you something kind of awkward.
So over in the new tab I'm going to go to localhost 5000 slash API slash log out remerge.
That's how we log out.
So I'm now logged out of the application.
If I go back over to the re-act side and refresh the page.
Now when we see that action has a payload of empty string because when the user is not logged in the
API is just returning an empty string which means essentially no you're not logged in.
So we don't really want to return empty string here.
That's kind of confusing.
So rather than returning empty string we're going to make sure that we explicitly return the value false
to do so inside every turn statement right here.
We will say action payload.
This is going to be either an object or an empty string.
To make sure that that empty string will actually end up as false.
We're going to use a little bit of trickery with javascript so let's add in the code and we'll talk
about what it's doing.
So when I say action payload or false like so.
So this might be kind of new to you but let's flip over to the terminal really quick and see what it
actually does.
So I know that whenever you're making use of javascript an empty string like this is interpreted to
be a falsie value.
So if I put an exclamation in front of that to kind of reverse the boolean value here it gets turned
into true.
And so I could just as easily do flip the reverse of true and now it really gets what it truly is.
False.
So this statement right here essentially says if that is an empty string or false will return the value
false.
So see how we get false right here.
We're going to use this little trick right here in which the first element inside the boolean expression
is treated as falsie which causes the entire boolean statement to return false.
We're going to use it several times throughout the course.
So this is just one of the first times that we're kind of getting our eyes on it.
OK.
So now we have made sure that the author reducer will always either return.
The user model or the value false.
So let's now test this out inside the browser.
I'll flip back over all refresh.
I did not save this file I think.
Make sure make sure I save it oh my mistake.
So we are counsel lugging the payload right here which is always going to be empty string.
We are not actually cancel logging the value of the reducer.
My mistake.
So at this point we can really safely assume that the reducer is behaving the way we expect and our
user or I should say our off piece of state is always going to be either.
The action or the user model or false.
So we don't really have a good way to fully test that just yet.
So let's continue with the next section we're going to make sure that the header is aware of the current
authentication state and at that point we can do a little bit more verification and be 100 percent sure
that the author douceur is doing the right thing.
Now the last thing I want to do inside of here is make sure that we clean up the console log statement
so we can take that out.
OK.
So it looks good.
Let's continue with the next section and continue working on the content that is displayed inside the
letter.
So I'll see you in just a second.