State Management in React: Comparing Context API, Zustand, Redux, and Jotai

Table of Contents

• Introduction
• Understanding State Management in React
• When Do You Need External State Management?
• Context API: Built-in Solution
• Zustand: Minimalist State Management
• Redux: The Industry Standard
• Jotai: Atomic State Management
• Comparing the Solutions
• Choosing the Right Solution
• Migration Patterns
• Best Practices
• Common Pitfalls to Avoid
• Conclusion

Introduction

State management is one of the most critical decisions you’ll make when building React applications. With so many options available—from React’s built-in Context API to powerful libraries like Redux, Zustand, and Jotai—choosing the right solution can feel overwhelming. Each tool has its strengths, weaknesses, and ideal use cases.

The wrong choice can lead to performance issues, unnecessary complexity, or code that’s difficult to maintain. On the other hand, the right state management solution can make your application more predictable, easier to test, and simpler to scale.

This comprehensive guide will help you understand when and why to use different state management solutions in React. We’ll dive deep into Context API, Zustand, Redux, and Jotai, comparing their approaches, performance characteristics, and developer experience. You’ll learn practical patterns, see real-world examples, and gain the knowledge needed to make informed decisions for your projects.

By the end of this guide, you’ll be able to evaluate your application’s needs and choose the most appropriate state management solution, whether you’re building a small personal project or a large-scale enterprise application.

Understanding State Management in React

Before comparing different solutions, it’s essential to understand what state management means in React and why it matters.

What is State?

State represents the data that changes over time in your application. It could be user input, data fetched from an API, UI state like modals being open or closed, or any other dynamic information that affects what your components render.

React components can manage their own local state using useState or useReducer hooks. This works perfectly for component-specific data that doesn’t need to be shared:

// Local state - perfect for component-specific data
function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

The Problem: Sharing State Across Components

When multiple components need access to the same state, passing props down through many levels (prop drilling) becomes cumbersome and error-prone:

// Prop drilling - becomes unwieldy with many levels
function App() {
  const [user, setUser] = useState(null);

  return (
    <Layout>
      <Header user={user} />
      <Content>
        <Sidebar user={user} />
        <MainContent>
          <Dashboard user={user} />
        </MainContent>
      </Content>
    </Layout>
  );
}

This is where state management solutions come in. They provide a way to:

• Share state across multiple components without prop drilling
• Manage complex state logic in a centralized location
• Enable predictable state updates with clear data flow
• Improve performance through selective re-renders
• Make state easier to test and debug

Types of State

Understanding different types of state helps you choose the right management strategy:

1. Server State: Data fetched from APIs (consider React Query, SWR, or TanStack Query)
2. UI State: Modal visibility, form inputs, theme preferences
3. Global Application State: User authentication, shopping cart, app-wide settings
4. Derived State: Computed values based on other state
5. Form State: Complex form data with validation (consider React Hook Form or Formik)

💡 Tip: Not all state needs global management. Start with local state and only lift it up when multiple components need it.

When Do You Need External State Management?

Before reaching for a state management library, evaluate whether you actually need it. Many React applications can get by with just useState, useReducer, and Context API.

✅ You Probably Need External State Management When:

• Multiple unrelated components need the same state
• Complex state logic with interdependent updates
• Time-travel debugging or state persistence is required
• Large-scale applications with many developers
• Performance optimization through selective subscriptions
• Middleware needs (logging, async actions, side effects)

❌ You Probably Don’t Need External State Management When:

• Simple applications with minimal shared state
• Component-specific state that doesn’t need to be shared
• Server state (use React Query or SWR instead)
• Form state (use React Hook Form or Formik)
• URL state (use React Router’s location state)

🔍 Deep Dive: The React team recommends starting with local state and Context API. Only add external libraries when you encounter specific problems they solve.

Context API: Built-in Solution

Context API is React’s built-in solution for sharing state across components without prop drilling. It’s been part of React since version 16.3 and provides a simple way to pass data through the component tree.

How Context API Works

Context API consists of three parts:

1. createContext: Creates a context object
2. Provider: Supplies the context value to children
3. useContext: Consumes the context value

// Creating a context
import { createContext, useContext, useState, ReactNode } from 'react';

type ThemeContextType = {
  theme: 'light' | 'dark';
  toggleTheme: () => void;
};

const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

