Redux with React: Missing Cart Items from Async Thunks

State management is the silent killer of React applications at scale. A cart component needs to know if the user is logged in. A header needs the cart count. A checkout page needs both. Prop-drilling turns your component tree into a telephone game, and React Context re-renders everything that consumes it whenever anything changes. At some point, you need a disciplined, predictable system — and that is exactly why Redux exists.

Redux solves a specific, hard problem: how do you make state changes predictable and traceable in a large application with many actors reading and writing to shared state? It enforces a unidirectional data flow — state only changes through dispatched actions, processed by pure reducer functions — making every state transition auditable, time-travelable, and testable in isolation. That is not just architecture astronautics; it is the difference between a bug you can reproduce in 30 seconds versus one you chase for three days.

By the end of this article you will understand how the Redux store actually works under the hood, why useSelector is deceptively tricky in production, how Redux Toolkit eliminates the boilerplate without hiding the model, and how to structure a real feature slice in a way that will not embarrass you in a code review. We will also cover the performance traps that bite even experienced engineers and the questions interviewers use to separate people who have read the docs from people who have shipped with Redux.

Here's the thing: Redux isn't magic. It's a handful of simple patterns executed well. The complexity appears when you don't follow them.

How Redux with React Manages State Across Components

Redux with React is a state management pattern where a single JavaScript object tree (the store) holds all application state, and React components read slices of that state via selectors. The core mechanic is unidirectional data flow: components dispatch actions, reducers compute new state immutably, and React re-renders only the components that depend on changed state. This eliminates prop drilling and gives you a predictable, debuggable state lifecycle.

In practice, Redux uses a centralized store, pure reducer functions, and middleware like Redux Thunk for async logic. The store is created once and passed to the React tree via a Provider component. Components use hooks like useSelector and useDispatch to read state and trigger updates. The key property is that state transitions are explicit and replayable — every action is a plain object, every reducer is a pure function, making time-travel debugging and logging trivial.

Use Redux with React when multiple components share state that changes frequently, or when you need a single source of truth for complex data flows like authentication, shopping carts, or real-time dashboards. It matters in production because it enforces discipline: state mutations are centralized, side effects are isolated in middleware, and performance is optimized via memoized selectors. For apps with moderate to high state complexity, Redux prevents the spaghetti of scattered setState calls and context re-renders.

The Redux Store: Architecture and Internal Data Flow

The store is created with createStore(reducer, preloadedState, enhancer) (legacy) or configureStore from Redux Toolkit. Under the hood, the store holds the current state tree, exposes getState(), dispatch(action), and subscribe(listener). When you dispatch an action, the store calls the root reducer with the current state and the action, receives the new state, and notifies all subscribers. React-Redux uses subscribe internally to force re-renders of connected components. The enhancer parameter (applied via applyMiddleware) wraps dispatch to allow middleware chains — each middleware intercepts actions before they reach the reducer.

Modern Redux Toolkit (RTK) uses configureStore which automatically combines reducers, adds middleware (including redux-thunk by default), and enables the Redux DevTools. It also uses Immer inside createSlice to let you write mutable-looking reducer logic that gets converted to immutable updates.

One detail most docs skip: configureStore wraps the middleware array with getDefaultMiddleware(). If you replace the middleware array entirely without including the defaults, you lose thunk support and the serializable check. Teams have shipped to production without realising they dropped async dispatch support — the app ran but thunks silently failed. Always spread defaults: middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(customMiddleware).

Another subtlety: the order of middleware matters. If you insert a logger before thunk, you'll see the action twice — once when the thunk function is dispatched, and again when the thunk dispatches internal actions. For error handling, you want your error middleware after thunk so it catches async errors too.

I've seen a team spend a day debugging why their thunk actions weren't triggering API calls — they had accidentally overridden the default middleware with an empty array. That's the kind of silent failure that makes you check the middleware config first on every new store setup.

// io.thecodeforge.redux.config
import { configureStore, createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: (state) => { state.value += 1; },
    decrement: (state) => { state.value -= 1; },
    incrementByAmount: (state, action) => { state.value += action.payload; },
  },
});

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

