The tracking issue for the version 3 syntax for rspc.
This syntax will come with a major change in the mental model. Instead of thinking about middleware and routers, you will think about procedures that are single operations. This aligns more with the tRPC v10 style of doing things and I think adopting the same patterns for rspc will make for a way better DX.
[x] Queries
[x] Mutations
[x] Subscriptions
[x] Middleware
[x] Middleware context switching
[x] Middleware args
[x] Router merging
[ ] Replace TPrevMapper to TPrevMiddleware in public API
[ ] Error for duplicate procedure names -> using #[track_caller] to help
[ ] Store key as an array and not string ready for proxy syntax
[ ] Fix data_typekey when routing merging
[ ] Unit test duplicate procedure name error, and bindings exporting with complicated router
[ ] Validate procedure names and router prefix patterns
The tracking issue for the version 3 syntax for rspc.
This syntax will come with a major change in the mental model. Instead of thinking about middleware and routers, you will think about procedures that are single operations. This aligns more with the tRPC v10 style of doing things and I think adopting the same patterns for rspc will make for a way better DX.
TPrevMappertoTPrevMiddlewarein public API#[track_caller]to helpdata_typekeywhen routing mergingOnce Full Send on v1 is active: