Redux interview questions and answers

Core Concepts

• Store: A single JavaScript object that holds the entire application state.

• Actions: Plain objects describing what happened (e.g., { type: 'todos/todoAdded', payload: 'Buy milk' }).

• Reducers: Pure functions that take current state and an action, then return new state without mutating the original.

• Dispatch: The only way to trigger a state change – you call dispatch(action).

• Selectors: Functions that extract specific pieces of state from the store.

How Redux Works with Redux Toolkit

Redux Toolkit (RTK) replaces the legacy createStore (deprecated) with configureStore, which automatically combines reducers, sets up middleware (including Redux Thunk by default), and enables DevTools. It also introduces createSlice:

• createSlice generates action creators and a reducer from a single configuration object.

• Inside a slice’s reducers, you write “mutating” code (e.g., state.push(item)), but Immer converts it to a new immutable state behind the scenes.

• createAsyncThunk handles asynchronous logic, such as API calls, by generating pending/fulfilled/rejected action types.

Using Redux with React

React-Redux provides two hooks: - useSelector to read state from the store. It subscribes to the store and re-renders the component when the selected value changes. - useDispatch to get a reference to the store’s dispatch function.

The legacy connect() HOC is still supported but not recommended for new code.

When Not to Use Redux

Redux adds complexity. Prefer simpler alternatives when: - State is local to a component (use useState or useReducer). - Only a few components need shared state (React Context + useReducer may suffice). - You are mainly fetching and caching server data (use React Query, SWR, or RTK Query, which is part of RTK).

Code Example

A typical Redux Toolkit setup with React:

// app/store.js
import { configureStore } from '@reduxjs/toolkit';
import todosReducer from '../features/todos/todosSlice';

export const store = configureStore({
  reducer: {
    todos: todosReducer,
  },
});

// features/todos/todosSlice.js
import { createSlice } from '@reduxjs/toolkit';

const todosSlice = createSlice({
  name: 'todos',
  initialState: [],
  reducers: {
    todoAdded(state, action) {
      state.push({ id: Date.now(), text: action.payload, completed: false });
    },
    todoToggled(state, action) {
      const todo = state.find(t => t.id === action.payload);
      if (todo) todo.completed = !todo.completed;
    },
  },
});

export const { todoAdded, todoToggled } = todosSlice.actions;
export default todosSlice.reducer;

// components/TodoList.jsx
import { useSelector, useDispatch } from 'react-redux';
import { todoAdded, todoToggled } from '../features/todos/todosSlice';

export default function TodoList() {
  const todos = useSelector((state) => state.todos);
  const dispatch = useDispatch();

  const handleAdd = () => dispatch(todoAdded('New task'));
  const handleToggle = (id) => dispatch(todoToggled(id));

  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id} onClick={() => handleToggle(todo.id)}>
          {todo.completed ? '✓ ' : ''}{todo.text}
        </li>
      ))}
      <button onClick={handleAdd}>Add</button>
    </ul>
  );
}

Best Practices and Pitfalls

• Keep state minimal: Store only data that is truly shared or needed across the app.

• Use selectors with memoization (e.g., createSelector from RTK) to avoid unnecessary re-renders.

• Never mutate state directly outside of createSlice reducers – only inside Immer-enabled reducers is it safe.

• Do not dispatch in reducers; keep reducers pure.

• Use RTK Query for API caching instead of writing manual thunks – it reduces boilerplate and handles cache invalidation automatically.

Single Source of Truth

• Global Store: The entire application state lives in one JavaScript object tree within a single store instance.

• Consistency: This centralization ensures every component accesses the same data snapshot, preventing synchronization errors.

• Toolkit Usage: In Redux Toolkit, this store is created using configureStore instead of the deprecated createStore function.

• DevTools: A single store enables features like time-travel debugging and consistent state serialization for development tools.

• Serialization: Having one store allows the whole state to be persisted or hydrated easily during server-side rendering.

State Is Read-Only

• Action Emission: State cannot be modified directly by components; instead, you emit actions describing what happened.

• Immutability Rule: Traditionally, reducers must return new state objects rather than mutating existing ones to preserve history.

• Immer Exception: With createSlice, Immer allows writing “mutating” logic safely because it drafts changes into a new immutable state.

• Direct Mutation: Avoid mutating state outside of slices, as Immer protection does not apply to plain reducers or other logic.

• Performance: Read-only semantics enable shallow equality checks in React-Redux to optimize component re-renders efficiently.

Changes Are Made with Pure Functions

• Reducer Logic: Reducers specify how the state tree transforms in response to actions without triggering side effects.

• Determinism: Pure functions ensure the same input always yields the same output, making state changes fully deterministic.

• Testing Simplicity: This purity enables easy unit testing and prevents unexpected behavior from asynchronous logic inside reducers.

• Async Handling: Asynchronous operations should live in createAsyncThunk or RTK Query, keeping reducers strictly synchronous and pure.

• Debuggability: Because functions are pure, logging actions and state changes provides a complete trace of application behavior.

Modern Implementation Nuances

• React Integration: Developers should use useSelector and useDispatch hooks rather than the legacy connect() higher-order component.

• Boilerplate Reduction: Redux Toolkit abstracts boilerplate while adhering to these principles under the hood automatically.

• Server State: RTK Query handles server-state caching separately, reducing the need to manually manage loading flags in the store.

• API Preference: Always prefer the Toolkit APIs over manual action type constants and switch statements found in older tutorials.

• Type Safety: Toolkit provides better TypeScript inference out of the box compared to manual Redux implementation patterns.

When to Avoid Redux

• Local State: Local component state, such as form inputs, should remain in React useState or useReducer hooks.

• Context Usage: Simple prop drilling or React Context often suffices for theme settings or authentication status propagation.

• Server Libraries: Server-state libraries like React Query or RTK Query are preferred over Redux for cached API data management.

• Complexity Cost: Introducing Redux adds indirection; only use it when shared state complexity justifies the architectural overhead.

• Prototype Phase: During early prototyping, managing state locally avoids the setup cost associated with configuring a global store.

How Actions Work

• An action is dispatched (sent) to the Redux store via dispatch(action).

• The store forwards the action to the reducer, which uses the action’s type to decide how to update the state.

• Actions are the only way to trigger state changes in Redux. The reducer must never mutate the existing state directly—it returns a new state object.

Structure of an Action

A standard action object follows the “Flux Standard Action” convention (often called FSA):

• type: a string, typically in the form 'domain/eventName' (e.g., 'todos/todoAdded'); must be unique per action.

• payload: optional; any serializable data needed for the update.

• meta: optional; extra information about the action.

• error: optional; set to true for error actions.

How Actions Are Created in Modern Redux (RTK)

With Redux Toolkit, you rarely write action objects manually. Instead, createSlice generates both the action creator functions and the reducer logic from a slice definition.

• You call createSlice with a name, an initialState, and a reducers object.

• Each key in reducers becomes a reducer function and an action creator.

• The action creator takes a single argument (the payload) and returns an action object whose type is 'sliceName/reducerName' and whose payload is the argument.

• Inside the reducer, you can write “mutating” code (e.g., state.push(action.payload)) because Redux Toolkit uses Immer to produce immutable updates safely.

• For standalone action creators without a slice, you can use createAction('typeString'), which returns a function that creates the action object when called.

Advantages of Generated Actions

• No accidental typos: the action type string is guaranteed to match the reducer.

• Type safety: TypeScript users get inferred payload types.

• Consistent naming: createSlice uses the pattern sliceName/actionName.

Best Practices and Common Pitfalls

• Always use createSlice for reducers and actions; avoid hand-writing action type constants and action creators.

• Payload should be minimal: send only the data the reducer needs, not the whole object.

• Do not dispatch non-serializable values (functions, Promises, class instances) in actions. Redux expects actions to be serializable.

• Reducers must be pure: the same action and state must always produce the same new state. Side effects (API calls, timers) belong in thunks or RTK Query.

• When to forgo Redux: if state is local (component-only) or only passed through a few levels, use React’s useState or useReducer. For server data, consider RTK Query or React Query instead of manual action dispatching.

How Actions Work

• An action must have a type field (a string, conventionally "domain/eventName") and an optional payload field containing the data needed for the update.

• The store’s dispatch method receives the action object and forwards it to all reducer functions. In Redux Toolkit, the reducer for the matching slice handles the action type.

• Reducers are pure functions: they take the current state and an action as arguments and return the new state (or, with Immer, apply mutations that Immer turns into immutable updates).

Role of Actions in the Update Flow

1. A component calls dispatch(someActionCreator(data)).

2. The action creator (generated by createSlice) returns an action like { type: "todos/addTodo", payload: data }.

3. Redux internally runs the corresponding reducer, which updates the slice’s state.

4. React-Redux’s useSelector detects the state change and re-renders subscribed components.

Using createSlice for Actions and Reducers

Redux Toolkit’s createSlice automatically generates action creators and a reducer from an object of reducer functions (named “reducers”). Your action types are derived from the slice name and reducer key. Inside those reducer functions you can “mutate” state safely thanks to Immer.

Best Practices

• Keep actions semantically meaningful: each action should represent one user intention (e.g., addTodo, toggleTodo), not low-level state changes.

• Use prepare callbacks (inside createSlice reducers) if you need to generate a payload or validate it before the reducer runs.

• Avoid dispatching plain string types: always use the auto-generated action creators from createSlice to prevent typos and keep types consistent.

• Don’t overuse Redux: for component‑local state, use useState; for server data, consider RTK Query or another server‑state library. Redux is best for shared global state that needs to be predictable and debuggable.

Core Responsibility

The reducer receives two arguments: the current state and an action object containing a type field and optional payload. Based on the action type, it calculates and returns the next state. If the action is unrecognized, it must return the current state unchanged. This design enforces a unidirectional data flow where state changes are explicit and traceable.

• Determinism: Given the same state and action, the reducer always produces the same result.

• State Transition: It defines the mapping from state A to state B, never handling asynchronous logic or side effects.

Immutability and Redux Toolkit

Historically, Redux required strict immutability, meaning developers had to use spread operators or Object.assign to avoid mutating state. With Redux Toolkit, createSlice leverages the Immer library internally. This allows you to write “mutating” logic inside the reducer definition safely, as Immer produces a new immutable state behind the scenes.

• createSlice: Safe to use draft-state mutation syntax (e.g., state.value = 1).

• Plain Reducers: If writing a reducer function manually without Immer, you must still return new objects immutably.

• configureStore: Sets up the store with good defaults, including the slice reducers combined automatically.

When Redux Is Unnecessary

Redux introduces boilerplate and complexity, so it should be reserved for global state that many components need. Situations where Redux is often overkill include:

• Local UI State: Form inputs or toggle states belong in React useState.

• Component Props: Data passed down from a parent does not need global storage.

• Server State: Cached API data is better handled by RTK Query or React Query, which manage loading, caching, and invalidation automatically.

• Context API: Simple theme or auth flags can often use React Context without the Redux overhead.

Best Practices

Keep reducers thin and focused solely on state calculation. Asynchronous logic, random number generation, or API calls belong in createAsyncThunk or effects, never inside a reducer. Always export actions generated by createSlice so components can dispatch them using useDispatch. When selecting data in components, use useSelector to subscribe to relevant state slices efficiently. Avoid placing business logic that does not affect state inside reducers, as this complicates testing and debugging.

Scope and Ownership

• Local component state: Belongs strictly to the component that declares it. Other components can only access it if it is explicitly passed down through props.

• Redux state: Belongs to a single store created with configureStore. Any component can read the exact slice it needs through useSelector, and trigger updates through useDispatch, without relying on deep prop drilling.

• Source of truth: Local state can be fragmented across many components, whereas Redux aims for one predictable source of truth for shared state.

Updates and Immutability

• Local state updates: Handled directly by the component’s state setter with no global action flow required.

• Redux updates: Handled through reducers in response to dispatched actions. With Redux Toolkit’s createSlice, Immer is used, so writing “mutating” code inside those reducers is safe and will still produce immutable updates. However, this only applies to createSlice reducers, not plain reducers, which must perform true immutable updates with no mutations at all.

• Predictability: Every change to shared Redux state goes through the store’s update flow, making transitions easier to trace than scattered local updates.

When to Use Each

• Reach for local state: For strictly UI-focused concerns, such as opening a dropdown, toggling a modal, or managing an input value that no other component needs.

• Reach for Redux: For state that must be shared by distant parts of the tree, needs consistent coordination, or requires strict traceability across complex flows.

• When Redux isn’t needed: For purely local state, React Context can be suitable for simple cross-cutting needs, and for server-state (fetched, cached, or synchronized remote data), dedicated server-state libraries are often a much better fit than storing that data directly in Redux.

Key Differences at a Glance

Best Practices

• Start small: Default to local state with React hooks. Only introduce Redux when prop drilling or shared coordination becomes a real problem.

• Use the official path: Stick to Redux Toolkit (configureStore, createSlice) and React-Redux hooks. Avoid re-introducing deprecated patterns.

• Keep concerns split: Don’t mirror server-state blindly into the Redux store. Choose the right tool for the job between local state, Context, Redux, or a server-state library.

• Respect immutability boundaries: Only rely on the “mutating” reducer style when using createSlice. If you ever write a plain reducer, treat immutability as a strict requirement.

What the Store Holds and Exposes

• Root state object: the entire application state, combined from all reducers.

• dispatch(action): the only supported way to trigger state changes; actions must normally be plain objects unless middleware such as Redux Thunk handles them.

• getState(): returns the current state tree; useful in middleware or thunks, but should not be called during render.

• subscribe(listener): registers a callback that runs after each dispatch; React-Redux uses this internally, so components rarely need it directly.

• Single instance: a Redux application normally has one store. Multiple stores are technically possible but defeat the single-source-of-truth design and are discouraged.

How It Fits in React

• configureStore from Redux Toolkit creates the store, combines reducers, adds useful middleware such as Redux Thunk, and enables Redux DevTools by default.

• <Provider store={store}> makes the store available to the React component tree.

• Components read state with useSelector and send actions with useDispatch; they should not import or call the store directly.

• This replaces the legacy createStore and connect() APIs, which are deprecated.

Immutability and the Store

• The store never permits direct mutation; state is replaced only by the values reducers return.

• In createSlice reducers, Immer allows writing “mutating” code such as state.value += 1; Immer produces a new immutable state behind the scenes.

• In plain reducers written without Immer, every update must return a new object. Mutating the existing state corrupts change detection and breaks time-travel debugging.

• useSelector compares the previous and current selector result with strict reference equality (===). Mutating an object in place and returning the same reference prevents re-renders; returning a new reference triggers them. Memoized selectors created with createSelector avoid expensive recomputation, they do not change equality behavior.

When a Global Store Is Not Needed

RTK Query is part of Redux Toolkit and stores server state in the Redux store, but for many applications it can replace hand-written global data slices.

Common Pitfalls

• Overusing Redux: moving every piece of state into the store increases boilerplate and hurts encapsulation. Keep local state local.

• Mutating state outside reducers: this breaks DevTools, middleware, and can silently fail to re-render components.

• Unstable selector results: returning a new object or array from a selector on every render causes unnecessary re-renders. Select only the fields you need and memoize expensive selectors.

• Non-serializable state: storing functions, Promises, or class instances in the state breaks DevTools and the serializable-state middleware. Keep stored values serialifiable.

Core Concept

In traditional component-based architectures, state might be scattered across many local variables, leading to inconsistencies and synchronization bugs. Redux consolidates this into a global store accessible by any component that needs it. When a component needs data, it subscribes to the relevant slice of this state. When data changes, the store updates, and all subscribed components re-render. This centralization allows developers to inspect the exact state at any time, facilitating features like time-travel debugging, state persistence, and reliable logging of every action dispatched.

Implementation and React Integration

Modern Redux uses Redux Toolkit (RTK) to simplify store creation. The configureStore function sets up the store with sensible defaults, including the Redux DevTools Extension and middleware. Instead of manually writing reducers, developers use createSlice, which generates reducer functions and action creators automatically. Components interact with the store using React-Redux hooks rather than the older connect higher-order component. useSelector extracts specific data from the state tree, while useDispatch sends actions to trigger updates, ensuring components only re-render when selected data changes.

Immutability and Immer

A common concern is how state updates remain immutable. In plain Redux reducers, you must manually copy objects before modifying them. However, createSlice integrates Immer internally. This allows developers to write logic that looks like mutation inside the reducer function, while Immer produces a new immutable state tree behind the scenes. This safety mechanism ensures the single source of truth is updated correctly without accidental references leaking between states, preventing subtle bugs caused by direct mutation outside of slices.

When Redux Isn’t Needed

Despite its benefits, Redux adds architectural complexity and boilerplate. It is unnecessary for local UI state (like form inputs, dropdowns, or toggle flags) which should remain in React useState or useReducer. Server-state management is often better handled by dedicated libraries like React Query or RTK Query rather than manual Redux caching, as they handle loading states and invalidation automatically. For simple prop-drilling issues, React Context API is often sufficient. Use Redux when multiple components need access to the same state, or when complex state transitions require strict traceability and middleware support.

Best Practices

• Normalize State: Keep data flat and normalized within the store to avoid duplication and ensure consistency across the single source. Nested data should be flattened into lookup tables keyed by ID.

• Slice by Feature: Organize reducers by feature domain rather than by data type to improve maintainability as the application grows and teams scale.

• Avoid Overuse: Do not store transient UI state in Redux; keep it local to the component to reduce store noise and unnecessary re-renders that hurt performance.

• Type Safety: Use TypeScript with RTK to gain autocomplete and compile-time checks on state shapes and actions, reducing runtime errors and improving developer experience.

Understanding Immutable State

In programming, mutable data allows direct modification (e.g., state.value = 5), whereas immutable data requires creating a copy (e.g., return { ...state, value: 5 }). Redux relies on immutability to detect changes via reference equality. If the state reference changes, React components subscribed via useSelector know to re-render. Without immutability, changes might go unnoticed, leading to stale UIs and inconsistent application behavior.

Why It Matters in Redux

• Predictability: Pure functions with immutable inputs ensure the same action always yields the same state transition, making logic easier to test.

• Debugging: Time-travel debugging works because each state snapshot is a distinct object preserved in history, allowing developers to inspect past states.

• Performance: React-Redux optimizes rendering by comparing previous and next state references using shallow equality checks. Mutating state in place prevents this optimization, causing unnecessary renders or missed updates.

How Redux Toolkit Simplifies Immutability

Redux Toolkit’s createSlice uses Immer internally. This allows developers to write “mutating” logic inside reducers safely. Immer detects changes made to a draft state and produces a new immutable state behind the scenes. For example, inside a slice reducer you may write state.value += 1; Immer converts that into an equivalent immutable update. However, this safety net only applies inside RTK reducers. Outside reducers, such as in components or thunks, you must still treat state as immutable and never modify it directly.

When Redux Isn’t Needed

Not every application requires Redux. Consider these alternatives based on the data type: - Local State: Use React useState or useReducer for data confined to a single component, such as form inputs or toggle states. - React Context: Suitable for theme settings or user preferences shared across many components without complex business logic. - Server State: For caching server data, libraries like RTK Query, React Query, or SWR are often better suited than manual Redux state management, as they handle loading states and caching automatically.

Common Pitfalls

• Mutating State Outside Reducers: Never modify state directly in components or thunks. Always dispatch actions generated by slices.

• Returning Undefined: Ensure reducers always return a valid state; returning undefined can break the store initialization or cause runtime errors.

• Overusing Redux: Storing transient UI state in Redux adds unnecessary boilerplate compared to local state, increasing maintenance costs without benefit.

• Confusing Immer Safety with Global Mutability: Just because createSlice permits mutating syntax does not mean the underlying state is mutable; the same mutating code outside a reducer will corrupt the store.

