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

11–20 of 64 posts

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

#11

Post by aurbano »

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

Happy to help with this.

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

#12

Post by gherkinnn »

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…

Unlike Apollo, React Query is pleasant to use. It is more like a small wrapper that gets out of your way.

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

#13

Post by phronesis »

fabian2k wrote: post #6
phronesis wrote: post #4

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

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

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

#14

Post by aj_g »

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

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

#15

Post by supermatt »

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

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

#16

Post by gherkinnn »

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

I too default to useSWR because the docs are nicer and it is smaller both in scope and size. Never hit any limits.

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

#18

Post by andrewstuart »

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.

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

#19

Post by audessuscest »

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 enough. (and the project is still active)

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

#20

Post by 4lun »

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…

Had 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

Post reply on HN