tRPC•7mo ago

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

I finally managed to find an (incredibly janky) solution:

A server component runs
```
await headers()
```
await headers()
```
await headers()
```
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.

Jump to solution

Solution

andy•5/25/25, 5:29 PM

I finally managed to find an (incredibly janky) solution:

A server component runs
```
await headers()
```
```
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.

Icestonks•5/25/25, 7:36 PM

I think it should work if you use prefetching and hydration boundaries in the server component

Aandy I finally managed to find an (incredibly janky) solution: - A server component ...

Icestonks•5/25/25, 7:40 PM

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-secretsnpm i ssr-only-secrets. There are no other projects in the npm registry using ssr-onl...

IIcestonks And is the headers not accessible in the browser with that method? You could try...

andyOP•5/25/25, 10:18 PM

i wouldn't consider headers sensitive data, especially given the fact that the client is the one sending headers

Aandy i wouldn't consider headers sensitive data, especially given the fact that the c...

Icestonks•5/25/25, 10:31 PM

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?

IIcestonks Even if you are using HttpOnly cookies? If you are, would that not make the 'Htt...

andyOP•5/25/25, 10:32 PM

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

Aandy i don't believe i'm using httponly cookies, and to be honest, the idea of having...

Icestonks•5/25/25, 10:36 PM

I don’t see why you wouldn’t use it. It’s just extra protection against XSS attacks and generally considered good practice.

andyOP•5/25/25, 10:38 PM

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

Aandy okay, for the sake of not installing another dependency, i'm just gonna store a ...

Icestonks•5/25/25, 10:43 PM

Did you try the prefetching and hydration boundaries? Seems a bit simpler and might do the job.

IIcestonks Did you try the prefetching and hydration boundaries? Seems a bit simpler and mi...

andyOP•5/25/25, 10:43 PM

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

Aandy i tried a while ago, and i couldn't get it to work, plus manually setting up pre...

Icestonks•5/25/25, 10:46 PM

Totally agree that it's a pain in the ass, but it can be made a bit easier with some helper functions