// Provider component
export function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState<'light' | 'dark'>('light');

  const toggleTheme = () => {
    setTheme(prev => prev === 'light' ? 'dark' : 'light');
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

// Custom hook for consuming context
export function useTheme() {
  const context = useContext(ThemeContext);
  if (context === undefined) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
}

Using Context in Components

function App() {
  return (
    <ThemeProvider>
      <Header />
      <Content />
    </ThemeProvider>
  );
}

// Header.tsx - consumes context
function Header() {
  const { theme, toggleTheme } = useTheme();

  return (
    <header className={theme}>
      <h1>My App</h1>
      <button onClick={toggleTheme}>Toggle Theme</button>
    </header>
  );
}

✅ Context API Advantages

• No external dependencies - built into React
• Simple API - easy to learn and use
• TypeScript support - works well with TypeScript
• Perfect for theme, auth, or settings - use cases with infrequent updates

❌ Context API Limitations

• Performance issues - all consumers re-render when context value changes
• No selective subscriptions - can’t subscribe to part of the context
• Provider nesting - can lead to “provider hell” with many contexts
• No middleware - limited support for side effects or async operations

Performance Optimization with Context

To mitigate performance issues, you can split contexts and use memoization:

// Split contexts to prevent unnecessary re-renders
const ThemeContext = createContext<'light' | 'dark'>('light');
const ThemeActionsContext = createContext<() => void>(() => {});

export function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState<'light' | 'dark'>('light');

  const toggleTheme = useCallback(() => {
    setTheme(prev => prev === 'light' ? 'dark' : 'light');
  }, []);

  return (
    <ThemeContext.Provider value={theme}>
      <ThemeActionsContext.Provider value={toggleTheme}>
        {children}
      </ThemeActionsContext.Provider>
    </ThemeContext.Provider>
  );
}

// Components that only need the theme value won't re-render when toggleTheme changes
function ThemeDisplay() {
  const theme = useContext(ThemeContext);
  return <div>Current theme: {theme}</div>;
}

// Components that only need the action won't re-render when theme changes
function ThemeToggle() {
  const toggleTheme = useContext(ThemeActionsContext);
  return <button onClick={toggleTheme}>Toggle</button>;
}

⚠️ Warning: Context API can cause performance problems in large applications. If you notice unnecessary re-renders, consider splitting contexts or using a more sophisticated solution.

Zustand: Minimalist State Management

Zustand (German for “state”) is a small, fast, and scalable state management library that takes a minimalist approach. It’s designed to be simple, unopinionated, and performant.

Core Concepts

Zustand uses a single store that you can subscribe to selectively. It’s built on React hooks and provides a simple API:

pnpm add zustand

Basic Zustand Store

import { create } from "zustand";

type CounterStore = {
  count: number;
  increment: () => void;
  decrement: () => void;
  reset: () => void;
};

export const useCounterStore = create<CounterStore>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
  reset: () => set({ count: 0 }),
}));

Using Zustand in Components

