SSR with Client Components
I've been banging my head against the wall for a while now trying to get the following to work:
- I have a client component that gets queries for some data, but I want it to be able to get that data during SSR as well
- Right now, a request is made, but it does not pass along headers, causing it to throw an error on the server due to being unauthorized.
What's the correct way to pass along the headers from the initial request during SSR?
Solution:Jump to solution
I finally managed to find an (incredibly janky) solution:
- A server component runs
await headers() and then passes it into a client component that then passes it into a context
- The TRPC client reads said headers
...11 Replies
Solution
I finally managed to find an (incredibly janky) solution:
- A server component runs
await headers() and then passes it into a client component that then passes it into a context
- The TRPC client reads said headers
I feel like this should be listed somewhere on the docs.I think it should work if you use prefetching and hydration boundaries in the server component
And is the headers not accessible in the browser with that method? You could try looking at something like ssr-only-secrets
npm
ssr-only-secrets
This package provides a way to pass secrets from Server Components into the SSR-run of Client Components, without them being accessible in the browser.. Latest version: 0.1.2, last published: a year ago. Start using ssr-only-secrets in your project by running
npm i ssr-only-secrets. There are no other projects in the npm registry using ssr-onl...i wouldn't consider headers sensitive data, especially given the fact that the client is the one sending headers
Even if you are using HttpOnly cookies? If you are, would that not make the 'HttpOnly' part useless, as you are sending it down to the client in the HTML?
i don't believe i'm using httponly cookies, and to be honest, the idea of having a cookie that can't be accessed by javascript still feels so fragile and insecure that I just don't rely on it
I don’t see why you wouldn’t use it. It’s just extra protection against XSS attacks and generally considered good practice.
okay, for the sake of not installing another dependency, i'm just gonna store a global WeakMap, and instead of the SSR context storing the headers directly, they store an object which can be accessed in the server only WeakMap
Did you try the prefetching and hydration boundaries? Seems a bit simpler and might do the job.
i tried a while ago, and i couldn't get it to work, plus manually setting up prefetching for every route is a bit of a pain
Totally agree that it's a pain in the ass, but it can be made a bit easier with some helper functions