Redux is not the wrong tool. It is just very often the heavier tool.
In many modern React apps, the biggest global state needs are not event-sourced domain workflows. They are things like:
- modal state
- sidebar state
- active filters
- user preferences
For that kind of state, Zustand often feels cleaner because it gives you a small external store without the ceremony of reducers, actions, and providers everywhere.
A Typical Zustand Shape
import { create } from "zustand";
type UiStore = {
isSidebarOpen: boolean;
toggleSidebar: () => void;
};
export const useUiStore = create<UiStore>((set) => ({
isSidebarOpen: false,
toggleSidebar: () =>
set((state) => ({ isSidebarOpen: !state.isSidebarOpen })),
}));
Consumers can subscribe only to the slice they need:
const isSidebarOpen = useUiStore((state) => state.isSidebarOpen);
That is usually enough for a lot of product UI.
The Real Architectural Split
Teams get into trouble when they store too much server state in the same global store. Cached API results, refetch behavior, optimistic updates, invalidation, and background synchronization are usually better handled by server-state tools like React Query.
That means the modern split often looks like:
- Zustand for UI state
- React Query for server state
That is more useful than trying to pick one store to own everything.
Trade-Offs
Redux still makes sense when:
- state transitions need strict structure
- the team wants explicit event-driven state modeling
- tooling around reducers and middleware is valuable
Zustand makes sense when simplicity and selective subscriptions are the bigger win.
Further Reading