Access response headers in "vanilla client?"

[peterp]

Hey!

I'm trying to gain access to the response headers for each request processed via the vanilla client. My assumption is that this would be available through a link, but I can't find a way to reference the headers anywhere.

Happy to contribute docs!

[KATT]

I built support for this before I had links, maybe it would make more sense to have it as part of links! Right now you have it when you initialize the client.

Here's an example:

const client = createTRPCClient<AppRouter>({
  links: [
    () =>
      ({ op, prev, next }) => {
        console.log('->', op.type, op.path, op.input);

        return next(op, (result) => {
          console.log('<-', op.type, op.path, op.input, ':', result);
          prev(result);
        });
      },
    httpBatchLink({ url }),
  ],
  headers() {
    // do whatever you want here - will be called for every request
    return {
      'x-cat': 'MEOW',
    }
  }
});

I would love some improved docs on this! 🙏

[peterp]

Unfortunate. It's very hard to do this well in a CLI without resorting to headers, otherwise every command has a synchronous call that needs to be completed before you can complete output.

Is there's no hidden access via a link, or something temporary that can be injected into those?

[KATT]

No, there's no hidden access via the link and I can't add more metadata to it as it's only accepting the data without a surrounding envelope right now.

What you could do is to write your own ending http link that looks out for this and do some sort of global messaging outside of it.

Files that could help guide you:

• https://github.com/trpc/trpc/blob/main/packages/client/src/links/httpLink.ts
• https://github.com/trpc/trpc/blob/main/packages/client/src/internals/httpRequest.ts
• https://github.com/trpc/trpc/blob/main/packages/client/src/internals/transformRPCResponse.ts

[KATT]

Sidenote: I'm not super happy with the links architecture - getting subscriptions to work made it all quite convoluted, but it works and is well-tested.

In the future, I want the link chain to be an observer where the results can be updated several times along the chain, even for queries. If we nail that, we could do a react-lite that didn't rely on react-query and allow for a lot smarter links for things like query deduplication/caching/etc that we rely on react-query for right now.

[peterp]

Thanks @KATT, I'll give it a try and looking forward to helping along with the future architectural decisions.

[KATT]

#1366

In this, I add more features to the response so one can get meta data from the request and not only the data it returns
It will also be possible to make react-query redundant and make a lighter version where you cherry-pick the features you need by adding different links (similar to urql).

If you're familiar with observables/rxjs I'd love some eyes on it

(I did my own naive observables implementation because I don't want trpc to have deps)

I'd happily do a video walk-through of the architectural decisions or jump on a call to talk it through.