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

51–60 of 64 posts

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

#51

Post by tkdodo »

phronesis wrote: post #13
fabian2k wrote: post #6

Earlier quoted context omitted.

which 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".

It's a fair point that I agree with. I meant more in terms of, why not just name it `garbageCollectTime`.

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

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

#53

Post by klauserc »

andix wrote: post #34
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…

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

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

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

#54

Post by klauserc »

going_north wrote: post #29
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 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/

Looks 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 [1] https://openapi-ts.pages.dev/openapi-fetch/

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

#55

Post by klauserc »

onion2k wrote: post #41
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.

Thanks!

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.

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

#56

Post by klauserc »

aurbano wrote: post #11
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…

Best 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 o…

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

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

#57

Post by hobofan »

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.

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

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

#58

Post by bradfox2 »

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.

This is insane when react query is available and so easy to use.

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

#59

Post by kabes »

tusharmath wrote: post #35
kabes wrote: post #23

Earlier quoted context omitted.

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.

Writing 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

I was talking about apollo client library (since we're comparing it with react query)

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

#60

Post by andy_ppp »

sadn1ck wrote: post #52
andy_ppp wrote: post #44

It’s worth noting you can autogenerate TanStack Query clients in a typesafe way using graphql-codegen, really saves a lot of time!

wait really? do you have a link I can check out?

Sure: https://the-guild.dev/graphql/codegen/plugins/typescript/typ...
Post reply on HN