Is Redux Dead? Why I Kicked Redux Out of Our SaaS App

🔥Connect: https://www.subham.online

🔥GitHub: https://github.com/Subham-Maity

🔥Twitter: https://twitter.com/TheSubhamMaity

🔥LinkedIn: https://www.linkedin.com/in/subham-xam

🔥Insta: https://www.instagram.com/subham_xam

A few months ago, I took the plunge and refactored parts of a SaaS app I’ve been working on for a while. We had Redux in there, doing its thing, managing global state. Even with the newer RTK Query approach, which streamlines Redux’s handling of server state, we found ourselves gravitating toward React Query for its straightforward setup and reduced boilerplate... You know, like when you carry around stuff in your backpack that you haven’t touched in months? That’s how it felt.
But as our app grew, so did the complexity. Redux started to feel less like a solution and more like a problem. We were writing more boilerplate than actual logic.

💡 The Redux Dilemma

One day, while battling yet another Redux-related bug, I stumbled upon React Query. I'd heard a lot of buzz around it, but I never thought it could completely replace Redux. Then I gave it a try.

Before (with Redux):

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react'

export const api = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (builder) => ({
    getUser: builder.query({
      query: (userId) => `users/${userId}`,
    }),
  }),
})

// Component with RTK Query
const UserProfile = ({ userId }) => {
  const { data, isLoading, error } = api.useGetUserQuery(userId);

  if (isLoading) return <Spinner />;
  if (error) return <Error message={error.message} />;
  return <UserInfo user={data} />;
};

After (with React Query):

const useUserData = (userId) => {
  return useQuery(['user', userId], () => api.fetchUser(userId));
};

const UserProfile = ({ userId }) => {
  const { data, isLoading, error } = useUserData(userId);

  if (isLoading) return <Spinner />;
  if (error) return <Error message={error.message} />;
  return <UserInfo user={data} />;
};

While both approaches might look similar in this simple example, React Query's simplicity shows in real-world applications. It doesn't require setting up stores or managing additional architectural patterns - it just works out of the box while giving you powerful caching and state management capabilities.

Instead of manually fetching data, writing reducers, dispatching actions, and then updating the store (old pattern of redux), React Query did most of that heavy lifting for us. Pair that with some well-crafted custom hooks, and we had a lean, mean state-management machine.

🤔 But Wait, Is Redux All Bad?

Now, don't get me wrong. Redux isn't the boogeyman. It's a powerful tool that has its place. If you're building an app with complex client-side state that needs to be shared across many unrelated components, If you’re working with deeply nested state, or if you need a more explicit control over the flow of your app but for 90% of cases, especially for handling server state, React Query + custom hooks is more than enough.

So, why the fuss? Sometimes, as devs, we fall into the trap of using what’s familiar, even when there are better tools out there. That’s what happened with me and Redux. I was stuck in my old ways, thinking Redux was the only way to manage state in larger apps. I mean, the whole internet was saying “Redux or bust!” right?

🎭 The Plot Twist

Here's the kicker: by choosing React Query over Redux (even modern Redux), we actually made our app MORE scalable. Counter-intuitive, right? But think about it – with React Query handling our server state and custom hooks managing local state, we had a clearer separation of concerns. Each part of our app became more modular and easier to reason about, without the overhead of Redux's architecture.

✅ Why We Still Choose React Query

• Simplicity: React Query required fewer configurations and dependencies, allowing us to start quickly and avoid setup time.
  • You need to include Redux as a dependency
  • You need to set up Redux store configuration
  • It's integrated with Redux's architecture
• Bundle Size: When you only need server state management, React Query offers a lighter solution since you don't need to include the entire Redux ecosystem
• Flexibility: With React Query, managing server state felt more intuitive, especially for small, isolated pieces of server data.
• Learning Curve: For teams not already using Redux, React Query often provides a gentler learning curve

🚀 Why This Approach is Correct:

RTK Query was developed to bridge the gap between Redux and modern server state tools like React Query. However, for server state management, React Query remains a more streamlined choice, offering specialized features for caching, background updates, and retries without Redux’s added setup. For global client state, you can combine React Query with lightweight libraries like Zustand or even use React's Context API. This approach avoids Redux’s heavier infrastructure, keeping your application’s state management both simpler and more performant by focusing React Query on server state and relying on lighter options for global client state.

🏁 Is Redux dead?

Honestly, in the last few months, I’ve seen very few cases where React Query didn’t meet my needs.

So, is Redux dead? Maybe not, but it's definitely not the all-star it used to be for handling server state in modern React apps.

The beauty of React Query lies in its focused approach to solving server state challenges without the additional complexity of a global state management system.

It's not about Redux being bad - it's about choosing the right tool for the job. In our case, React Query proved to be that tool. React Query bring a new level of simplicity and efficiency that’s hard to ignore. For those not tied to Redux, it might be worth exploring if React Query or other dedicated server state solutions could better meet your app’s needs."

So, there you have it. Our journey from Redux addiction to React Query enlightenment. It wasn't always easy – there were moments of doubt, late-night debugging sessions, and more than a few facepalms. But in the end, it was worth it.

The key isn't choosing what's popular or traditional - it's choosing what's right for your specific needs. For us, that was React Query, and we haven't looked back since.

If you're feeling bogged down by Redux in your own app, I encourage you to take a step back and ask yourself: do you really need it? You might be surprised by the answer.

sometimes less is more. Especially when it comes to state management. Now if you'll excuse me, I have some more reducers to delete. Happy coding!

You can also check: Learn RTK Query