6 ms·
TanStack Query(a.k.a. React Query) v5 announced
- klauserc 3y agoOur 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?
- Rapzid 3y agoSaw 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.
- andrewstuart 3y agoI used to cache queries. Now I just fetch the data again. Simple.
- aurbano 3y agoBest thing you could do, spend some time learning how it works properly (query keys, invalidations... ) and how you'd set up things like pagination. 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.
- klauserc 3y agoIt does seem to have an answer to most common challenges. 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).
- gherkinnn 3y agoUnlike Apollo, React Query is pleasant to use. It is more like a small wrapper that gets out of your way.
- kabes 3y agoWhat don't you like about Apollo? I've used both apollo (for graphql backends) and react query (for rest backends) and find them quite similar.
- tusharmath 3y agoWriting your own backend for GraphQL doesn't scale. You should stick to no-code solutions that can auto generate graphQL on top of existing APIs. Checkout https://tailcall.run https://tailcall.run
- kabes 3y agoI was talking about apollo client library (since we're comparing it with react query)
- 4lun 3y agoHad a good experience with RTK Query, lives under redux toolkit but does much more than just reducing the boilerplate for redux which I don't think many people have noticed 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 https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview
- going_north 3y agoI would suggest taking a look at SWR [0]. I think it strikes a very nice balance between using fetch and something more heavy-handed like React Query. [0] https://swr.vercel.app/ https://swr.vercel.app/
- klauserc 3y agoLooks interesting. Thanks! Not sure how I feel about the key being handed to the fetcher (might be great, might be annoyingly verbose). Will have to see what it looks like in practice. (We are going to use feTS [0] or openapi-fetch [1], which are very particular about how the path is assembled) [0] https://the-guild.dev/openapi/fets/client/quick-start https://the-guild.dev/openapi/fets/client/quick-start [1] https://openapi-ts.pages.dev/openapi-fetch/ https://openapi-ts.pages.dev/openapi-fetch/
- andix 3y agoIn my opinion react query doesn't really add complexity if you just use to "await" your fetches. It even comes with the nice added functionality to refetch everything when refocusing the browser. And some automatic error handling. 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.
- klauserc 3y agoMix of both. Some data needs to be ready on page load, but we also have quite a number of interactive use cases (e.g., form validation with a backend query).
- onion2k 3y agoI spent a couple of years on a project that used React Query with Axios. The massive advantage over plain fetch was the middleware API. If you want to do things like injecting an auth header or clientside token refresh it's really useful. That was more Axios than React Query though.
- klauserc 3y agoThanks! 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.
- alvarlagerlof 3y agoI've tried plain fetch + useEffect + useState. It's very easy to mess up the implementation. For example you have to think about what happens if the useEffect triggers again while it is already fetching. For reasons like that, react-query is totally worth it to me.
- zegl 3y agoVery 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.
- phronesis 3y ago> 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.
- fabian2k 3y agowhich 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".
- phronesis 3y agoIt's a fair point that I agree with. I meant more in terms of, why not just name it `garbageCollectTime`.
- tkdodo 3y agoso cacheTime was really confusing because it seemed like "this is the amount time we cache data for", but that's not what it is. So a rename had to happen. We had some discussion on the public roadmap (https://github.com/TanStack/query/discussions/4252 https://github.com/TanStack/query/discussions/4252) about what it's gonna be. I'm usually against abbreviations, simply because there's always someone who doesn't understand what it means. But all other suggestions like inactiveCacheTime also had room for interpretation. gc is an abbreviation that is known well enough (think git gc), and it's also not an option that you will customize on a daily basis (usually once, globally).
- fabian2k 3y agoThere 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.
- cced 3y agoCan you provide examples regarding right/wrong common mistakes you found in use?
- fabian2k 3y agoIt 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 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.
- janaagaard 3y agoFirst: Realize that React Query isn't a library for fetching data, but a library for caching the fetched data. So think about how you will be invalidating that cache. For us, the rule of thumb was that each fetch to the API should have it's own cache key in React Query. 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.
- aj_g 3y agoI would almost consider this a default package to use in a react application for server-side state. Any mildly complex UI will almost immediately need init/loading/error/data states, and you begin to write a wrapper that trends towards what react-query gives you. It makes it a lot easier to by default, write code that provides much better UX. The improvement there far outweighs the small amount of time it takes to learn the library and overhead it introduces.
- supermatt 3y agoI currently use SWR. Is there a reason to choose tanstack query over SWR? A cursory look shows them to be near identical in scope, but tanstack is ~3x the bundled size. AFAICS there isnt anything that SWR doesnt support either OOTB or via minor modification to the fetcher (e.g. cancellable requests).
- gherkinnn 3y agoI too default to useSWR because the docs are nicer and it is smaller both in scope and size. Never hit any limits.
- andix 3y agoThe dev tools of react query did it for me. Much easier to see what's going on. Especially if you are not completely familiar with all the concepts yet. Also I think react query has more options (you may or may not find useful).
- supermatt 3y agoThere are devtools for SWR, but im not sure how react query ones compare. I will have to try it out i guess :)
- sebdufbeau 3y agoHow are you comparing bundle sizes? I know that the reported size on some sites like Bundlephobia for v5 is bigger than reality: https://twitter.com/TkDodo/status/1714275314745081895 https://twitter.com/TkDodo/status/1714275314745081895
- supermatt 3y agoThats a good point. I checked using the "better" tool (pkg-size.dev) they show on your link and it seems they are actually comparable for the "default" export (but im not sure what that gives me with tanstack query - its effectively everything with SWR).
- steve_adams_86 3y ago
- floucky 3y agoI love this package, I'm able to remove most of my Redux use cases with it.
- andrewstuart 3y agoMy react applications cache nothing and don’t use global state except to put the user Id in localstorage. 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.
- supermatt 3y agoIf you have multiple components that require access to the same data do you fetch the same data multiple times?
- andrewstuart 3y agoI send it in a custom event to the part of the system that needs it. 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.
- IceDane 3y agoNot gonna lie: that sounds absolutely awful, and I can't imagine this works at any real scale. It will also have poor UX, because your users will be waiting for data which you already fetched and should just have cached. 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.
- edgyquant 3y agoOne of the apps I currently manage does this. It works fine, but that’s because we’ve basically reimplemented redux
- hobofan 3y agoIf you have a fast API it's very feasible. I'll take slighly reduced UX due to slower page load times any day over unpredictable completely broken UX introduced by bad state management (common with e.g. Redux non-RTK in the hands of inexperienced frontend devs). I'd personally still favor Next.js + TanStack Query if given the choice.
- audessuscest 3y agoI've been using React-query on several projects including the v5 on a recent one. On a new project I decided to give a try to RTK (Redux ToolKit), I must say there's not much reason to not use RTK over a lib like react-query. You basically have the same and more, and all the advantages of using react-redux. It felt backward at first to come back to Redux after all this time, but I'm glad I did, and can't recommend it enough. (and the project is still active)
- IceDane 3y agoRedux is great, sure. But it's not a great fit for all applications, or maybe even most. 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.
- audessuscest 3y agoReact-query does have a state management, like redux. You can use RTK "the same way" than react-query, and it comes with more if needed, that's why I don't see real reason to prefer RQ over it Edit: Also, IMO RTK enforce cleaner code/structure than RQ
- andix 3y agoNever used RTK, just plain redux. But for me it was always unnecessary ceremony. Most application state is rather simple, once you properly organize it into "real" state and computed values. 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.
- audessuscest 3y ago
- nsonha 3y agois there a non react equivalent? I wanna vomit every time I see the word "hook" these days.
- deleted 3y ago[deleted]
- acemarke 3y agoThe underlying TanStack Query library is UI-agnostic, and has adapters for React and other frameworks. (There's also our RTK Query API that's part of Redux Toolkit, which is UI-agnostic but also has a React adapter.)
- nsonha 3y agoI guess it's not intended to be used directly hence no document at all? Might as well not exist.
- deleted 3y ago[deleted]
- andy_ppp 3y agoIt’s worth noting you can autogenerate TanStack Query clients in a typesafe way using graphql-codegen, really saves a lot of time!
- kebsup 3y agoI've seen multiple projects, in which people try to save results of requests into global state using Redux (not rtk), Zustand etc. and I have never seen it done well. React Query and Redux toolkit really should be the default options for request state management.
- jrogan993 3y agoBest react package ever.