How It Works

• You pass an object where each key names a slice of state, such as users or posts, and each value is the reducer responsible for that slice.

• combineReducers returns a new root reducer.

• When an action is dispatched, the root reducer calls every slice reducer with that slice’s previous state and the action.

• Each slice reducer must return its next slice state. If a reducer receives undefined state, it must explicitly return its initial state.

• If all slice references are unchanged, combineReducers can return the previous root state object, preserving reference equality.

Role in Redux Toolkit

• With createSlice, each slice automatically generates a reducer and action creators.

• configureStore({ reducer: { users: usersReducer, posts: postsReducer } }) accepts an object of slice reducers and internally calls combineReducers.

• createSlice reducers use Immer, so code that appears to mutate state inside the reducer is safe there. Plain reducers outside createSlice must still perform real immutable updates.

• Immer does not change combineReducers behavior: it still calls each slice reducer with that slice’s own state.

Advantages

• Separation of concerns: each slice reducer manages only its own state shape and relevant actions, making the code easier to test and maintain.

• Scalability: new features can add a new slice without modifying unrelated reducers.

• Predictable updates: every slice sees every action, but normally returns unchanged state for actions it does not handle.

• Performance: unchanged slice state keeps the same reference, and the root state can remain unchanged when no slice changes, enabling efficient selector and component checks.

Limitations and Common Pitfalls

• It composes reducers at one level of the state tree. Nested shapes are handled by composing reducers or designing cohesive slices.

• A slice reducer must never return undefined. For an unknown action, return the previous slice state; for initial setup, return the initial slice state. Returning undefined causes combineReducers to throw an error.

• Do not assume actions are routed only to one reducer: combineReducers calls all slice reducers for every action.

Best Practices

• Prefer configureStore and createSlice in modern Redux applications.

• Use combineReducers directly only when composing non-slice reducers, library reducers, custom root reducers, or legacy store setups.

• Keep slices focused on a cohesive domain or UI concern rather than creating many tiny, unrelated reducers.

• Do not add Redux solely because an app feels complex. Local component state is often enough for ephemeral UI state, React context can hold low-frequency global values such as a theme, and server data should usually be handled with RTK Query or another server-state library rather than hand-written Redux reducers.

Pure Functions in Redux

Reducers must be pure functions. Given the same state and action arguments, they always return the same new state object and have no observable side effects. This means a reducer should never:

• Mutate its arguments (e.g., state.items.push(item)) – unless using Immer inside createSlice.

• Perform API calls, Date.now(), Math.random(), or routing transitions.

• Read or write files, modify the DOM, or interact with external services.

When using Redux Toolkit’s createSlice, reducers look like they mutate state, but Immer wraps the operation to produce an immutable update under the hood. The reducer itself remains pure from the perspective of the Redux store.

Side Effects and Where They Belong

Side effects are operations that touch the outside world. In Redux they are never placed inside reducers. Instead they are executed in:

• Thunks (with createAsyncThunk or the thunk middleware) – for async logic like fetching data.

• Middleware (e.g., Redux Saga, Redux Observable) – for complex side‑effect orchestration.

• Components or custom hooks – for UI‑specific effects that do not require store access.

Redux Toolkit uses configureStore which includes the thunk middleware by default, making createAsyncThunk the recommended way to handle API calls and other asynchronous side effects.

How Redux Toolkit Handles Side Effects with createAsyncThunk

createAsyncThunk generates action types (pending, fulfilled, rejected) and dispatches them automatically. The thunk function itself is impure because it performs an async request, but the resulting actions are dispatched to pure reducers that update state based on the response. In extraReducers, you register handlers for each lifecycle case; those handlers receive the Immer-wrapped state and the action whose payload carries the thunk’s returned value. Because the handlers only derive new state from those inputs, they stay pure while the HTTP call lives entirely inside the thunk.

Best Practices and Common Pitfalls

• Keep reducers side‑effect‑free: Never dispatch actions, call external APIs, or use non‑deterministic values inside a reducer. Even though Immer lets you write mutating syntax, the logic must still be deterministic.

• Use createAsyncThunk for async flows – it handles error/dispatch lifecycle automatically. Avoid writing custom thunks for simple requests.

• Do not over‑use Redux: For local component state or UI‑specific side effects (like a form submission toast), useState and useEffect are simpler. Redux is for global state that many components need.

• Avoid side effects in selectors: Memoized selectors (e.g., createSelector) should also be pure; do not call new Date() or random inside them.

• Test pure reducers easily: Because reducers are pure, you can unit‑test them by providing a state and action and asserting the returned state, without any mocking.

• Remember deprecations: The original createStore is deprecated; always use Redux Toolkit’s configureStore which sets up the thunk middleware and Redux DevTools by default.

How It Works

• Use Redux Toolkit as the standard: The original createStore is deprecated. configureStore is the recommended way to set up your store with sensible defaults.

• Keep reducers pure: Reducers must remain pure and synchronous. No promises, fetch calls, timers, subscriptions, or other side effects may be performed inside a reducer.

• Thunks by default: configureStore adds the Redux Thunk middleware by default in Redux Toolkit, so async action creators can be used without manually installing or wiring up a separate thunk middleware in the vast majority of setups.

• Immer for immutability: When using createSlice, you may write “mutating” syntax inside your reducers and Immer will safely produce immutable updates. This safety only applies to reducers created with createSlice, not to plain reducers written manually.

Key Options For Handling Async Actions

• createAsyncThunk for custom async flows: Use this when you need custom logic around an asynchronous operation (e.g. posting data, chaining multiple requests, mapping responses, or coordinating non-trivial side effects). It automatically generates pending, fulfilled, and rejected action types that you can handle in extraReducers. Always account for all three states in your UI.

• RTK Query for server-state: For fetching, caching, re-fetching, synchronizing, and invalidating data from an API, RTK Query (included within Redux Toolkit) is the official, recommended tool. It drastically reduces boilerplate for standard CRUD and data-fetching use cases by managing loading states, caching, and request lifecycles for you. Prefer RTK Query for server-state before reaching for a fully manual createAsyncThunk flow for generic API data.

• Other thunks when necessary: For one-off side effects that aren’t purely API CRUD (e.g. writing to localStorage, analytics, or coordinating app-specific flows), a manually created thunk action creator remains a valid, explicit option.

When Redux Isn’t Needed

• Local component state: For UI-only state (e.g. toggling a modal or controlling an input’s focus), use React’s built-in useState or useReducer first.

• Shared non-remote state: For deeply shared, but non-server state, React Context can sometimes be simpler. Be cautious of unnecessary re-renders at scale.

• Primarily server-driven apps: If your app is mostly driven by remote data, lean on RTK Query for that server-state. Avoid dumping every piece of server data into global Redux slices by hand when RTK Query’s caching and normalization can handle it. Global client state should be reserved for state that truly needs to be shared across many parts of the app.

Best Practices And Common Pitfalls

• Connect via hooks: Use the React-Redux hooks useSelector and useDispatch to interact with the store. The older connect() higher-order component is the older API and is generally avoided in new code.

• Never do side effects in reducers: Dispatch actions from your async logic (thunks/RTK Query). Reducers must stay pure and synchronous.

• Handle all async states: With createAsyncThunk, explicitly handle pending, fulfilled, and rejected. For RTK Query, use its generated hooks and their isLoading, isFetching, isError, and error fields appropriately.

• Don’t overuse global state: Avoid putting transient form values, uncontrolled UI state, or values that can be trivially derived into Redux. Derive them when possible.

• Use the right layer: Treat RTK Query as your source of truth for remote/server-state, createAsyncThunk for custom side-effect flows, and component/local or Context state for strictly local concerns.

The Unidirectional Cycle

The data flow follows a deterministic loop initiated by the user interface. When an interaction occurs, the application dispatches an action object containing a type field and optional payload. The store intercepts this action and passes it to the root reducer, which returns a new state tree based on the action type. Finally, the view layer subscribes to the store and re-renders only when the relevant slice of state changes. This cycle prevents side effects during rendering and makes state transitions traceable. Middleware, such as Redux Thunk included by default in RTK, sits between dispatch and the reducer to handle asynchronous logic before actions reach the reducer.

Redux Toolkit and Immutability

Modern Redux uses Redux Toolkit (RTK) to simplify boilerplate and enforce best practices automatically. The configureStore function sets up the store with sensible defaults, including the Redux DevTools Extension and thunk middleware. Within createSlice, reducers are written using Immer, which allows developers to write code that appears to mutate state directly while producing immutable updates safely. - createSlice: Generates action creators and reducers based on an object of reducer functions. - Immer: Enables safe “mutating” syntax inside reducers without violating immutability principles. - Plain Reducers: Outside of RTK slices, manual immutability is still required using spread operators or immutable libraries. - createAsyncThunk: Handles async logic by dispatching pending, fulfilled, and rejected actions automatically.

React Integration with Hooks

Components interact with the Redux store using React-Redux hooks rather than the legacy connect() higher-order component. - useSelector: Extracts specific data from the store state and subscribes the component to updates for that data. - useDispatch: Returns a reference to the dispatch function, allowing components to send actions to the store. This hook-based approach reduces wrapper nesting and aligns with modern React functional component patterns.

When Redux Is Not Needed

Redux adds complexity and should only be used for global state that many components need to access or update. - Local State: Use React useState or useReducer for data confined to a single component. - Context API: Suitable for theme settings or authentication status passed down a component tree without frequent updates. - Server State: Use RTK Query or libraries like React Query for caching server data, as this handles loading states and normalization better than manual Redux logic. Overusing Redux for trivial state can lead to unnecessary indirection and boilerplate.

Best Practices

Keep the store minimal by storing only derived or shared state, avoiding duplication of server responses unless normalized. Always type your state and actions when using TypeScript to catch errors early. Prefer RTK Query for API interactions instead of createAsyncThunk where possible, as it provides built-in caching and lifecycle management. Finally, ensure selectors are memoized with createSelector if computations become expensive to prevent unnecessary re-renders.

How It Works

Redux Toolkit’s createSlice accepts an object of reducers – functions that receive the current state and an action. For each reducer function you define, createSlice automatically generates an action creator with the same name and exports it under slice.actions. The action type string is derived from the slice name and the reducer key (e.g., "todos/addTodo"), eliminating the need to manually write actionTypes constants and creator functions.

For asynchronous logic such as API calls, createAsyncThunk generates a thunk action creator plus three lifecycle action creators (pending, fulfilled, rejected). The thunk dispatches them automatically. The async executor receives an API object that exposes fulfillWithValue and rejectWithValue, letting you shape the fulfilled or rejected payload without returning it directly.

Key Features

• Auto-generated action creators: createSlice returns an object with an actions property containing the creators. You destructure and export them from the slice file.

• Type-safe: With TypeScript, payload types are inferred from the reducer parameters, and PayloadAction<T> gives compile-time safety.

• Immer integration: Reducers inside createSlice can use “mutating” syntax because Immer converts it to immutable updates. This simplifies reducer writing but does not change how action creators are organized.

• Async lifecycle management: createAsyncThunk bundles the pending/fulfilled/rejected creators with the thunk, so the feature file owns the whole async flow.

Best Practices and Common Pitfalls

• Do not hand-write action creators unless you need logic that createSlice or createAsyncThunk cannot handle. Even then, prefer a custom prepare callback inside a reducers entry.

• Export action creators from the slice file as named imports, and keep them co-located with the slice’s reducers and state. Avoid a global actions/ folder.

• Use extraReducers to respond to actions defined outside the slice (e.g., thunks), rather than mixing them into the slice’s own reducers.

• Keep action creators pure: they should only return a plain action object (or, with prepare, a processed payload). Business logic belongs in reducers or thunks.

• Structure action type strings as domain/eventName. createSlice and createAsyncThunk enforce this automatically when you name the slice and thunk appropriately.

• Remember: action creators describe an event or intent; they do not replace selectors or reducer logic. Organize them per feature inside slice files.

How It Works

A synchronous action creator returns an action object that the store’s reducer uses to update state. In plain Redux you write these by hand; in Redux Toolkit, a slice’s reducers field defines a handler (a “case reducer”) and createSlice automatically generates an action creator with the same name. The action creator is a pure function – it takes the payload (if any) and returns { type: 'sliceName/reducerName', payload }. Dispatch this action to update state synchronously.

Key Features

• No side effects: The creator itself never performs async work, network calls, or reads external state.

• Payload is optional: If the reducer expects no payload, the creator can be called with no argument and the action object will only have a type.

• TypeScript support: createSlice infers the payload type from the reducer’s second parameter (the action). The generated creator returns a correctly typed action.

• Immer integration: Case reducers can safely “mutate” state inside the reducer, making code shorter and less error-prone.

Code Example

import { createSlice, PayloadAction } from '@reduxjs/toolkit';
import { useDispatch, useSelector } from 'react-redux';
import type { RootState } from './store';

// Define the slice – it automatically creates synchronous action creators.
const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    // A reducer without payload (action has only type).
    increment(state) {
      // Immer lets us "mutate" state safely.
      state.value += 1;
    },
    // A reducer with a typed payload.
    addAmount(state, action: PayloadAction<number>) {
      state.value += action.payload;
    },
    // Another sync reducer that uses current state to produce new state.
    reset() {
      return { value: 0 };   // direct return is also fine with Immer
    },
  },
});

// Action creators (synchronous):
//   counterSlice.actions.increment  → () => { type: 'counter/increment' }
//   counterSlice.actions.addAmount  → (payload: number) => { type: 'counter/addAmount', payload }
//   counterSlice.actions.reset      → () => { type: 'counter/reset' }

export const { increment, addAmount, reset } = counterSlice.actions;

// Export reducer to be used in configureStore
export default counterSlice.reducer;

// ---- Usage in a React component ----
function Counter() {
  const count = useSelector((state: RootState) => state.counter.value);
  const dispatch = useDispatch();

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => dispatch(increment())}>+1</button>
      <button onClick={() => dispatch(addAmount(5))}>+5</button>
      <button onClick={() => dispatch(reset())}>Reset</button>
    </div>
  );
}

Best Practices and Common Pitfalls

• Do not manually write action creators for slice reducers – createSlice already generates them. If you need a standalone action creator (e.g., for a custom middleware test), define it as a function returning a plain object with type and optionally payload, but prefer slice-generated creators.

• Keep reducers synchronous and side-effect free – async work belongs in thunks (createAsyncThunk) or RTK Query.

• Use the prepare callback when the action creator needs to transform the payload before creating the action (e.g., generate an ID). Pass a prepare function in the reducer object: addTodo: { reducer(state, action) {}, prepare(text: string) { return { payload: { id: nanoid(), text } }; } }.

• Do not call action creators inside useSelector or outside a dispatch – they are meant to be dispatched, not used as selectors.

• Redux is not needed for simple local state – using React’s useState or useReducer is often simpler when state does not need to be shared globally or persisted across page visits.

How It Works

• A reducer is invoked by the Redux store every time an action is dispatched. The store passes the current state and the dispatched action to the root reducer.

• Inside the reducer, a switch statement (or equivalent conditional logic) checks action.type. Each case corresponds to one action type and returns the new state.

• With createSlice, you skip writing the switch statement. Instead you provide a reducers object where each key is an action name (e.g., increment). The slice automatically generates the action creator (increment()) and the action type string (e.g., "counter/increment").

• The reducer logic for each case is placed in a method that receives the current state and the action payload. Thanks to Immer, you can directly assign to state properties (e.g., state.value += 1) and the slice returns a new immutable state for you.

Key Principles

• Immutability: Plain Redux requires you to never mutate state – you must return a new object. createSlice with Immer lifts this burden, but the principle still holds under the hood.

• Pure functions: Reducers should not have side effects (no API calls, no random values). All necessary data should come from the action payload.

• Single responsibility: Each reducer typically handles one slice of the global state. Combine multiple slices with combineReducers or define them in configureStore’s reducer option as an object.

Code Example

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

// Define the type of the slice state
interface CounterState {
  value: number;
}

const initialState: CounterState = { value: 0 };

// createSlice generates the reducer and action creators
const counterSlice = createSlice({
  name: 'counter',
  initialState,
  reducers: {
    increment(state) {
      state.value += 1;          // Immer handles immutability
    },
    decrement(state) {
      state.value -= 1;
    },
    incrementByAmount(state, action: PayloadAction<number>) {
      state.value += action.payload;
    },
    reset: () => initialState,   // Return a new object directly, also valid
  },
});

// Export auto-generated action creators
export const { increment, decrement, incrementByAmount, reset } = counterSlice.actions;

// Export the reducer to be used in configureStore
export default counterSlice.reducer;

Usage in a React component (with useDispatch and useSelector from React-Redux):

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

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

  return (
    <div>
      <button onClick={() => dispatch(decrement())}>-</button>
      <span>{count}</span>
      <button onClick={() => dispatch(increment())}>+</button>
    </div>
  );
}

When to Use This Approach

• Use createSlice for every new Redux slice. The legacy createStore is deprecated; configureStore is the standard.

• For async logic, combine with createAsyncThunk or RTK Query, never put side effects inside the reducer.

• Redux is best suited for globally shared state that needs to be predictable and debugged with DevTools. For local UI state, consider React’s useState or useReducer; for cross-cutting app data, React Context may be simpler; and for server data, prefer a server-state library such as RTK Query or TanStack Query instead of caching it in Redux.

Common Pitfalls

• Mutating state outside Immer: If you write a reducer as a standalone function (not inside createSlice), you must return a new object and never mutate the input state. Always use createSlice to avoid confusion.

• Putting non-serializable values in state: Actions and state should be serializable (plain objects, arrays, primitives) to enable DevTools and persistence.

• Forgetting to export actions: Each reducer method from createSlice generates an action creator; you must export it to dispatch from components.

What createSlice Produces

• Reducer function: the slice reducer itself, which you pass to configureStore under a state key such as todos or auth.

• Action creators: functions like todoAdded or loginSucceeded, generated automatically from the keys of your reducers object.

• Action type strings: namespaced strings derived from the slice name and the case reducer key, for example "todos/addTodo".

• React-Redux integration: components read slice state with useSelector and dispatch the generated actions with useDispatch; the older connect() higher-order component is legacy and no longer recommended.

Immutability and Immer

• Inside a createSlice case reducer you write “mutating” code such as state.push(item) or state.loading = false.

• Redux Toolkit wraps your case reducers with Immer, which tracks changes to a draft state object and produces a new immutable state afterward.

• This safety is limited to createSlice: plain reducer functions that you write outside Redux Toolkit must still return new objects and must never mutate the previous state.

Mounting the Slice Reducer

• configureStore builds the root reducer from an object where each key becomes a property on the store state and each value is a slice reducer.

• For example, configureStore({ reducer: { todos: todosReducer, filters: filtersReducer } }) exposes state.todos and state.filters.

• The slice name option is used for action type strings; the actual state key is the property name you choose in the root reducer object.

Slice Reducer Compared with a Plain Reducer

When You Do Not Need Redux

• Local component state: use useState or useReducer for state that lives inside one component or a small subtree.

• Infrequently changing cross-cutting state: React Context is often sufficient and avoids Redux overhead.

• Server state: prefer RTK Query (bundled with Redux Toolkit) or another server-state library for cached API data instead of hand-maintaining slices for the same information.

Best Practices

• One slice per feature domain: create authSlice, postsSlice, and uiSlice rather than one monolithic slice.

• Keep state normalized: store entities in a lookup table keyed by ID to avoid deeply nested updates.

• Do not duplicate server data: if RTK Query already caches an endpoint response, do not copy that payload into a slice.

• Use TypeScript: type the slice state and actions so useSelector callbacks and dispatch calls remain type-safe.

How Redux State Updates Work

