Loosen trpcNext.CreateNextContextOptions type for better SSR support

[kripod]

I just started using trpcNext.CreateNextContextOptions and noticed that it’s typed as follows:

type CreateNextContextOptions = {
  req: NextApiRequest,
  res: NextApiResponse,
};

While it works great for API requests, the context that gets passed to getServerSideProps only contains a portion of this information – the basis of NextApiRequest and NextApiResponse objects:

import type { IncomingMessage, ServerResponse } from "http";

type GetServerSidePropsContextOptions = {
  req: IncomingMessage & { cookies: NextApiRequestCookies },
  res: ServerResponse,
};

In order to support SSR better and keep the API context versatile, I propose a context in which only the req object is mandatory during SSR, as responses shouldn’t be altered in that case. API functionality is kept intact:

type CreateNextContextOptions =
  | {
      req: NextApiRequest;
      res: NextApiResponse;
    }
  | {
      req: IncomingMessage & { cookies: NextApiRequestCookies };
      // Altering responses during SSR isn’t a good idea:
      res?: never; // Previous thought: `res?: ServerResponse;`
    };

[kripod]

With this change, the parameter given to createContext should always be required:

- export async function createContext(opts?: trpcNext.CreateNextContextOptions) {
+ export async function createContext(opts: trpcNext.CreateNextContextOptions) {

[KATT]

You know, you can simply do ssr: true in the top level HOC to enable ssr, you don't need to do any manual ssr stuff unless you specifically want ssg

See https://trpc.io/docs/ssr

On my phone, will answer properly later

[KATT]

The next-hello-world example has ssr enabled if you want a reference

[kripod]

I know about the { ssr: true } option, but that relies upon getInitialProps, which breaks SSG for static pages. I wouldn’t like to use that option due to this.

I think the default context parameter should be adjusted regardless of that, even when { ssr: true } is specified. I proposed not to forward res during SSR, but always forward req so that cookies can be read (e.g. for auth)

[KATT]

I think you have a good point but we'd need a third constant to make it easy to differentiate between them:

type CreateNextContextOptions =
  | {
      type: 'api',
      req: NextApiRequest;
      res: NextApiResponse;
    }
  | {
      type: 'ssr',
      req: IncomingMessage & { cookies: NextApiRequestCookies };
      // Altering responses during SSR isn’t a good idea:
      res?: never; // Previous thought: `res?: ServerResponse;`
    };

---

The way I've solved this myself when I wanted similar stuff in my getStaticProps-fns is to make opts optional so I can simply call my createContext from the function.

Example

context fn

trpc/examples/next-prisma-todomvc/pages/api/trpc/[trpc].ts

Lines 10 to 19 in b0ad15e

	export const createContext = async (
	opts?: trpcNext.CreateNextContextOptions,
	) => {
	return {
	req: opts?.req,
	prisma,
	task: prisma.task,
	};
	};
	export type Context = trpc.inferAsyncReturnType<typeof createContext>;

usage

trpc/examples/next-prisma-todomvc/pages/[filter].tsx

Lines 340 to 346 in b0ad15e

	const ssg = createSSGHelpers({
	router: appRouter,
	transformer,
	ctx: await createContext(),
	});
	await ssg.fetchQuery('todos.all');

[kripod]

Making opts optional doesn’t work in my case, as most API endpoints require authentication via cookies, so passing the req object is mandatory in both cases. I think that most applications with cookie-based auth have a similar problem – that’s why I’m proposing to make req mandatory and res optional.

When we have a res specified, we know that we’re handling an API request, not an SSR-invoked one. I think that specifying a new type parameter is redundant and should be left as an option to add in user-land.

[KATT]

For now can you try the following?:

type SSRContextOptions = {
  req: IncomingMessage & { cookies: NextApiRequestCookies };
  res?: never; // Previous thought: `res?: ServerResponse;`
};
export const createContext = async (
  opts: trpcNext.CreateNextContextOptions | SSRContextOptions,
) => {
  return {
    // ...
  };
};
export type Context = trpc.inferAsyncReturnType<typeof createContext>;

Play with it and see how it works for you

[KATT]

I might consider adding this as a default, potentially with the extra type:-const if we deem it needed

[kripod]

Sure, thank you! I’ve tried it out and it works without flaws. TypeScript even warns me when I try to pass the entire context parameter of gSSP – which includes a res object. Thank you for considering the change!

[domnantas]

I just wanted to mention that I encountered the same issue – I have getServerSideProps/getStaticProps that require auth in context. I agree that expanding CreateNextContextOptions to include the getServerSideProps/getStaticProps would probably be the best approach. My proposal:

export type CreateNextContextOptions = NodeHTTPCreateContextFnOptions<
  NextApiRequest,
  NextApiResponse
> | Pick<GetServerSidePropsContext, "req" | "res">;