next-auth: SSR + useSession causes an extra network call and render cycle

Hi there! I am writing this comment while I am using version 4, in fact, I am not entirely sure if my problem is related to what was presented in this problem or that the fixes that were introduced solve my problem, but despite all this, I am facing a similar problem, I will describe it. I use the useSession hook in order to get the session and store it in context, it works fine except it sends many extra requests to the /api/auth/session which are useless after actually getting the session for the first time, I mean the session is checked repeatedly whenever lose focus and refocus the window. I attached a screenshot of the successive requests.

I am looking forward to getting rid of these requests, I hope this is clear.

I think doing it “right” does require some kind of fix or re-structuring on the next-auth side, but I can share a workaround I’ve been using in the meantime.

The basic goal is to write our own context that provides the session object.

The naive approach looks like this in _app.tsx:

import { getSession, Session } from "next-auth/client";

type ExpandedAppProps = AppProps & { session: Session };

const App = ({ Component, pageProps, session }: ExpandedAppProps) => {
	return (
		<MyCustomContext.Provider value={{ session }}>
			<Component {...pageProps} />
		</MyCustomContext.Provider>
	);
};

App.getInitialProps = async ({ ctx }: AppContext) => {
	const session = await getSession(ctx);
	return { session };
};

The problem with this is that there’s no way to access the session from getServerSideProps, since getServerSideProps is only passed a ctx: GetServerSidePropsContext object. I don’t think this ctx is always the same (===) one that is passed to App.getInitialProps, but the request object ctx.req definitely is the same for both.

What does this mean? It means this is a perfect place to use a WeakMap!

In some common file utils.ts:

import { Session, getSession } from "next-auth/client";

const sessionCache = new WeakMap<NextApiRequest, Session | null>()

export async function getCachedSession({ req }: { req: NextApiRequest }): Session | null {
  const session = sessionCache.get(req)
  if (sessionCache.has(req)) {
    return sessionCache.get(req)!
  } else {
    const session = await getSession({ req })
    sessionCache.set(req, session)
    return session
  }
}

then you can call await getCachedSession(ctx) from both App.getInitialProps and from getServerSideProps and it’ll only end up calling getSession once. Then on the client, we can get the session with useContext(MyCustomContext) whenever we need it.

Hope this helps! It’s pretty hacky - it’d be really great if the next-auth provider could encapsulate this.

(you might have to mess around with the types a little bit since I think ctx.req is a NextApiRequest when it’s in App.getInitialProps but just a plain IncomingMessage when it’s in getServerSideProps or something…)

@thilllon

Thanks, @ivan-kleshnin However, for what reasons should we Disable strict mode of React. ? https://reactjs.org/docs/strict-mode.html

The reason is React 18 with strict mode enabled will render components twice in dev environment. https://beta.reactjs.org/learn/keeping-components-pure#detecting-impure-calculations-with-strict-mode

We are working on making the next-auth core fully framework agnostic. 👍

you’ll be able to implement your own client however you want, or just use the REST api directly (that you can already do, see https://next-auth.js.org/getting-started/rest-api)

@3li7u it’s a classic case of “The road to hell is paved with good intentions”. React and Next-Auth try to help us a bit too much…

1. Disable strict mode of React.
2. useSession does not deduplicate queries. Don’t use SessionProvider and useSession and write your own useSession hook like https://github.com/nextauthjs/react-query/blob/main/index.js It can be based on React-Query or Apollo-Client or URQL or whatever you prefer.

👉 You really want to fetch & cache all data with a single “state-management-and-fetcher” tool (of your choice):

• to rely on a single devtools and see all data there!
• to rely on a single cross-tab sync tool!
• to not rehydrate in 2 different ways after SSR!

To me, using an out-of-the-box useSession feels like using an out-of-the-box signin form. It’s approapriate as a one-off, dev-mode solution but it’s not intended to be a final code.

I especially question the design decision to have a SessionProvider that triggers the first fetch. In my mind no component named like *Provider* should ever fetch or do other effects.

Hi there! A reproduction repo with a link would be extremely helpful to debug your issue. 🙂

In your getServerSideProps, you should return the session in props. Please see the Next.js docs.

Then in your _app, you should pass pageProps.session to the Provider ({ Provider } from 'next-auth/client')

If you could verify the behavior you are describing with a minimal reproduction, then maybe it is something in next-auth.

UPDATE: sorry, I have to read through the OP’s comment a bit more thoroughly, you say it happens with our official example as well. I’ll have a look.