Hacker News new | ask | show | jobs
by audessuscest 981 days ago
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)
4 comments

Hi, I'm a Redux maintainer. Yeah, Redux Toolkit includes our RTK Query data fetching and caching layer [0] [1], which is roughly equivalent in features and use case to React Query.

In fact, the React Query and Redux maintainers cross-recommend each other's libraries. If you're _not_ using Redux in an app, use React Query for your data fetching. If you _are_ using Redux in an app, use RTK Query for your data fetching.

(There are some differences in features and API design that might be a reason to use RTK Query even if you're not using Redux for client-side state management, such as the OpenAPI/GraphQL codegens, auto-generated React hooks, etc [1] )

[0] https://redux-toolkit.js.org/rtk-query/overview

[1] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...

[2] https://redux-toolkit.js.org/rtk-query/comparison

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

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

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.

> But for me it was always unnecessary ceremony

that's always the same critic people (including me) have, but RTK moslty solve that

> But just for fetching/mutating server data more or less synchronously

With RTK you can basically have the same simple usage (with better structure IMO), and if needed you have all the power of redux, side-effect, ready to use