function Counter() {
  // Select only what you need - prevents unnecessary re-renders
  const count = useCounterStore((state) => state.count);
  const increment = useCounterStore((state) => state.increment);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

// Another component - only re-renders when 'count' changes
function CountDisplay() {
  const count = useCounterStore((state) => state.count);
  return <div>Current count: {count}</div>;
}

Advanced Zustand Patterns

Async Actions

import { create } from "zustand";

type UserStore = {
  user: User | null;
  loading: boolean;
  error: string | null;
  fetchUser: (id: string) => Promise<void>;
};

export const useUserStore = create<UserStore>((set) => ({
  user: null,
  loading: false,
  error: null,
  fetchUser: async (id: string) => {
    set({ loading: true, error: null });
    try {
      const response = await fetch(`/api/users/${id}`);
      const user = await response.json();
      set({ user, loading: false });
    } catch (error) {
      set({ error: error.message, loading: false });
    }
  },
}));

Middleware: Persist, DevTools, and More

import { create } from "zustand";
import { persist, createJSONStorage } from "zustand/middleware";
import { devtools } from "zustand/middleware";

type SettingsStore = {
  theme: "light" | "dark";
  language: string;
  setTheme: (theme: "light" | "dark") => void;
  setLanguage: (language: string) => void;
};

export const useSettingsStore = create<SettingsStore>()(
  devtools(
    persist(
      (set) => ({
        theme: "light",
        language: "en",
        setTheme: (theme) => set({ theme }),
        setLanguage: (language) => set({ language }),
      }),
      {
        name: "settings-storage", // localStorage key
        storage: createJSONStorage(() => localStorage),
      },
    ),
    { name: "SettingsStore" }, // DevTools name
  ),
);

Immer Integration for Nested Updates

import { create } from "zustand";
import { immer } from "zustand/middleware/immer";

type TodoStore = {
  todos: Todo[];
  addTodo: (text: string) => void;
  toggleTodo: (id: string) => void;
  updateTodo: (id: string, updates: Partial<Todo>) => void;
};

export const useTodoStore = create<TodoStore>()(
  immer((set) => ({
    todos: [],
    addTodo: (text) =>
      set((state) => {
        state.todos.push({ id: Date.now().toString(), text, done: false });
      }),
    toggleTodo: (id) =>
      set((state) => {
        const todo = state.todos.find((t) => t.id === id);
        if (todo) todo.done = !todo.done;
      }),
    updateTodo: (id, updates) =>
      set((state) => {
        const todo = state.todos.find((t) => t.id === id);
        if (todo) Object.assign(todo, updates);
      }),
  })),
);

✅ Zustand Advantages

• Tiny bundle size - ~1KB gzipped
• Simple API - minimal boilerplate
• Selective subscriptions - only re-render when selected state changes
• No providers needed - use hooks directly
• Great TypeScript support - excellent type inference
• Middleware ecosystem - persist, devtools, immer, and more

❌ Zustand Limitations

• Less structure - can lead to inconsistent patterns in large teams
• Smaller ecosystem - fewer resources compared to Redux
• No built-in async handling - need to handle async actions manually

💡 Tip: Zustand is perfect for medium-sized applications where you want the power of Redux without the boilerplate. It’s become the go-to choice for many modern React applications.

Redux: The Industry Standard

Redux is the most popular and battle-tested state management library for React. It provides a predictable state container with a strict unidirectional data flow and excellent developer tools.

Core Concepts

Redux follows three principles:

1. Single source of truth - entire app state in one store
2. State is read-only - changes via dispatched actions
3. Changes are made with pure functions - reducers

pnpm add @reduxjs/toolkit react-redux

Redux Toolkit Setup

Redux Toolkit (RTK) is the modern, recommended way to use Redux:

import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "./features/counter/counterSlice";
import userReducer from "./features/user/userSlice";

export const store = configureStore({
  reducer: {
    counter: counterReducer,
    user: userReducer,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Creating a Slice

import { createSlice, PayloadAction } from "@reduxjs/toolkit";

type CounterState = {
  value: number;
};

const initialState: CounterState = {
  value: 0,
};

const counterSlice = createSlice({
  name: "counter",
  initialState,
  reducers: {
    increment: (state) => {
      state.value += 1; // Immer makes this safe
    },
    decrement: (state) => {
      state.value -= 1;
    },
    incrementByAmount: (state, action: PayloadAction<number>) => {
      state.value += action.payload;
    },
    reset: (state) => {
      state.value = 0;
    },
  },
});

export const { increment, decrement, incrementByAmount, reset } =
  counterSlice.actions;
export default counterSlice.reducer;

Using Redux in Components

import { Provider } from 'react-redux';
import { store } from './store';

function App() {
  return (
    <Provider store={store}>
      <Counter />
    </Provider>
  );
}

// Counter.tsx
import { useSelector, useDispatch } from 'react-redux';
import { RootState } from '../store';
import { increment, decrement } from './counterSlice';

function Counter() {
  const count = useSelector((state: RootState) => state.counter.value);
  const dispatch = useDispatch();

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => dispatch(increment())}>Increment</button>
      <button onClick={() => dispatch(decrement())}>Decrement</button>
    </div>
  );
}

Async Actions with Redux Toolkit Query

Redux Toolkit Query (RTK Query) provides powerful data fetching and caching:

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

export const apiSlice = createApi({
  reducerPath: "api",
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  tagTypes: ["User", "Post"],
  endpoints: (builder) => ({
    getUser: builder.query<User, string>({
      query: (id) => `/users/${id}`,
      providesTags: ["User"],
    }),
    createPost: builder.mutation<Post, Partial<Post>>({
      query: (newPost) => ({
        url: "/posts",
        method: "POST",
        body: newPost,
      }),
      invalidatesTags: ["Post"],
    }),
  }),
});

export const { useGetUserQuery, useCreatePostMutation } = apiSlice;

Using RTK Query in Components

function UserProfile({ userId }: { userId: string }) {
  const { data: user, isLoading, error } = useGetUserQuery(userId);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error loading user</div>;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
}

✅ Redux Advantages

• Predictable state updates - strict unidirectional data flow
• Excellent DevTools - time-travel debugging, action replay
• Large ecosystem - extensive middleware and tools
• Team collaboration - consistent patterns for large teams
• RTK Query - powerful data fetching and caching
• Mature and stable - battle-tested in production

❌ Redux Limitations

• Boilerplate - more code than other solutions (though RTK reduces this)
• Learning curve - concepts like actions, reducers, middleware
• Bundle size - larger than Zustand or Jotai
• Overkill for small apps - can add unnecessary complexity

🔍 Deep Dive: Redux Toolkit significantly reduces boilerplate compared to classic Redux. The createSlice API automatically generates action creators and uses Immer for safe mutations.

Jotai: Atomic State Management

Jotai takes a unique approach to state management using atomic primitives. Instead of a single store, Jotai uses atoms—small, independent pieces of state that can be composed together.

Core Concepts

Jotai’s atomic model means:

• Each piece of state is an atom
• Atoms can depend on other atoms (derived state)
• Components subscribe to specific atoms
• Only components using changed atoms re-render

pnpm add jotai

Basic Atoms

import { atom, useAtom } from 'jotai';

// Primitive atom
const countAtom = atom(0);

// Read-write atom with custom logic
const incrementAtom = atom(null, (get, set) => {
  set(countAtom, get(countAtom) + 1);
});

function Counter() {
  const [count, setCount] = useAtom(countAtom);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => useAtomValue(incrementAtom)}>Increment (atom)</button>
    </div>
  );
}

