feat: Split `GetInferenceHelpers` in `Output` and `Input`

Describe the feature you’d like to request

Instead of having inference helpers that expose input and output together, I think we should make two distinct inference helpers

Current:

type RouterTypes = GetInferenceHelpers<AppRouter>;

type Post = RouterTypes['public']['post']['list']['output']['items'][number];
// Getting `items[number]` of `public.post.list.output`
// Hard to read

Describe the solution you’d like to see

Better legibility:

type RouterOutput = GetOutputInferenceHelpers<AppRouter>;
type RouterInput = GetInputInferenceHelpers<AppRouter>;


type Post = RouterOutput['public']['post']['list']['items'][number];

Split inference helpers in two.

Desribe alternate solutions

We could also allow for this, which is even better legibility but will negatively affect TS perf on bigger routers.

Flattened path

type RouterOutput = inferRouterOutput<AppRouter>;
type RouterInput = inferRouterInput<AppRouter>;


type Post = RouterOutput['public.post.list']['items'][number];

Fake representation of a router

@sachinraja brought up this idea as well:

// could be a proxy for a readable error or we could just straight-up lie about the types

const routerOutputs = createRouterOutputTypes<AppRouter>();
const routerInputs = createRouterOutputTypes<AppRouter>();

type Post = typeof routerOutputs.post.byId

It’s arguably a lot nicer for power users, but we do lie about the types.

Additional information

Discussion about naming: https://github.com/trpc/trpc/discussions/2825

👨‍👧‍👦 Contributing

• 🙋‍♂️ Yes, I’d be down to file a PR implementing this feature!

[sachinraja]

I would go with option 4:

• Keep the GetXInferenceHelpers and inferProcedureX
• Remove GetInferenceHelpers
• Change the docs so we show a clear preference for GetXInferenceHelpers

[rhenriquez28]

It wouldn’t because TS defers evaluation of object properties.

Oh well, TIL. That being said, between just splitting the inference helpers and using the flattened path (with whichever approach you decide to go with), I very much prefer the flattened path. It’s more readable and faster to work with.