State updates are triggered by dispatching an action – a plain object with a type field and an optional payload. The store runs the appropriate reducer function, which receives the current state and the action, and must return the next state. Redux enforces that reducers are pure functions: no side effects, no modifying arguments, and no asynchronous operations.

Using createSlice to Define Reducers

createSlice is the recommended way to define Redux logic. It accepts a name, initialState, and an object of reducer functions. Each reducer is automatically assigned an action type string based on the slice name and the reducer name. Inside a reducer, you can write code that looks like it mutates the state, but Immer tracks those changes and produces a new immutable state object.

import { createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment(state) {
      state.value += 1;                 // "Mutation" safe via Immer
    },
    incrementByAmount(state, action) {
      state.value += action.payload;
    }
  }
});

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

The Role of Immer in Safe Mutations

Immer creates a draft of the state, allows mutable edits, and then produces the next immutable state. createSlice wraps every reducer with Immer automatically. You cannot both mutate the draft and return a new object in the same reducer; choose one pattern. Mutations outside the reducer (e.g., in selectors or action creators) are not protected.

Code Example: Dispatching Actions from React

The store is configured with configureStore:

import { configureStore } from '@reduxjs/toolkit';
import counterReducer from './counterSlice';

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

A component dispatches actions using the useDispatch hook and reads state with useSelector:

import { useDispatch, useSelector } from 'react-redux';
import { increment, incrementByAmount } from './counterSlice';

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

  return (
    <div>
      <span>{value}</span>
      <button onClick={() => dispatch(increment())}>Increment</button>
      <button onClick={() => dispatch(incrementByAmount(5))}>Add 5</button>
    </div>
  );
}

This approach ensures immutable, predictable state updates with minimal boilerplate.

Best Practices for State Updates

• Keep reducers pure: Do not perform API calls, generate random numbers, or use Date.now() inside a reducer. Use createAsyncThunk or RTK Query for asynchronous logic.

• Use prepare callbacks when action payloads need transformation or validation before reaching the reducer.

• Normalize nested state with createEntityAdapter to simplify updates and avoid deep spreading.

• Leverage extraReducers to handle actions defined elsewhere, such as lifecycle actions from thunks.

• Avoid storing non-serializable values (functions, class instances) in the Redux store.

• Do not overuse Redux: local state, React Context, or server-state libraries like RTK Query are often simpler for UI-only or fetching logic.

How It Works

• When you pass an object map to configureStore, such as { todos: todosReducer, user: userReducer }, it creates the root reducer using combineReducers.

• The root reducer passes each dispatched action to every slice reducer, then reassembles the returned branches into the next state object.

• Each slice reducer receives only its own branch of state plus the action; it does not need to know about the rest of the tree.

• Inside createSlice, composition continues within one slice: the reducers map defines focused case reducers, and extraReducers lets a slice respond to actions defined elsewhere.

• The original createStore API is deprecated; configureStore is the recommended setup. connect() is the older React-Redux binding, while useSelector and useDispatch are the current hooks API.

Composition at Two Levels

Keeping the root map flat makes state shape predictable and selectors simple; deeper nesting is useful only when a domain has stable sub-domains.

Benefits

• Separation of concerns: each reducer has one job, so reasoning about a feature means reading a small reducer rather than a giant switch.

• Testability: a slice reducer can be tested in isolation by calling it with a state and an action, with no store setup.

• Team scalability: different developers can own different slices, reducing merge conflicts in one monolithic reducer.

• Predictable state shape: combineReducers enforces that state keys match reducer keys, catching wiring mistakes early.

• Reusability: a generic reducer, such as one that manages a paginated list, can be reused across features.

Immutability and Immer

createSlice uses Immer, so “mutating” code inside its case reducers is safe: Immer tracks changes to a draft and produces a new immutable state object. The same guarantee applies inside createReducer. In a plain reducer written by hand, you must return new objects and arrays explicitly, because mutating the incoming state is a real bug.

When Redux Is Not Needed

• Local component state: values such as a modal toggle, form input, or hover state usually belong in useState.

• Low-frequency cross-cutting values: React Context can be simpler when the data is not changing rapidly.

• Server state: caching, fetching, and synchronization are often better handled by RTK Query or another server-state library rather than hand-written slices.

Common Pitfalls and Best Practices

• Cross-slice coupling: reducers should not reach into other slices. When two slices must react to the same event, use extraReducers to listen for the shared action.

• Over-nesting: deeply nested reducer trees complicate selectors and debugging; prefer a flat root map unless sub-domains are clearly warranted.

• Tiny case reducers: keep each reducer focused and move complex derivations into helpers or selectors outside the reducer.

• Async lifecycles: use createAsyncThunk with extraReducers to handle pending, fulfilled, and rejected states instead of hand-rolled action types.

• Server data first: reach for RTK Query before writing manual data-fetching reducers.

• Avoid unnecessary Redux: small applications often work well with component state or Context alone.

Why Immutability Matters

Redux relies on pure functions and immutable state to determine when the store has changed. When a reducer returns a new object reference rather than modifying the existing one, React-Redux hooks like useSelector can efficiently compare previous and current states. If state is mutated in place, the reference remains unchanged, potentially causing components to skip necessary re-renders or breaking time-travel debugging features in Redux DevTools.

How Redux Toolkit Simplifies Immutability

Redux Toolkit (RTK) is the official recommended approach, replacing the deprecated createStore. Its createSlice function automatically wraps reducer logic with Immer. This means developers can write code that looks like direct mutation inside the reducer, such as state.value += 1, and Immer produces a new immutable state tree behind the scenes. This reduces boilerplate and eliminates common accidental mutation bugs found in manual spread syntax.

Plain Reducers vs createSlice

The immutability requirement depends on how the reducer is defined. Inside a createSlice reducer, Immer handles the immutability, so draft mutation is safe. However, if you write a standalone reducer function passed directly to configureStore, you must still return new state objects manually. Mixing these approaches incorrectly can lead to silent failures where the UI does not update despite state changes.

When Redux Is Not Needed

Immutability management adds complexity that isn’t always justified. For local UI state (e.g., form inputs, toggle visibility), React useState or useReducer is sufficient. For server-state management (caching, synchronization), RTK Query or libraries like React Query are preferred over manual Redux state. Redux shines when global state is needed across many components or when complex middleware logic is required.

Best Practices

• Use RTK exclusively: Avoid createStore and manual immutable spreads when createSlice is available.

• Leverage hooks: Use useSelector and useDispatch in React components instead of the legacy connect() API.

• Avoid excessive global state: Keep state as local as possible to minimize re-render costs and simplify testing.

• Prefer draft mutation: Avoid returning new state objects inside createSlice reducers unless replacing the entire state, as draft mutation is the preferred pattern.

State Mutation and Immer

• Immer draft: Inside createSlice, reducers receive an Immer draft; mutating properties or array items on that draft is safe and produces a new immutable state automatically.

• Plain reducers: Any reducer written outside createSlice must return a new state object or array; direct mutation breaks reference-equality checks in useSelector and prevents re-renders.

• Legacy warning: The original createStore API is deprecated; use configureStore and createSlice so Immer handles immutability for you.

Purity and Side Effects

• Pure functions: Reducers must be synchronous and deterministic; do not call APIs, read from localStorage, or invoke Math.random() or Date.now() inside them.

• Async boundaries: Use createAsyncThunk to perform network requests; its pending, fulfilled, and rejected action types are then handled by extraReducers.

• Side effects in components: Trigger data fetching from event handlers or useEffect in React, never from within a reducer.

Serializability and State Shape

• Serializable state: State should contain only plain objects, arrays, and primitives; avoid class instances, Map, functions, and Promises.

• Time-travel and persistence: Non-serializable values break Redux DevTools time-travel debugging and libraries like redux-persist.

• Normalization: Flatten deeply nested collections by ID so updates require spreading only a few levels, not an entire tree.

When Redux Isn’t Needed

• Local UI state: Form inputs, open/closed toggles, and animation states usually belong in useState.

• Server state: Use RTK Query instead of manually storing fetched API data; it caches, dedupes, and manages loading states.

• Context: Low-frequency global values such as theme or locale are often better handled by React Context.

Best Practices

• Default to createSlice: Write virtually all reducers with createSlice so Immer manages immutability and you avoid hand-rolled spread logic.

• Keep state flat: Prefer normalized shapes (byId + allIds) over deeply nested trees to simplify updates and reduce accidental mutation risk.

• Validate with middleware: Use Redux Toolkit’s serializability and immutability checks in development to catch non-serializable payloads and mutations early.

What It Solves

By default, Redux reducers must be synchronous and receive only serializable action objects. A basic Redux store cannot wait for an HTTP request, timer, or WebSocket message before producing an action.

redux-thunk solves this by adding a layer between dispatch() and the reducer:

1. You dispatch a function, called a thunk.

2. Redux passes dispatch, getState, and an optional extra argument to that function.

3. The function runs any logic it needs.

4. It dispatches ordinary actions such as pending, fulfilled, and rejected.

This makes it possible to keep Redux as the predictable place for state changes while still handling side effects such as API calls.

Role in Redux Toolkit

Redux Toolkit is the official, recommended way to write Redux logic. Its configureStore API includes the thunk middleware automatically, so most applications do not need to install or configure redux-thunk separately.

• configureStore: creates the store with Redux Toolkit defaults, including thunk support.

• createSlice: creates reducers and action creators together.

• createAsyncThunk: creates standardized async thunks with pending, fulfilled, and rejected action types.

• RTK Query: handles data fetching and caching automatically when server state is a major part of the application.

Raw Thunks vs. createAsyncThunk

Immutability and Immer

Inside createSlice, reducers use Immer, so code that appears to mutate state is safe because Immer produces the next immutable state internally.

This does not apply to plain Redux reducers outside createSlice. In those reducers, you must avoid mutation and return a new object or array.

React Integration

React components interact with the store using React-Redux hooks:

• useSelector() reads a value from the store.

• useDispatch() returns the dispatch function used to trigger thunks.

The older connect() API still works, but hooks are the current recommended approach for function components.

Best Practices and Pitfalls

• Prefer createAsyncThunk over writing many raw thunks by hand.

• Keep Redux actions serializable; do not place functions, class instances, or promises in action payloads.

• Use RTK Query for significant server-state caching instead of manually writing thunks for every endpoint.

• Avoid putting non-serializable values into the Redux store.

• Do not reach for Redux for purely local UI state, simple form values, or values already available through React context.

• Remember that thunks can call getState(), but excessive state inspection can make async logic harder to test and reason about.

• Handle cancellation and duplicate requests carefully; RTK Query provides stronger built-in support for those concerns than individual thunks.

What Redux-Saga Does

Redux-saga replaces thunks with generator functions that “yield” declarative effect descriptors. A watcher saga listens for dispatched actions and delegates work to worker sagas, which can pause, cancel, retry, fork parallel tasks, or race against each other. This makes it well-suited for intricate flows such as authentication token refresh loops, WebSocket message handling, multi-step checkout processes, or coordinating several API calls that must happen in a specific order.

What Redux-Thunk Does

Redux-thunk is a minimal middleware that allows action creators to return a function instead of a plain action object. That inner function receives dispatch and getState, enabling you to dispatch multiple actions over time—typically pending, fulfilled, and rejected around an async call. It is straightforward, imperative, and easy to test, making it ideal for simple request/response patterns.

Comparison at a Glance

The Modern Redux Toolkit Perspective

Redux Toolkit’s configureStore adds thunk middleware automatically, so you do not need to install redux-thunk separately. For standard async requests, createAsyncThunk generates the pending/fulfilled/rejected lifecycle for you. For server-state management—caching, polling, and cache invalidation—RTK Query is the officially recommended solution and usually removes the need to write any middleware-level async code at all. Redux-saga still earns its place when you need features like non-cancelable background tasks, debounced streams, or complex retry logic that feels awkward with thunks alone.

When to Choose Which

• Default to createAsyncThunk for simple, one-off async operations.

• Use RTK Query whenever the goal is fetching, caching, and synchronizing server data.

• Adopt redux-saga only when side-effect orchestration becomes genuinely complex: websockets, long-lived background sync, auth flows requiring automatic token refresh, or coordinated multi-request sequences.

• Skip Redux entirely if the state is local UI state (for example, a modal open flag or form input focus) and can live in useState or React Context.

When Redux Is Not Needed

Not every application needs Redux. Local component state is often best handled with useState or useReducer. Server state should typically live in a dedicated data-fetching library such as RTK Query, TanStack Query, or SWR rather than in the Redux store, because those tools handle caching, deduplication, and revalidation more robustly. Reach for Redux when you have shared client state across many components that cannot be easily lifted or context-ized without excessive prop drilling or re-render problems.

The Middleware Signature

Every middleware follows the same three‑level curried signature:

(storeAPI) => (next) => (action) => {
  // storeAPI provides getState() and dispatch()
  // next is the next middleware in the chain or the reducer
  // action is the dispatched action object
  return next(action)
}

• The outermost function receives the store’s dispatch and getState methods.

• The second function receives the next function, which passes the action to the next middleware (or to the reducers if this is the last middleware).

• The innermost function handles the received action. It must call next(action) or return next(action) to continue the chain; omitting this call will suppress the action.

Adding a Custom Middleware with Redux Toolkit

configureStore expects the middleware option to be a callback that receives getDefaultMiddleware and returns an array of middleware. The recommended pattern is:

import { configureStore } from '@reduxjs/toolkit'
import rootReducer from './rootReducer'

const loggerMiddleware = (store) => (next) => (action) => {
  console.group(action.type)
  console.info('dispatching', action)
  let result = next(action)
  console.log('next state', store.getState())
  console.groupEnd()
  return result
}

const store = configureStore({
  reducer: rootReducer,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(loggerMiddleware),
})

• getDefaultMiddleware() returns the default middleware list (thunk, immutable state check, serializable state check).

• .concat(loggerMiddleware) appends your custom middleware after the defaults. To insert it before them, spread the default middleware into a new array: middleware: (getDefaultMiddleware) => [loggerMiddleware, ...getDefaultMiddleware()].

Code Example: Action Timing Middleware

Below is a more practical middleware that logs how long each action takes, useful for performance monitoring.

// timingMiddleware.js
const timingMiddleware = (store) => (next) => (action) => {
  const start = performance.now()
  const result = next(action)
  const end = performance.now()
  console.log(`%c${action.type} took ${(end - start).toFixed(2)}ms`, 'color:blue;')
  return result
}

// store.js
import { configureStore } from '@reduxjs/toolkit'
import rootReducer from './rootReducer'

const store = configureStore({
  reducer: rootReducer,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(timingMiddleware),
})

export default store

Best Practices and When Not to Use Custom Middleware

• Keep middleware focused: each middleware should do one thing (logging, routing, analytics, etc.).

• Always call next(action) unless you intentionally want to block the action (very rare).

• Avoid asynchronous logic in the middleware chain unless you are writing a thunk-like middleware; for side effects, prefer createAsyncThunk or createListenerMiddleware.

• Don’t overuse middleware: many needs (e.g., API calls, caching) are better served by RTK Query or thunks. Custom middleware is best for app‑wide cross‑cutting concerns.

• Remember immutability: the action object returned from next(action) is the same reference; never mutate it. If you need to modify the action, dispatch a new action instead.

How Middleware Works

• Pipeline position: Middleware sits between dispatch and the reducer chain, receiving every dispatched action.

• Signature: A middleware is a curried function store => next => action => next(action), where next forwards the action to the next layer.

• Short-circuit: Middleware may log, clone, block, or delay an action; it does not have to call next if it fully handles the action itself.

• Composition: Redux Toolkit composes all supplied middleware into a single dispatch wrapper, so ordering matters.

Capabilities Middleware Adds

Middleware in Redux Toolkit

• configureStore: Accepts a middleware option, usually as a callback that receives getDefaultMiddleware() so you can append custom entries.

• Built-ins: The default set includes thunk for function-dispatching, plus serializable state/action validation; an immutable-state check runs in development.

• createAsyncThunk: Builds on thunk to standardize pending, fulfilled, and rejected action types for promise-based operations.

• RTK Query: The createApi middleware automates cache lifetime and polling; you add it when building the store.

• Immer vs. middleware: Reducers inside createSlice may appear to mutate state because Immer produces immutable updates, but middleware should still treat actions and state as immutable plain objects.

When Redux Isn’t Needed

• Purely local state: Component-scoped values are best held in useState or useReducer.

• Simple shared state: React Context avoids the boilerplate of actions and reducers for low-frequency updates.

• Server state: Dedicated libraries such as RTK Query or TanStack Query manage fetching, caching, and synchronization more effectively than hand-rolled Redux logic.

• Small applications: If state transitions are straightforward, the indirection of Redux adds complexity without benefit.

Best Practices and Pitfalls

• Prefer built-ins first: Reach for thunk or createAsyncThunk before writing custom middleware.

• Keep concerns isolated: A middleware should do one job—logging, auth, or metrics—rather than mixing business logic.

• Handle rejections: Always catch errors inside async middleware or thunks so failed promises don’t leave the store in an inconsistent state.

• Avoid mutating actions: Do not modify the original action object; if changes are needed, return a new action.

• Connect with hooks: In React-Redux 9, use useSelector and useDispatch; connect() is the older higher-order component API and is no longer recommended for new code.

• Legacy store creation: The original createStore API is deprecated; use configureStore from Redux Toolkit for all new development.

Store Setup and Provider

• configureStore: creates the store with sensible defaults, including the Redux DevTools Extension in development and Redux Thunk middleware.

• createSlice: defines state, action creators, and reducers for one feature in a single place.

• Provider: wraps the React tree above any component that uses Redux hooks, making the store available through React context.

• Legacy store API: do not build new stores with the original Redux createStore; use configureStore from Redux Toolkit.

Component Integration

• useSelector: reads a value from the store and subscribes the component to changes in the selected value.

• useDispatch: returns the store’s dispatch method for actions from slices or createAsyncThunk.

• Type safety: in TypeScript, derive RootState and AppDispatch from the store, then create small typed hooks.

Immutability

• Inside createSlice reducers: assignments such as state.value += 1 are safe because Immer produces the next immutable state.

• Outside slice reducers: never mutate Redux state directly in plain reducers, components, or middleware; build new values instead.

When Redux Is Unnecessary

• Local state: use useState or useReducer for form fields or data confined to one component.

• Limited sharing: pass props when state is only needed a few levels down.

• Server state: prefer RTK Query or TanStack Query over hand-written Redux caching logic.

Code Example

import { configureStore, createSlice } from '@reduxjs/toolkit';
import {
  Provider,
  TypedUseSelectorHook,
  useDispatch,
  useSelector,
} from 'react-redux';
import { createRoot } from 'react-dom/client';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: (state) => {
      state.value += 1; // safe mutation inside createSlice because of Immer
    },
    decrement: (state) => {
      state.value -= 1;
    },
  },
});

const { increment, decrement } = counterSlice.actions;

const store = configureStore({
  reducer: {
    counter: counterSlice.reducer,
  },
});

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

const useAppDispatch = () => useDispatch<AppDispatch>();
const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;

function Counter() {
  const count = useAppSelector((state) => state.counter.value);
  const dispatch = useAppDispatch();

  return (
    <div>
      <span>{count}</span>
      <button onClick={() => dispatch(increment())}>+</button>
      <button onClick={() => dispatch(decrement())}>-</button>
    </div>
  );
}

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

createRoot(document.getElementById('root')!).render(<App />);

Best Practices and Pitfalls

• Selector results: return primitives or stable references; creating a new object or array inside useSelector causes extra re-renders on store updates.

• Memoized derived data: use createSelector from Redux Toolkit/Reselect for expensive computations.

• Granular slices: keep each slice focused on one domain to simplify testing and maintenance.

• Stable dispatch: useDispatch returns a stable reference, so it does not need to be included in useEffect dependency arrays.

