Top 60 Redux Interview Questions (2026)

Redux is a predictable state container for JavaScript apps. It keeps your application state in one central store and lets you change it only by dispatching actions, which pure reducer functions handle. Because every change goes through the same explicit path, you can trace, log, and replay exactly how state got to where it is.

The problem it solves is shared state that many components read and write. Without a central store, that state gets scattered, passed through deep prop chains, and hard to trace. Redux makes every change explicit and debuggable.

Single source of truth: the whole app state lives in one store. Read-only state: you never mutate it directly, you dispatch an action to describe a change. Changes with pure functions: reducers are pure functions that take state and an action and return the next state.

Together these give you a one-way data flow that's traceable, testable, and works with time-travel debugging.

An action is a plain JavaScript object that describes something that happened in the app. It must have a type field, a string like "cart/itemAdded", and it usually carries data in a payload field. Think of it as an event record: it says what occurred, not how state should change in response.

Actions are the only way to send data to the store. You don't call a setter; you dispatch an action, and a reducer decides how state changes in response.

A reducer is a pure function with the signature (state, action) => newState. It looks at the action type and returns the next state, or the current state unchanged if the action doesn't apply.

The rules: it must be pure, so no API calls, no random values, no mutating the state argument. It should return a new object or array instead of editing the existing one. Same inputs always produce the same output.

The store is the object that holds your app's whole state tree, and there's exactly one per app. It ties the pieces together: it holds state, lets you read it, lets you update it by dispatching actions, and lets other code react to changes. You create it with configureStore.

Its main methods are getState() to read the current state, dispatch(action) to trigger an update, and subscribe(listener) to run a callback whenever state changes.

It's a one-way loop. Something happens in the UI, so you dispatch an action. The store passes the current state and that action to the reducer. The reducer returns the next state. The store saves it and notifies every subscriber. Subscribed UI reads the new state and re-renders.

Nothing skips a step. The UI never changes state directly, which is what keeps the flow predictable.

Redux detects changes by comparing references. If a reducer mutates the old state object instead of returning a new one, the reference stays the same, so Redux and connected components think nothing changed and skip re-rendering.

Immutability also enables time-travel debugging (each state is a distinct snapshot) and makes reasoning about changes easier because past states never change under you.

An action creator is a function that builds and returns an action object. Instead of writing the same object literal everywhere, you call a function that produces it. That keeps action shapes consistent across the codebase and removes typos in the type string, which is a common source of silent bugs.

You dispatch the result: dispatch(itemAdded(item)). Redux Toolkit's createSlice generates action creators for every reducer automatically, so you rarely hand-write them anymore.

dispatch is the store method that sends an action into Redux, and calling store.dispatch(action) is the only way to trigger a state change. Nothing else touches the store. You dispatch an action, and Redux runs it through the middleware chain and then the root reducer to compute the next state.

After the reducer returns, the store saves that state and notifies every subscriber. In a React component you get dispatch from the useDispatch hook rather than reaching for the store directly.

Use local state (useState) for data that only one component cares about: a form input, a toggle, a hover flag. Reach for Redux when state is shared across many components far apart in the tree, needs to persist across routes, or is complex enough that tracing changes matters.

Small apps rarely need Redux at all. The honest coverage names the cost: Redux adds setup and indirection, so it earns its place only when shared state gets genuinely hard to manage.

Context is a way to pass a value down the tree without prop drilling. It's not a state manager: it has no actions, reducers, or DevTools, and every consumer re-renders whenever the context value changes.

Redux is a full state management library with a strict update flow, middleware, and selective subscriptions so components re-render only for the slice they read. Context suits low-frequency values like theme or the current user; Redux suits frequently updated, widely shared state.

A pure function returns the same output for the same input and has no side effects: it doesn't mutate its arguments, call APIs, read the clock, generate random values, or touch anything outside itself. Given the same state and action, a pure reducer always returns the same next state, every single time.

Reducers must be pure so state changes stay predictable and reproducible. That's what lets Redux replay actions for time-travel debugging and makes reducers trivial to unit test.

The convention is Flux Standard Action: a type field (required) and optionally payload for the data, error for a boolean error flag, and meta for extra info. Keeping to this shape makes actions consistent and tooling-friendly.

Redux Toolkit's action creators follow it automatically: the argument you pass becomes action.payload.

