fix(trpc): allow to pass custom headers to trpc client

[goetzrobin]

A tRPCHeaders signal is exposed to set/get the headers added to each tRPC call. This allows us to, e.g. add an authorization header that we can then use to create protected procedures that can only be executed when the user is authorized.

closes #394

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/analogjs/analog/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

Which package are you modifying?

• vite-plugin-angular
• vite-plugin-nitro
• astro-angular
• create-analog
• router
• platform
• content
• nx-plugin
• trpc

What is the current behavior?

Closes #394

What is the new behavior?

You can provide custom headers to the trpc client by setting the tRPCHeaders signal

Does this PR introduce a breaking change?

• Yes
• No

Other information

It works but I feel like the way we configure the tRPC client could be much better.
I think we should aim for a way to configure the tRPC client like @markostanimirovic allows the ngrx signal store to be configured. I want to get this merged because it is essential for anyone who wants to use the client for anything that is
not public and the DX is alright but we should definitely rethink the way we allow people to configure the tRPC client.

const { tRPCClient, provideTRPCClient, tRPCHeaders } = createTrpcClient(
  withTransformer(superjson),
  withLinks([yourCustomLink()]),
  withHttpBatchLink(
      withURL(''),
      withHeaders()
  )
);

[optional] What gif best describes this PR or how it makes you feel?

[netlify]

✅ Deploy Preview for analog-docs ready!

Name	Link
🔨 Latest commit	a2d7342
🔍 Latest deploy log	https://app.netlify.com/sites/analog-docs/deploys/6470d3ca2ac404000876359a
😎 Deploy Preview	https://deploy-preview-441--analog-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for analog-blog ready!

Name	Link
🔨 Latest commit	a2d7342
🔍 Latest deploy log	https://app.netlify.com/sites/analog-blog/deploys/6470d3ca88667a0009f6679e
😎 Deploy Preview	https://deploy-preview-441--analog-blog.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for analog-app ready!

Name	Link
🔨 Latest commit	a2d7342
🔍 Latest deploy log	https://app.netlify.com/sites/analog-app/deploys/6470d3caf22cd300085cbb31
😎 Deploy Preview	https://deploy-preview-441--analog-app.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[goetzrobin]

@brandonroberts @Dafnik @markostanimirovic please take a look at the Other information section and let me know what you guys think. I might need some help from you guys as I took a look at https://github.com/markostanimirovic/ngrx-signal-store-playground/blob/main/src/lib/signal-store.ts and there's definitely a lot going on that I don't understand yet!

[brandonroberts]

@goetzrobin its worth a look. I don't think we need to build an abstraction on top of tRPC configuration if we give them direct access to configure it already. If we don't maybe we should consider that first and not make this too Angular-specific.

[markostanimirovic]

Hey guys 👋

I think that function composition would not bring many benefits in this case.

SignalStore APIs are designed in a composable way mostly to allow building features that can be reused in multiple stores, overcome limitations of the class-based state mgmt solutions, and enable tree-shaking of unused stuff.

In the case of the createTrpcClient function, I'd keep the current signature. It looks simple and intuitive. 👌

[goetzrobin]

Yeah I might have jumped ahead to some premature optimization on that one. I was just trying to think ahead of we'd ever allow for a Web-socket link and all that. Maybe the way to go is what you suggested @brandonroberts: to expose more of the config directly

[brandonroberts]

Yeah I might have jumped ahead to some premature optimization on that one. I was just trying to think ahead of we'd ever allow for a Web-socket link and all that. Maybe the way to go is what you suggested @brandonroberts: to expose more of the config directly

Its less for you to maintain in the long run 🙂