31–40 of 64 posts
I 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).
I'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…
Never 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/m…
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
is there a non react equivalent? I wanna vomit every time I see the word "hook" these days.
Our 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…
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.
Earlier quoted context omitted.
Unlike Apollo, React Query is pleasant to use. It is more like a small wrapper that gets out of your way.
What 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.
I 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).
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 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).
How 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
I 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).
The 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).
There 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?
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.
I'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…
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...