Now we made good progress
before we explored as change Password feature
and all of that.
There is a little optimization, which you could
consider implementing, especially if you had
a bigger Application.
At the moment, we're using this session
functionality in a couple of different components.
To be precise we use use session
in the Main Navigation component.
Now, one problem we have
with that is that if we are authenticated
and I reload whilst on this profile page
then we figure out whether the user is authenticated
or not in that get service side props function of that page,
here, this function runs,
and then after the page was loaded, does use session hook
which we use and Main Navigation.
We'll technically also, again, run some logic to find
out whether we have a session or not.
And we see this here in the Network tab.
If I reload, you see there is a request being
sent to /api/auth/session.
That request is actually sent by that use session hook.
And it's sent to check Whether that session cookie
which had found is valid,
because we can't validate that
with client site JavaScript for security reasons.
Hence that cookie needs to be sent to an end point
which then determines whether it is valid or not.
So that's why this request is being sent.
There is nothing wrong with this request, but
since we already checked our session here in
getServerSideProps.
when we loaded slash profile
we already know that we are authenticated.
So this is actually a redundant request
which is being sent here.
And we can avoid it,
by using a extra component offered
by next off in our _app.JS file.
So in this file which wraps all our page components,
which are being rendered.
We can import the special Provider component from
next-auth/client.
This is a wrapper
which we can wrap around all our other components.
So around the layout and de nested components
and then Provider
once a session prop, and here we simply set,
any session data, which we might already have.
Now, the interesting thing is
that here in this root app component
we don't just get the page component that should be loaded
but all of the Props for that page.
So the Props determined by get static Props
or getServerSideProps,
and at least for our profile page
these Props will contain a session key
with the session we validated inside of getServerSideProps.
So we are setting this session Prop
on this profile page and we are setting it to this session
which we already loaded
and validated with that service side code.
That means that not all our pages, but some pages
in this case, the Profile page we'll have a session
Prop with session data.
So we can set the session
for this Provider component equal to pageProps.session.
In most cases, this will be undefined
because most pages don't have this Prop
but our profile page, for example, does have it.
And then the session is already set to this already
loaded session.
And that then allows next off to skip the extra session
check performed by use session.
If we already have the session from our
getServeSideProp function.
Now, if we loaded number of component, where does this not
set session is on the find and use session
We'll still do its thing and check it manually.
But in cases where we already know that there is a session
we can save some performance and a wide
some redundant HTTP requests.
And that's never a bad thing simply by wrapping our
Application with this extra provider component
and utilizing the information which we already have,
now here in my case, I actually still see this extra session
request being made here thereafter.
Next off will have its reasons.
Nonetheless, using this provider wrapper, is a recommended
pattern because it theoretically or practically allows next
off to optimize itself internally,
and skip certain checks
and possibly HTTP requests.
Even though we unfortunately don't see that here
nonetheless, adding this extra wrapper is
a recommended optimization
which idea for, of course also a wanted to show to You.