One store means one source of truth. Every part of the app reads the same state, so there's no risk of two stores drifting out of sync and disagreeing, and debugging means inspecting one object instead of hunting across several. It also makes persistence and time-travel straightforward, because there's a single state to snapshot.

You still organize that store into slices, one per feature, and combine their reducers. So you get modular code with a single unified state tree, not one giant hand-written reducer.

combineReducers merges several slice reducers into one root reducer. Each slice reducer owns one key of the state object and only sees its own slice, so a cart reducer never touches user state. This is how you split a large store into small, focused reducers instead of one giant function.

With Redux Toolkit you rarely call combineReducers directly: passing a reducer object to configureStore combines them for you under the hood.

Provider is a component from react-redux that makes the Redux store available to every component below it in the tree. You wrap your app once, near the root, and pass the store as a prop. Under the hood it uses React context to hand the store down, so any descendant can reach it without prop drilling.

Without the Provider, hooks like useSelector and useDispatch have no store to reach and throw an error.

useSelector reads a piece of state from the store and subscribes the component to it, so the component re-renders when that value changes. useDispatch returns the store's dispatch function so you can send actions.

They're the modern react-redux API and replace the older connect() higher-order component for most code.

Each reducer declares its own initial state as the default value of its state parameter, or as the initialState field in createSlice. When the store first starts, Redux dispatches an internal init action that no reducer handles, so every reducer falls through to its default and returns its initial state. That's how the store gets a fully populated starting tree.

You can also pass a preloadedState to configureStore, which is handy for hydrating state from the server or localStorage.

The state tree is the single JavaScript object that holds all your app state, organized by slice. Each top-level key is one feature's slice of state, so you might have state.cart, state.user, and state.products side by side in one object.

Keeping it a plain, serializable object (no class instances, promises, or functions) is what lets Redux persist it, send it over the wire, and replay it in DevTools.

getState() returns the current state right now: a one-time snapshot read. subscribe(listener) is different: it registers a callback that runs every time the state changes, so your code can react to updates over time. One reads once, the other keeps listening until you unsubscribe.

In a React app you rarely call either directly. react-redux wires subscribe and getState together under the hood, and you read state with useSelector instead.

Redux logs, replays, and time-travels through actions, and DevTools serializes them. A plain object with a string type is easy to inspect, store, and replay. Functions, promises, or class instances can't be serialized reliably, so they'd break those features.

When you need async or dynamic logic, that lives in middleware like thunks, and the middleware still dispatches plain objects to the reducer at the end.

Redux Toolkit (RTK) is the official, recommended way to write Redux. It packages the setup that used to be manual: configureStore sets up the store with sensible defaults, createSlice generates reducers and action creators together, and Immer lets you write update logic that looks mutable.

It exists because classic Redux was verbose: separate action types, action creators, and switch reducers for every feature. RTK removes that boilerplate and bakes in good defaults like the Redux DevTools and a serializability check.

createSlice takes a name, an initial state, and an object of reducer functions, and returns a slice reducer plus one action creator per reducer. Names are derived automatically, so a reducer called increment produces an increment action creator.

It collapses the action-type, action-creator, and reducer boilerplate into one place, and it wraps your reducers with Immer so you can write update logic that looks like mutation.

RTK runs your case reducers inside Immer. Immer hands you a draft of the current state; you mutate that draft freely, and behind the scenes Immer tracks every change you make and produces a brand-new immutable state from them. You get the readability of mutation with the correctness of immutable updates.

So state.value += 1 inside a createSlice reducer is safe: you're mutating a draft, not the real store. Outside createSlice (a plain reducer), the same code would be a bug, so know where the rule applies.

configureStore wraps createStore with good defaults. It combines your slice reducers automatically, adds redux-thunk middleware out of the box, sets up the Redux DevTools, and turns on development checks for accidental mutations and non-serializable values.

createStore is the low-level function that does none of that; you wire middleware and DevTools yourself. RTK's configureStore is the recommended entry point, and classic createStore is now marked as legacy.

Middleware sits between dispatching an action and the moment it reaches the reducer. Each middleware can inspect the action, run side effects, delay or stop it, or dispatch other actions before passing it along.

It's the extension point for logging, crash reporting, and async logic. The signature is a chain of functions: store => next => action, where calling next(action) passes control to the next middleware or the reducer.

