Introducing the new TanStack React Query integration #6508
Replies: 23 comments 28 replies
-
|
Wohooooo! |
Beta Was this translation helpful? Give feedback.
-
|
This is a big step in the right direction. Great job! |
Beta Was this translation helpful? Give feedback.
-
|
Not sure i am convinced by the changes. I fear it adds confusion to the confusion. |
Beta Was this translation helpful? Give feedback.
-
|
See discussion in #6508 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
In love with this direction! I'm working on a pet project that has a lot in common with tRPC, and I'll surely adopt the changes mentioned here. |
Beta Was this translation helpful? Give feedback.
-
|
I like it a lot, just migrated our entire app to it with the help of the codemod. |
Beta Was this translation helpful? Give feedback.
-
|
yea this is a bug in our |
Beta Was this translation helpful? Give feedback.
-
|
you can do queryClient.getQueryData(trpc.post.list.queryOptions().queryKey)for the time being |
Beta Was this translation helpful? Give feedback.
-
|
Is queryClient.getQueryData(trpc.post.list.queryKey(id)) also valid or do I always need to use queryOptions beforehand? |
Beta Was this translation helpful? Give feedback.
-
|
This makes a lot of sense. Thanks for the great updates y'all 👏 Your approach to moving forward while not breaking existing things is exceptional. |
Beta Was this translation helpful? Give feedback.
-
|
What about invalidation? Does |
Beta Was this translation helpful? Give feedback.
-
|
Nevermind, just saw the migration guide. |
Beta Was this translation helpful? Give feedback.
-
|
I don’t like this change from the perspective of API consumer. The original trpc client api was wayyy better than the query key factory approaches we see elsewhere for libraries that work with tanstack query. I just feel like this creates more work for the developer. In fact I made a wrapper to make vanilla react query look much more like the trpc client that we use internally at work, it’s awesome. To me really it comes down to this question: why are we manually managing query keys when it could be done under the hood for us? There’s no reason for developers to manually pass around query keys, in 100% of cases query keys are just a one to one mapping of input variables. That’s why the trpc client was better, it abstracted away boilerplate. One less thing to remember and one less thing for devs to mess up. It’s not that big of a deal but IMO the API just got worse. I’m pretty ignorant to the other tradeoffs at play here but as far as “which api is the best” goes the old one was clearly better and I can’t imagine any arguments otherwise |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the change to expose queryOptions itself is definitely a good one. Having said that, taking away the old API which is objectively better for most trpc users, most of the time (who usually don't care that much that it was objectively worse for maintainers) seems a big shame. I think library of trpc's level of adoption should be very wary of breaking changes. I'd be interested to know whether there's a simplified 90% use case reimplementation of the old API which uses the new queryOptions helper under the hood. I could imagine a basic setup that uses the old API, with the new API being the escape hatch for tighter control, maybe better type inference for complex cases, and new RQ features. It would also mean beginners can just get started with trpc, without being too worry about RQ just yet. That would obviously be more work than not doing it, but it's possible it'd be easier than before with the new improved/refactored design. It's worth considering I think - it's a really big deal to force every single useQuery and useMutation to be rewritten. There are literally millions of instances out there working perfectly well. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @mmkal, thank for your feedback. I want to emphasize that the packages are fully interoperable, so you can incrementally upgrade if you want to, or even keep both around! Made a simple example: https://github.com/juliusmarminge/trpc-interop |
Beta Was this translation helpful? Give feedback.
-
|
I get the feedback though - for the 90% data fetching you do in an SPA, it's extra steps - perhaps we could have some "happy path" hooks for simple queries/mutations and just let people know to use query options for any more advanced use cases. Feel free to drop more thoughts on how you'd see that could look like in the comments / new RFC / draft PR. Both @iway1 and @mmkal are long-term users and contributors, so we'll really take your feedback seriously. If any of you want help champion and iniative that fills the gaps, we'd love to have you involve you. |
Beta Was this translation helpful? Give feedback.
-
|
@KATT / @juliusmarminge , i mean, first things went longer with the introduction of now we have |
Beta Was this translation helpful? Give feedback.
-
|
@KATT @juliusmarminge I'm possibly under-thinking this, but I created a draft PR here where we could discuss the specific pitfalls of continuing to support the old API too, if any: #6563 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for this great lib! |
Beta Was this translation helpful? Give feedback.
-
|
It's also an additional import as well. I'm personally fine with this new update as long the old approach is not deprecated. I'll just use the new approach when there's a new RQ feature I have to use. |
Beta Was this translation helpful? Give feedback.
-
|
Having a thinner tRPC layer makes it easier for AI code gen. Writing more characters isn’t a primary DX issue nowadays (e.g. shadcn). Like, who is still writing optimistic updates by hand? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your feedback! We have responded more in depth to this concern above #6508 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Is there a mistake in the invalidation section of the migration guide?
|
Beta Was this translation helpful? Give feedback.
-
|
Agreed. I also think that the argument passed to |
Beta Was this translation helpful? Give feedback.
-
|
Thanks both, we're working on a PR to address lots of little details and I've added these changes: 372333a |
Beta Was this translation helpful? Give feedback.
-
|
Any way we could get this merged soon? @Nick-Lucas that is the only thing keeping us from migrating right now :) |
Beta Was this translation helpful? Give feedback.
-
|
It was released last night! Let us know if any lingering issues |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Nick-Lucas, working great! |
Beta Was this translation helpful? Give feedback.
-
|
But I love the classic integration. I think that is minimal. I am sad because you guys are going to deprecate the classic one. I wish if we have both. What I understand the new integration need several hook to call like |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your feedback! We have responded more in depth to this concern above #6508 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a great change. In our project we had some difficulties in the current integration being too “magical”.l and preventing further abstractions on top of it. For example, we use a lot a isSlowFetching to only show loaders when fetching is longer than some threshold. We would like this to be a default, but that would mean wrapping trpc proxy to wrap every hook. The new implement implementation I can just wrap react query This integration is a better building block. The convenience of the classic one can be built on top of this, but not the other way around. Good job! |
Beta Was this translation helpful? Give feedback.
-
|
Congrats! Thank you for your hard work! |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, We had to make some breaking changes due to some bugs. Most notably is the For more details, see the PR: #6529 |
Beta Was this translation helpful? Give feedback.
-
|
I think this direction is great, especially if it reduces the maintenance complexity of the package. However, I must say I'm not a fan of the useTRPC hook being a the primary way of accessing the api instead of just importing the api directly. I tried using the createTRPCOptionsProxy and exporting directly but it requires passing in the trpcClient and query client during initialization. This differs from the existing createTRPCReact, which could be declared and exported directly, and then used to create the client in a stable useState at the top level provider. // Requires trpcClient that I don't have yet!
export const trpc = createTRPCOptionsProxy<AppRouter>({
client: trpcClient,
queryClient,
});
export const api = createTRPCReact<AppRouter>();
export type RouterInputs = inferRouterInputs<AppRouter>;
export type RouterOutputs = inferRouterOutputs<AppRouter>;
export function TRPCReactProvider(props: { children: React.ReactNode }) {
const queryClient = getQueryClient();
const router = useRouter();
const [trpcClient] = useState(() =>
api.createClient({
links: [
loggerLink({
enabled: (op) =>
process.env.NODE_ENV === "development" ||
(op.direction === "down" && op.result instanceof Error),
}),
unstable_httpBatchStreamLink({
transformer: SuperJSON,
url: getBaseUrl() + "/api/trpc",
headers: () => {
const headers = new Headers();
headers.set("x-trpc-source", "nextjs-react");
return headers;
},
}),
],
}),
);
return (
<QueryClientProvider client={queryClient}>
<api.Provider client={trpcClient} queryClient={queryClient}>
{props.children}
</api.Provider>
<ReactQueryDevtools initialIsOpen={false} />
</QueryClientProvider>
);
}From my understanding, in NextJS land if I don't declare the client in a stable space like a useState I run the risk of re-intializing the client during revalidations and similiar. Are there any plans of updating some helper methods here so we can have a similiar api interface, just without wrapping useQuery internally? |
Beta Was this translation helpful? Give feedback.
-
No that would not be possible since the trpc client lives in react context and the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, i'm a huge fun of your invention called trpc. Personally I'll stick to the classic (v10 api) but think that integration would be appreciated by lots of people. Instead of const greetingQuery = useQuery(trpc.greeting.queryOptions({ name: 'Jerry' })); I would go with: const greetingQuery = useQuery(trpc.greeting.getQueryFn({ name: 'Jerry' })); Instead of: const createUserMutation = useMutation(trpc.createUser.mutationOptions()); I would go with: const createUserMutation = useMutation(trpc.createUser.getMutationFn()); Instead of: trpc.greeting.queryFilter({ name: 'Jerry' }), I would go with: trpc.greeting.getQueryKey({ name: 'Jerry' }), Why?
What you think, @KATT @juliusmarminge ? best wishes and thank you all for your hard work creating and maintaining trpc :) |
Beta Was this translation helpful? Give feedback.
-
|
I absolutely love this change 🚀🚀🚀 |
Beta Was this translation helpful? Give feedback.
-
|
With the support of TanStack Query for Angular, is there a chance to get this experience as well? |
Beta Was this translation helpful? Give feedback.
-
|
The recommended way to set up a SPA with tRPC is using the Singleton Pattern. But since most auth libraries use providers/hooks (I'm using clerk), the So what's the best way to pass the // const { getToken } = useAuth(); react land
const trpcClient = createTRPCClient<CoreApiRouter>({
links: [
httpBatchLink({
url: import.meta.env.VITE_CORE_URL,
transformer: superjson,
headers() {
return {
"Authorization": await getToken(); // cannot do this anymore
};
},
}),
],
});previous implementation export function TrpcProvider({ children }: { children: ReactNode }) {
const { getToken } = useAuth();
const [queryClient] = useState(() => new QueryClient());
const [trpcClient] = useState(() =>
trpc.createClient({
links: [
httpBatchLink({
transformer: superjson,
url: import.meta.env.VITE_CORE_URL,
// You can pass any HTTP headers you wish here
async headers() {
return {
Authorization: `Bearer ${await getToken()}`,
};
},
}),
],
}),
);
return (
<trpc.Provider client={trpcClient} queryClient={queryClient}>
<QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
</trpc.Provider>
);
}I'm using VITE |
Beta Was this translation helpful? Give feedback.
-
|
yes if you need react context then you should use the provider setup:
|
Beta Was this translation helpful? Give feedback.
-
|
Is there any reason why this is a reaction only api? Seems like this api would work perfectly as a framework agnostic “tanstack-query” integration. Originally thought that was the case, and maybe I’m missing a way to use it like that! |
Beta Was this translation helpful? Give feedback.
-
|
The types for queryOptions differ across frameworks, so it must be tied to the respective tanstack package. But it should be much easier to make a solid/vue/svelte port of this package in the same way |
Beta Was this translation helpful? Give feedback.
-
|
In the old API, we had We would like something to type the export function useAnyById(input: string, options?: any) {
const trpc = useTRPC()
return useQuery(trpc.any.byId.queryOptions(input, {
...options,
staleTime: 3600
}))
} |
Beta Was this translation helpful? Give feedback.
-
|
@KATT is there currently a migration path for this one? |
Beta Was this translation helpful? Give feedback.
-
|
Any updates/solutions? |
Beta Was this translation helpful? Give feedback.
-
|
Hi all, I managed to do the migration to this new setup, but running into some type issues. Anyone have any ideas on how to resolve this? 
Note: My application seems to run fine and these mutations still work |
Beta Was this translation helpful? Give feedback.
-
|
Resolved, just needed to restart vs code |
Beta Was this translation helpful? Give feedback.
-
|
i was wondering if this is final and will be the only api going forward? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We are excited to announce the new TanStack React Query integration for tRPC is now available on tRPC's
next-release. Compared to our classic React Query Integration it's simpler and more TanStack Query-native, choosing to utilize the QueryOptions and MutationOptions interfaces native to TanStack React Query, instead of wrappinguseQueryanduseMutationwith our own client.Read the announcement: https://trpc.io/blog/introducing-tanstack-react-query-client
Beta Was this translation helpful? Give feedback.
All reactions