TanStack Query(a.k.a. React Query) v5 announced(tanstack.com) |
TanStack Query(a.k.a. React Query) v5 announced(tanstack.com) |
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.
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.
Second: The data in cached in React Query is effectively globally available, so it comes with all the benefits and pitfalls that globals have. We use Storybook and do not use React Query in the components that have stories, so React Query is only used in the root components of the app.
Anyone have experiences to share, either using react-query, a different library or particularly painful memories _not_ using a comparable library?
People do seem to prefer RQ generally, maybe because it’s a bit more intuitive and better documented. It might be a better choice for more complex caching and mutating needs. SWR is still so easy and intuitive as it is, so I haven’t seen a reason to prefer RQ by default.
I guess its worth giving it a spin and see for myself :)
Also I think react query has more options (you may or may not find useful).
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.
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.
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".
No redux, no context, no network cache, no nothing.
Minimal props.
I just use custom events to tell the rest of the application what to.
And use fetch to get stuff.
Does away with all the complexity of state management or prop drilling.
There are also plenty of applications where what you are describing is arguably just not feasible at all, like heavier applications that due to their nature just need a lot of client-side state.
I'd personally still favor Next.js + TanStack Query if given the choice.
Or I ask multiple times.
Asking multiple times is a tradeoff - if you are really needing to economise on back end server load then maybe front end caching matters more. But if your back end isn't going to mind, then ask again.
(There's also our RTK Query API that's part of Redux Toolkit, which is UI-agnostic but also has a React adapter.)
In fact, the React Query and Redux maintainers cross-recommend each other's libraries. If you're _not_ using Redux in an app, use React Query for your data fetching. If you _are_ using Redux in an app, use RTK Query for your data fetching.
(There are some differences in features and API design that might be a reason to use RTK Query even if you're not using Redux for client-side state management, such as the OpenAPI/GraphQL codegens, auto-generated React hooks, etc [1] )
[0] https://redux-toolkit.js.org/rtk-query/overview
[1] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...
The largest need for state management in most react applications is for so-called "server state", which is really just data from your backend. RQ lets you deal with that elegantly without buying into any other major state management solution like redux.
If you are already using redux for other reasons, RTK Query is a no-brainer. But if you aren't, something like RQ is probably a better choice.
Edit: Also, IMO RTK enforce cleaner code/structure than RQ
I think it vastly depends what you use redux for. If you have very complex local state, that is not always in sync with the server, than it may be the right thing to do. For example something like draw.io.
But just for fetching/mutating server data more or less synchronously (view, edit, save) it feels very unnecessary.
that's always the same critic people (including me) have, but RTK moslty solve that
> But just for fetching/mutating server data more or less synchronously
With RTK you can basically have the same simple usage (with better structure IMO), and if needed you have all the power of redux, side-effect, ready to use
I migrated a project to it from react query last year as we liked the react query style hooks and some of its behaviour, but found our usage of react query was getting a bit messy when we started adding dozens and dozens of more endpoints in a large app. Lots of things felt spread out and duplicated, we wanted to centralise things a bit (and simplify the typing) without adding a ton of custom hooks or abstractions
With RTK Query we got to move all the endpoint definitions, cache invalidation behaviour (we had many endpoints that used parameters from many other endpoint responses) and TS definitions to a single place. Also it uses redux underneath so we got the redux tools as well
I'd still use either projects again in the future, just depends on the project
RTK Query felt really good when dealing with a ton of microservices, but maybe overkill if you don't have a ton of endpoints where responses feed into other request parameters
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.
If at any point anyone goes like "oh it doesn't seem to support this, we'll have to write some wrappers/custom stuff", take a step back and read the docs again or ask around - the library in general takes care of everything it should and gets out of the way really well otherwise.
Happy to help with this.
Debouncing (for interactive form validations) seems to be something that you still have to sort out yourself.
And I'm not sure how much work the mutation support saves in practice (compared to the extremely sophisticated Apollo cache).
Once you need query invalidation it gets really useful.
But it also depends how you use fetch right now. If you do it on per-route basis, than react query might not bring a lot of benefits.
The only option I saw was to wrap `useQuery` so that you can do custom shenanigans like hooking up the abort signal to the fetch requests.
[0] https://the-guild.dev/openapi/fets/client/quick-start [1] https://openapi-ts.pages.dev/openapi-fetch/
Now I just fetch the data again.
Simple.
It may still make sense to keep react-query out of your storybooks though.