Reducers are pure and dispatch expects a plain object, so neither can do async work like fetching data. redux-thunk is middleware that lets an action creator return a function instead of an object. That function receives dispatch and getState, so it can await async work and dispatch real actions when it finishes.

It's the simplest way to handle side effects in Redux, and RTK includes it by default.

Both handle async side effects, but differently. Thunks are just functions: you write async/await inline, which is simple and enough for most apps. Sagas use generator functions and run in a separate middleware, describing side effects as yielded effect objects that the library executes.

Sagas shine for complex flows: cancellation, debouncing, retries, and orchestrating many concurrent tasks. The cost is a steeper learning curve. Most teams reach for thunks or RTK Query first and add sagas only when the async logic is genuinely intricate.

createAsyncThunk generates a thunk plus three action types for you: pending, fulfilled, and rejected. You give it a type prefix and an async function; it dispatches pending when the call starts, fulfilled with the result on success, and rejected with the error on failure.

You handle those three actions in your slice's extraReducers to update loading, data, and error state. It removes the boilerplate of writing the three actions by hand.

The reducers field defines the actions this slice owns, and RTK auto-generates a matching action creator for each one. The extraReducers field is for responding to actions defined elsewhere: createAsyncThunk's pending, fulfilled, and rejected actions, or actions dispatched by a different slice. It doesn't create any new action creators.

So a slice uses reducers for its own actions and extraReducers to react to external ones, which keeps async lifecycle handling out of the local reducer list.

A selector is a function that takes the Redux state and returns a piece of it, or something computed from it. Instead of reaching into state.cart.items directly in every component, you call selectCartItems(state). It's a small indirection that pays off: the component asks for what it needs and doesn't care how the state is shaped.

Selectors centralize the shape of state in one place, so if the state structure changes you fix one function, not fifty components. They also give you a spot to memoize derived data.

A selector that computes derived data (a filtered or mapped list) returns a brand-new array every call. useSelector compares by reference, so a new array every render triggers a re-render even when the underlying data didn't change.

createSelector from Reselect memoizes: it only recomputes when its input selectors return different values, and otherwise returns the same cached reference. That keeps the output stable and avoids needless re-renders.

connect is the older react-redux API: a higher-order component that injects state and dispatch into a component via mapStateToProps and mapDispatchToProps. It wraps your component and passes the selected data down as props, so the component itself stays unaware of Redux and just reads its props. It was the standard approach before hooks arrived.

The hooks useSelector and useDispatch do the same job with less indirection and are recommended for new code. connect still works and appears in older codebases, and it's occasionally useful for injecting Redux into class components.

Normalizing means storing a collection as a lookup table keyed by id, plus a separate array of ids for ordering, instead of a deeply nested array of objects. Each entity lives in exactly one place, so the same record is never duplicated across the state tree. It's the same idea as a relational database table with a primary key.

It avoids duplication and makes updates cheap: to change one item you update one entry by id rather than mapping over a nested array. RTK's createEntityAdapter provides ready-made reducers and selectors for this shape.

RTK Query is Redux Toolkit's data-fetching and caching layer. You define endpoints for your API, and it generates React hooks like useGetUserQuery that handle fetching, caching, loading and error states, deduping requests, and refetching on demand. It stores the cache in Redux, so the same data isn't fetched twice across components.

Use it when most of your Redux state is really server data. It removes the need to hand-write thunks, loading flags, and cache logic for API calls. Keep plain slices for genuine client-only state.

The Redux DevTools are a browser extension that shows every dispatched action, the state before and after, and a diff. You can time-travel: jump back to any earlier state, replay actions, and even skip actions to see the effect.

They work because Redux state is immutable and changes only through actions, so each action is a discrete, replayable step. configureStore wires them up automatically in development.

Reducers must be pure: same inputs, same output, no side effects. An API call is a side effect and its result is non-deterministic, so it breaks purity and would make state changes unpredictable and un-replayable.

Async work belongs in middleware: a thunk, createAsyncThunk, RTK Query, or a saga. The reducer only handles the plain actions those tools dispatch when the data arrives.

Select the smallest piece of state a component actually needs, not a whole object. useSelector re-runs after every dispatch and compares its result to the previous one by reference, so returning a fresh object or array each time forces a re-render even when nothing meaningful changed. Narrow selections avoid that entirely.

For derived data use memoized selectors (createSelector). When you must return a new object, pass shallowEqual as useSelector's second argument so it compares fields instead of reference.