• Async work: use createAsyncThunk for request flows, and RTK Query when the main problem is server-state caching.

How It Works

connect accepts up to four arguments: mapStateToProps, mapDispatchToProps, mergeProps, and options. mapStateToProps receives the Redux store state (and optionally the component’s own props) and returns an object merged into the component’s props. mapDispatchToProps can be a function or an object that provides pre-bound action creators as props. The optional mergeProps lets you customize how state props, dispatch props, and own props are combined, while options can tune subscription behavior and whether the wrapper renders as the wrapped component. The returned wrapper component subscribes to the store, runs the mapping functions on every store change, and re-renders the wrapped component only when the returned props differ, using a shallow equality check.

Key Advantages

• Automatic store subscription: Components never manually subscribe or unsubscribe; connect handles cleanup on unmount.

• Performance optimisations: connect implements a shouldComponentUpdate-like check that prevents unnecessary re-renders by shallow-comparing the result of mapStateToProps with its previous value.

• Separation of concerns: Container components handle data and actions; presentational components receive plain props and are easier to test and reuse.

• Action dispatching without store access: mapDispatchToProps provides bound action creators, so the component never needs a reference to the store or dispatch.

• Class component support: connect works with class components, which cannot use hooks, making it the only option for legacy class-based code.

• Composability: Multiple connect calls can be chained or nested, each scoping a different slice of state.

Comparison with the Hooks API

Best Practices and Pitfalls

• For new projects, use the hooks API – it is simpler, easier to type, and works seamlessly with Redux Toolkit.

• When maintaining existing code using connect, ensure mapStateToProps selectors are memoised (e.g., with createSelector from Reselect) to avoid creating new objects on every call.

• Avoid passing inline functions directly in mapDispatchToProps object form; use the object shorthand only with plain action creators that do not depend on ownProps.

• Remember that connect wraps the component; if you use React.memo on the wrapped component, you can stack performance optimisations.

• Not every piece of state belongs in Redux – prefer local component state or React Context for truly local concerns, and consider RTK Query for server-cached data.

How mapStateToProps Works

mapStateToProps is called whenever the store state changes. It receives the entire store state as its first argument and the component’s own props (if provided) as an optional second argument.

const mapStateToProps = (state, ownProps) => ({
  count: state.counter.value,
});

• It must return an object; each key becomes a prop on the wrapped component.

• To avoid unnecessary re‑renders, the returned object should only contain the specific slices of state the component needs and should return new references only when that data actually changes.

• For derived data, use memoized selectors (e.g., from reselect) inside mapStateToProps.

How mapDispatchToProps Works

mapDispatchToProps can be either a function or an object.
As a function, it receives dispatch and optional ownProps and returns an object of callback props that call dispatch:

const mapDispatchToProps = (dispatch) => ({
  increment: () => dispatch(counterActions.increment()),
});

As an object, each key is an action creator, and connect automatically wraps each one with dispatch:

const mapDispatchToProps = {
  increment: counterActions.increment,
};

Both forms make those callbacks available as props (e.g., this.props.increment or props.increment in a function component).

Legacy vs Modern Approach

The hooks approach (useSelector and useDispatch) is cleaner, avoids the mental overhead of HOCs, and works naturally with function components.

Code Example

Legacy approach with connect:

import { connect } from 'react-redux';
import { increment, decrement } from './counterSlice';

const Counter = ({ count, increment, decrement }) => (
  <div>
    <span>{count}</span>
    <button onClick={increment}>+</button>
    <button onClick={decrement}>-</button>
  </div>
);

const mapStateToProps = (state) => ({ count: state.counter.value });
const mapDispatchToProps = { increment, decrement };

export default connect(mapStateToProps, mapDispatchToProps)(Counter);

Modern approach with hooks:

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

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

  return (
    <div>
      <span>{count}</span>
      <button onClick={() => dispatch(increment())}>+</button>
      <button onClick={() => dispatch(decrement())}>-</button>
    </div>
  );
};

export default Counter;

Best Practices and Pitfalls

• Prefer hooks over connect in new code. Redux Toolkit’s documentation explicitly recommends hooks as the primary way to interact with the store.

• When using mapStateToProps, avoid returning new objects or arrays on every call (e.g., using .map() inside the function) unless the data actually changed — this causes unnecessary re‑renders.

• For mapDispatchToProps, the object shorthand is simpler, but the function form gives you access to ownProps and allows you to inject dependencies or wrap actions with side logic.

• Never call dispatch directly inside mapStateToProps — it must be a pure function.

• In both legacy and modern code, keep selectors simple and composable. Extract them from the component to enable reuse and testing.

How useSelector Triggers Re-renders

• useSelector subscribes the component to the Redux store. After every dispatched action, it re-runs the selector function and compares the new result with the previous result using ===.

• If the result is a primitive (string, number, boolean), reference equality works as value equality, so re-renders only happen when the primitive changes.

• If the result is an object or array (e.g., { name: state.user.name } or state.items.filter(...) ), the selector creates a new reference every time. This forces React to re-render the component, even if the actual data content is identical.

Optimising Selectors with Memoization

• createSelector from Redux Toolkit (RTK) creates memoized selectors that recompute derived data only when their input selectors return new references. This reduces unnecessary processing and stabilises references.

• Pass a custom equality function to useSelector as the second argument. For selecting an object literal or an array, use shallowEqual (exported from react-redux). This performs a shallow comparison of each property, so re-renders occur only when a property value actually changes.

• RTK Query automatically memoises query results, so components that use generated hooks (e.g., useGetPostsQuery) re-render only when data changes.

Structuring State to Minimise Updates

• Store data in a normalized shape using RTK’s createEntityAdapter. Flat, keyed entities allow components to select individual records by ID without pulling in unrelated data.

• Write fine-grained selectors that return exactly the data a component needs. Avoid selecting whole slices and then deriving data inside the component, as that creates new references on every store update.

• Keep state serializable and avoid non-serializable values (functions, Symbol, Promise), which break equality checks and complicate debugging.

Using React.memo and Stable References

• Wrap presentational components with React.memo to skip re-rendering when their props (including derived Redux data) have not changed, based on shallow equality.

• useDispatch and the action creators from createSlice are stable references (they don’t change across renders). They never need to be included in dependency arrays of hooks like useEffect.

• When passing callback functions that dispatch actions, use useCallback only if the callback is passed as a prop to a memoized child. Since dispatchers are stable, the callback often doesn’t need memoization.

Common Pitfalls

• Over-memoization: Using createSelector on selectors that return primitives is unnecessary and adds overhead. Let the default === work.

• Selecting whole slices inside components: useSelector(state => state) always returns a new reference because state is a new object after every action, causing the entire tree of connected components to re-render.

• Forgetting that useSelector with a function that returns an inline array (e.g., .map()) creates a new array every time. Either memoize with createSelector or use shallowEqual.

• Premature optimisation: Default behaviour is fine for components that update infrequently or display data that changes often. Profile with React DevTools before applying complex memoization.

How Unnecessary Re‑renders Occur

Every time the Redux store updates, useSelector runs the selector function and compares the result with the previous value using a reference equality check (===). If the selector returns a new object, array, or function on each call (even if the data inside is logically unchanged), the component re‑renders. This also cascades to child components unless they are memoized.

Key Optimization Strategies

• Memoized Selectors with createSelector
  A selector created by createSelector caches its output until one of its input selectors returns a new value. This prevents derived data (e.g., filtered lists, computed totals) from generating new references when the underlying data hasn’t changed.
  “‘javascript import { createSelector } from ’@reduxjs/toolkit’;

const selectTodos = state => state.todos.items; const selectCompletedTodos = createSelector( [selectTodos], todos => todos.filter(todo => todo.completed) ); “‘

• Controlling useSelector Equality
  Pass a custom equality function as the second argument to useSelector. Use shallowEqual from react-redux when the selector returns an object or array whose individual elements are primitive values.
  “‘javascript import { useSelector, shallowEqual } from ’react-redux’;

const user = useSelector( state => ({ name: state.user.name, age: state.user.age }), shallowEqual ); “‘

• Normalizing State Shape
  Keep your store flat with entities keyed by ID (using createEntityAdapter from Redux Toolkit). This avoids deeply nested objects that cause cascading re-renders and makes updates cheaper.

• Component Memoization with React.memo
  Wrap presentational components in React.memo to only re-render when their props change. For Redux‑connected components, the selector already controls prop updates, but memoizing child components prevents unnecessary reconciliation.

• Leverage RTK Query for Server State
  RTK Query automatically maintains a normalized cache keyed by endpoint and serialized parameters, provides built‑in memoization, and triggers re‑renders only when the requested data changes. It eliminates the need for manual selector optimizations for API‑derived state.

Code Example

The following example contrasts a naive selector with an optimised version in a TodoList component:

import { useSelector } from 'react-redux';
import { createSelector } from '@reduxjs/toolkit';
import React from 'react';

interface Todo {
  id: string;
  text: string;
  completed: boolean;
}

interface RootState {
  todos: {
    items: Todo[];
  };
}

// Naive: returns a new filtered array on every store change
const naiveCompletedTodos = (state: RootState) =>
  state.todos.items.filter(todo => todo.completed);

// Optimised: memoized selector
const selectCompletedTodos = createSelector(
  [(state: RootState) => state.todos.items],
  items => items.filter(item => item.completed)
);

const TodoItem: React.FC<{ todo: Todo }> = ({ todo }) => (
  <li>{todo.text}</li>
);
const MemoizedTodoItem = React.memo(TodoItem);

const TodoList: React.FC = () => {
  // Using memoized selector; returns same array reference unless items change
  const completedTodos = useSelector(selectCompletedTodos);

  return (
    <ul>
      {completedTodos.map(todo => (
        <MemoizedTodoItem key={todo.id} todo={todo} />
      ))}
    </ul>
  );
};

Best Practices and Common Pitfalls

• Use createEntityAdapter: It provides built‑in selectors that return memoised references, further reducing manual optimisation.

• Minimise store updates: useDispatch returns a stable function, so re-renders come from the state changes it triggers—dispatch only when data actually changes.

• Don’t over‑optimise: Start with simple selectors and only add memoization when profiling reveals excessive re-renders. Over‑using React.memo or deep equality checks can add overhead.

• Keep selectors colocated: Place selectors near the slice they access; it makes dependencies clear and simplifies refactoring.

• Be careful with shallowEqual: It performs a shallow comparison of every key; for large objects this can be slower than a correctly written memoized selector.

How It Works

• A HOR has the shape (reducer) => (state, action) => newState.

• It can intercept specific action types, transform state before or after the inner reducer runs, conditionally delegate, or add logging.

• It must still return the initial state when state is undefined, and return the existing state unchanged for actions the inner reducer does not handle.

• Redux’s combineReducers is itself a simple HOR: it maps slice reducers to state keys and delegates actions to each.

• With RTK, wrappers are applied to slice reducers in the reducer object passed to configureStore, not to the deprecated createStore.

Common Use Cases

• State reset: restoring a feature’s state to its initial value when a global action such as auth/logout is dispatched.

• Action filtering: allowing only a subset of actions to reach a slice, or ignoring actions outside a feature’s domain.

• Debugging and logging: printing each action and state transition for a specific slice without changing production logic.

• Feature flags: enabling or disabling slice behavior based on runtime configuration without duplicating the slice.

• Persistence and hydration: merging state read from storage into the slice state before the inner reducer processes the action.

• Undo/redo: maintaining a history buffer around a slice reducer so past states can be restored.

Immutability and Immer

• Inside a createSlice reducer, “mutating” the draft state is safe because Immer produces an immutable result.

• A HOR is ordinary JavaScript/TypeScript: it must never mutate the incoming state directly. Use spread syntax, map, filter, or Immer’s public produce helper when it needs to transform state.

• The safest HORs pass state straight through to the inner slice reducer and only replace the result when a cross-cutting condition is met.

• Because HORs sit outside createSlice, they do not automatically receive Immer drafting and must manage immutability themselves.

HORs Versus Other Redux Tools

Best Practices and Pitfalls

• Keep HORs pure and synchronous; handle async logic with middleware or createAsyncThunk, not reducer composition.

• Avoid deeply nested HOR stacks: each wrapper adds indirection and makes debugging harder.

• Do not use Redux or HORs for transient UI state, concerns easily solved by React Context, or server state—prefer RTK Query for the latter.

• In TypeScript, write HORs with explicit generic state types rather than any; RTK slice reducers are already strongly typed.

• Always preserve the inner reducer’s initial-state and unknown-action behavior, otherwise the store can return undefined or lose state.

How It Works

A feature toggle is a boolean or small configuration object that turns functionality on or off without redeploying code. In a Redux app you model toggles as normal state: a slice holds a map of flag names to boolean values, reducers update individual flags or replace the whole map when a remote configuration arrives, and components subscribe to the slice with useSelector. Because the flags live in the global store, any component can read them without prop drilling.

Immutability and Immer

Redux requires state updates to be immutable. With configureStore and createSlice, the reducers are wrapped in Immer, so code that appears to mutate the draft state—such as state.flags[key] = enabled—is safe and produces a new immutable object under the hood. This convenience does not apply to plain hand-written reducers or to code outside a createSlice reducer; there you must return brand-new objects and arrays.

Wiring Into React

Use the modern React-Redux hooks rather than the legacy connect() higher-order component. useSelector reads the flag map or a derived boolean, and useDispatch sends actions such as setFlag. If your toggles originate from a server, fetch them over HTTPS with createAsyncThunk or RTK Query and hydrate the slice when the request resolves, treating remote configuration as server state where appropriate.

When Redux Is Not the Right Tool

Redux is not always necessary for feature toggles. If the set of flags is static and known at build time, plain module constants are simpler. If flags are shared by a small subtree only, React Context can provide them without a global store. If the real problem is caching and synchronizing remote configuration, a server-state library such as RTK Query may be a better fit than manually storing the payload in a Redux slice.

Code Example

// featureTogglesSlice.ts
import { createSlice, type PayloadAction } from '@reduxjs/toolkit';

interface FeatureTogglesState {
  flags: Record<string, boolean>;
}

const initialState: FeatureTogglesState = {
  flags: {
    newDashboard: false,
    betaCheckout: false,
  },
};

const featureTogglesSlice = createSlice({
  name: 'featureToggles',
  initialState,
  reducers: {
    setFlag(
      state,
      action: PayloadAction<{ key: string; enabled: boolean }>
    ) {
      // Safe "mutation" courtesy of Immer
      state.flags[action.payload.key] = action.payload.enabled;
    },
  },
});

export const { setFlag } = featureTogglesSlice.actions;
export default featureTogglesSlice.reducer;

// store.ts
import { configureStore } from '@reduxjs/toolkit';
import featureTogglesReducer from './featureTogglesSlice';

export const store = configureStore({
  reducer: {
    featureToggles: featureTogglesReducer,
  },
});

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

// Dashboard.tsx
import { useSelector, useDispatch } from 'react-redux';
import { setFlag } from './featureTogglesSlice';
import type { AppDispatch, RootState } from './store';

export function Dashboard() {
  const flags = useSelector((state: RootState) => state.featureToggles.flags);
  const dispatch = useDispatch<AppDispatch>();

  return (
    <div>
      {flags.newDashboard ? <h1>New Dashboard</h1> : <h1>Legacy Dashboard</h1>}
      <button
        onClick={() =>
          dispatch(setFlag({ key: 'newDashboard', enabled: !flags.newDashboard }))
        }
      >
        Toggle Dashboard
      </button>
    </div>
  );
}

Best Practices and Pitfalls

• Type your flag names: use a union of string literals or a generated enum so misspelled keys fail at compile time rather than silently returning false.

• Validate remote payloads: when flags arrive from an API, validate the response shape before storing it so malformed data cannot crash the UI.

• Separate concerns: do not mix global feature flags with per-user permissions; they have different lifecycles and audiences.

• Avoid over-fetching: if toggles rarely change, fetch them once on app start instead of polling; use RTK Query caching if you need automatic deduplication.

• Clean up stale flags: a flag left at true forever becomes dead code, defeating the purpose of a toggle.

• Never store secrets: feature toggles are client-side and can be inspected; they must never gate security controls or hide sensitive data.

Core Structure

A slice definition requires a unique name, initial state, and an object of reducer functions. The name prefixes generated action types to prevent collisions across features. Each key in the reducers object becomes an action case, and createSlice automatically exports the corresponding action creators alongside the reducer function. You can also define extraReducers to handle async thunks or actions from other slices without adding them to the reducers object.

Immutability Handling

Unlike traditional Redux reducers that require immutable updates via spread operators, slices use Immer internally. This means developers can write code that appears to mutate the state directly, such as state.value += 1, without breaking change detection. This syntax is only safe inside createSlice; plain reducers still require immutable patterns to avoid bugs. Never return undefined from a reducer—Immer throws in that case—but returning an entirely new state object is permitted.

React Integration

To use slice data in a UI, import the generated action creators and the reducer. The reducer is passed into configureStore during setup to build the global store. Inside components, access state with useSelector and dispatch actions with useDispatch. This hook-based approach replaces the legacy connect() higher-order component and simplifies typing compared to wrapping components in containers.

When to Avoid Redux

Not all state belongs in Redux. Local component state, form inputs, or data that does not need to be shared globally should remain in React useState or useContext. Additionally, server-state management is often better handled by RTK Query or libraries like React Query rather than manual caching in slices. Using Redux for transient UI state adds unnecessary boilerplate and complexity to the application architecture.

Code Example

// counterSlice.ts
import { createSlice } from '@reduxjs/toolkit'

export const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    incremented: (state) => {
      state.value += 1 // Safe due to Immer
    },
  },
})

export const { incremented } = counterSlice.actions
export default counterSlice.reducer

// CounterComponent.tsx
import { useSelector, useDispatch } from 'react-redux'
import { incremented } from './counterSlice'

export function Counter() {
  const count = useSelector((state: { counter: { value: number } }) => state.counter.value)
  const dispatch = useDispatch()
  return <button onClick={() => dispatch(incremented())}>{count}</button>
}

Best Practices

Keep slices focused on a single domain entity, such as users or cart. Avoid creating slices for UI booleans that do not persist or share across components. Always type your state interfaces when using TypeScript to ensure autocomplete safety within reducers. Normalize complex nested data to prevent duplication and ensure consistent updates across the state tree. Use extraReducers for async thunks and cross-slice actions instead of adding unrelated cases to reducers.

How the Ducks Pattern Works

Each “duck” module exports:

• The reducer as the default export.

• Action creators as named exports.

• Action type constants (optionally) as named exports.

Action types follow a naming convention to avoid collisions: appName/duckName/ACTION_NAME.

With Redux Toolkit, createSlice automates this: it generates the reducer, action types, and action creators from a single configuration object. Because createSlice uses Immer, reducer logic can be written with apparent mutation while remaining truly immutable.

Key Features

• Co‑location: Everything related to one feature (e.g., user, todos) lives in one file (user.slice.js, todos.slice.ts).

• Predictable exports: The default export is always the reducer; named exports are action creators and selector helpers.

• Standardized action type strings: The pattern encourages consistent prefixes such as todos/fetchTodos/pending, todos/fetchTodos/fulfilled (used by createAsyncThunk).

• Immer‑based mutation safety: When using Redux Toolkit’s createSlice, reducers can be written with apparent mutation because Immer produces a new immutable state behind the scenes; plain reducers without Immer must never mutate state.

Advantages and Limitations

Best Practices and Common Pitfalls

• Use createSlice instead of writing ducks manually – it is the official Redux Toolkit API and eliminates boilerplate.

• Avoid action type string collisions by using the name property of the slice as the type prefix.

• Do not export the reducer as a named export – keep it as default so that configureStore can import it cleanly.

• Do not put side effects inside a slice reducer – reducers must be pure. Use createAsyncThunk or RTK Query for asynchronous logic.

