🔥Connect: https://www.subham.online
🔥GitHub: https://github.com/Subham-Maity
🔥Twitter: https://twitter.com/TheSubham...
For further actions, you may consider blocking this person and/or reporting abuse
IMO it's not really fair to compare vanilla Redux and specialized library. Through evolution of a product I work on for 5 years, we as a team came to conclusion, that boilerplate code should be reduced; that handling of a single request doesn't have to be so heavyweight: actions, reducers, sagas and so on. Yet, when you just try to migrate all the business logic to React Query, you instantly fail, you can't just add a new query to a feature that uses bunch of sagas that performs some chained requests. So, then the most preferred option is RTK Query, as it is still Redux and business logic doesn't fall apart from "just server state". And, if I'm not very wrong, it has pretty everything that React Query does, background refetching, caching, long polling etc. Never felt that something's missing, honestly.
Would I use RTK Query in a new project? Maybe, why not. You get a server-state manager and a global state manager in one box.
Would I use React Query with Zustand or something like that? Again, maybe, why not. It's a shiny new tools that cool kids are using.
Would I refactor all my entire codebase just to get rid of Redux, that is nicely wrapped in Redux Toolkit that encaplusates boilerplate? Can't see any reason why.
Our complete Redux removal wasn't just about reducing boilerplate - it led to cleaner architecture, better performance, and more maintainable code. For complex business logic and chained requests, React Query's mutation hooks and query invalidation patterns actually proved more powerful than Redux sagas.
The question isn't whether RTK Query can handle server state - it's whether carrying Redux's complexity is worth it when specialized tools do the job better. In our case, the refactor effort paid off significantly in long-term maintainability and developer productivity.
maybe use redux rtk from toolkit to ease some things :)
No, not really. I've used Redux Toolkit (RTK) with Redux Thunk extensively, and even wrote an article on it: Learn RTK Query in Next.js in 5 Minutes. While RTK is powerful, especially for global state management, I've found that React Query outperforms it in key areas like performance, simplicity, and scalability—particularly when dealing with server-side data. React Query’s approach to state management is far more intuitive, with automatic caching, background fetching, and minimal boilerplate. In most cases, about 90% of what you need can be handled efficiently through React Query, leaving Redux or Zustand for managing only the truly global client-side state. RTK, while effective, can feel messier due to the extra setup and less streamlined state synchronization.
Hi, I'm a Redux maintainer.
If you're comparing "RTK" to React Query in terms of writing your own reducers and thunks for data fetching, yes, I agree there's a difference. But, we specifically teach using the purpose-built RTK Query data fetching and caching layer for data fetching in Redux apps, and we designed RTK Query to be very similar to React Query in terms of API, concepts, and usage.
Can you point to specific aspects where you feel RTK Query does not match React Query in terms of "performance, simplicity, and scalability"? Or is this just a comparison of React Query vs "RTK with writing my own logic"?
Thank you for taking the time to review and provide feedback.
I apologize for the wrong comparison in the original article. I've updated the article to properly compare RTK Query and React Query side by side.
The core differences I've found in practice are mainly around initial setup requirements and bundle size considerations when working with server-state focused applications. That said, both solutions are powerful and well-designed... the choice really depends on team requirements and existing architecture.
Really appreciate your input in helping make this article more accurate and valuable for the community.
I guess it's a matter of personal preference. But you did compare raw redux even without toolkit against library focused on making queries. If you want to judge something then compare rtk with react query and then make some conclusions. I don't say you are wrong, cause you can't be wrong by using what you like and feel good but you are comparing wrong things. Writing raw logic always must fail against library specialized in certain things.
I totally get your point! You’re absolutely right that it's important to compare tools on more equal footing. My focus was specifically on RTK Query versus React Query for server-side data management. In that context, I find React Query’s automatic caching, background re-fetching, and overall simplicity more efficient, especially when working with server-state-heavy apps.
That said, I still use Redux Toolkit for managing client-side global state in certain parts of my projects where it's necessary. I haven't abandoned it entirely—RTK definitely has its strengths for handling complex or shared state. But for server-side data, React Query often feels like the more streamlined solution.
At the end of the day, as you mentioned, it really comes down to personal preference and the specific needs of your project!
Those are my thoughts exactly. RTK has fetchBaseQuery for handling API requests and it has background fetching and automatic caching too
Redux real replacement is useReducer, which is original, lightweight React state handling solution paired with commonly used useState. The Big difference is the useReducer working with reducer and actions so it is capable to handle a complex state handling instead useState just handle a single one.
If would like avoid dispatch passing and typesafe useReducer, feel free to try: jsdoc-duck ... maybe worth it.
But redux have own strength as battle tested global state handler library for Redux
Well I'm little confused here as React query is a data fetching library and not a state management library while Redux is state management library.
so in your example React query only helps to optimize the fetching part and eliminate useEffect in the component.
yes I agree using React query makes code more predictable and easier to understand
but what if this component also wants to share state under the deeper component where redux makes more sense and react query wont
Conclusion is Redux is not data fetching library but state management while React query is data fetching library not state management
I've found that a large portion (often 80%+) of what we traditionally put in Redux was actually server state - data fetched from APIs that we were manually syncing and caching. For the remaining client-side state that truly needs to be global, I've found that lighter solutions like Context + hooks or Zustand work well enough.
That said, there are absolutely valid use cases where Redux still shines:
If you ended up removing part or most of redux code from your project then you probably shouldn't have used it to that extent in the first place. But comparing plain redux with react-query is a bit misleading.
Nonetheless, one should be careful before going full on with redux as it introduces new complexity. In a team environment, everyone keeps adding one more global state to redux store. And before you know it, it gets too big to handle.
We went overboard with Redux at first. You know how it goes ...you start putting everything in Redux just because it's there. True that comparing with plain Redux wasn't fair.. we actually used RTK Query and redux Toolkit before.
But after seeing our app getting messy, we switched things up. Now we just use React Query for API stuff and Zustand for the few things that actually need global state sharing.
The code's much cleaner now without all that extra Redux complexity!
Redux is a global state manager, not an async state control library. In my project I use both, but redux is to hold information that needs to be accessible by any component, not to execute queries.
I've found that many teams (including mine) were using it as a catch-all solution, even for managing server data - which led to unnecessary complexity. The distinction between global state management and async state control is exactly why we moved away from Redux.
In our experience, about 90% of what we were storing in Redux was actually server state - data that React Query now handles much more elegantly with built-in caching, background updates, and synchronization. For the small amount of truly global client state we needed, simpler solutions like Context + custom hooks proved more than sufficient.
The question isn't whether Redux can store global state - it's whether we need that level of complexity for most modern web applications. After removing Redux, our codebase became more maintainable, our components more focused, and our state management more intuitive.