Dispatch a single top-level action, say auth/loggedOut, and handle it in a wrapper around the root reducer. When that action arrives, you ignore the current state and pass undefined down instead, which makes every slice fall back to its own initial state. It's a clean, one-place reset rather than clearing each slice by hand.

The pattern is to wrap the combined reducer: if the action is the reset one, call the underlying reducer with undefined so every slice re-initializes.

createEntityAdapter is an RTK helper for managing normalized collections. It stores items as { ids: [], entities: {} } and hands you prewritten CRUD reducers (addOne, upsertMany, removeOne, updateOne) plus memoized selectors (selectAll, selectById).

It saves you from hand-writing the same normalized update logic for every list, and it pairs cleanly with createAsyncThunk to load and store fetched data.

You can call dispatch multiple times inside a thunk, and each runs the full reducer cycle. That's fine for a real sequence, like dispatching a loading action, then a success action after a fetch.

But don't split one logical change across many actions just to update several slices; that causes several re-render passes and a noisy log. Prefer one well-named event action that multiple reducers respond to, which keeps the change atomic.

applyMiddleware composes middleware into a pipeline around dispatch. Each middleware has the shape store => next => action. The store's real dispatch is the last next in the chain; each middleware wraps the next one.

When you dispatch, the action flows through each middleware in order. A middleware can act before calling next(action), after it, both, or never (stopping the action). Because each holds a reference to store.dispatch, it can also dispatch new actions, which restart at the top of the chain.

createSelector takes input selectors and a result function. It caches the last inputs and last output. On each call it runs the input selectors; if every result is reference-equal to last time, it returns the cached output without recomputing.

The classic limit is a cache size of one: a selector shared by multiple components with different arguments thrashes the cache, recomputing every call. The fix is a selector factory (a function that returns a fresh createSelector per component) or a weak-map-based memoizer.

Immutability makes state changes into a sequence of discrete snapshots. That enables three things at once: cheap change detection by reference comparison, time-travel debugging and action replay, and safe concurrent reads because no one mutates state under you.

It also makes reducers trivially testable: given a state and an action, assert on the returned state, with no setup or teardown. The whole predictability story rests on old state never changing.

Incrementally, slice by slice. RTK is designed to interoperate with classic Redux, so you don't rewrite everything at once. Start by swapping createStore for configureStore, which keeps existing reducers working while adding DevTools and the mutation and serializability checks.

Then convert one feature at a time: replace its action types, action creators, and switch reducer with a single createSlice. Convert manual thunks to createAsyncThunk. Move pure API-cache slices to RTK Query last, since that changes the component data-access pattern.

Normalize entities into id-keyed lookup tables (createEntityAdapter) so updates touch one record and no data is duplicated. Keep derived data out of the store and compute it in memoized selectors instead. Split state into feature slices that own their shape, and colocate their reducers, selectors, and thunks.

For rendering, select narrow slices, memoize derived selectors, and lean on RTK Query for server cache so you're not hand-managing loading flags. Avoid deeply nested state, which makes immutable updates verbose and error-prone.

redux-persist saves the store, or a chosen subset of slices, to storage like localStorage and rehydrates it when the app loads. You wrap your reducer with persistReducer, whitelist only the slices worth saving, and gate the initial render behind a PersistGate so the UI waits until rehydration finishes before it reads state.

Pitfalls: don't persist server cache (it goes stale, prefer RTK Query), version and migrate the persisted shape or old data crashes new reducers, keep persisted state serializable, and never store secrets in localStorage. Persisting everything blindly is the common mistake.

Reducers are pure, so testing is direct: call the reducer with a state and an action, assert on the returned state. No mocks needed. Selectors are the same: pass a state object, assert the output.

Thunks need dispatch and any API mocked. With createAsyncThunk you can dispatch it against a real store configured for the test and assert the resulting state, or mock fetch and check the dispatched pending and fulfilled actions. Testing behavior through the store beats asserting exact internal action sequences.

RTK's serializability middleware flags values like Promises, class instances, Dates, Maps, or functions in the state or in actions. Redux assumes serializable data so it can persist state, send it to DevTools, and time-travel reliably; non-serializable values break those guarantees.

The right fixes are to store serializable data (an ISO string instead of a Date, an id instead of a class instance) and keep functions and promises out of state. For unavoidable cases you can configure the middleware to ignore specific paths or action types.