• Do not over‑engineer with ducks – if a feature is very small, it may still be fine to keep it in one file; for large features, split into sub‑files but keep the duck as the public boundary.

• Redux is not always needed – consider local state (useState) for UI‑only data, React Context for simple shared state, or a server‑state library like React Query or RTK Query when the data comes from an API.

Why Normalize State

• Data Consistency: When data lives in one place, updates propagate universally. If a user’s name changes in one list, it changes everywhere because both lists reference the same ID.

• Lookup Performance: Accessing an entity by ID becomes an O(1) object lookup rather than an O(n) array search, which matters as datasets grow.

• Update Simplicity: You modify one record instead of locating and updating duplicates across multiple nested arrays or slices.

• Memory Efficiency: Storing references instead of copies reduces memory footprint, especially with large datasets.

How Redux Toolkit Simplifies It

Redux Toolkit provides createEntityAdapter, which generates normalized state shapes and optimized CRUD reducers automatically. It handles the lookup tables (entities) and ordering IDs (ids) for you. Since createSlice uses Immer internally, you can write mutating-style logic inside reducers safely, though the adapter methods return new state immutably. This removes the boilerplate of manually managing normalization logic.

In components, you access the normalized data via the adapter’s generated selectors (e.g., selectAll, selectById) together with the useSelector hook, so the normalized shape never leaks into UI code.

When Redux Isn’t Needed

Do not use Redux for local UI state (e.g., form inputs, toggle flags) where React useState suffices. Avoid it for server-state caching if libraries like React Query or SWR handle synchronization better. Use Redux only for global state that many components need across the app. Normalization adds complexity, so only apply it when the data relationships justify it.

Best Practices and Pitfalls

• Use Selectors: Encapsulate state shape access with selectors so normalization details don’t leak into components. This allows you to change the internal structure later without refactoring UI.

• Avoid Manual Normalization: Do not manually flatten data; rely on createEntityAdapter to prevent errors and ensure optimized reducer logic.

• Don’t Over-Normalize: Simple lists of primitives or small static data rarely need normalization; keep the store shape shallow where possible.

• Immutable Updates Outside Slices: Remember Immer only applies inside createSlice reducers; always return new state in plain functions or thunks.

How normalization works

Instead of storing a list of nested objects like:

{
  posts: [
    { id: 1, title: 'First', author: { id: 5, name: 'Alice', posts: [1, 2] } },
    ...
  ]
}

You store two collections:

• An entities object mapping IDs to items.

• An ids array maintaining the order.

{
  users: { entities: { 5: { id: 5, name: 'Alice' } }, ids: [5] },
  posts: { entities: { 1: { id: 1, title: 'First', authorId: 5 } }, ids: [1] }
}

This avoids duplication, makes updates simpler, and prevents cascading re‑renders when one part of the data changes.

createEntityAdapter – the official builder

createEntityAdapter generates ready‑to‑use reducers and selectors for a given entity type.

• getInitialState() returns { ids: [], entities: {} }, plus optional extra fields.

• CRUD reducers: addOne, addMany, setAll, removeOne, removeMany, updateOne, upsertOne, etc.

• Sort comparators can be passed to keep ids sorted automatically.

• Selectors like selectAll, selectById, selectIds can be generated and exported.

All reducer logic uses Immer under the hood, so you can write “mutating” code safely.

Code Example

import { createSlice, createEntityAdapter, nanoid } from '@reduxjs/toolkit';

// 1. Define the adapter – sort by title alphabetically
const postsAdapter = createEntityAdapter({
  sortComparer: (a, b) => a.title.localeCompare(b.title),
});

// 2. Create the slice using the adapter's initial state
const postsSlice = createSlice({
  name: 'posts',
  initialState: postsAdapter.getInitialState(),
  reducers: {
    // Adapter reducers are added directly
    addPost: {
      reducer: postsAdapter.addOne,
      prepare(title, authorId) {
        return { payload: { id: nanoid(), title, authorId } };
      },
    },
    removePost: postsAdapter.removeOne,
    updatePost: postsAdapter.updateOne,
  },
});

export const { addPost, removePost, updatePost } = postsSlice.actions;

// 3. Export generated selectors scoped to the store slice
export const {
  selectAll: selectAllPosts,
  selectById: selectPostById,
} = postsAdapter.getSelectors((state) => state.posts);

export default postsSlice.reducer;

In a component:

import { useSelector, useDispatch } from 'react-redux';
import { addPost, selectAllPosts } from './postsSlice';

function PostList() {
  const posts = useSelector(selectAllPosts);
  const dispatch = useDispatch();

  return (
    <ul>
      {posts.map((p) => <li key={p.id}>{p.title}</li>)}
    </ul>
  );
}

Advantages and tradeoffs

• Performance: Updates to one entity don’t touch other entities. Only the changed entity triggers a re‑render (via shallowEqual or createSelector memoization).

• No duplication: Author data lives in one place, not copied into every post.

• Simpler updates: updateOne with { id, changes } is straightforward.

• Tradeoff: Components need to “join” related entities manually (e.g., fetch author by authorId). For deeply nested UIs, consider using Reselect memoized selectors or RTK Query’s normalized cache.

When to normalize

• Data is relational (e.g., posts with authors, comments).

• The same entity appears in multiple places.

• You need fast lookups by ID (selectById).

• Don’t normalize when the data is simple, read‑only, or shown in a single flat list (local component state or React context may be enough).

Normalization is a tool for predictable state management and rendering performance, not a rule for every reducer.

Denormalized vs Normalized State

In a normalized shape, entities live in dictionaries keyed by ID and other slices reference them by ID:

• users.byId[1] holds the user object.

• orders.byId[1] holds { id: 1, userId: 1, total: 100 }.

A denormalized shape embeds the related data directly:

• orders[0] contains { id: 1, total: 100, user: { id: 1, name: 'Alice' } }.

Normalization is the default pattern in Redux Toolkit, especially when you use createEntityAdapter. Denormalization deliberately accepts duplication to simplify reads.

When Denormalization Is Useful

• Read‑heavy, write‑light data: A blog where user profiles rarely change but appear alongside every post.

• Small prototypes: You want to avoid the extra selectors and join logic that normalization requires.

• Offline‑first apps: You control update propagation manually and can tolerate duplicated copies.

• Server‑side cache already consistent: The Redux store is only a fast projection of server data, so duplication is harmless.

Advantages of Denormalized State

• Simpler selectors: One useSelector call returns the whole tree; no need to join slices.

• Less reducer logic: Updating a related entity does not require touching multiple slices.

• Faster reads for deeply nested UI: If the UI always displays the full nested structure, you skip the cost of normalizing and re‑joining on every render.

• Easier onboarding: New developers see the complete shape directly in the state.

Limitations and Best Practices

Best practices

• Reserve denormalization for truly static or rarely updated data.

• For most applications, use createEntityAdapter for normalized collections and write selectors (via createSelector or RTK Query helpers) that denormalize on the fly only for rendering.

• If you do denormalize, treat the server as the single source of truth and re‑fetch the whole tree when an entity changes.

• Remember that Redux itself is often unnecessary: for local UI state use React useState/useReducer, for cross‑component state consider React Context, and for server state prefer RTK Query or other server‑state libraries.

Denormalization trades long‑term consistency for short‑term convenience. It is not the Redux‑recommended pattern, but it can be a pragmatic choice when you understand the trade‑offs and the data is mostly read‑only.

Why Normalize State

Normalization prevents data duplication and consistency bugs across your application. When entities relate, such as Users and Posts, storing nested copies leads to update anomalies where one instance changes but another does not. - Single Source of Truth: Each entity lives in one place within the state tree. - Performance: Selectors memoize results, reducing unnecessary component re-renders. - Simplicity: Updates target specific IDs without requiring deep cloning of nested objects.

Using createEntityAdapter

Redux Toolkit provides createEntityAdapter to generate standard reducers and selectors for normalized data. It manages an internal shape containing entities (a lookup map by ID) and ids (an ordered array). - Adapter Methods: addOne, addMany, updateOne, and removeAll handle immutable updates safely within slices. - Selectors: Generate selectors via adapter.getSelectors() to access selectAll, selectById, and selectIds. - Immer Integration: Inside createSlice, you can write “mutating” logic because Immer produces the actual immutable state behind the scenes.

Modeling Relations

Relations are represented by storing IDs within entities, functioning similarly to foreign keys in a relational database. - One-to-Many: A User entity contains an array of postIds, while each Post contains a single userId. - Many-to-Many: Both entities store arrays of related IDs, such as Users belonging to multiple Groups. - Fetching Data: Use createAsyncThunk or RTK Query to fetch data, then normalize the payload before passing it to the adapter. RTK Query can automatically normalize data if configured with entity adapters.

When Redux Isn’t Needed

Not all state requires global management, and overusing Redux can add unnecessary complexity. Avoid Redux for: - Local UI State: Form inputs, toggle states, or modal visibility belong in React useState. - Server State: If you only cache API data, RTK Query or React Query may suffice without manual slice management. - Prop Drilling: Simple parent-child data passing does not justify initializing a global store.

Best Practices

• Memoize Selectors: Use createSelector from Reselect for derived data to prevent unnecessary calculations during renders.

• Keep Slices Small: Separate adapters for distinct entities rather than maintaining one giant normalized object.

• Update Both Sides: When adding a Post, ensure the User’s postIds array is also updated to maintain relation integrity across slices.

Historical Role in Redux

• Immutability contract: classic Redux with createStore required reducers to return new state rather than mutate existing state. Immutable.js enforced that contract structurally.

• Typical integration: initial state was often an Immutable.Map or Immutable.List; reducers used methods such as state.set(), state.update(), and state.push(), which returned new values while sharing unchanged structure.

• Boundary conversion: API payloads were converted with Immutable.fromJS() and converted back for components or serialization with toJS(), adding boilerplate.

• Reducer composition: because Immutable.Map is not a plain object, plain Redux combineReducers did not fit that state shape directly; the legacy redux-immutable package was sometimes used.

• Performance: structural sharing made top-level reference comparisons cheap and avoided copying entire trees, but the extra data structures and conversions could complicate debugging.

Redux Toolkit and Immer Today

• createStore is deprecated; use Redux Toolkit configureStore.

• createSlice and createReducer use Immer: write draft mutations like state.value += 1 or state.items.push(item), and Immer produces a new plain JavaScript state safely.

• This mutation-like syntax is safe only inside Immer-enabled reducers, not ordinary reducer functions; there, use spread syntax or explicit copies.

• Components should read state with useSelector and dispatch with useDispatch; connect() is the older React-Redux API.

Immutable.js vs Redux Toolkit with Immer

When Redux Is Unnecessary

• Local state: useState is preferred for component-local data such as form inputs or UI toggles.

• React Context: useful for low-frequency global values such as theme preferences or authentication status.

• Server state: RTK Query, React Query, or SWR handle caching, loading states, and refetching better than manual Redux actions.

• Immutability alone is not a reason to add Redux or Immutable.js; Immer inside Redux Toolkit solves common reducer immutability concerns.

Best Practices and Common Pitfalls

• For new Redux code, use RTK createSlice and let Immer handle immutability; keep the store plain and serializable.

• Do not mutate state outside Immer-enabled reducers; plain reducers must return new objects via spread syntax or explicit copies.

• Avoid mixing Immutable.js collections with RTK slices; non-plain values can trigger RTK serializability checks and complicate DevTools or persistence.

• Do not store functions, Promises, Symbols, or class instances in Redux state.

• If a specific non-Redux part of an application needs persistent immutable collections, Immutable.js can still be used, but convert at the Redux boundary instead of making it the default store format.

Core Features

The extension provides a panel within the browser’s developer tools displaying several key views: - Action Log: A chronological list of every dispatched action with its payload and timestamp. - State Tree: The current global state structure, allowing expansion of nested objects. - Diff View: Highlights exactly which parts of the state changed between actions, leveraging immutable updates to detect differences efficiently. - Stack Trace: Shows the code path that triggered the action, helping identify the source of unintended state changes.

Integration with Redux Toolkit

Unlike legacy Redux setups requiring manual enhancer configuration, Redux Toolkit’s configureStore enables DevTools by default when process.env.NODE_ENV is not set to production. This means developers get debugging capabilities out of the box without importing composeWithDevTools. Since createSlice uses Immer internally, reducers can appear to mutate state safely, and DevTools will still reflect the correct immutable snapshots produced by Immer.

Time-Travel Debugging Workflow

This feature allows developers to pause the application state at any point in history. You can: 1. Step Back/Forward: Move through actions one by one to observe UI changes. 2. Skip Actions: Bypass specific actions to see how the app behaves without them. 3. Dispatch Manually: Type and send new actions directly from the panel to test edge cases without writing UI interactions. This is particularly useful for reproducing complex bugs that depend on a specific sequence of events.

Security and Production Usage

DevTools should never be enabled in production builds. State trees often contain sensitive user data, authentication tokens, or internal logic details that should not be exposed to end users. Additionally, the extension adds bundle size and performance overhead. Redux Toolkit handles this automatically by disabling DevTools in production environments unless explicitly overridden.

Best Practices and Pitfalls

• Avoid Storing Secrets: Never put API keys, tokens, or PII in the Redux state, as DevTools makes them easily inspectable.

• Serializable Actions: Ensure actions contain serializable data; non-serializable values like Promises or classes may break DevTools functionality.

• Know When Not to Use Redux: If state is local to a component or only needed by a few siblings, use React useState or Context instead of Redux. DevTools visibility does not justify over-engineering global state.

• Performance Monitoring: While useful, excessive logging in DevTools can slow down large applications; monitor performance impacts during development.

How Memoized Selectors Work

• Input selectors: small functions that extract raw pieces of state, such as state => state.todos.items.

• Result function: combines those inputs into derived output, for example filtering or aggregating a list.

• Cache: after each call, createSelector stores the previous inputs and the returned output. On the next call it compares new inputs to the cached ones using reference equality; if they match, it returns the cached result immediately without running the result function.

• Default memoization behaviour: reselect 5.x uses weakMapMemoize by default, which retains cached results for as long as the input references remain alive. In reselect 4.x the default memoizer kept only the single most recent call. To customize caching—such as using a bounded LRU cache or different equality checks—use createSelectorCreator with a custom memoization function.

Building Selectors with createSelector

• Signature: createSelector([input1, input2, ...], resultFn) or createSelector(input1, input2, ..., resultFn).

• Import path: you can import createSelector from reselect or from @reduxjs/toolkit; RTK re-exports it so Redux-only projects do not need an extra dependency.

• Composition: selectors can be composed by using one memoized selector as an input to another, which keeps derivation chains efficient.

• RTK Query parity: RTK Query applies similar caching principles to server state, so you rarely need to hand-write selectors for fetched data.

Code Example

// features/todos/selectors.ts
import { createSelector } from '@reduxjs/toolkit';
import type { RootState } from '../../app/store';

const selectTodos = (state: RootState) => state.todos.items;
const selectFilter = (state: RootState) => state.todos.filter;

export const selectVisibleTodos = createSelector(
  [selectTodos, selectFilter],
  (todos, filter) => {
    // This runs only when todos or filter references change
    switch (filter) {
      case 'active':
        return todos.filter((t) => !t.completed);
      case 'completed':
        return todos.filter((t) => t.completed);
      default:
        return todos;
    }
  }
);

// features/todos/TodoList.tsx
import { useSelector } from 'react-redux';
import { selectVisibleTodos } from './selectors';

