Why did the usage change in that way?
Bit of a general question. Is there a blogpost or a video talking about that?
I personally liked the old usage in the component much better:
Old
New
Solution:Jump to solution
Introducing the new TanStack React Query integration | tRPC
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 wrapping useQuery and use...
3 Replies
im sorry. Bit of an obnoxious question. I found the blog post :0
sorry lukas :/
Solution
Introducing the new TanStack React Query integration | tRPC
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 wrapping useQuery and use...
TLDR there is a post from @julius explaining that, but i'll simplify below:
1. Everytime react query changes or add more options, params, @trpc/react-query has to update to follow it and add those options and its api, making hard to keep up to date.
2. LESS abstractions: the option had a lot of abstractions and has a deep tight with react query. This has advantages/producvity but also downsizes as mentioned on option 1. So the new approach seems less over bloated and simple having clear boundaries what is trpc and what is react query.
Not right or wrong and it seems they will keep maintaining both.