Derived Atoms

import { atom } from "jotai";

const baseCountAtom = atom(0);

// Derived atom - automatically updates when baseCountAtom changes
const doubledCountAtom = atom((get) => get(baseCountAtom) * 2);

// Complex derived atom
const countStatsAtom = atom((get) => {
  const count = get(baseCountAtom);
  return {
    value: count,
    doubled: count * 2,
    isEven: count % 2 === 0,
    isPositive: count > 0,
  };
});

Async Atoms

import { atom } from "jotai";

type User = {
  id: string;
  name: string;
  email: string;
};

// Async atom for fetching data
const userAtom = atom(async (get) => {
  const userId = get(userIdAtom);
  const response = await fetch(`/api/users/${userId}`);
  return response.json() as Promise<User>;
});

// Loading state atom
const userLoadingAtom = atom((get) => {
  const user = get(userAtom);
  return user instanceof Promise;
});

Using Jotai in Components

import { useAtom, useAtomValue } from 'jotai';

function UserProfile() {
  // Read-only atom value
  const user = useAtomValue(userAtom);
  const isLoading = useAtomValue(userLoadingAtom);

  if (isLoading) return <div>Loading...</div>;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
}

// Component that only reads doubled count
function DoubledCount() {
  const doubled = useAtomValue(doubledCountAtom);
  return <div>Doubled: {doubled}</div>;
}

Provider and Scope

Jotai works without a Provider by default (uses a default store), but you can create scoped stores:

import { Provider } from 'jotai';

function App() {
  return (
    <Provider>
      <Counter />
      <UserProfile />
    </Provider>
  );
}

// Multiple providers for different scopes
function MultiTenantApp() {
  return (
    <>
      <Provider scope="tenant1">
        <TenantDashboard tenantId="tenant1" />
      </Provider>
      <Provider scope="tenant2">
        <TenantDashboard tenantId="tenant2" />
      </Provider>
    </>
  );
}

Advanced Patterns

Write-only Atoms

const incrementAtom = atom(null, (get, set) => {
  set(countAtom, get(countAtom) + 1);
});

function IncrementButton() {
  const increment = useSetAtom(incrementAtom);
  return <button onClick={increment}>Increment</button>;
}

Split Atoms for Performance

const todosAtom = atom<Todo[]>([]);

// Split into individual atoms
const todoAtomsAtom = atom((get) => {
  const todos = get(todosAtom);
  return todos.map((_, index) => atom((get) => get(todosAtom)[index]));
});