export function TodoList() {
  const visibleTodos = useSelector(selectVisibleTodos);

  return (
    <ul>
      {visibleTodos.map((todo) => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

Immutability and Reference Equality

Memoized selectors rely on reference equality to decide whether to recompute. Redux Toolkit’s createSlice uses Immer, so you can write “mutating” code inside its reducers—such as state.value = 1—and Immer will safely produce a new immutable state object. In contrast, plain reducers outside createSlice must never mutate the existing state; they must return new objects or arrays. If state is mutated in place, selectors may see identical references for changed data and incorrectly return stale cached results.

When Redux or Selectors Aren’t Needed

Best Practices and Common Pitfalls

• Define selectors outside components so the same memoized instance is reused across renders; recreating it inside a component defeats caching.

• Keep input selectors granular and return stable references; avoid returning new object literals from input selectors unless necessary.

• Do not mutate state in plain reducers; only createSlice reducers can use Immer’s “mutating” syntax.

• Prefer useSelector and useDispatch in new React code; the older connect() higher-order component is legacy and should not be used in modern applications.

• Reach for RTK Query first for server interactions instead of duplicating fetch-and-cache logic in slices and selectors.

Core Toolkit and Data Fetching

Redux Toolkit consolidates previously separate libraries into one package to reduce setup friction. - configureStore: Replaces the deprecated createStore. It automatically sets up Redux DevTools and applies middleware like redux-thunk by default. - createSlice: Generates action creators and types automatically based on reducer functions, eliminating manual action constants. - RTK Query: Built-in data fetching and caching layer for standard API interactions, handling loading states and caching logic. For many apps it reduces the need for hand-written createAsyncThunk logic.

React Integration and Hooks

Connecting Redux to React is achieved via the react-redux package using hooks rather than higher-order components. - useSelector: Subscribes the component to the store and extracts specific data using a selector function. - useDispatch: Returns a reference to the dispatch function to send actions to the store. - The legacy connect() higher-order component remains available but is older style; hooks are recommended for all new development.

Immutability Handling

A frequent point of confusion involves how state updates are processed within reducer logic. - Immer Integration: createSlice uses the Immer library internally, allowing developers to write “mutating” logic (e.g., state.value += 1) that is safely translated into immutable updates. - Plain Reducers: If writing a reducer function outside of createSlice, standard immutability rules apply, and direct mutation will cause bugs. - Serializability: RTK includes middleware to warn against storing non-serializable values like functions or Promises in the state.

When to Avoid Redux

Before reaching for Redux, evaluate if the complexity is justified for the specific state needs. - Local State: Use React useState or useReducer for data confined to a single component or subtree. - Context API: React Context is sufficient for simple global values like themes or authentication status without the overhead of Redux. - Server State: For fetching, caching, and synchronizing remote data, a dedicated server-state library such as TanStack Query is often simpler than modeling server data in a global store. RTK Query is the in-house option, but it still requires Redux machinery. - Derived Data: Avoid storing derived data that can be computed via selectors, as this increases store complexity unnecessarily.

Comparing State Management Approaches

The table below summarizes common pairings and their sweet spots.

Best Practices and Pitfalls

• Colocation: Keep slices feature-based so reducers, actions, and selectors live together.

• Normalization: Normalize nested data to avoid deeply nested updates and duplicated entities.

• Selector Performance: Use memoized selectors (e.g., via Reselect, included in RTK) to prevent unnecessary re-renders.

• Avoid Premature Abstraction: Do not wrap every dispatch in a custom hook unless it improves readability across many components.

Core APIs and Their Roles

• configureStore: Replaces the deprecated createStore. It automatically wires up Redux DevTools, combines reducers, and applies common middleware such as Redux Thunk without manual setup.

• createSlice: Generates action creators and action types from a single reducer definition. Reducers inside a slice can safely use “mutating” syntax because Immer produces an immutable update under the hood.

• createAsyncThunk: Manages asynchronous request lifecycles (pending, fulfilled, rejected) automatically, eliminating hand-written action-type strings and boilerplate thunks.

• RTK Query: A built-in data-fetching and caching layer that removes the need to manually track loading, error, and cache state for server data.

Immutability and Immer

• Immer integration: createSlice wraps reducers with Immer, so code that looks like direct mutation (for example, assigning to a draft state property) results in a new immutable state object. This protection does not extend to plain reducers passed directly to combineReducers; outside a slice, manual copying or immutable update patterns are still required.

• Plain reducer caveat: Mutating state outside a slice bypasses Immer and can cause React components to miss updates because reference equality checks fail to detect the change.

React Integration

• Hooks over HOCs: useSelector and useDispatch are the current, recommended way to read state and dispatch actions. The older connect() higher-order component still functions, but hooks reduce nesting and give better TypeScript inference.

• Typed hooks: In TypeScript applications, pre-typed versions of useDispatch and useSelector are standard to avoid repeating generics in every component.

When Redux Isn’t Needed

• Truly local state: useState or useReducer is sufficient for UI-only concerns such as form inputs, toggle visibility, or transient animation state.

• React context: Appropriate for low-frequency updates like theme or locale, but it can trigger widespread re-renders when values change often.

• Server-state libraries: Tools such as TanStack Query, SWR, Apollo Client, or RTK Query handle caching, background refetching, and request deduplication better than storing remote responses in a global client store.

Legacy vs. Modern Patterns

Best Practices and Common Pitfalls

• Do not use createStore: It is deprecated and lacks the middleware and DevTools defaults that configureStore provides.

• Keep slices cohesive: Organize state by feature domain rather than data type to avoid over-fragmentation and cross-slice coupling.

• Do not mix mutation styles: Writing mutating code outside createSlice bypasses Immer and leads to silent bugs.

• Avoid globalizing server data: Prefer RTK Query or a dedicated server-state library for remote data instead of caching raw responses in a client-side slice.

• Selector performance: useSelector executes on every dispatch, so keep selectors fast and use reselect (bundled with RTK) for expensive derived data to prevent unnecessary re-renders.

Testing Slice Reducers

• Pure function testing: Call the reducer generated by createSlice directly with an initial state and an action object; no store or React rendering is required.

• Immer guarantees: Reducers may contain “mutating” code because createSlice uses Immer, which produces a new immutable state. Assert on the returned state rather than reference equality.

• Generated actions: Use the action creators exported from the slice (e.g. counterSlice.actions.increment) to build the exact actions passed to the reducer.

Testing Async Thunks

• Promise-based: createAsyncThunk returns a thunk that resolves or rejects when dispatched. Dispatch it against a real store and await the result.

• Clean assertions: Call .unwrap() on the returned promise to throw rejection reasons instead of silently logging unhandled rejections, making pending, fulfilled, and rejected paths easy to assert.

• State transitions: After dispatching, inspect store.getState() to confirm the slice handled the lifecycle actions correctly.

Integration Testing

• Real store: Instantiate configureStore with the actual combined reducers when multiple slices or middleware interact.

• Sequential dispatch: Dispatch actions and thunks in order, then read the final state tree from store.getState().

• Default middleware: configureStore includes the thunk middleware and serializability/immutability checks by default, so integration tests mirror runtime behavior.

Code Example

import { createSlice, createAsyncThunk, PayloadAction, configureStore } from '@reduxjs/toolkit';

export const fetchCount = createAsyncThunk('counter/fetchCount', async (amount: number) => {
  return Promise.resolve(amount);
});

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0, loading: false },
  reducers: {
    incrementByAmount: (state, action: PayloadAction<number>) => {
      state.value += action.payload;
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(fetchCount.pending, (state) => {
        state.loading = true;
      })
      .addCase(fetchCount.fulfilled, (state, action) => {
        state.value += action.payload;
        state.loading = false;
      })
      .addCase(fetchCount.rejected, (state) => {
        state.loading = false;
      });
  },
});

const store = configureStore({
  reducer: {
    counter: counterSlice.reducer,
  },
});

it('increments value correctly', () => {
  const initialState = { value: 0, loading: false };
  const action = counterSlice.actions.incrementByAmount(5);
  const finalState = counterSlice.reducer(initialState, action);
  expect(finalState.value).toBe(5);
});

it('fulfills fetchCount and updates state', async () => {
  const result = await store.dispatch(fetchCount(10)).unwrap();
  expect(result).toBe(10);
  expect(store.getState().counter.value).toBe(10);
  expect(store.getState().counter.loading).toBe(false);
});

Best Practices and Common Pitfalls

• Test logic, not wiring: Assert on reducer output and state transitions, not on whether a component called dispatch.

• Avoid legacy APIs: Do not use the deprecated createStore; prefer configureStore for sensible defaults.

• Skip Redux when unnecessary: Simple UI state belongs in local component state or React Context, not Redux.

How to Test Reducers

Reducers created with createSlice are plain functions that take (state, action) and return new state. Testing them is a matter of calling the reducer with a known state and action, then asserting the result.

• No store needed – the reducer is a pure function.

• Immer integration – inside a slice reducer you write “mutating” code, but the output is still immutable. You test against the expected new state, not intermediate mutations.

• Example: call counterSlice.reducer(initialState, increment()) and check state.value.

How to Test Async Thunks (createAsyncThunk)

Async thunks encapsulate side effects and dispatch pending/fulfilled/rejected actions. The simplest way to test them is to create a real Redux store with configureStore, dispatch the thunk, and observe the state changes.

• Use configureStore with a reducer object that includes the relevant slice reducer.

• Mock the API call (e.g., jest.spyOn or vi.fn()) so the thunk does not rely on a real network.

• Dispatch the thunk: await store.dispatch(thunkActionCreator(argument))

• Assert state with store.getState() after the thunk settles.

• Optionally, assert the sequence of actions using store.dispatch calls if needed.

How to Test React Components Connected to Redux

For components that use useSelector and useDispatch, create a test store and wrap the component in a <Provider>.

• Use configureStore to generate a store, possibly with preloadedState to set initial data.

• Use render from @testing-library/react with a custom wrapper that includes <Provider store={store}>.

• After rendering, use screen queries to verify the UI.

• To test dispatch actions, you can spy on store.dispatch or dispatch real actions and check state updates (preferred).

• Do not mock useSelector – using a real store ensures your tests match production behavior.

Advantages and Limitations

Best Practices and Common Pitfalls

• Prefer a real store over redux-mock-store – Redux Toolkit’s configureStore is lightweight and gives you true reducer behaviour.

• Keep tests focused – test reducers in isolation for pure logic; use component/integration tests for UI.

• Don’t test internal implementation – avoid asserting that dispatch was called with a specific action type; instead assert state changes or visible UI.

• Use beforeEach to create a fresh store – this isolates tests and prevents state leakage.

• For async thunks, always await the dispatch – otherwise the test may finish before the thunk resolves.

• Mock at the network boundary – mock fetch or axios, not the thunk itself.

• Redux is not always needed – for local or server-state, consider React context, useState, or dedicated server-state libraries like React Query. Reserve Redux for complex client‑state that is shared across many components.

Core Store Creation

Use configureStore from Redux Toolkit instead of the deprecated createStore. It automatically sets up the Redux DevTools Extension and includes middleware such as redux-thunk by default. Define state with createSlice, which uses Immer so “mutating” syntax inside reducers is safe and preserves immutability. For server state, add RTK Query API reducers to the store to handle caching and loading uniformly.

Framework Integration

There is no official Redux binding for Vue or Angular from the Redux team. You integrate by exposing the store and subscribing manually.

When Redux Is Not Needed

Redux adds complexity and should be avoided for local UI state or data that does not require global synchronization. React context, framework-native solutions like Pinia or Angular services, and server-state libraries such as RTK Query or TanStack Query can replace Redux when global traceability is unnecessary.

Code Example

// store.ts
import { configureStore, createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    incremented: (state) => {
      // Safe mutation thanks to Immer
      state.value += 1;
    },
  },
});

export const store = configureStore({
  reducer: {
    counter: counterSlice.reducer,
  },
});

export const { incremented } = counterSlice.actions;

// useCounter.ts (Vue 3 Composition API composable)
import { onUnmounted, ref } from 'vue';
import { store, incremented } from './store';

export function useCounter() {
  const count = ref(store.getState().counter.value);

  const unsubscribe = store.subscribe(() => {
    count.value = store.getState().counter.value;
  });

  // Unsubscribe when the component unmounts to prevent memory leaks
  onUnmounted(unsubscribe);

  const increment = () => store.dispatch(incremented());

  return { count, increment };
}

Best Practices

• Immutability: Trust Immer inside createSlice, but never mutate state outside of reducers.

• Deprecation: Avoid createStore; it is legacy and lacks RTK defaults.

• Type Safety: Use TypeScript to infer store types, ensuring dispatch and state shapes are validated.

• Cleanup: Always unsubscribe from store subscriptions when components unmount to prevent memory leaks.

• Separation: Keep business logic in thunks or RTK Query, leaving components focused on rendering.

Core Toolkit APIs

• configureStore: Creates the store and automatically applies Redux Thunk plus development checks; the legacy createStore is deprecated and should not be used in new code.

• createSlice: Groups related actions and reducers into one file. Reducers written here can appear to mutate state directly because Immer produces immutable updates behind the scenes.

• createAsyncThunk: Generates pending/fulfilled/rejected action types for asynchronous work such as network requests, removing the need for custom middleware.

• RTK Query: An optional data-fetching and caching layer included in Redux Toolkit; it is often a better fit for server state than hand-writing thunks.

Immutability and Immer

• Inside a createSlice reducer, writing state.value = 1 is safe and encouraged; Immer records the mutation and returns a new immutable state object.

• In plain, hand-written reducers—outside of createSlice—you must never mutate the existing state. Always return new objects or use spread syntax, otherwise React-Redux may fail to detect changes.

When Redux Isn’t Needed

• Local component state: Use useState or useReducer when only one screen or component cares about the data.

• Rarely changing app settings: React Context is simpler for themes, locale, or auth tokens that do not change often.

• Server state: Prefer RTK Query, TanStack Query, or SWR for caching API responses. Storing server data in the global Redux store often duplicates state and adds unnecessary complexity.

Code Example

import { configureStore, createSlice, createAsyncThunk, PayloadAction } from '@reduxjs/toolkit';
import { Provider, useDispatch, useSelector } from 'react-redux';
import { View, Text, Button, ActivityIndicator } from 'react-native';

interface User { name: string }
interface UserState { user: User | null; loading: boolean }

// Async action for fetching a user from an HTTPS API
export const fetchUser = createAsyncThunk<User, string>('user/fetch', async (userId) => {
  const res = await fetch(`https://api.example.com/users/${userId}`);
  if (!res.ok) throw new Error('Request failed');
  return res.json();
});

