In the last section we applied some styling to our Hetter by hooking up materialized CSSA library and
adding in some very special markup to our head or component that followed the documentation for making
a nav bar essentially.
There's just one little thing that I want to point out about the nav bar.
You'll notice that the nav bar really sandwiches up against the side of the screen like that and the
text that we have is really close to the left hand edge as well.
So this is a slightly undocumented feature.
I'm going to say undocumented just because the materialized library doesn't make it super clear but
essentially materialized really requires you to have at least one root component in SA or one root element
I should say inside of your application with a class name of container.
A lot of the different elements and lots of different styling that materialized makes use of assumes
that you have at least one root element with the class of container.
So let's add this thing in.
And I think you'll get a better idea of what I'm talking about.
So I'm going to change over to my code editor.
I'm going to find my app.
Yes file.
And inside the app thought jazz file you find the top level div and I'm going to give it a class name
of container like so.
So again this is something that materialized just kind of assumes that you have somewhere inside of
your application on one of your higher level elements.
So now when we flip back over you'll notice that we have a lot more nice styling or I should say spacing
on the left and right hand sides.
If I start to collapse the screen everything starts to kind of collapse nicely along with it.
If I go back down to a reasonable zoomin level then everything gets even better.
OK.
So much better than what we had before.
OK.
So this is looking pretty good.
Now I want to focus a little bit more on the header itself.
At this point there's really a couple different ways in which it needs to be improved because it's pretty
rough right now.
Yes it looks good but there's not a lot of functionality around it.
So first off the logo over here on the left hand side is not clickable.
I would really expect that if you click on email over here it should take you back to like some route
route inside the application.
In addition the logging in with Google button over here.
It looks like it's clickable But if you click it nothing actually happens.
And then finally the entire goal of everything we're really trying to accomplish right now which is
to change the content inside the header based on whether or not the user is logged in.
Clearly we have not done really anything around that as well.
So a couple of different areas to advance on.
I think that the best place to get started right now is to make sure that the content shows the correct
the header shows the correct content based on whether or not you are logged in.
So essentially we're just going to stay the course here.
We're going to acknowledge yes this stuff should be clickable but we're going to come back and address
those items later.
OK.
So that leads us to how do we figure out if the current user is logged in.
Great question.
How do we figure out if the current user is logged in because that is how we decide what content to
show in the header.
Well I want to remind you of something that we put together on the server side of our application.
A while ago if I go back to my root server directory open up the route's file or something route's directory
and then open up the auth routes file.
You might recall that we put one very little API handler in here called Current User if a current user
or if a user is currently signed into the application of like the person who is making the request here
is signed into the application.
This route will respond back with the model represented the person who has signed it.
And so this route right here is the exact way in which we are going to decide whether or not a user
is signed into the application whenever our application first boots up.
We're going to make a request to this route right here if it responds back with the user model.
That means fantastic we must be logged in.
But if it responds back with like undefined or no.
Or just empty response then that must mean that nobody is actually logged into the application.
OK.
So that's how we're going to figure this out.
So in short we want to make sure that the instant our application starts to boot up we make an API request
to figure out whether or not the user is signed in.
So that's our goal.
Now before we just start kind of like diving in headfirst I want to remind you about exactly how we
handle requesting data.
Fetching data inside or react and redux application.
Traditionally we will set up a react component to make sure that it calls an action creator in this
action creator right here will be responsible for making some type of API request and then once we get
a response back it will return or dispatch in action.
That action will be sent to all of our different reducers of which one is our author reducer and so
that author douceur is going to watch for an action that says hey here is a request that figures out
whether or not the users logged in the reducer will then return some value that specifies whether or
not the user signed in that will update all the state inside of a redux store and that redux store all
the state inside of it will be sent back down to all of our re-act components.
So in short what we really want to do right now is create an action creator that will make a Ajax request
over to this I disclosed it or to go over to this route handler on our server right here.
So this is going to be fantastic because it will be our first exposure to how we really do communication
between the react and server side of our application.
Now this is going to be pretty in-depth.
The first time we go through it.
So let's take a break right now.
We'll come back in the next section and start working on our action creator.
So I'll see you in just a second.