Hacker News Reader

Comment by klauserc | Hacker News Reader

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 memories _not_ using a comparable library?

View on HN

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

Saw a team trip all over themselves trying to implement the pagination and also introduced a bunch of caching bugs(predictable any time caching is introduced).

It's cool that it's ALSO a general pattern for any async call, but it's really heavy for just that if you don't want the caching and stuff.

Personally I'm just sticking with MobX and more straightforward fetching mechanics.

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.

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

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

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.

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.

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/

I used to cache queries.

Now I just fetch the data again.

Simple.

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.

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)

Reply on news.ycombinator.com