We're not going to start to focus on creating this header that's going to be displayed at the top of
every single page given that this thing is displayed at the top of every page.
There's definitely two ways we can go about designing it and showing it on the screen.
Option number one would be to go into every one of our different page components such as index dot J.S.
sign in and sign up and in each of these we could add in about inside a sign in at the very top.
Maybe like right above that form some kind of like reusable header component.
If we took this kind of approach we would have to go round to every different page and remember to add
in that header element there's definitely a better way to handle this.
You might recall then site of our pages directory we had created a custom app component that was inside
of our underscore abduct J as file.
The reason we had originally done this was to just be able to include some global sea assets but it
turns out that this custom app combined right here can also be used to show some elements on the screen.
They'll be visible on every single page.
Remember that this component prop right here is really the page that you're trying to show.
So component will be equal to our signing component or sign up or the landing page.
So if we want to show something that's gonna be visible on every page we can wrap this component with
that extra content.
Let me show you what I mean.
I'm going to add in a dip right here around that component and then right above the component itself.
I'm gonna put on in each one of header.
Make sure you move the semicolon at the very end of component.
If you had 1 0 then save this and I'll flip back over and let's see what we get.
OK well we now have header at the very top.
And if I start to navigate to some other routes you'll notice that's present everywhere.
So without a doubt this would be a pretty solid way of getting the header to be displayed on the screen.
Now one thing that we need to really understand around this header is that it's kind of reactive in
nature as the user starts to sign in and sign out of our application.
We need to update the content in the header.
So if the user is not signed in we need to show some links to go to the sign up in sign and pages.
But once a user is authenticated we're going to change that to just say Sign out instead so that means
that our header needs to understand who the current user is and that kind of presents a little bit of
a problem for us with our current architecture.
Let me show you a diagram to help you understand why it's at present.
This is what we're saying that we want to do.
We want our app component to always display a header and possibly index not just sign up or sign in
at present index such s is already fetching some data to figure out who the current user is.
But we are now saying that we want to somehow also have our header now with the current user is rather
than having two separate requests to fetch some data.
It makes a lot of sense to really just centralize that data fetching Logic up into the app component
alone.
So the app component can be in charge of some get initial prompts function to fetch the current user
so it can fetch the current user and then pass that down as a prop into the header and index.
J.S. that's what we're going to start to do rather than having the landing page figure out who the current
user is.
We're going to extract that into the app component instead.
Then once the app component understands who the current user is it can pass it down as a prop into header
and index dot J.S..
So eventually right here instead of each one we'll have an actual header component and we'll pass down
some prop to it that says hey here's the current user.
Same thing for this component as well.
Remember that component is going to eventually be the index not J.S. component.
And so we can somehow include it in this J.S. sex element and this definitely sounds like not the worst
thing in the world but there is a little bit of a complication.
We need to be aware of we're saying right now that we're going to move this data fetching logic from
index up to app.
What that really means is we are going to define get initial props inside of our app component and index
our chests will not require a get initial props function anymore.
So we're moving that entire function over an index which I guess is not going to have one.
However at some point in the future I think it is not unreasonable to say that we might have some other
components that does need to have some get initial promise function.
Maybe it will be the landing page.
Maybe it'll be some other page but we probably are going to eventually be in a scenario where we want
to have both the app component have get initial props and some page have get initial props as well.
And it turns out that having these two different components or these two different pages with the get
initial prowess function is a little bit more challenging to deal with with next J.S. than you would
probably expect as we're kind of finding his true with a lot of this stuff right next to us.
Anyways the point is we might eventually want to have get initial props up here and down here as well
and to accommodate for that we do have to add in a little bit of extra code something to be aware of.
But right now let's just focus on relocating get initial props from landing page up to app component.
It's quite possible start to write out this code in just a moment.