export const store = configureStore({
  reducer: {
    counter: counterSlice.reducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(logger),
});

useSelector: How It Works and Why It Re-renders

useSelector(selector, equalityFn) subscribes the component to the store. On every dispatch, React-Redux runs the selector function with the current store state. If the result differs from the previous result (by default using === reference equality), the component re-renders. This is where most performance bugs originate. Creating new arrays or objects inside the selector on every call — useSelector(state => state.items.filter(...)) — produces a new reference every time, causing infinite re-renders even if the underlying data hasn't changed.

The fix is to either memoize the derived data with createSelector from Reselect, or use shallow equality by passing shallowEqual as the second argument. For simple leaf values (state.counter.value), reference equality works fine. But for derived data, always memoize.

React-Redux v8+ uses useSyncExternalStore under the hood, which is more efficient and avoids tearing during concurrent rendering.

Here's the trap that catches teams new to hooks: passing a function reference as the selector argument directly inside the component creates a new function on every render. That's fine for React-Redux because it uses the selector itself to compute values. But the real problem is when the selector returns a new reference. Slice selectors that return parts of the state tree from nested objects can also cause issues if you return a sub-object directly — it's still the same reference unless you spread. Use shallowEqual if you must return an object: useSelector(state => ({ name: state.user.name, age: state.user.age }), shallowEqual).

One more nuance: if you select from deeply nested state without memoization, your component re-renders even when a completely unrelated slice changes. That's why you should keep selectors as granular as possible. Think of it like a SQL query — select only the columns you need.

A common debugging trick: add a console.log inside the component body to see how often it renders. If it logs on every store dispatch, your selector is problematic. I've seen a list component re-render 100 times for a single state change because the selector was returning a new array — the fix was a one-line createSelector.

import { useSelector, useDispatch, shallowEqual } from 'react-redux';
import { increment } from './store';

function Counter() {
  const value = useSelector(state => state.counter.value);
  const dispatch = useDispatch();
  return (
    <div>
      <span>{value}</span>
      <button onClick={() => dispatch(increment())}>+</button>
    </div>
  );
}

// BAD: new array on every render
const items = useSelector(state => state.todos.filter(t => t.completed));

// GOOD: memoized selector
import { createSelector } from '@reduxjs/toolkit';
const selectCompletedTodos = createSelector(
  state => state.todos,
  todos => todos.filter(t => t.completed)
);
const items = useSelector(selectCompletedTodos);

Middleware: Handling Side Effects with Thunks and Sagas

Redux middleware intercepts every dispatched action before it reaches the reducer. This is where side effects — API calls, timers, logging — belong. The most common middleware is Redux Thunk (included with RTK). A thunk is a function that returns another function with (dispatch, getState) parameters. You can dispatch multiple actions from within a thunk to handle loading states.

Redux Saga (a separate middleware) uses ES6 generators for more complex orchestration. It can watch for actions, fork tasks, cancel them, and handle race conditions. Sagas are powerful but add another layer of abstraction. For 90% of apps, thunks are sufficient.

RTK Query (part of RTK) eliminates the need for hand-written thunks for data fetching. It auto-generates hooks like useGetPostsQuery and manages caching, loading states, and cache invalidation out of the box.

A hidden cost of sagas: every saga runs on the main thread. A long-running saga that blocks can freeze the UI if not properly yielded. Also, sagas are hard to type — the generator yield types are not checked by TypeScript in the same way as thunks. If your team struggles with debugging, thunks plus RTK Query are usually the safer bet.

Something I've seen multiple times: teams use takeLatest for search but forget to cancel the underlying HTTP call. The user types 'ab', the first request goes out, then 'abc' triggers a new one. The first response arrives after the second, overwriting the correct result. That's a classic race condition. With sagas you can cancel the first request's generator, but the browser's fetch is still in flight. Always pair with AbortController.

Another trap: dispatching a synchronous action inside a thunk before the async call is fine, but be careful not to dispatch too many actions in a single thunk — each dispatch triggers a full store update and subscriber cycle. Batch related updates into a single action if possible.

// io.thecodeforge.redux.thunk
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit';
import { api } from './api';

export const fetchUser = createAsyncThunk(
  'users/fetchById',
  async (userId, { rejectWithValue }) => {
    try {
      const response = await api.get(`/users/${userId}`);
      return response.data;
    } catch (err) {
      return rejectWithValue(err.response.data);
    }
  }
);

const userSlice = createSlice({
  name: 'user',
  initialState: { entity: null, loading: 'idle', error: null },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchUser.pending, (state) => { state.loading = 'loading'; })
      .addCase(fetchUser.fulfilled, (state, action) => {
        state.loading = 'idle';
        state.entity = action.payload;
      })
      .addCase(fetchUser.rejected, (state, action) => {
        state.loading = 'idle';
        state.error = action.payload;
      });
  },
});

export default userSlice.reducer;

Redux Toolkit: Why It’s the Standard and How It Works

Redux Toolkit (RTK) is the officially recommended way to write Redux logic. It wraps createStore with sensible defaults: combined reducers, built-in thunk middleware, DevTools enabled, and Immer integration. createSlice auto-generates action creators and action types from a reducer map, drastically reducing boilerplate. createAsyncThunk standardizes the pattern for async requests with pending/fulfilled/rejected states.

RTK also introduces createReducer which uses Immer under the hood so you can write mutable logic that becomes immutable automatically. This eliminates the most common source of bugs: forgetting to spread or copy state.

RTK Query, an optional add-on, eliminates the need for any manual action creators, reducers, or selectors for API calls. It generates hooks that manage caching, polling, optimistic updates, and cache invalidation based on tag systems.

One underappreciated feature: RTK Query's tag-based invalidation lets you express complex refetch rules without manual logic. For example, a 'Post' tag can be invalidated after a 'like' mutation, triggering a refetch of the post list. This avoids stale data without polling. But beware of over-invalidation — if you invalidate too broadly, you refetch everything on every mutation, killing performance.

Another practical tip: RTK's createAction and createReducer are great for migrating legacy Redux code incrementally. You don't have to rewrite everything at once — you can adopt slice by slice.

I've migrated a large codebase from legacy createStore to RTK piece by piece. The key is to start with configureStore and then replace one reducer at a time with createSlice. No big bang, no breaking everything at once.

// io.thecodeforge.redux.rtkquery
import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

export const apiSlice = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  tagTypes: ['Post'],
  endpoints: (builder) => ({
    getPosts: builder.query({
      query: () => '/posts',
      providesTags: ['Post'],
    }),
    addPost: builder.mutation({
      query: (newPost) => ({
        url: '/posts',
        method: 'POST',
        body: newPost,
      }),
      invalidatesTags: ['Post'],
    }),
  }),
});

export const { useGetPostsQuery, useAddPostMutation } = apiSlice;

Common Production Pitfalls with Redux

Even with tooling, teams hit recurring issues. Here are the patterns that cause the most outages:

1. State mutation inside reducers — even with spread operators, deep nested updates are error-prone. Solution: use createSlice (Immer) or manual deep cloning.
2. Blindly using useSelector with inline functions — every render creates a new function, but the real problem is when the selector returns a new reference (like filtering). Solution: memoize with createSelector.
3. Dispatching too many actions synchronously — each dispatch triggers a store update and re-render of all subscribers. Batch related dispatches with unstable_batchedUpdates or use middleware to batch.
4. Storing non-serializable data — functions, Promises, or class instances in store break time-travel and persistence. Keep the store serializable.
5. Over-normalization — flattening state too aggressively leads to complex joins in selectors. Sometimes a relational structure inside Redux is acceptable.
6. Ignoring the serializable check middleware — RTK enables it by default in development. Warnings about non-serializable values are easy to dismiss, but they cause silent failures in production when DevTools or persistence middleware tries to stringify the state. Treat those warnings as errors.
7. Not splitting reducers into slices — a single monolithic reducer becomes a nightmare to maintain. Use combineReducers or configureStore's reducer object from day one.

Here's a real one: I worked with a team that ignored the serializableCheck warnings for weeks. Then they added redux-persist and the app crashed on page reload because functions were being serialized. Those warnings are not suggestions — they're early warning systems for production failures.

// BAD: inline function returning new reference
useSelector(state => state.items.filter(item => item.active));

// GOOD: memoized selector
const selectActiveItems = createSelector(
  state => state.items,
  items => items.filter(item => item.active)
);
useSelector(selectActiveItems);

// BAD: storing Date object
// store.dispatch({ type: 'SET_DATE', payload: new Date() });

// GOOD: store timestamp number
store.dispatch({ type: 'SET_DATE', payload: Date.now() });

// BAD: three sequential dispatches causing three re-renders
// dispatch({ type: 'INIT' });
// dispatch({ type: 'PROCESS' });
// dispatch({ type: 'COMPLETE' });

// GOOD: batch into one dispatch
// dispatch({ type: 'BATCHED_UPDATE', payload: { step: 'complete' } });

Testing Redux in Production

Redux logic is pure — that makes it extremely testable. But teams often skip tests for reducers, thunks, and selectors, assuming they work. That assumption costs hours in production.

Reducer tests: Pure functions. Test that given an initial state and an action, the new state is correct. Use createReducer or createSlice and test the exported reducer directly.

Thunk tests: Use a mock store created with configureStore and mock API calls. Dispatch the thunk and assert that the correct actions were dispatched (pending, fulfilled, rejected). Use createAsyncThunk with a mock API to control timing.

Selector tests: Memoized selectors are also pure. Call them with different state shapes and verify the derived value.

Component integration tests: Use Provider with a real store and render from React Testing Library. Dispatch initial state, then assert the UI renders correctly. For async flows, use waitFor to wait for state updates.

One pattern that fails in production: integration tests that reuse the same mock store across tests. If you don't reset the store between tests, state leaks. Create a fresh store for each test using a setupStore function.

Another nuanced point: when testing thunks that dispatch other thunks, you should test those as integration tests rather than mocking the inner thunk. Otherwise you're testing the mock, not the real flow.

I once saw a test suite that passed locally every time but failed in CI 30% of the time — the culprit was a shared store instance. Switching to per-test stores fixed it completely.

// io.thecodeforge.redux.test
import { configureStore } from '@reduxjs/toolkit';
import { fetchUser } from './userSlice';
import { api } from './api';

// Mock the API module
jest.mock('./api', () => ({
  api: {
    get: jest.fn(),
  },
}));

const setupStore = () =>
  configureStore({
    reducer: {
      user: userReducer,
    },
  });

describe('fetchUser thunk', () => {
  it('dispatches pending and fulfilled actions on success', async () => {
    api.get.mockResolvedValue({ data: { id: 1, name: 'Alice' } });
    const store = setupStore();
    await store.dispatch(fetchUser(1));
    const actions = store.getActions();
    expect(actions[0].type).toEqual(fetchUser.pending.type);
    expect(actions[1].type).toEqual(fetchUser.fulfilled.type);
    expect(actions[1].payload).toEqual({ id: 1, name: 'Alice' });
  });
});

Selectors: The Memoization Trap That Sinks Performance

Most devs think useSelector is free. It's not. Every time you call it, React-Redux runs the selector function and compares the result to the previous one using strict equality. If you return a new object or array on every call, you trigger a re-render. This is why you see components flickering when nothing changed. The fix is memoized selectors. Reselect (now bundled into Redux Toolkit's createSelector) caches the last input and output. Only recompute when the input slice changes. But here's the trap: if your selector returns a derived value that's expensive to compute, like filtering a 10K-item list, and you don't memoize, you're recalculating on every state change across the entire app. That's a silent CPU killer. Always use createSelector when deriving data. Never return inline objects or arrays from a selector unless you want a re-render party.

// io.thecodeforge — javascript tutorial

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

// Bad: returns a new array every time
const selectUnpaidInvoicesUnmemoized = (state) =>
  state.invoices.filter(inv => !inv.paid);

// Good: memoized selector, only recomputes when invoices changes
const selectUnpaidInvoices = createSelector(
  [state => state.invoices],
  (invoices) => invoices.filter(inv => !inv.paid)
);

// Usage in component — no unnecessary re-renders
const unpaid = useSelector(selectUnpaidInvoices);

// Edge case: selector with multiple inputs
const selectOverdueAccounts = createSelector(
  [state => state.invoices, state => state.thresholdDays],
  (invoices, threshold) => invoices.filter(
    inv => !inv.paid && daysSinceDue(inv) > threshold
  )
);

Slice Cohesion: Why Your Reducers Are Bloody Mess

You've seen it: a single reducer handling user auth, shopping cart, and notification preferences. That's a rookie mistake. The entire point of Redux's architecture is separation of concerns via slices. Each slice should own a single domain of your application state. If you find yourself writing a reducer that checks action types from three different domains, you've created a god reducer. It's untestable, unreadable, and will break in production. Redux Toolkit's createSlice enforces this by scoping reducers to a slice name. But the design still depends on you. Keep slices small. One slice per feature or data domain. createSlice auto-generates action creators. Use those. Never dispatch raw action types across slices unless you're handling cross-cutting concerns like auth logout that reset state. When you do need cross-slice logic, use extraReducers to listen to actions from other slices. This keeps reducers pure and predictable.

// io.thecodeforge — javascript tutorial

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

// Profile slice — owns user profile data only
const profileSlice = createSlice({
  name: 'profile',
  initialState: { name: '', email: '', loaded: false },
  reducers: {
    setProfile(state, action) {
      state.name = action.payload.name;
      state.email = action.payload.email;
      state.loaded = true;
    },
  },
});

// Cart slice — owns cart items, nothing else
const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [], total: 0 },
  reducers: {
    addItem(state, action) {
      state.items.push(action.payload);
      state.total += action.payload.price;
    },
    clearCart(state) {
      state.items = [];
      state.total = 0;
    },
  },
  // Cross-slice: clear cart when user logs out
  extraReducers: (builder) => {
    builder.addCase('auth/logout', (state) => {
      state.items = [];
      state.total = 0;
    });
  },
});

export const { setProfile } = profileSlice.actions;
export const { addItem, clearCart } = cartSlice.actions;