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...
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.
Edit: Also, IMO RTK enforce cleaner code/structure than RQ
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.
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