createListenerMiddleware lets you run logic in response to dispatched actions or state changes, without generators. You register listeners that match actions (or a predicate) and run effects: debouncing, conditional dispatch, cancellation via a fork/take-style API.

It's the recommended lighter alternative to redux-saga for reactive side effects. Use it when thunks aren't enough because you need to react to actions across features, but you don't want the full saga machinery.

You can't safely, and Redux guards against it: dispatching while the reducer is running throws, because a reducer must be a pure function of state and action, not a place that triggers more state changes. Allowing it would make the update order impossible to reason about.

If one change should trigger another, do it outside the reducer: dispatch a second action from a thunk or the listener middleware after the first completes, or handle both concerns in a single well-designed action.

For small or mid-size apps where the ceremony of Redux outweighs its benefits, Zustand (a single hook-based store, minimal boilerplate) or Jotai (atomic, bottom-up state) often fit better. They need less setup and have a gentler learning curve.

Redux still wins when you want strict conventions across a large team, deep DevTools and time travel, a mature middleware ecosystem, or RTK Query's caching. The honest answer weighs team size, app complexity, and how much you value traceability against setup cost.

Update the store immediately as if the request succeeded, keep the previous value, then reconcile when the server responds. On success you keep the optimistic state; on failure you roll back to the saved value and surface an error.

In RTK Query you do this with onQueryStarted: apply an updateQueryData patch right away, and call patchResult.undo() if the request rejects. With plain thunks you snapshot the old state, dispatch the optimistic change, and dispatch a revert action on error.

Model actions as events that describe what happened (cart/itemAdded, checkout/failed), not as setters that describe what to change (setCartItems). Event-style actions keep intent in one place, let many reducers respond to a single event, and produce a readable, auditable log in DevTools.

Setter-style actions push logic into components (the component computes the next state and just stores it), which scatters business rules and defeats the point of a central reducer. This distinction is a senior-level design signal.

Yes. Middleware runs in the order you register it, wrapping outward, so position changes behavior. A logger placed before the thunk middleware logs the raw function-typed action; placed after, it logs the plain actions the thunk actually dispatches.

The practical rule: put middleware that should see final, plain actions (loggers, analytics) after the ones that transform or intercept actions (thunk, saga, listener). RTK's getDefaultMiddleware lets you insert yours at the right spot with prepend or concat.

Middleware customizes dispatch: it wraps the dispatch function to intercept actions. A store enhancer is higher-level: it wraps the whole createStore, so it can override any part of the store, including getState, subscribe, and dispatch.

applyMiddleware is itself implemented as an enhancer. You'd write a custom enhancer only for cross-cutting store behavior that middleware can't reach, like the Redux DevTools enhancer or persistence wiring. Most apps never need a hand-written one.

Diagnose first: use the React DevTools profiler and the Redux DevTools to see which components render and which actions fire. The usual causes are selectors returning new references each call, subscribing to too much state, or every row reading the whole list.

Fixes in order: memoize derived selectors with createSelector, have each row select only its own item by id (so unrelated updates don't touch it), wrap rows in React.memo, and virtualize the list so only visible rows mount. Measure after each change rather than applying all at once.

Yes, for the problems it was built for. Hooks and Context handle local and low-frequency shared state well, and server components move some data-loading off the client, so Redux is no longer the default for every app. That's a good thing: it's now used where it earns its place.

Where it stays strong: large client-heavy apps with complex, frequently updated shared state, teams that value strict conventions and DevTools, and codebases using RTK Query for cache management. The honest take is that Redux got narrower and better, not obsolete.

RTK Query fits data that's owned by the server: lists, records, and anything you fetch, cache, and refetch. It handles caching keys, deduping, loading and error flags, and cache invalidation with tags, which is logic you'd otherwise write by hand in thunk slices.

Hand-written thunks earn their place when the async flow is unusual: multi-step orchestration, heavy local transformation before storing, or state that isn't really a cached server resource. Mixing both is normal: RTK Query for the API cache, plain slices for genuine client state.

Keep a registry of the currently loaded slice reducers, and when a lazy feature mounts, add its reducer and rebuild the root reducer with store.replaceReducer. This keeps the initial bundle small: a feature's reducer ships only when the feature loads.

The pattern is a small injectReducer helper that stores the new reducer, recombines everything, and calls replaceReducer. RTK Query's api reducer and middleware can be added the same way. Guard against injecting the same key twice.