Loosen `trpcNext.CreateNextContextOptions` type for better SSR support about trpc HOT 5 CLOSED

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)

from trpc.

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) {

from trpc.

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

from trpc.

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

from trpc.

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

usage

from trpc.