Fetch api.orders.getAll with these arguments a,b,c \r\n\r\n```\r\ncomments: \r\n- I left out the comments as I don't know how to document it right, so here are some comments. \r\n- is use proxies to solve the missing key errors. \r\n- Functions are needed making it possible to be `api.orders` and `api.orders()`. \r\n- _path saves the path like `api.orders.getAll`\r\n- When somewhere a function is called, handlers.apply is called. \r\n- this is *an* implementation not *the* implementation, rather a proof of concept. I use the proxy syntax never, but vue's reactivity system uses it.\r\n\r\n## Final notes\r\nI trying my best to make it easy to grasp, Try the code provided in technical details in your own sandbox to understand a little bit better how it works. Personally, I think this is the easiest syntax as it feels like your calling a function on your backend. I also understand this not Graphql like syntax. Potentially you can have multiple client interfaces. To be honest, I only know this library for a couple of days, because Theo appeared in my youtube feed. So I also don't know if this syntax is in line with the vision of trpc. \r\n\r\nAfter all, I still wanted to show this javascript trickery and proposal, especially after the many hours figuring it out. Do not hesitate to ask further questions if something is unclear. \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n",[2897],{"name":2898,"color":2899},"💡 ideas","bfdadc",2215,"Documentation Proxy Api and @trcp/client","2022-10-04T06:09:12Z","https://github.com/trpc/trpc/issues/2215",0.63869625,{"description":2906,"labels":2907,"number":2911,"owner":2868,"repository":2868,"state":2878,"title":2912,"updated_at":2913,"url":2914,"score":2915},"## Problem\r\n\r\nCurrently, it's possible to use the old client APIs to call the new ways of defining routers and procedures and the other way around. This creates quite a heavy load on TypeScript performance as we flatten all procedures on the router, whether it's used or not.\r\n\r\nSeeing that we are stepping away from string literals, this is an undesirable bottleneck & makes tRPC slower.\r\n\r\n## Proposed solution\r\n\r\n- Procedures defined with old way (i.e. `trpc.router().query('oldProc', { resolve: () => '..' )`) should **not** be callable through a proxy, and **only** with the legacy string literals\r\n- Procedures defined with new way, (i.e. `t.router({ newProc: t.query(() => '..') })`), should not be callable **except through a proxy**\r\n\r\n## Implications\r\n\r\n- Proxy will be the only way to call things in the default tRPC clients\r\n- People who want to support environments [which can't support `Proxy`](https://caniuse.com/#search=Proxy) will need another tRPC client *(TBD if we make one of those ourselves)*\r\n- We need to change the way we define interop mode on the client\r\n- We will deprecate `createTRPCClient` & `createReactQueryHooks` in favor of proxy-based APIs\r\n- We will need to define interop clients or make the current clients automatically expose a `.proxy` object\r\n- This **should not** make incremental migration from v9->v10 harder\r\n\r\n\r\n## Proposed APIs\r\n\r\nGiven the following backend:\r\n\r\n```ts\r\nconst t = initTRPC()();\r\nconst legacyRouter = trpc\r\n .router()\r\n .query('legacyProc', {\r\n input: z.string().optional(),\r\n resolve({ input }) {\r\n return `hello ${input ?? 'world'}`;\r\n },\r\n })\r\nconst newAppRouter = t.router({\r\n newProc: t.procedure.query(() => \"I am just a test, I don't know! \"),\r\n});\r\nconst appRouter = t.mergeRouters(legacyRouter.interop(), newAppRouter);\r\n```\r\n\r\n### `@trpc/client`\r\n\r\n**New way of creating a client:**\r\n```ts\r\n// Create new client\r\nconst client = createTRPCProxyClient\u003CAppRouter>({ \r\n url: 'http://localhost:3001',\r\n})\r\n\r\n// Usage:\r\nclient.newProc.query();\r\n```\r\n\r\n**Interop:**\r\n\r\n```ts\r\n// Will show deprecation error\r\nconst client = createTRPCClient\u003CAppRouter>({\r\n url: 'http://localhost:3001',\r\n})\r\n\r\n// Expose a proxy prop automatically:\r\nconst proxy = client.proxy;\r\n\r\n// ✅ These calls will work\r\nproxy.newProc.query();\r\nclient.query('legacyProc');\r\n\r\n// ❌ These will now show TypeScript error\r\nproxy.legacyProc.query();\r\nclient.query('newProc');\r\n```\r\n\r\n### `@trpc/react`\r\n\r\n**New default way of creating a client:**\r\n\r\n```tsx\r\nconst trpc = createTRPCReact\u003CAppRouter>();\r\n\r\n// Calls:\r\ntrpc.newProc.useQuery();\r\n```\r\n\r\n**Interop:**\r\n\r\n```tsx\r\nconst trpc = createReactQueryHooks\u003CAppRouter>();\r\n\r\nconst proxy = trpc.proxy;\r\n\r\n// ✅ These calls will work\r\nproxy.newProc.useQuery();\r\ntrpc.useQuery(['legacyProc']);\r\n\r\n// ❌ These will now show TypeScript error\r\nproxy.legacyProc.useQuery();\r\ntrpc.useQuery(['newProc']);\r\n```\r\n",[2908],{"name":2909,"color":2910},"RFC","78B062",2311,"[v10] Make interop non-proxy string literals & and new proxy calls mutually exclusive","2022-10-04T00:18:25Z","https://github.com/trpc/trpc/issues/2311",0.64809173,{"description":2917,"labels":2918,"number":2922,"owner":2868,"repository":2868,"state":2878,"title":2923,"updated_at":2924,"url":2925,"score":2926},"Some recommendations for improvements to the API:\r\n\r\n- I don't really see any reason to split up `@trpc/server` and `@trpc/client`. I think they should be merged into a single `trpc` module. It makes the out-of-the-box experience so much cleaner.\r\n- Then the `@trpc` scope can be used for specific plugins/adapters etc. You could publish the Express adapter as `@trpc/express` for instance. That would also let you properly specify all the requisite peerDependencies (which I don't believe are specified using the current `@trpc/server/adapters/express` approach since it doesn't have its own package.json.\r\n- I think `import * as` imports are a bad user experience. I submitted a PR with a solution.\r\n- Simplify the function names: `createTRPCClient` => `createClient`, `createNextApiHandler` => `createHandler`, `CreateNextContextOptions` => `ContextOptions`. It should be standard across adapters. It's obvious that a function called `createHandler` imported from `\"@trpc/server/adapters/next\"` is creating a Next.js API handler. It doesn't need to be in the name.\r\n- The adapters should export a `createContext` function that can automatically type `opts` with the necessary types.\r\n- I think all requests (queries and mutations) should get served from a single URL. The `path` can be added as an additional query parameter for queries and in the `body` for mutations. This would also simplify the Next/Express adapters (no need for a catchall API route).\r\n\r\n\r\nLess important:\r\n\r\nI think there should be a way of manually typing the input of a resolver without passing a validator into `input`. This is easy to do if the resolver functions had two parameters instead of one. I have this working on a local branch (type inference still works the same).\r\n\r\nI propose this syntax/convention:\r\n\r\n```ts\r\nconst router = trpc.router\u003CContext>().query('test', {\r\n resolve(input: number, req) {\r\n return input;\r\n },\r\n });\r\n```\r\n\r\nThe `req` variable above if of type `{ ctx: TContext, type: ProcedureType }`. This leaves the door open to future API expansion, as `req` can act like a catchall for any additional properties we want to pass into resolvers. ",[2919],{"name":2920,"color":2921},"💬 discussion","4B318A",211,"API recommendations","2021-04-12T21:57:33Z","https://github.com/trpc/trpc/issues/211",0.6492044,{"description":2928,"labels":2929,"number":2933,"owner":2868,"repository":2868,"state":2878,"title":2934,"updated_at":2935,"url":2936,"score":2937},"### Area of Improvement\n\nCurrently in V10, we infer the types like this:\r\n```ts\r\n// sample router\r\nconst router = t.router({\r\n post: t.procedure.input(z.string()).mutation(() => {\r\n // ...\r\n return post.id;\r\n })\r\n});\r\ntype AppRouter = typeof appRouter;\r\n\r\n// usage\r\nimport type { inferProcedureInput } from \"@trpc/server\";\r\nimport type { AppRouter } from \"routers/_app\";\r\n\r\nexport type PostInput = inferProcedureInput\u003CAppRouter['post']>;\r\n```\r\n\r\nthe double import here is kinda annoying imo, would be nice to provide a wrapper in the documentation that would allow for something like this:\r\n```ts\r\n// utils/trpc.ts\r\nimport type{ inferProcedureInput } from \"@trpc/server\";\r\nimport type { AppRouter } from \"routers/_app\";\r\n\r\nexport type InferProcedureInput[path] = inferProcedureInput\u003CAppRouter[path]>;\r\n\r\n// usage\r\nimport type { InferProcedureInput } from \"utils/trpc\";\r\n\r\ntype PostInput = InferProcedureInput['post'];\r\n```\n\n### Link to related docs\n\nhttps://alpha.trpc.io/docs/infer-types\n\n### Additional information\n\nNot a TS-Wizard so I don't know how to make such generic type, since routers can be arbitrary deep. Is it possible?\n\n### 👨👧👦 Contributing\n\n- [ ] 🙋♂️ Yes, I'd be down to file a PR implementing the suggested changes!",[2930],{"name":2931,"color":2932},"📚 documentation / examples","0075ca",2482,"docs: include an inference helper in documentation","2022-10-09T12:02:14Z","https://github.com/trpc/trpc/issues/2482",0.6521701,{"description":2939,"labels":2940,"number":2947,"owner":2868,"repository":2868,"state":2878,"title":2948,"updated_at":2949,"url":2950,"score":2951},"This is a super weird one. It may have been me who broke it, and I haven't been able to figure out how/why yet. My team's project hits this error trying to update to v9.6.0 (from v9.0.0-alpha.0, which was before #915 went in but after/somewhere in the middle of #718).\r\n\r\nWe're finding that *under certain conditions* `inferProcedureInput\u003C>` is returning `unknown` (in fact, it's the type inference of router definition - the procedure itself is `Procedure\u003CContext, Context, unknown, { ...result... }>`). Repro (note - this does _not_ repro in this repo, if you do `import * as trpc from '../src'` in a test, which is what I tried first. You can use this [playground link](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgUwB5mQYxgFQJ4YDyAZnAL5zFQQhwDkaG2AtDAcnQNwBQokscAFRwAhgGc4MKGEyVqtOgAEpMgPRjkUAG6a6vcNHgIAXhSo16xiABM93TBAB2Y+CLBgAShACuMTXABeSWlMADpqX00ACgBKUJBNAHNkKO44ehFrEGBHVToAGjTgmSL08J8-KFjSuHjfERhgJyi6PxcAWXrGpwLEGvScsF8ALjhjUIgAIwArLBgohH70yggIUfGXKBzE2MLl5bIYvf24KGQxCAAbHVHxPEdZBbhB33IYwIA+OAADABIEF4wULEVZkACE32O6UONXiwGs1kuyAA7iIzlE7g84E9HGh4IdPnBcah5jEjtwYjxuGwMHBOjAGk1nIFJOwIKQ3J4KppQgB9azIYh1BndZw8RhzfBEYgAHiKKjCOWImgACtRMMhrN4zgBJRxDGAy+mMpxiADadEy2VybRgxtFdAAuh9uB9YqEYBAAKIAR28IkuUuQJBlSBBazgm225DdlO4EuwQZD8pCoSVqvVmu1yD1BqNXSZ5stWRyqlt9qZTpdsdCjggQM9ACFkABVRwAazryMcsR4QA) to see it going wrong:\r\n\r\n```ts\r\nimport { expectTypeOf } from 'expect-type';\r\nimport * as trpc from '@trpc/server'\r\nimport {z} from 'zod'\r\n\r\nconst appRouter = trpc.router().merge(\r\n 'admin/',\r\n trpc\r\n .router()\r\n .mutation('testMutation', {\r\n input: z.object({\r\n foo: z.string(),\r\n }),\r\n resolve: async ({ input }) => `${input.foo}!`,\r\n })\r\n .middleware(async ({ next }) => next()),\r\n);\r\n\r\ntype Mutations = typeof appRouter._def.mutations;\r\n\r\nexpectTypeOf\u003C\r\n trpc.inferProcedureInput\u003CMutations['admin/testMutation']>\r\n>().toEqualTypeOf\u003C{ foo: string }>();\r\n\r\nexpectTypeOf\u003C\r\n trpc.inferProcedureInput\u003CMutations['admin/testMutation']>\r\n>().not.toBeUnknown();\r\n```\r\n\r\nThe two `expectTypeOf` tests fail. The second is just to show that the inferred type is `unknown` and that it isn't a typo/bad test setup.\r\n\r\nUpdate: The tests succeed if you remove the `.middleware(async ({ next }) => next())` line (in this case, the middleware is pointless - we are seeing it for a similar middleware that throws under certain circumstances)\r\n\r\nUpdate 2: It can also be repro'd by doing `import * as trpc from '../dist/trpc-server.cjs'` in this repo, which makes things much easier. Could there be some types that are being stripped at build time, maybe?",[2941,2944],{"name":2942,"color":2943},"🐛 bug","d73a4a",{"name":2945,"color":2946},"🧙🏻 typescript wizardry","391441",949,"`inferProcedureInput` broken in published package","2022-10-04T18:08:21Z","https://github.com/trpc/trpc/issues/949",0.6524691,{"description":2953,"labels":2954,"number":2955,"owner":2868,"repository":2868,"state":2878,"title":2956,"updated_at":2957,"url":2958,"score":2959},"I'm experimenting with a new stack and using v10 of trpc for it (the new proxy calls are awesome btw.). During SSR, I want to call my router procedures directly from the server (so without the client) - the adapters seem to still use the previous `.createCaller` API (maybe there's a newer one available?). I've noticed the types do actually include the correct (procedure) paths but those values are all undefined during runtime:\r\n\r\n```ts\r\nconst UserRouter = trpc.router({\r\n\tgetAll: trpc.procedure.query(async () => {\r\n\t\treturn (await prisma.user.findMany()) as UserRecord[];\r\n\t}),\r\n});\r\n\r\nconsole.log(UserRouter.getAll.query()); // \u003C- Typescript is happy, but it doesn't work during runtime (.getAll is undefined)\r\n```\r\n\r\nBased on the client proxy wrapper (which gave me an error when I wrapped the server router with it), I wrote this little helper:\r\n\r\n```ts\r\nimport type { AnyRouter } from \"@trpc/server\";\r\n\r\nexport function createTRPCServerProxy\u003CT extends AnyRouter>(router: T, path: string[] = []): T {\r\n\treturn new Proxy(router, {\r\n\t\tget(target, p: string) {\r\n // You can extend this for mutations too - 'tis just an example\r\n\t\t\tif (p === \"query\") {\r\n\t\t\t\treturn (input: any, opts: any) => {\r\n\t\t\t\t\tconst caller = target.createCaller(opts.context);\r\n\r\n\t\t\t\t\treturn caller.query(path.join(\".\"), input);\r\n\t\t\t\t};\r\n\t\t\t} else {\r\n\t\t\t\treturn createTRPCServerProxy(target, [...path, p]);\r\n\t\t\t}\r\n\t\t},\r\n\t});\r\n}\r\n```\r\n\r\n```ts\r\nconsole.log(createTRPCServerProxy(UserRouter).getAll.query()); // \u003C- Works and typechecks correctly\r\n```\r\n\r\nThe types for the router are already there (as I mentioned earlier) so we don't have to adjust those. I just wrap the property accesses and chain them into the query after the `createCaller` has been finally called.\r\n\r\nThis worked for me, it would be nice though if trpc@10 had this method built-in 🙂 \r\nAlternatively it would also work if the procedure properties were actually defined during runtime (I don't know if this is planned since the types are there but it might require more changes if it is not). ",[],2284,"Add server proxy wrapper helper to @trpc/server v10","2022-10-04T06:09:03Z","https://github.com/trpc/trpc/issues/2284",0.6526078,{"description":2961,"labels":2962,"number":2972,"owner":2868,"repository":2868,"state":2878,"title":2973,"updated_at":2974,"url":2975,"score":2976},"So. We're making a new major. \r\n\r\n\r\n\r\n\r\n\r\n## Goals\r\n\r\n- **More ergonomic API for creating procedures** and building out your backend\r\n- **CMD+Click** from your frontend and jump straight into the backend procedure. This will work with `react-query` as well!\r\n- **Better scaling** than the current structure - the TypeScript server starts choking a bit when you get close to 100 procedures in your backend\r\n- **Fully backward compatible** for the 99% use-case with a migration path which you can do incrementally. \r\n\r\n\r\n## Todos\r\n\r\n> **Important for contributors:** All of the work here is related to the [`next`](https://github.com/trpc/trpc/tree/next) branch.\r\n\r\n\r\nTracked in https://github.com/orgs/trpc/projects/1\r\n\r\n- [x] New Router API\r\n - [x] Tracked in [trpc/v10-playground](https://github.com/trpc/v10-playground) - the current winning proposal is https://github.com/trpc/v10-playground/pull/33\r\n - [x] Error formatting in new API - [`formatError()`](https://trpc.io/docs/error-formatting)-equivalent. \r\n - [x] `meta`-equivalent\r\n - [x] Maybe we need a `createRootRouter()` that additionally accepts `{ transformer: X, formatError: Y}`\r\n - [x] Implement new API in tRPC\r\n - [x] Make old routers compatible (`.legacy()` at the end to transform them to the new version)\r\n- [x] New client API with backward compatibility \r\n - Maybe old can be `client.query('postById', input, options)` whilst new stuff can be `client.queries.postById({ input, ...options})`\r\n- [x] New react-query API with backward compat\r\n- [ ] Make actual issues for all of these\r\n- [x] Add all old projects in a folder (copy/paste `examples/*` to `examples/.test` so we can track breaking changes easily and make sure we remain backward compatible for a long time\r\n- [ ] Rewrite `TRPCClient` to be functional instead of a class but reuse the same interface\r\n- [ ] Write a migration guide\r\n - [ ] New router API\r\n - [ ] New links\r\n- [x] Move transformers back to `runtime` to make it backward compatible\r\n- [ ] Explore: Add [`stripInternal`](https://www.typescriptlang.org/tsconfig#stripInternal)-flag\r\n- [x] Simplify HTTP-responses\r\n- [x] New links architecture (#1366)\r\n- [ ] Refactor observables implementation to have `unknown` errors or make it guaranteed to be `TRPCClientError` of some sort. \r\n- [ ] Make transformers dynamically opt-in similar to how a batch request is indicated by `?batch=1` maybe a transformed request could be `?transform=1` or `transform=TRANSFORMER_NAME`?\r\n- [ ] Write a blog post about new major and API.\r\n- [ ] \"Marketing\"? Hype video, new website, etc\r\n- [ ] Decide on structure for react-query integration\r\n- [ ] Add old website on `www/`-docs as `v9.trpc.io`\r\n - [ ] Link it in Docusaurus\r\n - [ ] Make sure we have deployment for a \"v9\"-branch\r\n\r\n### Stretch\r\n\r\n- [ ] Add DTO for clients without transformers - #1694\r\n- [x] #1597\r\n- [x] New Subscriptions API (nice to have) - #1596 \r\n- [ ] `trpc.output.snapshot()` https://github.com/trpc/trpc/issues/3435\r\n\r\n\r\n\r\n\r\n\r\n\u003Cdetails>\u003Csummary>Old notes\u003C/summary>\r\n\r\n## Definite\r\n\r\n- [x] Remove official support for node `12.x`\r\n - [x] Remove E2E-test for 12.x\r\n - [x] Change `tsconfig` build target\r\n- [ ] Add official support for node `16.x`\r\n- [ ] Add `stripInternal`-flag\r\n- [x] Remove all `@deprecated` stuff\r\n - [x] Remove `LegacyRouter` introduced in #915\r\n - [ ] [...]\r\n- [x] New links architecture (#1366)\r\n- [ ] Move official support for `react-query` `3` to `4`\r\n- [ ] Simplify HTTP-responses\r\n - [ ] From `{ id:null, result: {type: 'data', data: x } }` -> `{ result: { data: x } }`\r\n - [ ] maybe remove `id: null` from HTTP responses?\r\n- [ ] Migration guides for all changed parts\r\n - [ ] New Links\r\n\r\n\r\n## Maybe ❓ \r\n\r\n> Feedback please!\r\n\r\n\r\n- [x] Optimize so router inference only needs to be done once? #1218 \r\n- [ ] ~Update so procedures needs to return `{ data: x }` instead of just `x` so we could add metadata and potentially discriminated union of `{ data: x } | { error: y }` ~\r\n- [x] Decide: \r\n - Pipe-based rather than object resolvers? `{ input: z.string(), resolve({input}) {}}` -> `t.pipe(t.input(z.string), ({input}) => \r\n - Chained resolvers\r\n- [x] Plan how to deal with degrading typescript performance when approaching ~100 procedures (there are no runtime issues, but the DX slows down) \r\n- [ ] Turn `client.query` result into `[ output, { meta } ]`\r\n- [ ] New `useQuery()` API that expects suspense as default - See this gist: https://gist.github.com/KATT/aa1ad532d6e57520b942f657569e1505\r\n- [ ] Refactor `@trpc/server` to easier work with CloudFlare-workers etc (#1375)\r\n- [ ] Collaborate with Blitz.js? https://github.com/blitz-js/blitz/discussions/3083#discussioncomment-1841427\r\n- [ ] https://jsonapi.org/format/\r\n\r\n### Transformers\r\n\r\n- [x] Turn transformers into a link on the client (#1366)\r\n- [ ] Revert above and put transformers back to runtime 😬 \r\n- [ ] ~Turn transformers into a middleware on the server~\r\n- [ ] Make transformers dynamically opt-in similar to how a batch request is indicated by `?batch=1` maybe a transformed request could be `?transform=1` or `transform=TRANSFORMER_NAME`?\r\n\r\n### Misc\r\n\r\n- [ ] Rename `@trpc/react/ssg` -> `@trpc/react/ssr` & `createSSGHelpers` -> `createServerSideHelpers` (or something, as it is often used in `getServerSideProps()` as well as `getStaticProps()`)\r\n\r\n## Open questions\r\n\r\n- Should we continue to follow OpenRPC?\r\n- Any changes that could make tRPC easier to support stuff like Svelte/Vue?\r\n- Any changes that could make tRPC stricter support stuff like AWS Lambdas? (Already is doable to do Lambdas but through an Express->Lambda converter) #882 \r\n- Ideas?\r\n\r\n\r\n\r\n\u003C/details>",[2963,2966,2969],{"name":2964,"color":2965},"🙏 review please","A7356F",{"name":2967,"color":2968},"💸 Get paid!","c2e0c6",{"name":2970,"color":2971},"next-major/definite","5319E7",887,"[RFC] Next major overview","2022-12-19T22:11:47Z","https://github.com/trpc/trpc/issues/887",0.6544909,["Reactive",2978],{},["Set"],["ShallowReactive",2981],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$f9QGrLnEf24FusV0_kqqTX_3j2gL8fVsOCUz02DijwnI":-1},"/trpc/v10-playground/24"]