Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TanStack Query(a.k.a. React Query) v5 announced

tanstack.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: TanStack Query(a.k.a. React Query) v5 announced

#41

Post by onion2k »

klauserc wrote: post #3

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…

I 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.

Re: TanStack Query(a.k.a. React Query) v5 announced

#42

Post by acemarke »

nsonha wrote: post #21

is there a non react equivalent? I wanna vomit every time I see the word "hook" these days.

The 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.)

Re: TanStack Query(a.k.a. React Query) v5 announced

#43

Post by supermatt »

steve_adams_86 wrote: post #36
supermatt wrote: post #15

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).

There are some nice to have features in React Query off of the shelf, but nothing I’m aware of that can’t be accomplished with SWR if needed. There’s scroll restoration and offline mutations primarily. I’ve never actually needed either of those, and I personally prefer SWR because it’s so lightweight, out of the way, and portable. One thing RQ definitely has over SWR is better dev tools, but I’ve never actually neede…

OOTB offline-first sounds handy. With SWR I had to modify the fetcher to query and store in indexedDB and then later replay to remote, which while not exactly difficult did require some effort.

I guess its worth giving it a spin and see for myself :)

Re: TanStack Query(a.k.a. React Query) v5 announced

#45

Post by alvarlagerlof »

klauserc wrote: post #3

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…

I'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.

Re: TanStack Query(a.k.a. React Query) v5 announced

#46

Post by kebsup »

audessuscest wrote: post #19

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 one of my recent projects I've used rtk in combination with their openApi generator and that was one of the fastest developed apps I've made. Having all hooks ready from a single command is just great.

Re: TanStack Query(a.k.a. React Query) v5 announced

#47

Post by kebsup »

I'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.

Re: TanStack Query(a.k.a. React Query) v5 announced

#49

Post by edgyquant »

IceDane wrote: post #25
andrewstuart wrote: post #18

My 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.

One of the apps I currently manage does this. It works fine, but that’s because we’ve basically reimplemented redux

Re: TanStack Query(a.k.a. React Query) v5 announced

#50

Post by SebastianKra »

janaagaard wrote: post #39
cced wrote: post #8

Earlier quoted context omitted.

Can you provide examples regarding right/wrong common mistakes you found in use?

First: 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…

ReactQuery state is not global. It's set in a context, and it takes two lines to write a Storybook decorator that ensures a unique cache for each story.

It may still make sense to keep react-query out of your storybooks though.

Post reply on HN