function TodoList() {
  const todoAtoms = useAtomValue(todoAtomsAtom);

  return (
    <ul>
      {todoAtoms.map((todoAtom, index) => (
        <TodoItem key={index} todoAtom={todoAtom} />
      ))}
    </ul>
  );
}

// Only re-renders when this specific todo changes
function TodoItem({ todoAtom }: { todoAtom: PrimitiveAtom<Todo> }) {
  const [todo, setTodo] = useAtom(todoAtom);
  return <li>{todo.text}</li>;
}

✅ Jotai Advantages

• Composable - atoms can be combined and derived
• Fine-grained reactivity - only affected components re-render
• No providers needed - works out of the box
• Small bundle size - ~3KB gzipped
• TypeScript-first - excellent type inference
• Flexible - works with any React pattern

❌ Jotai Limitations

• Different mental model - atomic approach takes time to understand
• Smaller community - fewer resources than Redux
• No built-in DevTools - though community tools exist
• Can be verbose - many small atoms vs. one store

💡 Tip: Jotai excels when you need fine-grained control over re-renders and want to compose state from small, independent pieces. It’s particularly powerful for complex UIs with many interdependent components.

Comparing the Solutions

Let’s compare Context API, Zustand, Redux, and Jotai across key dimensions:

Bundle Size Comparison

Performance Characteristics

Developer Experience

Use Case Recommendations

Choosing the Right Solution

The best state management solution depends on your specific needs. Here’s a decision framework:

Decision Tree

Do you need to share state across components?
├─ No → Use useState/useReducer
└─ Yes → Is it simple theme/auth/settings?
    ├─ Yes → Context API
    └─ No → How complex is your app?
        ├─ Small/Medium → Zustand
        ├─ Large/Enterprise → Redux
        └─ Complex UI with many atoms → Jotai

Project Size Considerations

Small Projects (< 10 components)

• Start with Context API or local state
• Consider Zustand if you need selective subscriptions

Medium Projects (10-50 components)

• Zustand is often the sweet spot
• Redux if you need strong structure and DevTools

Large Projects (50+ components)

• Redux for structure and team collaboration
• Jotai for fine-grained control
• Consider micro-frontends with different solutions per module

Team Considerations

• Solo developer: Zustand or Jotai for flexibility
• Small team: Zustand or Redux (depending on complexity)
• Large team: Redux for consistency and established patterns
• Mixed experience levels: Redux for extensive resources and documentation

Performance Requirements

• High performance needs: Zustand, Redux, or Jotai (all support selective subscriptions)
• Simple apps: Context API is fine
• Real-time updates: Consider Zustand or Redux with middleware

Migration Patterns

If you need to migrate between solutions, here are common patterns:

From Context API to Zustand

// Before: Context API
const ThemeContext = createContext();

// After: Zustand
const useThemeStore = create((set) => ({
  theme: "light",
  setTheme: (theme) => set({ theme }),
}));

From Redux to Zustand

// Before: Redux
const counterSlice = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
  },
});

// After: Zustand
const useCounterStore = create((set) => ({
  value: 0,
  increment: () => set((state) => ({ value: state.value + 1 })),
}));

From Zustand to Jotai

// Before: Zustand
const useCounterStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

// After: Jotai
const countAtom = atom(0);
const incrementAtom = atom(null, (get, set) => {
  set(countAtom, get(countAtom) + 1);
});

💡 Tip: When migrating, do it incrementally. You can use multiple state management solutions in the same app during the transition period.

Best Practices

Regardless of which solution you choose, follow these best practices:

✅ Do’s

1. Start Simple: Begin with local state, only lift when needed
2. Colocate Related State: Keep related state together
3. Use TypeScript: Type safety prevents many bugs
4. Normalize State: Avoid nested duplicates, use IDs and references
5. Keep State Minimal: Don’t store derived data, compute it
6. Use Selectors: Subscribe only to what you need
7. Handle Loading States: Always track loading and error states
8. Test State Logic: Write tests for state updates and reducers

❌ Don’ts

1. Don’t Over-Engineer: Don’t add state management until you need it
2. Don’t Store Everything Globally: Keep state as local as possible
3. Don’t Mutate State: Always return new state objects
4. Don’t Store Server State in Global State: Use React Query or SWR
5. Don’t Ignore Performance: Monitor re-renders and optimize
6. Don’t Mix Patterns: Be consistent within your codebase

Code Organization

