100 Redux Interview Questions & Answers

Redux is a predictable state container — a single, centralized store holding an application's entire state, updated only through dispatched actions handled by pure reducer functions. It's used (most commonly alongside React, though it's framework-agnostic) when an application's state is complex enough, or shared across enough distant components, that prop-drilling or scattered local state becomes genuinely hard to reason about.

{ type: "todos/add", payload: { text: "Buy milk" } }

An action is a plain JavaScript object describing something that happened — a required type field (conventionally a string) identifying what kind of event it is, plus any additional data (usually under payload) the reducer needs to compute the new state.

store.dispatch({ type: "todos/add", payload: { text: "Buy milk" } });
// The store runs the root reducer with (currentState, action), replacing state with whatever it returns

Dispatching an action is the only entry point for changing state — the store passes the action (and the current state) to the reducer, and whatever the reducer returns becomes the new state, triggering a re-render of any subscribed UI.

function todosReducer(state = [], action) {
  switch (action.type) {
    case "todos/add":
      return [...state, action.payload];
    default:
      return state;   // unknown action — return state unchanged
  }
}

A reducer is a pure function — (previousState, action) => newState — with no side effects, no mutation of its arguments, and no randomness/dates/API calls inside it. Purity is what makes Redux state predictable and enables features like time-travel debugging, since replaying the same actions against the same starting state always produces the same result.

Local state is the right default for anything genuinely local to one component/subtree; Redux earns its overhead when state is truly shared across many unrelated parts of the app, or when you want strict, centralized, inspectable state transitions.

import { configureStore } from "@reduxjs/toolkit";
const store = configureStore({ reducer: rootReducer });

store.getState();
store.dispatch(someAction);
store.subscribe(() => console.log("state changed"));

The store holds the application's entire state tree, and exposes getState() (read the current state), dispatch(action) (the only way to change it), and subscribe(listener) (react to changes) — it's a single object per application, not one per feature/component.

Every piece of shared application state lives in exactly one place — the store — rather than duplicated or synchronized across multiple components' local state. This eliminates an entire category of bugs where two copies of "the same" data drift out of sync with each other.

// Wrong — mutates the existing array
state.push(newTodo);
return state;

// Correct — returns a NEW array, leaving the original untouched
return [...state, newTodo];

Immutability means a reducer never modifies the existing state object — it always returns a new one. This matters because React-Redux (and Redux DevTools' time-travel) detect changes via reference equality — if state were mutated in place, the reference wouldn't change, and connected components would never know to re-render.