const userSlice = createSlice({
  name: 'user',
  initialState: { user: null, loading: false } as UserState,
  reducers: {
    clear: (state) => {
      state.user = null; // Safe because createSlice uses Immer
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(fetchUser.pending, (state) => { state.loading = true; })
      .addCase(fetchUser.fulfilled, (state, action: PayloadAction<User>) => {
        state.loading = false;
        state.user = action.payload;
      })
      .addCase(fetchUser.rejected, (state) => { state.loading = false; });
  },
});

const store = configureStore({ reducer: { user: userSlice.reducer } });

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

const { clear } = userSlice.actions;

function ProfileScreen() {
  const dispatch = useDispatch<AppDispatch>();
  const { user, loading } = useSelector((state: RootState) => state.user);

  if (loading) return <ActivityIndicator />;

  return (
    <View>
      <Text>{user ? user.name : 'No user loaded'}</Text>
      <Button title="Fetch User" onPress={() => dispatch(fetchUser('42'))} />
      <Button title="Clear" onPress={() => dispatch(clear())} />
    </View>
  );
}

export default function App() {
  return (
    <Provider store={store}>
      <ProfileScreen />
    </Provider>
  );
}

Best Practices and Common Pitfalls

• Use hooks, not connect(): useSelector and useDispatch are the modern React-Redux API; connect() is the older higher-order-component pattern.

• Keep the store serializable: Do not store functions, class instances, or non-serializable values in state; this breaks time-travel debugging and persistence.

• Normalize large collections: Store entities by ID in dictionaries rather than deeply nested arrays to simplify updates and lookups.

• Persist carefully on mobile: If you need offline support, use redux-persist with AsyncStorage, but only when truly necessary; RTK Query may cover most caching needs without a persistent store.

• Scope your selectors: Keep useSelector callbacks small and return primitive values when possible to avoid unnecessary re-renders in React Native’s bridge.

What Stays the Same

• Store creation: You still configure the application store with configureStore; the legacy createStore is deprecated and should not be used.

• Slices and reducers: You still define state with createSlice, and reducers written inside a slice can “mutate” the draft state safely because Redux Toolkit wraps them with Immer. This Immer behavior is exclusive to slice reducers; plain reducer functions passed directly to configureStore must return new immutable objects.

• Default middleware: The Thunk middleware is included automatically, so async logic via createAsyncThunk works identically in Node as it does in the browser.

What Changes

• No React-Redux: The React-Redux hooks useSelector and useDispatch, and the older connect() higher-order component, are never imported. You interact with the store imperatively using store.dispatch(), store.getState(), and store.subscribe().

• No DOM or browser APIs: Redux core never touched the DOM, but React-Redux relied on React’s render tree. In Node you also avoid browser globals such as window and localStorage; persist state with a database, Redis, or the file system instead.

• Process lifecycle: Long-running Node processes need explicit subscription cleanup and shutdown handling, whereas browser apps rely on component unmounting.

Middleware and Async Logic

• Thunks: createAsyncThunk remains the standard way to model side effects such as HTTP calls or database access.

• Listener middleware: RTK’s createListenerMiddleware is often more natural in Node than thunk cascades for reacting to dispatched actions.

• RTK Query: Although primarily a React data-fetching tool, createApi endpoints can still be invoked in Node with store.dispatch(endpoint.initiate(...)). For a pure backend, however, plain thunks or listener middleware are usually simpler unless you specifically need its caching behavior.

State Management Considerations in Node

• In-memory state is ephemeral: If the process restarts or you run multiple workers/cluster nodes, each instance has its own store copy. Shared server state generally belongs in Redis or a database rather than the Redux store alone.

• Serialization for IPC: When using Node worker threads or clustering, only serializable data can cross process boundaries; the development-only serializableCheck helps catch non-serializable values such as functions or class instances.

• Performance: The development-only immutableCheck and serializableCheck are enabled in development builds by default. In production they are off, but if you run long-lived, high-throughput Node services, monitor store size to avoid unbounded memory growth.

When Redux Isn’t Needed

Redux is valuable in the backend only when many modules share complex, cross-cutting state that benefits from a single predictable flow and dev-tools time travel. For a typical REST API or worker service, a plain module-scoped object, Node’s EventEmitter, or a small state-machine library is usually sufficient and simpler.

Best Practices and Pitfalls

• Dispose subscriptions: Always keep the return value of store.subscribe() and call it on shutdown to prevent memory leaks.

• Don’t mix plain reducers and Immer: Only createSlice reducers receive the Immer draft. A reducer passed directly to configureStore must return a new state object.

• Avoid browser globals: Never reference window, document, or localStorage in store logic; keep those concerns in environment-specific wrappers.

• Persist externally: Treat the Node process as disposable. Push state you need to survive restarts into an external store rather than relying on the in-memory Redux state.

• Keep the store lean: Do not use the Redux store as a general cache for every HTTP response or database row; reserve it for application state that genuinely needs centralized coordination.

Feature-First vs Type-First Layouts

• Feature-first: group files by domain (e.g., features/todos/); recommended for large apps because changes stay localized.

• Type-first: group by file kind (e.g., reducers/, actions/); common in legacy projects and becomes unwieldy as features grow.

Recommended Directory Structure

• src/features/<featureName>/ contains the slice, components, selectors, and RTK Query endpoints for that domain.

• src/app/ holds store configuration with configureStore, global middleware, and root reducer wiring.

• src/components/ or src/common/ holds truly reusable UI elements and helpers used across multiple features.

• src/hooks/ for shared custom hooks; avoid feature-specific hooks outside their feature folder.

State Boundaries and Redux Necessity

• Global client state: user session, theme, or complex multi-step forms that many unrelated components read.

• Local UI state: modal visibility, input drafts, or hover states—use useState; do not add Redux boilerplate.

• Server state: remote data caching, background refetching, and pagination—use RTK Query inside the feature folder rather than hand-writing thunks.

• React Context: dependency injection or rare global values where updates are infrequent and component trees are shallow.

• Custom async workflows: use createAsyncThunk inside the feature folder when RTK Query’s data-fetching model does not fit the side effect.

Immutability Rules

• Inside createSlice reducers, Immer lets you write “mutating” code safely; it records changes and produces a new immutable state object.

• Outside createSlice—for example, in a hand-written reducer passed to combineReducers—you must return a new state object and never mutate the existing one.

• RTK Query reducers are managed by the library; you do not write immutability logic for cached data.

Best Practices and Pitfalls

• Keep slices colocated: if a slice, component, and test all belong to todos, keep them together; resist splitting into parallel components/ and slices/ trees.

• Normalize nested data: use createEntityAdapter inside a slice when you manage collections with relationships, avoiding deeply nested objects.

• Export typed hooks: define useAppDispatch and useAppSelector in src/app/hooks.ts so components import typed versions rather than raw React-Redux hooks.

• Avoid cross-feature imports: if two features need the same data, lift the shared slice into src/features/<shared>/ or src/app/ rather than importing from a sibling feature.

• Do not use the deprecated connect() HOC in new code; use useSelector and useDispatch hooks.

• Do not call createStore directly; always use configureStore from Redux Toolkit.

Modular Feature Slices

createSlice bundles the reducers and corresponding action creators for a single domain—such as authentication, shopping cart, or posts—into one file. This replaces the legacy pattern of global action-type constants and large switch statements. Because createSlice relies on Immer, you can write “mutating” code inside its reducers safely; that same mutating style is unsafe in plain, hand-written reducers.

Normalizing State with Entity Adapters

createEntityAdapter stores collections as a lookup table keyed by id plus an ordered list of ids. This gives O(1) record access and simplifies updates without nested loops. The adapter exposes ready-made CRUD methods such as addOne, updateOne, removeOne, and setAll, which plug directly into a slice’s reducers or extraReducers.

Async Logic and Server State

createAsyncThunk encapsulates an asynchronous operation and automatically generates pending, fulfilled, and rejected action types that you can handle in extraReducers. For server data that is read-heavy, RTK Query provides declarative fetching with caching, request deduplication, and polling out of the box, eliminating many hand-written thunks. Reserve local Redux state for client-only concerns; when data lives on the server, a server-state tool is usually a better fit.

Best Practices and Pitfalls

• Use useSelector and useDispatch from React-Redux; the connect() higher-order component is the older API.

• The legacy createStore is deprecated—use configureStore, which sets up thunk middleware and development checks by default.

• Keep slices colocated with their feature folder and split large reducers rather than centralizing everything in one store module.

• Prefer RTK Query over manual thunks for standard create/read/update/delete server interactions.

• Redux is unnecessary for purely local component state; use useState or React Context instead.

A concrete illustration: a posts slice can define a postAdded reducer that calls postsAdapter.addOne(state, action.payload), while its extraReducers handle fetchPosts.pending, fetchPosts.fulfilled, and fetchPosts.rejected to manage loading state and replace the collection with server results.

Concept Clarification and State Structure

Domain-Driven Design (DDD) originates from backend architecture, focusing on business logic modeling. In Redux, this translates to grouping state slices by business capability rather than technical layers. Instead of a flat state, you define distinct slices that mirror aggregate roots using createSlice. configureStore combines these slices into a single store where top-level keys represent domains (e.g., state.auth, state.cart). This modularization supports scalability and team ownership of specific domains.

Immutability and Component Usage

A common confusion arises regarding immutability. In plain Redux reducers, you must return new objects. However, Redux Toolkit integrates Immer inside createSlice. This allows writing “mutating” logic safely within reducers, as Immer produces a new state tree behind the scenes. Writing state.value = 1 is safe inside createSlice but unsafe in plain reducers. To read and write state in React components, use the React-Redux hooks useSelector and useDispatch. The connect() function is the older API and hooks are preferred. Typed hooks (useAppSelector) are recommended when using TypeScript to ensure type safety across domains.

When Redux Is Not Needed

Adopting DDD-style state organization does not mean every domain needs Redux. Use React useState for UI toggles or form inputs local to a component. Use React Context for theming or authentication status shared deeply without frequent updates. Use RTK Query or React Query for cached server data instead of manual Redux state management. Reserve Redux for complex client state requiring middleware, time-travel debugging, or widespread subscription.

Best Practices

• Avoid Deep Nesting: Keep the state tree flat within domains to simplify selectors.

• Use Selectors: Encapsulate state access with createSelector to prevent components from depending on the raw shape.

• Type Safety: Define RootState and AppDispatch for typed hooks to catch errors at compile time.

• Lazy Loading: For large domains, consider injecting reducers dynamically if code splitting is required.

• Normalization: Within a domain, store relational data in normalized shapes (entities) to avoid duplication and ensure consistency.

Feature Modules and Slice Organization

• Slice: A feature module is a createSlice that encapsulates state shape, reducers, and generated action creators for one domain (e.g., usersSlice, cartSlice).

• Immer safety: createSlice uses Immer internally, so reducers can use “mutating” syntax while producing new immutable state; plain reducers outside a slice must remain pure and immutable.

• Co-location: Grouping selectors, thunks, and slice logic per feature avoids scattering related code across generic actions/ and reducers/ folders.

Code Splitting and Dynamic Reducers

• Bundle and architecture impact: Code splitting delays loading feature JavaScript until a route renders. In Redux this means reducers and slice logic join the store on demand, preventing a monolithic root reducer that grows without bound.

• Dynamic registration: The store from configureStore exposes store.replaceReducer, not addReducer. The standard pattern keeps a registry of slice reducers and calls replaceReducer with a newly combined root reducer after a lazy slice is imported.

• Initial state: Before a lazy reducer is registered, useSelector may read undefined for that slice key, so each slice should define a sensible initialState.

• Cleanup: Removing reducers at runtime is uncommon and can lose state; keep reducers registered for the session once loaded.

When Redux Isn’t Needed

• Local state: Form inputs, toggles, and modal visibility rarely need Redux.

• Context: React Context is simpler for low-frequency global values like theme or locale.

• Server state: RTK Query manages caching, loading, and invalidation automatically; avoid hand-rolled thunks for simple CRUD.

Best Practices

• Hooks over connect: Use useSelector and useDispatch from React-Redux; connect() is the older higher-order-component API.

• Typed hooks: With TypeScript, export typed useAppDispatch and useAppSelector to avoid repeating store types.

• Keep slices independent: Avoid cross-slice reducers; use extraReducers or shared thunks for communication.

• Guard against undefined: Initialize slice state so pre-load selector calls do not crash.

Core Architecture and Store Setup

The foundation involves replacing the deprecated createStore with configureStore. This function automatically configures the Redux DevTools Extension and includes useful middleware like redux-thunk by default. State logic is organized into slices using createSlice, which generates action creators and reducers from a single object definition. This structure encourages modular code where each feature owns its state slice.

Immutability and Immer Integration

A critical distinction lies in how updates are written: - Inside createSlice reducers: you can write code that appears to mutate state because Redux Toolkit wraps these functions with Immer. - In plain reducers or outside slices: immutability must be maintained manually by returning new objects. Understanding this boundary prevents accidental mutations that break change detection and time-travel debugging.

Handling Asynchronous Logic

For side effects like API calls, createAsyncThunk generates pending, fulfilled, and rejected actions automatically. For extensive server-state management, RTK Query is preferred as it handles caching, polling, and refetching without manual action types. Choosing between them depends on complexity:

React Integration Patterns

Components connect to the store using the hooks API rather than the legacy connect() higher-order component. - useSelector: extracts specific state values, triggering re-renders only when those values change. - useDispatch: returns the dispatch function to send actions. This pattern reduces wrapper hell and improves type inference in TypeScript environments.

Usage Guidelines and When to Avoid Redux

Keep state minimal and derived where possible using selectors. Ensure serializable actions and state to maintain DevTools functionality. Redux adds complexity and should not be used for every state need: - Local UI state: belongs in React useState. - React Context: is sufficient for low-frequency, app-wide concerns like themes or locale. - Server-state: often belongs in RTK Query or another dedicated server-state library rather than the Redux store. Do not put non-serializable values like class instances into the store.

Normalize State Structure

Storing nested or duplicated entities inflates the store unnecessarily. Instead, keep entities in a flat dictionary keyed by ID and store arrays of IDs separately. This ensures each entity exists only once, reducing memory usage and simplifying updates.

• Entities Map: { [id]: Entity } allows O(1) lookups without duplication.

• ID Lists: [id1, id2] maintain ordering without embedding full objects.

• Benefit: Updating a single entity requires changing only one reference instead of propagating changes through multiple nested arrays, preventing update anomalies.

Avoid Derived Data and Know When to Skip Redux

Never store data that can be computed from existing state. If you need a filtered list or a calculated total, compute it in a selector using useSelector from React-Redux. Storing derived values leads to synchronization bugs and bloated state. Use Reselect (included in RTK) to memoize expensive calculations.

Furthermore, not all state belongs in Redux. Overusing the global store is a primary cause of bloat. Use useState for form inputs or UI flags specific to one component. For server state, RTK Query manages caching and loading state automatically; do not duplicate this data in manual slices. Use React Context for theme settings that rarely change and need deep propagation without middleware overhead.

Pagination, Cleanup, and Immutability

Avoid loading infinite datasets into the store. Implement pagination or infinite scroll limits, and provide mechanisms to remove stale data. Store only the current page or a limited cache of recent pages. Dispatch actions to clear specific slices when users log out or navigate away from data-heavy sections to prevent memory leaks.

Redux Toolkit enables Immer within createSlice, allowing safe “mutation” syntax in reducers. However, non-serializable values like functions, Promises, or Symbols should never be stored. RTK’s default middleware includes a serializability check that warns in development when non-serializable data is detected. Keeping state serializable ensures DevTools functionality and prevents hydration errors during server-side rendering.

Best Practices and Common Pitfalls

• Storing Classes: Store plain data objects, not class instances, to avoid serialization issues.

• Ignoring Warnings: Disable serializability checks only if absolutely necessary; they protect store integrity.

• Global Bloat: If a slice is used by only one component, consider moving that state locally rather than globally.

• Configuration: Use configureStore to enable default middleware checks automatically rather than setting up the store manually.

Efficient Dispatching

• React 18 automatic batching: In React 18 and later, React itself batches state updates triggered by Redux dispatches inside event handlers, timeouts, and promises, so several dispatches in one handler usually produce a single re-render per subscribed component. Redux Toolkit does not perform batching itself; React-Redux 9.x subscribes with useSyncExternalStore and benefits from React’s batching. On React 17 and earlier, dispatches outside React event handlers could each cause their own render, so grouping updates mattered more.

• One dispatch per logical update: Never dispatch inside a loop; accumulate changes in a local variable or a thunk and dispatch once. A single dispatch produces at most one re-render per subscribed component, so fewer dispatches means less reconciliation work.

• RTK Query for server state: RTK Query deduplicates concurrent identical requests, caches responses, and manages loading flags, which replaces the manual “dispatch started/succeeded/failed” pattern built with createAsyncThunk for most data fetching.

• Avoid redundant dispatches: Do not store derived data; compute it in selectors so you never dispatch actions merely to mirror state elsewhere.

Reducing Payload Volume

• Normalization: Store entities in a dictionary keyed by ID instead of nested arrays. createEntityAdapter (part of Redux Toolkit) maintains ids and entities for you, prevents duplicating the same nested object in multiple places, and turns updates into a single-record write rather than a deep array copy.

• Minimal payloads: Dispatch identifiers such as an id and look the entity up in the store, rather than embedding whole objects the store already holds. For incoming data, request only the fields the UI needs and map them before they enter the store.

• Serializable state: Keep actions and state plain and serializable so the development-time checks and any persistence layer stay cheap.

When Redux Isn’t Needed

Using Redux for local or server state adds boilerplate and payload traffic without benefit.

Best Practices and Pitfalls

• Memoize selectors: useSelector re-runs after every dispatch and uses reference equality by default, so wrap derived data in createSelector (Reselect, re-exported by Redux Toolkit) and avoid returning freshly created object literals from the selector.

• Hooks preferred, connect() not deprecated: useSelector and useDispatch are the recommended style, but the older connect() higher-order-component API remains fully supported in React-Redux 9.x.

• Immer boundaries: Inside createSlice (and createReducer) reducers, “mutating” the draft state is safe because Immer records changes and produces an immutable result. Hand-written reducers passed directly to combineReducers or configureStore must still return new state objects.

• Keep serializability checks on: configureStore enables the serializable and immutability checks in development; if a value such as a Date must exist, narrow the check with ignoredActions or ignoredPaths instead of disabling it wholesale.

• Use configureStore: It wires good defaults (middleware, thunk, dev-tools integration) automatically; the original createStore API is deprecated.

Normalized State Shape

Storing nested arrays of objects causes performance issues when updating single items. Instead, flatten data into a dictionary keyed by ID. Redux Toolkit provides createEntityAdapter, which generates normalized case reducers and selectors automatically. This ensures updates to one entity do not require cloning large arrays, reducing memory pressure and diffing costs.

Memoized Selectors

Components should not re-render unless the specific data they need changes. Use createSelector from @reduxjs/toolkit to memoize derived data. These selectors only recompute when input values change, preventing expensive calculations on every store dispatch. When using useSelector, ensure you select the smallest possible slice of state to minimize subscription checks.

RTK Query for Server State

For frequent updates or large datasets fetched from APIs, avoid manual createAsyncThunk logic. RTK Query handles caching, background refetching, and polling out of the box. It invalidates caches based on tags, ensuring UI consistency without manual state synchronization. RTK Query stores each response under its cache key; when you need a relational lookup table, combine it with createEntityAdapter rather than relying on the cache shape alone.

When Redux Isn’t Needed

Not all state belongs in Redux. Local UI state (form inputs, toggles) should remain in React useState or useReducer. If data is only needed by a few deeply nested components, React Context may suffice. Server data should often live in RTK Query or another server-state library (e.g., TanStack Query) rather than being duplicated into a global Redux slice. Use Redux for global client state that many components access or where time-travel debugging is required.

Code Example

import { configureStore, createEntityAdapter, createSlice } from '@reduxjs/toolkit';
import { useSelector } from 'react-redux';

interface User {
  id: string;
  name: string;
}

const usersAdapter = createEntityAdapter<User>();

const usersSlice = createSlice({
  name: 'users',
  initialState: usersAdapter.getInitialState(),
  reducers: {
    addUser: usersAdapter.addOne,
    updateUser: usersAdapter.updateOne,
  },
});

const store = configureStore({
  reducer: { users: usersSlice.reducer },
});

type RootState = ReturnType<typeof store.getState>;

const { selectById } = usersAdapter.getSelectors((state: RootState) => state.users);

function UserProfile({ id }: { id: string }) {
  const user = useSelector((state: RootState) => selectById(state, id));
  return <div>{user?.name}</div>;
}

Common Pitfalls

• Storing Non-Serializable Data: Avoid putting functions, promises, or class instances in the store; RTK middleware warns against this.

• Over-subscribing: Calling useSelector with a function that returns a new object reference every time causes excessive re-renders on each store dispatch.

• Manual Immutability: Inside createSlice, you can write “mutating” logic thanks to Immer, but do not do this in plain reducers or outside slices.

Advantages of Centralizing Form State

• Cross-component coordination: Form values can drive sibling components, navigation guards, or global banners without prop drilling or Context providers.

• Persistence and recovery: Data can survive route changes, browser refreshes (via a persist layer), or accidental tab closures, which is valuable for long multi-step wizards.

• Debugging and time travel: Redux DevTools lets you inspect every action and replay the exact sequence of field changes, making it easier to reproduce validation bugs.

• Complex workflows: Multi-page forms, conditional branching, and draft autosave benefit from a single source of truth that persists across navigation.

Disadvantages and Performance Costs

• Re-render overhead: Every dispatch notifies subscribers; if many components select from the form slice via useSelector, typing can trigger excessive renders unless selectors are narrow.

• Ephemeral data in a global store: Form state is often temporary, yet placing it in Redux requires explicit cleanup actions to avoid stale values when the user abandons the form.

• Boilerplate and verbosity: Even with createSlice and Immer, wiring onChange handlers, validation flags, and touched state for dozens of inputs is tedious compared to a purpose-built form library.

• Immer safety boundaries: createSlice reducers may use “mutating” syntax because Immer produces immutable updates, but plain reducers must never mutate state directly; mixing the two styles is a common source of bugs.

Comparison with Alternatives

When Redux Is Unnecessary

• Local-only inputs: A login form, contact form, or search box used once does not need global state; useState or useReducer is sufficient.

• Server state mirroring: If the form loads and submits API data, use RTK Query to cache the server response rather than duplicating every server field in a client slice.

• Context-scoped forms: A settings panel or modal form contained within one provider can use React Context, avoiding global pollution and unnecessary re-renders.

Best Practices

• Hybrid ownership: Keep the active draft in local component state and dispatch to Redux only on blur, step change, or submit; this keeps typing smooth while preserving persistence.

• Narrow selectors: Use useSelector with field-specific selectors (and referential equality checks where needed) so unrelated store updates do not re-render the form.

• Explicit cleanup: Dispatch a reset action from a useEffect cleanup or an RTK Query lifecycle hook so abandoned forms do not leave stale data in the store.

• Respect Immer boundaries: Never mutate state outside createSlice reducers; if you write plain reducers or custom middleware, always return new state objects rather than modifying existing ones.

Why Redux State Is Insecure

Redux state is stored as a regular JavaScript object in the application’s memory. This means: - Any code running in the same browser context (e.g., third‑party scripts, browser extensions, or malicious injected code) can call store.getState() and read the entire state tree. - The Redux DevTools extension, commonly used during development, records every state transition and action payload. If the extension is left enabled in production, an attacker with access to the browser can inspect all stored data. - Middleware like redux-persist automatically serializes slices of the state to localStorage or sessionStorage. Persisting tokens to disk makes them vulnerable to cross‑site scripting (XSS) attacks that can read storage. - Redux actions themselves, if they carry sensitive payloads (e.g., a token from an API response), are also recorded by DevTools and persist in extension storage unless explicitly sanitized.

Recommended Storage for Tokens

For authentication tokens, the generally accepted best practice is to avoid storing them in Redux altogether:

• httpOnly cookies (with Secure, SameSite=Strict, and Path attributes) are the most secure option. The cookie is sent automatically with HTTP requests and is inaccessible to JavaScript, completely eliminating XSS exposure. The token is never stored in JavaScript memory beyond the few milliseconds needed during the initial exchange.

• Memory‑only variables outside Redux are a simpler alternative when httpOnly cookies are not feasible. For example, keep the token in a closure or a service module that is not serialized or exposed globally. The trade‑off is that the token is lost on page refresh, requiring a refresh token or re‑authentication.

• Session storage (not localStorage) can be used for short‑lived tokens, but it is still vulnerable to XSS that runs in the same tab.

Mitigations If You Must Store in Redux

If a project unavoidably needs a token in Redux (e.g., to centralize API request logic), apply these mitigations:

• Disable Redux DevTools in production: Use the devTools: process.env.NODE_ENV !== 'production' option (or the equivalent boolean false) in configureStore.

• Avoid persisting sensitive slices: When using redux-persist, explicitly exclude the auth slice from persistence with the blacklist or transforms option. Never serialize high‑risk values.

• Sanitize actions and state: Use a middleware that strips sensitive fields before they reach DevTools. For example, Redux Toolkit’s serializable‑state invariant middleware can be extended to remove token values from action payloads.

• Encrypt in memory? Not practical – if an attacker can read memory, they can also read a decryption key that is also in memory.

Common Pitfalls

• Storing tokens in localStorage via redux-persist: This is the single most common mistake. localStorage is readable by any JavaScript on the same origin; an XSS vulnerability instantly leaks the token.

• Leaving DevTools enabled in production: The Redux DevTools browser extension stores the entire state history, which can be accessed by anyone who inspects the browser.

• Accidental serialization in actions: Even if you do not persist the token, action payloads (e.g., fulfilled from createAsyncThunk) are serialized and recorded. Always strip the token from the action before dispatching if you must log it.

• Assuming Immer protects security: Immer’s proxy‑based “mutating” syntax in reducers is a convenience, not a security measure. It does not encrypt or isolate data.

In summary, the safest approach is to keep tokens completely outside Redux. If that is not possible, minimize exposure by disabling DevTools, avoiding persistence, and sanitizing all data that reaches DevTools or storage.

Assessing Necessity

Not all state belongs in Redux. Migrating unnecessarily adds indirection and boilerplate that harms maintainability.

Setting Up the Store

Replace the legacy createStore API with configureStore, which automatically sets up the Redux DevTools and includes useful middleware like redux-thunk by default. - configureStore: Simplifies store creation with good defaults and type safety. - createSlice: Generates action creators and reducers automatically based on provided logic. - createAsyncThunk: Handles asynchronous logic without the boilerplate of manual action types.

Incremental Integration

Do not refactor all components simultaneously. Wrap the app in <Provider> and migrate feature areas one by one to minimize risk. - Hooks API: Use useSelector and useDispatch in new components instead of the legacy connect() higher-order component. Hooks are cleaner and easier to test. - Coexistence: Allow legacy state management, such as Context API or class component state, to run alongside Redux during the transition. This prevents a big-bang rewrite failure. - Feature Slices: Build new features using RTK slices while gradually moving existing logic into the store. This ensures continuous delivery during migration.

Understanding Immutability

A common confusion is how reducers handle state changes. Inside createSlice, you can write “mutating” logic safely because Immer is used under the hood to produce new state objects. - Slice Reducers: Direct assignment like state.value = 1 is valid and safe within a slice. - Plain Reducers: If writing a reducer outside createSlice, you must return new objects immutably. - Selector Safety: Selectors should be pure functions to prevent unexpected side effects during rendering.

Common Pitfalls

• Over-normalization: Don’t store every piece of data globally; it increases complexity and debugging time.

• Stale Selectors: Ensure selectors memoize correctly with createSelector if derived data is expensive to compute.

• Legacy Mix-ups: Avoid mixing connect() and hooks in the same component tree unnecessarily, as it complicates debugging and testing.

How It Works

• The server creates a fresh store for each request using configureStore (the legacy createStore is deprecated and should not be used).

• Async logic runs through createAsyncThunk or RTK Query endpoints to populate the store before the HTML is generated.

• Reducers written with createSlice use Immer internally, so direct “mutations” such as state.items = action.payload are safe inside those reducers; plain Redux reducers outside a slice must still return new objects.

• After rendering, the server serializes the final state and embeds it in the HTML payload, commonly as a script variable or data attribute.

• On the client, a new store is created with configureStore({ preloadedState }), and React uses hydrateRoot to attach to the server-rendered markup.

Server and Client Flow

1. Request: A user hits an SSR route.

2. Store creation: The server instantiates a store with configureStore.

3. Data fetching: Required thunks are dispatched; slice reducers update state immutably via Immer.

4. Serialization: The resulting state is JSON-serialized, XSS-safe, and injected into the page. Sensitive fields must be stripped before this step.

5. Client bootstrapping: The browser reads the serialized blob from window and passes it to configureStore as preloadedState.

6. Rendering: hydrateRoot mounts React, and useSelector reads from the already-populated store without triggering a second network request for the same data.

Code Example

Server-side store preparation:

import { configureStore, createSlice, createAsyncThunk } from '@reduxjs/toolkit';

export const fetchItems = createAsyncThunk('data/fetchItems', async () => {
  const res = await fetch('https://api.example.com/items');
  return (await res.json()) as string[];
});

const dataSlice = createSlice({
  name: 'data',
  initialState: { items: [] as string[], loading: false },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchItems.fulfilled, (state, action) => {
        state.items = action.payload; // safe because Immer is active
        state.loading = false;
      })
      .addCase(fetchItems.pending, (state) => {
        state.loading = true;
      });
  },
});