// Recommended structure
src/
  store/
    slices/          # Redux slices or Zustand stores
      counter.ts
      user.ts
    index.ts         # Store configuration
  features/
    counter/
      components/
      hooks/
      store/         # Feature-specific state

Performance Optimization

// ✅ Good: Selective subscription
const count = useCounterStore((state) => state.count);

// ❌ Bad: Subscribing to entire store
const store = useCounterStore();

// ✅ Good: Memoized selectors
const expensiveValue = useMemo(() => computeExpensiveValue(data), [data]);

// ✅ Good: Split contexts for performance
const ValueContext = createContext();
const ActionsContext = createContext();

Common Pitfalls to Avoid

Learn from common mistakes developers make with state management:

1. Overusing Global State

❌ Anti-pattern: Storing everything globally

// Don't do this
const useEverythingStore = create((set) => ({
  inputValue: "",
  modalOpen: false,
  user: null,
  todos: [],
  // ... everything
}));

✅ Better: Keep state local when possible

// Local state for component-specific data
function Input() {
  const [value, setValue] = useState("");
  // ...
}

2. Not Handling Async State Properly

❌ Anti-pattern: Not tracking loading/error states

const useUserStore = create((set) => ({
  user: null,
  fetchUser: async (id) => {
    const user = await fetchUser(id);
    set({ user }); // What if it fails?
  },
}));

✅ Better: Always handle loading and errors

const useUserStore = create((set) => ({
  user: null,
  loading: false,
  error: null,
  fetchUser: async (id) => {
    set({ loading: true, error: null });
    try {
      const user = await fetchUser(id);
      set({ user, loading: false });
    } catch (error) {
      set({ error: error.message, loading: false });
    }
  },
}));

3. Unnecessary Re-renders

❌ Anti-pattern: Subscribing to more than needed

// Component re-renders when ANY store value changes
function Counter() {
  const store = useCounterStore();
  return <div>{store.count}</div>;
}

✅ Better: Select only what you need

// Only re-renders when count changes
function Counter() {
  const count = useCounterStore((state) => state.count);
  return <div>{count}</div>;
}

4. Mutating State Directly

❌ Anti-pattern: Direct mutation (breaks React’s immutability)

const useTodoStore = create((set) => ({
  todos: [],
  addTodo: (text) => {
    // ❌ Mutating directly
    todos.push({ id: Date.now(), text });
  },
}));

✅ Better: Return new state

const useTodoStore = create((set) => ({
  todos: [],
  addTodo: (text) => {
    set((state) => ({
      todos: [...state.todos, { id: Date.now(), text }],
    }));
  },
}));

5. Not Using TypeScript

❌ Anti-pattern: Untyped state

const useStore = create((set) => ({
  // No types, easy to make mistakes
  data: null,
}));

✅ Better: Type everything

type Store = {
  data: User | null;
  setData: (data: User) => void;
};

const useStore = create<Store>((set) => ({
  data: null,
  setData: (data) => set({ data }),
}));

⚠️ Warning: These pitfalls can lead to bugs, performance issues, and difficult-to-maintain code. Always follow best practices and use TypeScript for type safety.

Conclusion

Choosing the right state management solution for your React application is crucial for long-term success. Each solution—Context API, Zustand, Redux, and Jotai—has its strengths and ideal use cases.

Key Takeaways:

• Context API is perfect for simple, infrequently updated state like themes or settings
• Zustand offers the best balance of simplicity and power for most applications
• Redux provides structure and excellent tooling for large, complex applications
• Jotai excels when you need fine-grained reactivity and composable state

Remember that there’s no one-size-fits-all solution. Start simple with local state and Context API, and only add external state management when you encounter specific problems it solves. The best solution is the one that fits your team, project size, and requirements.

As you build more React applications, you’ll develop intuition for when each solution is appropriate. Don’t be afraid to experiment, but also don’t over-engineer. Keep state management as simple as possible while meeting your application’s needs.

For more React best practices and common pitfalls, check out our guide on 10 Most Common Pitfalls in React.js. If you’re new to React hooks, our React Hooks Cheatsheet provides a comprehensive reference.

Next Steps:

1. Evaluate your current application’s state management needs
2. Choose a solution based on your project size and requirements
3. Start with a small feature to validate your choice
4. Gradually migrate or expand as needed
5. Monitor performance and adjust your approach

Happy coding! 🚀