Benefits of different client side useSession() implementations

[lukvermeulen]

Question 💬

Hey there,
having a confusing time trying to wrap my head around the client side implementations of useSession().

1. The probably most easy implementation can be found in the securing pages and api routes documentation. I'd say the approach of retrieving the session and rendering different things according to the status is straight forward and clear.

2. With examples in the client api implementations, things get confusing for me. Both require session and custom session handling mention, that

Due to the way Next.js handles getServerSideProps / getInitialProps, every protected page load has to make a server-side request to check if the session is valid and then generate the requested page

.

This results in the following questions for me:

• Does this mean, that the approach from point 1 transforms my page into a SSR page or is an inefficient way of checking authentication?
• Both options mentioned in point 2 seem to do the same thing to me: Ensure that the session is never null once fetched, and being more efficient by passing session as a prop to the SessionProvider, but also redirecting the user if he is not logged in. Is this correct? If so, what would the benefits or differences of either option (require session vs custom client session handling) be and when would I chose which implementation?

If someone could clarify this, that would be much appreciated! Thanks in advance.

How to reproduce ☕️

Example code snippets are provided in the linked documentation.

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[balazsorban44]

Using API routes is pretty straight forward in most cases. one request in, one response out. Everything is sequential.

Clientside is a bit trickier, because you don't know the user's interaction before hand, you don't know when they make a request to the authenticated part of your app!

For this reason, we cache the session in-memory (in a single React state, nothing fancy) that you receive from the backend.

That state is then reused several times. This means you don't have to make expensive calls to check the session every time. This cache has to be populated somehow though. You have two options:

1. use getServerSideProps or getInitialProps to receive a session BEFORE the page loads, and pass it to SessionProvider so when the client is ready, it doesn't have to go to the backend to get it. it already has a session on the first load. drawback is that you'll end up with a slightly longer loading time, and a bit more pressure on the server as this will happen on every page request. advantage is that you won't have any flicker/loading state of the session, since you already have it in the cache!
2. when a session is not passed to the cache to begin with, first we have to go and fetch it to populate the cache. this will result in a faster page load, but an intermediate time when you have to show a loading screen to your user.

it's up to you to decide which approach makes most sense to you

[lukvermeulen]

Thanks balazs, that explains a lot on what is going on behind the scenes!

A follow up question: Can I assume, that when using the useSession() hook, that I am always using your option 2 (fetch the session and populate it while displaying a loading screen?)? And if so, are the different implementations described here just different flavors of fetching the session client side?

Example: I would want the navigation to be happening client side, thus not using SSR. That would mean I would use a loading state and fetch the client side. Can I do this with any of the shown useSession() implementations, or do I need to chose a specific one for that?

Thanks!

[balazsorban44]

useSession in itself doesn't populate any cache. it just uses a shared state (React Context) that SessionProvider provides.

The described alternatives are just different flavors for managing the session cache as you said.

Worth noting that v3 works a bit differently. It was previously not required to add a SessionProvider, and in that case, useSession would fetch a new session every time, since it didn't have the shared state! This caused multiple problems because the implementation broke with usual React paradigms (didn't follow the Rules of Hooks https://reactjs.org/docs/hooks-rules.html)

hence from v4, SessionProvider is mandatory.