const rootReducer = { data: dataSlice.reducer };
export type RootState = { data: ReturnType<typeof dataSlice.reducer> };

export const makeStore = (preloadedState?: unknown) =>
  configureStore({
    reducer: rootReducer,
    preloadedState: preloadedState as Partial<RootState> | undefined,
  });

// Server usage sketch:
// const store = makeStore();
// await store.dispatch(fetchItems());
// const html = renderToString(<Provider store={store}><App /></Provider>);
// const safeState = JSON.stringify(store.getState()).replace(/</g, '\\u003c');

Client entry using React-Redux hooks:

import { hydrateRoot } from 'react-dom/client';
import { Provider, useSelector, useDispatch } from 'react-redux';
import { makeStore, fetchItems } from './store';

declare global {
  interface Window {
    __PRELOADED_STATE__?: unknown;
  }
}

const store = makeStore(window.__PRELOADED_STATE__);

function App() {
  const items = useSelector(
    (state: ReturnType<typeof store.getState>) => state.data.items
  );
  const dispatch = useDispatch();

  return (
    <div>
      <button onClick={() => dispatch(fetchItems())}>Refresh</button>
      <ul>
        {items.map((item) => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

hydrateRoot(
  document.getElementById('root')!,
  <Provider store={store}>
    <App />
  </Provider>
);

Best Practices and Common Pitfalls

• Use configureStore and preloadedState: Never rely on the deprecated createStore; the modern API accepts the server state directly.

• Prefer hooks over connect(): New components should use useSelector and useDispatch from React-Redux; connect() remains only for legacy class components.

• Sanitize serialized state: Escape < characters in JSON before injection and omit secrets, tokens, or user-private data to prevent XSS and data leakage.

• Handle non-serializable values: Date, Map, Set, and class instances do not survive JSON.stringify cleanly; normalize them to plain objects or ISO strings before hydration.

• RTK Query hydration: If you use RTK Query, its cached responses live in the API slice reducer and are automatically included when you pass the full server state as preloadedState.

• Know when Redux is unnecessary: For client-only ephemeral UI state, plain useState or React Context is simpler. For remote server data in a SPA, RTK Query or another server-state library can often eliminate manual hydration entirely.

Common Integration Challenges

Legacy applications often rely on component state or context APIs, leading to conflicting sources of truth that cause synchronization bugs. Developers may also struggle with verbose boilerplate from legacy Redux patterns, such as manual action type constants and switch-case reducers. Additionally, team members unfamiliar with functional programming concepts may find the learning curve steep, especially regarding pure functions and immutability. Debugging tools like Redux DevTools must also be configured correctly to trace actions across mixed state systems.

Incremental Adoption Strategy

Avoid rewriting the entire state management layer at once. Instead, introduce configureStore alongside existing state mechanisms, enabling middleware like thunk or logger without disrupting current flows. New features should use Redux slices, while legacy components remain untouched until refactored. This hybrid approach reduces risk and allows gradual migration of state logic into the store without breaking existing functionality or requiring simultaneous deployment across all teams.

Immutability and Reducer Logic

With Redux Toolkit, reducers use Immer internally, allowing developers to write mutating logic safely within createSlice. However, this safety does not extend outside slices; plain reducers or manual state updates must still return new objects to trigger re-renders. Understanding this distinction prevents accidental mutations that break change detection in React components. Developers must remember that standard JavaScript objects passed into slices are drafted by Immer, but values returned from selectors remain plain data.

When Redux Is Unnecessary

Redux adds indirection and complexity that may not justify the benefits for simple use cases. Local component state is sufficient for form inputs or UI toggles, while React Context works well for theme or authentication data that changes infrequently. Server-state libraries like RTK Query or React Query are preferred for caching API responses rather than storing them in the Redux slice manually. Evaluating the scope of state sharing across components should always precede the decision to add Redux to the dependency list.

Best Practices and Pitfalls

Prefer useSelector and useDispatch hooks over the legacy connect() higher-order component, as hooks simplify testing and reduce wrapper hell. Normalize nested state to avoid duplication and ensure selectors remain performant when data structures grow. Avoid storing transient UI state or large binary data in the store, as this increases serialization costs. Finally, ensure the store is provided via Provider at the root level so hooks can access the context throughout the component tree, and use TypeScript interfaces to define state shapes for compile-time safety.

Current Direction of the Ecosystem

• Redux Toolkit is the default: configureStore is the standard store setup API; the original Redux createStore is deprecated for new code and replaced by configureStore.

• Feature slices replace hand-written action/reducer pairs: createSlice generates action creators and reducers together and is the normal way to model feature state.

• React integration uses hooks: React-Redux code normally uses useSelector and useDispatch; connect() remains available but is the older API.

• TypeScript is mainstream: RTK and React-Redux are designed for strong typing, including typed dispatch and typed selector hooks.

• Server data is separated from client state: createAsyncThunk remains useful for one-off async flows, but RTK Query’s createApi with fetchBaseQuery is the recommended pattern for fetching, caching, and invalidating server data.

Immutability and Reducer Style

• Inside createSlice, reducers may look “mutating” because RTK uses Immer internally; for example, state.value += 1 is safe inside a slice reducer.

• That safety does not extend to plain reducers, middleware, or selectors; do not mutate existing state there. Plain reducers must return new state objects.

• Derived values should be computed with memoized selectors rather than duplicated in multiple slices.

When Redux Is Needed and When It Is Not

Redux is often unnecessary for local UI state, simple app-wide settings, or server-cache management.

Common Community Practices

• Feature-based organization: use one slice per domain, grouping reducer logic with its generated actions, instead of separate files for every action type.

• Normalized collections: use createEntityAdapter when entities are referenced by ID across features.

• RTK Query endpoints: use them for standard CRUD and cache behavior instead of hand-writing every request thunk.

• Keep built-in tooling enabled: leave the DevTools setup and development-time serializable/immutability checks enabled through configureStore.

• Memoized selectors: create selectors with createSelector to avoid unnecessary recalculations and re-renders.

Common Pitfalls

• Starting new projects with deprecated createStore or the older connect() API instead of configureStore and hooks.

• Mutating state outside createSlice, where Immer protection is absent.

• Duplicating server responses into multiple slices instead of using RTK Query or another server-state layer.

• Putting ephemeral form state or modal visibility into the global store.

How Redux Has Repositioned Itself

• Redux Toolkit: the official, batteries-included way to write Redux; it removes manual action constants, repetitive immutable-update code, and complex store setup.

• createSlice: colocalizes reducers and action creators for one feature; its reducers may look “mutating” because Immer produces safe immutable updates.

• createAsyncThunk: standardizes async request state by dispatching pending, fulfilled, and rejected actions automatically.

• RTK Query: adds built-in data fetching, caching, deduplication, and cache invalidation, reducing the need to hand-roll server-state reducers.

• React-Redux hooks: useSelector and useDispatch are the modern integration path for function components; connect() is the older API.

• createStore: deprecated for new applications; use configureStore instead.

Why Redux Still Matters

Redux remains valuable when an application has complex, cross-cutting client state, many actors updating the same data, strict debugging requirements, or a large team that benefits from strong conventions. Its unidirectional flow, middleware ecosystem, DevTools support, and time-travel debugging are still hard to replace in enterprise-scale frontends. Redux Toolkit also answers much of the historical criticism that Redux was too verbose compared with libraries such as Zustand or Jotai.

When Redux Is Not Needed

Redux is often unnecessary when the state is local, short-lived, or mostly server-owned.

Likely Trajectory

Redux will probably not be the default for every small new app, but it remains a mature choice for complex applications and teams that need explicit structure. Its future depends on Redux Toolkit continuing to reduce boilerplate and on RTK Query making server-state management easier, rather than on replacing every emerging state-management library.

Practical Guidance

• Start with local component state, then lift state only when multiple distant components need it.

• If the app is mostly CRUD data, evaluate RTK Query or another server-state library before creating many slices.

• Keep server state and client state separate; do not duplicate API responses into ordinary Redux state without a caching strategy.

• Only mutate draft state inside createSlice reducers or Immer’s produce; plain reducers must return new objects.

• Prefer useSelector and useDispatch in new React code; migrate older connect() components gradually.

Derived Data and Selectors

• Derived data: Selectors read state and return filtered, sorted, or aggregated values without writing to the store.

• Memoization: createSelector from Reselect, re-exported by RTK, caches results and recomputes only when its input selectors change, preventing expensive recalculations on unrelated state updates.

• Composition: Selectors can call other selectors, forming a dependency graph. Each layer recomputes only when its own inputs change, making it practical to derive summaries, grouped lists, or computed fields from large normalized state.

• RTK Query selectors: RTK Query endpoints expose selector functions, such as api.endpoints.getUser.select(id), which can be combined with createEntityAdapter selectors to consume derived server state without manual selector boilerplate.

Handling Async Dependencies

• createAsyncThunk: Encapsulates async logic outside components and dispatches pending, fulfilled, and rejected actions. Use it for client-side async workflows or API calls that do not need RTK Query’s caching.

• RTK Query: Preferred for server state because it handles caching, invalidation, background refetching, and component-based subscription automatically. Its generated selectors and hooks reduce boilerplate for derived server data.

• extraReducers: Slices respond to thunk or RTK Query actions through extraReducers, keeping state updates colocated with the slice that owns the data.

State Structure and Normalization

• Immutability with Immer: createSlice reducers can use mutating syntax like state.entities[id] = action.payload; Immer converts it to an immutable update. Do not mutate state in thunks, selectors, or plain reducers.

• Entity relationships: createEntityAdapter stores records in a keyed entities object and maintains a sorted ids array. It provides adapters such as addOne, updateOne, removeOne, and setAll, plus selectors like selectById and selectAll. This avoids duplication, makes updates predictable, and simplifies joins between related entities such as users and posts.

• Flat, normalized shape: Keep state shallow and reference related entities by ID rather than nesting copies. Selectors then assemble the shape a component needs.

Comparison of Strategies

Best Practices and Pitfalls

• Avoid deep nesting: Flat state makes selectors simpler and reduces coupling between slices.

• Do not put everything in Redux: Local UI state such as form inputs and toggles belongs in React useState; data needed by only a few components may suit React Context. Redux is best for global, frequently accessed, or complex state.

• Use hooks, not legacy APIs: Use configureStore, createSlice, useSelector, and useDispatch. createStore and connect() are legacy and should be avoided.

• Prevent selector cycles: Ensure selectors do not form circular dependencies that cause infinite recomputation.

• Type safety: TypeScript improves inference for slices, thunks, and generated RTK Query hooks.

• Choose the right async tool: Prefer RTK Query for server state; reserve thunks for complex client-side logic that falls outside the server-state model.

Type Safety with Redux Toolkit

Redux Toolkit (RTK) infers types automatically from createSlice definitions, eliminating the need for manual action type strings. When defining reducers, use PayloadAction<T> to type the payload passed with each action. The store’s root state type is inferred with ReturnType<typeof store.getState>, and the dispatch type is captured as typeof store.dispatch; exporting these as RootState and AppDispatch lets you type useSelector and useDispatch so mismatched payload shapes are caught at compile time.

Immutability and State Consistency

Inside createSlice reducers, you can write code that looks like mutation because RTK uses Immer under the hood. Immer produces a new state object structurally, preserving consistency. However, in plain reducers or outside slices, strict immutability is required; never mutate state directly. Serializability is enforced by default via the serializable middleware (enabled in all environments), warning when non-serializable values (like functions or Promises) enter the state tree. This guarantees that state remains predictable and compatible with debugging tools like Redux DevTools.

When Redux Isn’t Needed

Before reaching for Redux, evaluate if the state truly needs global accessibility. Local component state via useState is sufficient for UI toggles or form inputs. React Context works well for theme settings or authentication status that rarely change. For server-state management, RTK Query or libraries like TanStack Query handle caching and loading states more effectively than manual Redux thunks. Using Redux for everything adds unnecessary complexity and indirection, potentially harming performance and maintainability.

Code Example

The following demonstrates a typed slice, store configuration, component usage with hooks, and the required Provider wrapper.

import { createSlice, configureStore, PayloadAction } from '@reduxjs/toolkit';
import { Provider, useSelector, useDispatch } from 'react-redux';

interface CounterState {
  value: number;
}

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 } as CounterState,
  reducers: {
    incremented: (state) => {
      // Safe mutation via Immer
      state.value += 1;
    },
    payloadIncremented: (state, action: PayloadAction<number>) => {
      state.value += action.payload;
    },
  },
});

const store = configureStore({
  reducer: { counter: counterSlice.reducer },
});

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

const { incremented } = counterSlice.actions;

const CounterComponent = () => {
  const count = useSelector((state: RootState) => state.counter.value);
  const dispatch = useDispatch<AppDispatch>();

  return (
    <div>
      <span>{count}</span>
      <button onClick={() => dispatch(incremented())}>Increment</button>
    </div>
  );
};

// Wrap the app with Provider so hooks can access the store
const App = () => (
  <Provider store={store}>
    <CounterComponent />
  </Provider>
);

Best Practices and Pitfalls

• Normalize State: Keep state flat and normalized to avoid duplication and consistency bugs.

• Avoid Non-Serializable Values: Do not store class instances, functions, or Promises in state.

• Use Hooks: Prefer useSelector and useDispatch over the legacy connect() HOC for cleaner components.

• Slice Logic: Keep reducer logic pure and synchronous; handle side effects with createAsyncThunk or RTK Query.

• DevTools: Enable Redux DevTools in development to trace actions and verify state transitions visually.

Core Mechanism

The standard pattern divides the state into three parts: past, present, and future. When a user performs an action that should be undoable, the current present state is pushed onto past, and the new result becomes present. The future array is cleared. Undoing pops the last item from past into present and pushes the old present into future. Redo does the reverse. This structure ensures deterministic state transitions without needing complex diffing algorithms.

Common Approaches

• Custom history slice: Build a dedicated reducer using createSlice that wraps your domain state in past, present, and future. Because Redux Toolkit uses Immer internally, you can write reducer logic that appears to mutate these arrays safely within the slice. This gives full control over which actions are recorded, how deep the history goes, and how memory is bounded.

• Higher-order reducers: Libraries such as redux-undo wrap your reducers and automatically track history for specified action types. This reduces boilerplate but introduces an extra abstraction layer. redux-undo is compatible with Redux Toolkit and combineReducers; it is not limited to legacy Redux patterns.

• RTK Query and server state: If the undoable data lives on the server, avoid persisting every intermediate step in global Redux history. Instead, use RTK Query optimistic updates and let the server be the source of truth, reversing the local cache only when a request fails.

React Integration

Access state and dispatch actions with the React-Redux hooks useSelector and useDispatch rather than the legacy connect(). Select the present value for rendering and bind buttons to dispatch undo or redo actions. This keeps the UI decoupled from the history logic and makes the store topology easier to test.

When Redux Is Not Needed

Before adding undo/redo to Redux, evaluate if the state truly needs to be global. For local form inputs or transient UI interactions, React’s useState or useReducer hook is sufficient and avoids global store pollution. Use Redux only when the undoable state is shared across many components or needs to survive route changes.

Approach Comparison

Best Practices and Pitfalls

• Limit History Depth: Unbounded history arrays grow indefinitely. Implement a maximum length in your reducer to cap memory usage.

• Serializable State: Ensure state snapshots are serializable. Avoid storing class instances, functions, or DOM nodes in past or future.

• Performance: Deep cloning large state objects on every commit can be costly. Structure your state so only the relevant subtree is tracked by the history slice.

• Immer Safety: Remember that mutating logic is safe only inside createSlice reducers. If you implement history logic outside slices (e.g., in middleware), you must return new objects immutably.

• Action Filtering: Not every action should be recorded. Filter high-frequency or irrelevant actions to keep the history meaningful.

Dividing Responsibilities

• Avoid duplication: Do not copy API responses into regular slices; read them directly from the RTK Query cache.

Local State with createSlice and Immer

createSlice uses Immer, so you can write “mutating” code inside its reducers and Immer produces the next immutable state object safely. This convenience does not apply to hand-written reducers outside createSlice, which must still use immutable patterns like spread operators. React-Redux’s useSelector and useDispatch hooks are the current standard for connecting components; the legacy connect() higher-order component is still available but not recommended for new code.

Server State with RTK Query

RTK Query replaces manual createAsyncThunk boilerplate for typical CRUD operations. - Declare endpoints with createApi and fetchBaseQuery. - Use generated hooks such as useGetPostsQuery and useAddPostMutation for data, isLoading, error, and refetch. - Use providesTags and invalidatesTags to refetch affected data automatically after mutations. - Reserve createAsyncThunk for non-CRUD side effects that fall outside normal endpoint definitions.

When Redux Isn’t Needed

• Ephemeral component state: use useState for input values, toggles, and other data that dies with the component.

• Infrequently changing app-wide state: React Context is often simpler than adding a global store.

• If Redux is used only for server state: a dedicated library such as TanStack Query may be lighter, but inside an existing Redux application RTK Query is the officially recommended choice.

Code Example

// store.ts
import { configureStore, createSlice } from '@reduxjs/toolkit';
import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

export interface Post { id: string; title: string; }

export const uiSlice = createSlice({
  name: 'ui',
  initialState: { sidebarOpen: false },
  reducers: {
    toggleSidebar: state => {
      state.sidebarOpen = !state.sidebarOpen; // safe Immer mutation
    },
  },
});

export const apiSlice = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: 'https://api.example.com/' }),
  tagTypes: ['Post'],
  endpoints: builder => ({
    getPosts: builder.query<Post[], void>({
      query: () => 'posts',
      providesTags: ['Post'],
    }),
    addPost: builder.mutation<Post, Partial<Post>>({
      query: body => ({ url: 'posts', method: 'POST', body }),
      invalidatesTags: ['Post'],
    }),
  }),
});

export const {
  useGetPostsQuery,
  useAddPostMutation,
} = apiSlice;

export const store = configureStore({
  reducer: {
    ui: uiSlice.reducer,
    [apiSlice.reducerPath]: apiSlice.reducer,
  },
  middleware: gDM => gDM().concat(apiSlice.middleware),
});

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

// Posts.tsx
import { useDispatch, useSelector } from 'react-redux';
import { useGetPostsQuery, useAddPostMutation, uiSlice, type RootState } from './store';

function Posts() {
  const dispatch = useDispatch();
  const sidebarOpen = useSelector((state: RootState) => state.ui.sidebarOpen);
  const { data: posts, isLoading } = useGetPostsQuery();
  const [addPost] = useAddPostMutation();

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

  return (
    <div>
      <button onClick={() => dispatch(uiSlice.actions.toggleSidebar())}>
        {sidebarOpen ? 'Close' : 'Open'} Sidebar
      </button>
      {posts?.map(p => <article key={p.id}>{p.title}</article>)}
    </div>
  );
}

Best Practices and Common Pitfalls

• Do not store server data in createSlice unless you are transforming it; RTK Query already caches responses and handles refetching.

• Normalize cache tags carefully: over-invalidation causes excessive network requests, while under-invalidation leaves stale UI.

• Keep Immer mutations inside createSlice: applying the same “mutating” style to plain reducers will silently break immutability checks and React re-rendering.

• Prefer RTK Query over ad-hoc thunks for standard API interactions, because it reduces boilerplate and centralizes cache lifecycle management.