In the last section we put together our first action creator that makes use of redux thunk.
I now want to add this action creator to one of our components inside of our application and make sure
that the instant our application starts to boot up we actually fetch the user and then do something
with them.
So if you recall we had previously been looking at this diagram right here.
We had said that we wanted to attempt to fetch this user we wanted to call this action creator.
Really the instant our re-act application boots up and so the immediate question the immediate thing
that we really want to be thinking about is well where should we really add this action creator to.
Well I'm going to suggest that the best place to add this call to this action creator is going to be
our app component.
So here's our out component which right now really just contains our different routing logic.
Now you might say to me Stephen should we add this action creator to the header like the header is what
actually cares about whether or not the user is logged in.
Isn't that where we should call the action Kreator.
Well you know what you're definitely right.
Right now only the header can cares about whether or not the users logged in but very shortly we're
going to have other locations inside of our application that also care about whether or not the user
signed in.
So this is not the only location right now that cares about if the user is signed in or not.
Or at least the headers not other locations will as well.
And so we are going to centralize that logic inside of our app component.
Now the next thing we need to be aware of is that right now our app component is a functional component.
We really only want to attempt to fetch the current user the very first time our app component is rendered
to the screen.
So I'm going to suggest that maybe we should refactor the app component and rather than making it a
functional component it should be class based instead.
And that way we can get access to a nice nice life cycle method which will be automatically called when
this component is actually rendered to the screen.
So I think that step number one right here is serif actor app to a class based component.
And then once it is refactored we will then use it to call our action creator.
So let's get to it.
The first thing we'll do is modify our import statement for react at the top and make sure we also pull
in the component base class as well.
We will then refactor our functional component over to a class based one.
So we're going to do this step by step.
First we're going to find the cost app declaration at the top and replace it with class app extends
component.
Now here's the same return block that we had before.
You'll notice that we still have the closing curly brace at the very bottom from the arrow function
that we just replaced.
So all we really have to do now is make sure that we wrap this return statement inside of a render function.
So as a new line I'm going to add the render method.
I'm going to make sure I close off this render method curly brace right after the return statement like
so and then I'm going to indent the entire return statement.
OK so there's the refactor.
So now we've got Rander return.
Here's the closing parentheses for render.
And then the closing curly brace for the render method and then the closing curly brace for the overall
class.
Now we've got our class based component.
We will add on our lifecycle method that we will use to fetch the current user.
So I'm going to say component did mount.
So in other words the instant this component has been mounted or rendered onto the screen go in attempt
to fetch the current user or figure out whether or not our current user is actually signed in.
Now you might look at a component in Mount right here and say You know Steven do we actually want to
figure out who the current user is before we render this component to this screen.
You know shouldn't we use the lifecycle method component real mount instead.
And the answer is that well you know what.
Two reasons that we're going to use did mount instead.
Number one in future versions of re-act the component will mount method might be getting called multiple
times automatically.
And so by convention component in MT is now looked upon as being the preferred location to make any
type of Inish initial Ajax request or anything like that.
In addition the difference in time between component will mount and component did mount is essentially
nil essentially zero.
So there's not really a big difference from the speed of the request.
If we call it from component will mount or did mount.
Not a big difference there.
OK.
So we've now got a great location to color action creator from our next step is going to be to wire
this class or this app component up to receive action creators from the redux side of our application.
So if you recall that is where we're going to bring in the use the connect helper from the re-act redux
library.
So again going a little bit into the details of reactor redux.
So that's going to be its own little challenge.
So I think that we'll take a quick break right now.
We'll come back in the next video and we'll wire up our app component and make sure that it is able
to call action creators inside of our application.
So I'll see you in just a second.