Zustand Makes More Sense When Your Global State Is Mostly UI State_

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

• Zustand Docs
• Redux Toolkit
• TanStack Query