I am a software developer with a passion for frontend technologies using HTML, CSS, JavaScript, and frameworks like Bootstrap, Vue, and React. I also write backend applications with NodeJS and Express
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.
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!
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
maybe use redux rtk from toolkit to ease some things :)
Those are my thoughts exactly. RTK has fetchBaseQuery for handling API requests and it has background fetching and automatic caching too
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.
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!
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.