New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: v11 goals & suggestion box #3496
Comments
This might be a bigger discussion and way out of scope here, but I think the React Query API could be cleaner long term if changes are on the table. There are a few painpoints with it Take this rough example: import { trpc } from '../utils/trpc';
function MyComponent() {
const utils = trpc.useContext();
const postsQuery = trpc.post.all.useQuery({ pageSize: 100 })
const mutation = trpc.post.useMutation({
onSuccess: () => {
utils.post.invalidate(/* id etc */)
}
})
} There are a couple painpoints:
Something a bit tidier might look like: import { useUtils, useMutation, useQuery } from '../utils/trpc';
function MyComponent() {
const utils = useUtils();
const postsQuery = useQuery(trpc => trpc.post.all({ pageSize: 100 })) // .all would likely return a config object, so query keys can be calculated, rather than being the trpc call itself
const mutation = useMutation(trpc => trpc.post.update, {
onSuccess: () => {
utils.post.invalidate(/* id etc */)
}
})
} Doesn't cover everything, but getting linting working seems like the important piece, and bringing the utils naming in line seems like low-hanging-fruit |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Let's try to sync this with TanStack Query v5. Our roadmap is here: |
This comment was marked as off-topic.
This comment was marked as off-topic.
Thanks, everyone! In order to keep the conversation here tidy, we will hide discussions & things that wouldn't result in breaking changes - feel free to open separate issues on those. If you wanna debate or discuss specific topics here, join Discord. I just set up a channel specifically for v11.
|
Content type support Like this lib, it would be super cool to support like file type And give it as input and receive as the output a different type like a string or an URL type |
Improved error handlingI really love the flexibility offered by the errorFormatter, however also love the inference achieved when returning 200 status responses. Wished we could throw an Error, and be able to access the data in a similar style to how 200 responses do so, particularly for validation style of errors. I know there have been discussions around the topic here |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Hidden a few comments that I think could all be non-breaking changes. Feel free to open separate issues or PRs. |
Add support for monorepo to be able to separate the definition of routes , and separately in the backend framework (nest or express or ...) implement the tsrpc api https://discord.com/channels/867764511159091230/1061875891774443570/1061875891774443570 |
I'd like to propose a use case of providing a superset of the trpc object to lower level components. Today it is difficult to define multiple routers with shared components. Here's an example using a monorepo with the following structure
What is possible today
What would be a great enhancementProvide a way to pass down a trpc client which is a superset of what the component needs. Starting from the ground up here is how I would envision building this.
import type { Context } from './create-context';
export const t = initTRPC.context<Context>().create({
transformer: superjson,
});
const isAuthed = t.middleware(({ next, ctx }) => {
if (!ctx.auth.userId) {
throw new TRPCError({ code: 'UNAUTHORIZED', message: 'You must be signed in to view this content ' });
}
return next({
ctx: {
auth: ctx.auth,
},
});
});
export const authenticatedProcedure = t.procedure.use(isAuthed);
export const publicProcedure = t.procedure;
import { authenticatedProcedure, publicProcedure, t } from '@monorepo/util/trpc';
import { z } from 'zod';
export const authRouter = t.router({
register: publicProcedure
.input(z.object({ email: z.string(), password: z.string() }))
.output(UserSchema)
.mutation(async ({ input }) => {
// psuedo-implementation
return createUser(input);
}),
getUser: authenticatedProcedure.query(({ ctx }) => {
return ctx.auth;
}),
});
export type AuthRouter = typeof authRouter;
import { TRPCNextClientLike } from '@trpc/next';
import type { AuthRouter } from '@monorepo/router/router-auth';
export type MyComponentProps = {
trpc: TRPCNextClientLike<{ auth: AuthRouter }>;
};
export function MyComponent({ trpc }: MyComponentProps) {
const { data } = trpc.auth.getUser.useQuery();
return <pre>JSON.stringify(data, null, 2)</pre>;
} This is the main part of the proposal. This component shouldn't care about whatever else is on the
import { authRouter } from '@monorepo/router/router-auth';
import { t } from '@monorepo/util/trpc';
export const dashboardClientAppRouter = t.router({
auth: authRouter,
dashboardClientSpecificProcedure: t.query(() => {
return 'something from dashboard-client';
}),
});
export type DashboardClientAppRouter = typeof dashboardClientAppRouter;
import type { DashboardClientAppRouter } from './server';
export const trpc = createTRPCNext<DashboardClientAppRouter>({
// ... implementation
});
import { MyComponent } from '@monorepo/feature/feature-auth';
import { trpc } from '../utils/trpc/client'; // defined locally in the app
export function IndexPage() {
return <MyComponent trpc={trpc} />;
} Steps 4, 5, and 6 should be repeated for the Ideal functionalityWhen using the client utility
Limitations I'd be willing to live with
I think what I've laid out above would help make tRPC a bit more reusable within the context of a monorepo while still sticking to the core tennant of type safety. Additionally, I think that the only change needed here is an additional type for each client (TRPCReact, TRPCNext). The above code is valid from a functionality standpoint and will run. This would help address #3798 |
I think a couple of people have mentioned this but I think having a schema export tool would be very useful for projects that can't be monorepos. It would be something like a TRPC route called This could be in the form of OpenAPI. The is already a library that can emit the basic structure of the entire TRPC app. Is it potentially possible to have that exported, imported on the frontend and instantiate a client that's fully typed? (I know we can just use OpenAPI libraries but it would be nice to have this all contained within the TRPC ecosystem) |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
We won't be removing the distinction between queries and mutations in the short-term unless someone from the community can agree to:
If someone is keen, we'll send you some money & might invite you to the core team. :) I will now hide all discussions in this thread as it's noisy - feel free to open a separate discussion about it |
Fix name inconsistency. You have Also, utility types (e.g., |
This comment was marked as abuse.
This comment was marked as abuse.
v5 of react-query comes with suspense / experimental server component support. Are we able to leverage that in trpc? |
You can do this today using |
Should work ootb, we kinda made that feature in trpc first before upstreaming the work to tanstack query. I use it in t3-turbo: https://github.com/t3-oss/create-t3-turbo/blob/41d84a2aed1dbd585469f68c5f464ab84b2f43b4/apps/nextjs/src/app/providers.tsx#L59 |
v11 beta has been released! https://trpc.io/docs/migrate-from-v10-to-v11 |
Define the root cause of this issue more clearly:
I honestly have no idea what causes it but it seems to crop up any time there's a typescript issue between the frontend/backend projects. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
cc @bchilcott @caidesen @schulzf Please raise actual issues for any of these problems if you can reproduce them. I've used v11 in production for several months. |
Here is the repository to reproduce the issue @bchilcott has mentioned above! Property createClient does not exist on type
in your router collides with a built-in method, rename this router or procedure on your backend." | "The property useUtils' in your router collides with a built-in method, rename this router or procedure on your backend." | ... 4 more ... | "The property useDehydratedState' in your route...'. The reproduction steps has been described in the README file! I have also created a new issue #5614 for the same. |
@bchilcott In my reproduction repo (https://github.com/akashdevcc/zero-stack), I have resolved my issue. The root cause was probably using "commonjs" modules for "trpc" section of my project. Because each package needs to be built first and export everything which was required by another package, somehow "trpc's unstable-core-do-not-import" types were not getting resolved. To resolve the issue, I explicitly re-exported those unresolved types from my However, as mentioned in tRPC code comments here, importing from this file should be avoided. So, I may file a new issue as instructed in this file. |
Summary
next
-branch@deprecated
(if we rename, we'll do an alias)Plan
Before official alpha
Proxy
from naming of functions. We haveUntyped
that is for the untyped. e.g:createTRPCProxyClient
->createTRPCClient
refactor: rename and deprecate proxy named stuff #4932@deprecated
and delete accordingly (chore(v11): remove some deprecated stuff #5026)react-query
TRPCError.cause
tounknown
@trpc/core
-package, we need to look at extensions using tRPC and make a way to extend tRPC for libraries - feat(v11): make it easier to extend tRPC #5308@trpc/core
-package #5210@trpc/client
/@trpc/server
etc are smurfed. Stuff in@trpc/core
don't need to be smurfed as it's all internal and not intended to be used directly@next
next
Beta
main
to10.x
&next
->main
Maybes of things to do
client
(maybe?)FIXME
in codebase and fix themctx
in theinput
parsers #1963Subtle breaking changes
See https://github.com/trpc/trpc/blob/next/.wip/changes.md
Hey you! Yes, you!
Anything you think we should add that should be fixed?
Funding
The text was updated successfully, but these errors were encountered: