feat(react-query): Generate polymorphic route/mutation/query interfaces from tRPC router

[Nick-Lucas]

This adds some helper types under react-query/src/shared/polymorphism, primarily RouterLike<TProcedure>, MutationLike<TProcedure> and QueryLike<TProcedure>, and documents a factory pattern for generating routes which share common functionality across several sub-routes.

The goal is to provide a 1st class API for passing around a factory-built route to React components, so we can build generic components with a variable tRPC route. I'm referring to it as polymorphism but there might be a better name here.

Closes #3627

🎯 Changes

What changes are made in this PR? Is it a feature or a bug fix?

✅ Checklist

• I have followed the steps listed in the Contributing guide.
• If necessary, I have added documentation related to the changes made.
• I have added or updated the tests related to the changes made.

[vercel]

@Nick-Lucas is attempting to deploy a commit to the trpc Team on Vercel.

A member of the Team first needs to authorize it.

[KATT]

Cool!

• I think the QueryLike and MutationLike types are useful. They should be exported in @trpc/react-query/shared
• Documentation should be added in here. I think it can be quite light with a link to the test you're making as a reference.
• I'd like the test, since it might also act as documentation, should import more comments

[Nick-Lucas]

Since this section is part of the react-query library and not particularly portable to other clients, should we actually move these to a new file under the react docs? Perhaps www/docs/react/infer-types.md?

[Nick-Lucas]

Thanks for the initial feedback, I believe that's all covered now. I've added some higher level types and the docs, plus had a stab at finding the right home for a couple types.

Once we're happy with this, I do think it will be worth it to write a test with a router factory which can utilise sub-types, and adapt the polymorphic types to work in that case. Having a generic (in the true OO sense) react component which can accept a sub-type and some inversion-of-control for the extra fields seems like the natural continuation of this work, and pretty important if a use case is to include a CRUD factory where the entities are all based off a core type like { id, name, createdAt, createdBy, modifiedAt, modifiedBy }. I need to investigate some appropriate React patterns for this.

[Nick-Lucas]

Okay, I've added a second example today to check support for sub-types in both the input/output data, and in extending the router beyond the initial factory result.

I believe this is ready now @KATT though obviously it's changed significantly since you last reviewed so I'm expecting some change requests :)

[KATT]

I really like this, but I want a second pair of eyes on it before merging.

can any of you guys check it, @trpc/trpc-core and smash the merge button?

[Nick-Lucas]

Thanks @sachinraja, looks like prettier wanted the imports in a different order so I've pushed that. Also rebased to get things up to date

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
next-prisma-starter	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 8, 2023 at 3:08PM (UTC)
og-image	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 8, 2023 at 3:08PM (UTC)
www	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 8, 2023 at 3:08PM (UTC)

[sachinraja]

I have some reservations about merging this, primarily because those tests look type-heavy but I don't know when I'll get to addressing those so this is fine to merge now. The types themselves look good and I can think of valid use cases for them.

[Nick-Lucas]

I have some reservations about merging this, primarily because those tests look type-heavy but I don't know when I'll get to addressing those so this is fine to merge now. The types themselves look good and I can think of valid use cases for them.

Thanks for getting this over the line!

Yes the tests ended up pretty substantial. We can probably almost half the test code (and move code from the sister files into the spec) just by jettisoning the simpler example, but since the goal was for them also to serve as an example linked in the docs it might be worth doing that at the same time as standing up an example project for the factory pattern.

I'm pretty active on discord if you want to chat informally about it and come up with a plan