is there a non react equivalent? I wanna vomit every time I see the word "hook" these days.
TanStack Query(a.k.a. React Query) v5 announced
21–30 of 64 posts
Re: TanStack Query(a.k.a. React Query) v5 announced
#22I'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…
Redux 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.
Re: TanStack Query(a.k.a. React Query) v5 announced
#23Our 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…
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.
Re: TanStack Query(a.k.a. React Query) v5 announced
#24My 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.
If you have multiple components that require access to the same data do you fetch the same data multiple times?
Re: TanStack Query(a.k.a. React Query) v5 announced
#25My 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.
Not 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.
Re: TanStack Query(a.k.a. React Query) v5 announced
#26I'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/mutating server data more or less synchronously (view, edit, save) it feels very unnecessary.
Re: TanStack Query(a.k.a. React Query) v5 announced
#27I'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…
Redux 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.…
React-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
Re: TanStack Query(a.k.a. React Query) v5 announced
#28I 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).
Re: TanStack Query(a.k.a. React Query) v5 announced
#29Our 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 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.
Re: TanStack Query(a.k.a. React Query) v5 announced
#30[deleted]