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.
-
|
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.
-
|
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.
-
|
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.
-
|
Hi, thanks for this great lib! |
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
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