TanStack Query(a.k.a. React Query) v5 announced
tanstack.com
TanStack Query(a.k.a. React Query) v5 announced
1–10 of 64 posts
Re: TanStack Query(a.k.a. React Query) v5 announced
#2Very nice, and well done team!
I've been using v5 in production since beta 20, and it has been working very reliable for us since then. The documentation for how to upgrade has been a great resource, and a great example of how to do breaking changes in a library as large as this one.
Re: TanStack Query(a.k.a. React Query) v5 announced
#3Our team is currently debating whether we should adopt react-query or stick with plain old hand-written code around `fetch`. The team used Apollo in another project, so we are quite familiar with a "heavy handed wrapper" around backend requests. But I'm not sure the added complexity of react-query is "worth it".
Anyone have experiences to share, either using react-query, a different library or particularly painful memories _not_ using a comparable library?
Re: TanStack Query(a.k.a. React Query) v5 announced
#4> Apart from that, we've renamed cacheTime to gcTime to better reflect what it is doing
Does it though? Maybe it's super obvious to more experienced users, but now I need to read the docs to find out what "gc" stands for. Not a big deal, just seems like an unnecessary abbreviation, so I'm curious as to what the reasoning is.
Re: TanStack Query(a.k.a. React Query) v5 announced
#5There have been endless discussions about state management in React. React Query solved the most common and most annoying part of state management for me, which was everything that you fetched via the network. The part that remains is straightforward enough with the built-in useState/useReducer.
It does take a moment to learn React Query. You should make sure everyone understands how query keys work and uses them correctly. I saw some confusion there when we started using it, and one developer trying to work around stuff manually that React Query does automatically if you properly set up your query keys and invalidate them.
Re: TanStack Query(a.k.a. React Query) v5 announced
#6> Apart from that, we've renamed cacheTime to gcTime to better reflect what it is doing Does it though? Maybe it's super obvious to more experienced users, but now I need to read the docs to find out what "gc" stands for. Not a big deal, just seems like an unnecessary abbreviation, so I'm curious as to what the reasoning is.
which is likely much better than making the wrong assumption because you know what "cache" means. Check the docs, cacheTime is very likely not doing what you expected.
A typical expectation would be that "cacheTime" controls how long react query uses the cached value before it tries to fetch that data again from the server. That part is actually controlled by "staleTime".
Re: TanStack Query(a.k.a. React Query) v5 announced
#7Our team is currently debating whether we should adopt react-query or stick with plain old hand-written code around `fetch`. The team used Apollo in another project, so we are quite familiar with a "heavy handed wrapper" around backend requests. But I'm not sure the added complexity of react-query is "worth it". Anyone have experiences to share, either using react-query, a different library or particularly painful me…
Saw a team trip all over themselves trying to implement the pagination and also introduced a bunch of caching bugs(predictable any time caching is introduced).
It's cool that it's ALSO a general pattern for any async call, but it's really heavy for just that if you don't want the caching and stuff.
Personally I'm just sticking with MobX and more straightforward fetching mechanics.
Re: TanStack Query(a.k.a. React Query) v5 announced
#8There have been endless discussions about state management in React. React Query solved the most common and most annoying part of state management for me, which was everything that you fetched via the network. The part that remains is straightforward enough with the built-in useState/useReducer. It does take a moment to learn React Query. You should make sure everyone understands how query keys work and uses them cor…
Can you provide examples regarding right/wrong common mistakes you found in use?
Re: TanStack Query(a.k.a. React Query) v5 announced
#9There have been endless discussions about state management in React. React Query solved the most common and most annoying part of state management for me, which was everything that you fetched via the network. The part that remains is straightforward enough with the built-in useState/useReducer. It does take a moment to learn React Query. You should make sure everyone understands how query keys work and uses them cor…
Can you provide examples regarding right/wrong common mistakes you found in use?
It was more of a general misunderstanding on how React Query is supposed to work, partially triggered by some mistakes in defining the query keys that meant that React Query didn't work as intended.
I'd recommend this blog post (or actually all blog posts on React query on that site):
https://tkdodo.eu/blog/effective-react-query-keys
What I observed was that the query keys were not consistently defined, which broke automatic refetching when the data was modified and invalidated. So the developer added some manual refetches because they thought React Query couldn't handle that automatically.
You need a consistent structure for your query keys and use that everywhere. Then you only need to make sure to invalidate the correct part of the query key hierarchy and the rest works automatically.
Re: TanStack Query(a.k.a. React Query) v5 announced
#10Our team is currently debating whether we should adopt react-query or stick with plain old hand-written code around `fetch`. The team used Apollo in another project, so we are quite familiar with a "heavy handed wrapper" around backend requests. But I'm not sure the added complexity of react-query is "worth it". Anyone have experiences to share, either using react-query, a different library or particularly painful me…
I used to cache queries.
Now I just fetch the data again.
Simple.