In the last section, we worked on the header component inside of our application and I got a little
bit of an error message about the React router library not being found.
That was a little bit of configuration error that was on my side.
I fixed it up.
So you probably didn't have that air at all.
Again, it was just a small mistake that I made.
So we've now got the text header showing on the screen, which means our header component is successfully
being displayed to our users, which is exactly what we want to have.
So that's definitely good.
Now that we've got the header on the screen, we need to start thinking about what content it needs
to show.
So let's look at a diagram that's going to help us figure out exactly how to deal with this header.
OK, so when our application first loads up on the page and the user sees that header component on the
screen, we want to make sure that it shows the correct buttons inside the header, depending on whether
or not the user is currently authenticated with our application.
So when our header first loads up, I'm going to suggest that maybe we make a query to get our current
authentication state.
So remember that we just added in a field to our route query type to ask whether or not our user is
currently signed in or to get the currently signed end user.
So if we make a query inside of the header and we ask for that piece of data from our server, we can
say that if the user is currently signed in will show a set of buttons that allow the user to log out.
So that will probably be just a single button that says log out and if the user clicks it, we'll call
the log out mutation.
So that's definitely straightforward enough.
Now, if the user is not currently authenticated, so if they are not yet signed into our application,
we can show a set of login buttons instead.
And those login buttons will be a button that say, you know, maybe log in and log out.
So it'll allow the user to click on one of those and then go to the appropriate form to actually sign
in or sign up to our application.
So I think this is a good plan to go forward with.
Will first write out our query inside of graphical and then we'll move the query over to our application
and then make sure that we call the query from inside of our header component.
So let's get to it first.
I'm going to switch on over to graphical.
Now, one of the last queries that we wrote was actually to test the current user query on the route,
the route query type.
So we've kind of already got this thing up here.
If you deleted this for any reason, then you can certainly rewrite the query out very quickly.
Here we are asking the query type to find the current user and we're asking to get back the current
email and ID associated with them.
So I'm going to add on the ID on there as well.
You know, refresh it just to make sure that we get the ID as well.
Cool.
So now we can ask for the currently authenticated user and we get back the ID and the email of that
user, just as we would expect, do you remember that if you see a user of NUL over here, that means
that you're not currently authenticated with our application, which means you can run the login mutation
to authenticate with the application and then you can rerun this query right here to get back the ID
in the email of your currently authenticated user.
OK, so we're going to take this query over here and we're going to move it over to our application,
so I just copied it.
We're going to move it over to our application inside of a new file that's going to house all of our
different queries in my client directory.
I'm going to make a new folder first and I'm going to call it queries.
So I don't really expect to have many queries associated with this application.
But definitely I want to, wherever possible, try to isolate them into a single file just in case we
need to ask in multiple locations for the currently authenticated user.
So inside of here, I'm going to make a new file called Current User G.S..
So this current user query will be responsible for returning the current user of our application.
We've written queries inside of individual files several times before, so remember, at the very top
will import the GQ will helper from Graff QOL tag and then we'll export default.
The actual query.
And again, we've done this several times.
We place our GQ helper, we place our template string, and then we paste in our query like sell.
OK, that's looking pretty good.
We can now import this query into our header component and then instantly run the query whenever the
header is rendered onto the screen.
So I'm going to flip on over to my header at the top.
We're going to import both the query that we just wrote and the graphical helper from the reactive Paulo
Library.
So we'll first import graph QOL from React Apollo.
Remember that this function right here is what allows us to take a query and a component and sandwiched
the two of them together.
And then we'll also import our current user query.
We can just call it query instead.
Let's just keep it simple and call it query from up one directory and the queries folder and get the
current user query.
All right, next, we've done this next several times before to a lot of repeat code in here, we'll
place the graphical helper at the bottom will pass that the query that we want it to execute and then
wrap the component in a second set of parentheses after it.
OK, so again, our job now is to run this query, look at the query and then decide whether or not
we want to show a set of buttons that allow the user to log out or allow them to navigate to a form
to log in or sign up to our application.
So I'm going to suggest that maybe we can log the results of the query and then we look at the query
itself and figure out exactly what properties we can refer to to decide what content we want to render
inside the header.
So essentially, whether or not we want to show the button to log out or the two buttons to sign in.
So I'm going to place a log in here and we're just going to log out the results of the query, we're
going to look at it and decide what to do.
Remember that the results of the query always exists on this props dot data.
OK, so this is looking pretty good.
I think that we're just about ready to give this a test.
I'm going to flip on over to my application.
I'm going to refresh the page and I get my two queries logged out here.
Perfect.
So just what I want.
Remember that the first result right here is from when before the query is actually completed.
So that is the first time the component is rendered.
The component is rendered instantly as the query is in progress and then the component renders another
time once the component or once the query has been completed.
So let's look at the data on these things and see what we have available.
OK, so it looks like in the case that the user or the query has not been completed, loading is true
and we've seen this property several times before.
Chances are that when loading is true, we have not yet fetched any details about the user whatsoever.
So I do not yet know whether or not I want to show some content to the user to say, oh yeah, you need
to sign in or you are signed in.
When loading is true, I still don't know what to render.
So I think that we should probably have some catch inside of our component to say that if the query
is still in progress, I probably don't want to show any buttons whatsoever because I don't want to
assume that the user is or is not logged out.
Now, in the response or the second counselling that we get here, we have a loading of false debt,
so that definitely makes sense.
The query is now completed and our user field is null, which means our user is not currently authenticated.
Now, if you're looking at this and you're trying to say you're trying to figure out, well, Stephen,
didn't we just make a query which said that we are authenticated?
Aren't we currently authenticated with the server?
Shouldn't user be populated right here?
Well, the answer is yeah.
We'll get to that in just a second.
Just bear with me for a moment.
The last thing I want to say about this is just after loading flips over to false, we will be able
to look at this user property right here and if user is not null.
So if a user is an object that has an ID and an email, that means that we should probably show the
log out button.
But in the case that user is null, well, then we should probably show the two buttons that allow the
user to navigate over to the sign up or sign in forms.
OK, so that's the overall plan here.
We want to look at the loading flag first and figure out whether or not we should show any buttons.
And then once loading is false, we can then look at the user property and decide what we want to actually
do.
OK, now I want to go back to something that I kind of interjected in there where I said that we're
looking at this user property and it's set to null.
But we had just ran a query over here, which seems to think that we are currently authenticated.
So remember that you'll only see an ID in email right here if you have already signed in to the application.
So if you are not currently signed in, be sure to run the login mutation and then you'll be able to
ask for the current user and see the idea of the email that you're currently signed in as.
Anyways, what I what I'm trying to indicate here, what I'm trying to show to you is that when we run
this query to get the current user inside of graphical, everything around authentication functions
the way that we expect.
We are currently signed into the application.
However, when we run the query inside of our application, it appears that we are not correctly fetching
the current user.
So it looks like between graphical and our application, there's a little bit of a disagreement on whether
or not we're currently authenticated.
So let's take a pause from our header in the next section and let's figure out what's going on here
and let's figure out why our current user is not correctly being fetched inside of our application.