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');