trpc

trpc copied to clipboard

From @TheoBr - https://clips.twitch.tv/SleepyVibrantGrasshopperDxCat-ZJjzoC-yQHmSmyDE

• [ ] Add this on the /examples/next-prisma-starter: https://github.com/trpc/examples-next-prisma-starter-websockets/blob/main/src/pages/_app.tsx#L75
• [ ] Add docs in https://trpc.io/docs/ssr
• [ ] https://github.com/trpc/examples-next-prisma-starter/blob/db7e2c1469170a660a12a45d7c40829ed4bc9509/src/pages/_app.tsx#L28-L44
• [ ] Make sure you don't use getServerSideProps or getStaticProps anywhere in the app (#596)

Maybe it would be better to move https://github.com/trpc/examples-next-prisma-starter-websockets/blob/main/src/pages/_app.tsx#L76 inside the withTRPC implementation and merge those headers with the user provided headers? This would simplify configuration and probably solve 90% of use cases.

Maybe it would be better to move https://github.com/trpc/examples-next-prisma-starter-websockets/blob/main/src/pages/_app.tsx#L76 inside the withTRPC implementation and merge those headers with the user provided headers? This would simplify configuration and probably solve 90% of use cases.

Can there be a case where one would not want to merge the client's headers during SSR?

Maybe it would be better to move https://github.com/trpc/examples-next-prisma-starter-websockets/blob/main/src/pages/_app.tsx#L76 inside the withTRPC implementation and merge those headers with the user provided headers? This would simplify configuration and probably solve 90% of use cases.

Can there be a case where one would not want to merge the client's headers during SSR?

Rare that you wouldn't want it, but you might want to add stuff dynamically in the headers and as a framework I don't want trpc to be responsible for keys colliding etc

Just to comment, I think I was running into errors related to https://github.com/trpc/trpc/issues/596#issuecomment-980638289 (and maybe https://github.com/trpc/trpc/issues/2140) and solved by turning SSR off.

Only to say if there are improvements to the docs regarding SSR, I would suggest a clear

• SSR can be integrated for things like x,y,z
  • (example with getInitialProps?)
• SSR cannot (or should not) be used in these ways (not built for x,y,z) (not planning on supporting x for now)
• SSR FAQs

Because my intuitions about how tRPC would run during SSR, just by following example code, seem to stop once I try and add something more like auth or other things, and get a little overwhelmed by some of the configs.

Hi @KATT , I'm the guy you helped with the issue you mentioned in https://github.com/trpc/trpc/issues/2420. I was thinking that maybe we should document the process to forward the headers on the SSR page, at least as an optional step. We have already added the forward header example to create-t3-app (see https://github.com/t3-oss/create-t3-app/commit/30f3db64c3a81475488c712fa16682076ba3f18b), but I fear that some users would be confused as to why they need to do this if it isn't in the docs.

I was thinking of taking the existing SSR doc and doing a little revamp based on @spenceradolph 's suggestions. I would also want to add the justification for why tRPC isn't just forwarding these headers automatically and base it on the answer you gave previously:

Rare that you wouldn't want it, but you might want to add stuff dynamically in the headers and as a framework I don't want trpc to be responsible for keys colliding etc

I would present it here and see where we go from there, what do you think?

Also, I don't know what your plans for this issue are when it comes to v10, so for now I'll assume that nothing has changed in regards to this.

Sorry for the delay, been busy at work. Anyway, this is what I have to improve the SSR docs page:

import superjson from 'superjson';
import type { AppRouter } from './api/trpc/[trpc]';

export const trpc = createTRPCNext<AppRouter>({
  config({ ctx }) {
   ...

    return {
      transformer: superjson, // optional - adds superjson serialization
      url,
      headers: () => {
        if (ctx?.req) {
          // To use SSR properly, you need to forward the client's headers to the server
          const headers = ctx?.req?.headers;
          // If you're using Node 18, delete the "connection" header
          delete headers?.connection;
          return {
            ...headers,
            // optional - inform server that it's an ssr request
            'x-ssr': '1',
          };
        }
        return {};
      },
    };
  },
  ssr: true,
});

FAQ

Q: Why do I need to forward the client's headers to the server manually? Why doesn't tRPC automatically does that for me?

R: While it's rare that you wouldn't want to forward the client's headers to the server when doing SSR, you might want to add things dynamically in the headers. Therefore, tRPC doesn't want to take responsibility for header keys colliding, etc.

Q: Why do I need to delete the connection header when using SSR on Node 18?

R: If you don't remove the connection header, the data fetching will fail with TRPCClientError: fetch failed. (This needs more substance, but I don't know enough about this to write about it haha)

Q: Can I use getServerSideProps and/or getStaticProps while using SSR?

R: When you enable SSR, tRPC will use getInitialProps to prefetch all queries on the server. That causes problems like this when you use getServerSideProps in a page and solving it is out of our hands. Though, you can use SSG Helpers to prefetch queries in getStaticProps or getServerSideProps.

It seems the SSR headers issue has been brought up many times now. Not just in this issue and in https://github.com/trpc/trpc/issues/2420, but also in https://github.com/trpc/trpc/issues/2084 and https://github.com/trpc/trpc/pull/2085 . I think there was a moment where you guys were working on a stripHeaders utility but I don't know if work on that is on pause or something...

This issue has been locked because it had no new activity for 14 days. If you are running into a similar issue, please create a new issue. Thank you.