Make the trpc API simple #1537
cloudcompute
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
I'm not going to switch to enforcing output schemas, that sort of ruins the point of tRPC. That said, I am looking at ways to simplify this stuff and to allow to more fun DX-things, if you're interested in getting involved, please dive into the issues at https://github.com/trpc/v10-playground :) |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A lot of boilerplate code is there in the current implementation:
a. Method chaining
b. create router
c. ...
Consider this TS interface
Let the users create the two interfaces where the
trpcQueries
andtrpcMutations
are standardtrpc
keywords. For example:createRouter()
,.query()
,.mutation()
,resolve()
, etc. is all boilerplate. The users will simply implement thetrpcQueries
andtrpcMutations
interfaces.This design has a disadvantage though. The user needs to maintain the method signatures at two places. A much better alternative is to let us use the
trpcQuery
andtrpcMutation
decorators.As it is mentioned in the trpc docs..
There's no internal difference between queries and mutations apart from semantics.
, a single decoratortrpc
may do.Currently the user is resolving the input using the different validators. Looks like the
reflect-metadata
package might help us resolve the method's signatures.dear community, kindly give your suggestions.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions