Redux interview questions and answers

A single source of truth: the whole app state lives in one store. State is read-only: the only way to change it is to dispatch an action, a plain object describing what happened. Changes are made with pure functions: reducers take the previous state and an action and return the next state without side effects.

A UI event dispatches an action. The store calls the root reducer with the current state and the action; reducers return a new state. The store notifies subscribers, and UI bound with useSelector re-renders where its selected data changed. Middleware sits between dispatch and the reducer for side effects.

Purity makes results predictable and testable, and enables time-travel debugging and replay. Immutability lets Redux and React detect changes cheaply by reference (prev !== next) instead of deep comparison; mutating state in place hides changes and causes stale UI. Redux Toolkit uses Immer so you can write mutating-looking code safely.

Middleware wraps dispatch, seeing every action before it reaches reducers. It handles side effects and cross-cutting concerns: redux-thunk lets you dispatch functions for async logic, redux-saga uses generators for complex flows, redux-observable uses RxJS, and loggers or crash reporters observe actions. RTK includes the thunk and listener middleware.

The store is created once and provided with <Provider store>. Components read slices with useSelector and send actions with useDispatch. Reducers compute the next state, and subscribed components re-render when their selected values change.

Reducers must be pure, so side effects go in middleware: thunks (functions that dispatch actions before and after a request), sagas, observables or the listener middleware. Redux Toolkit's createAsyncThunk and RTK Query cover most cases.

Plain serialisable data makes time-travel debugging, persistence, logging and server rendering reliable. Promises, class instances, functions or Maps break DevTools and persistence, so keep them out of state and actions.

useSelector(selector) reads data from the store and re-renders the component when the selected value changes by reference equality. useDispatch() returns the store's dispatch function. Keep selectors small and return stable references; avoid creating new objects in selectors without memoisation.

createSelector builds selectors that cache their result and recompute only when inputs change. They avoid repeating expensive derivations and keep returned references stable, preventing needless re-renders. Keep state minimal and derive the rest with selectors.

Normalise data: store entities by ID in lookup tables ({ ids: [], entities: {} }) instead of nested arrays, split state into slices by feature, keep server cache separate (RTK Query), and keep UI-only state local unless it is shared.

When state is simple or local, when most state is server data (use a data-fetching library), or when the team does not need its structure. Context, component state or a lighter store may be enough. Redux shines with complex shared client state, many contributors and strong debugging needs.

Redux Toolkit: configureStore, createSlice with Immer-powered reducers, createAsyncThunk or RTK Query for data, TypeScript-typed hooks, and React-Redux hooks rather than connect. Hand-written action types, switch reducers and createStore are legacy.

Local state (useState) suits data used by one component or a small subtree, such as an open dropdown. Redux suits data shared widely, needed after navigation, or updated from many places. Not everything belongs in Redux.

Select the smallest value needed, avoid creating new objects or arrays in selectors, use memoised selectors (createSelector) for derived data, or pass shallowEqual as the equality function when selecting several fields.

Keeping a feature's action types, action creators and reducer in one file. Redux Toolkit's createSlice formalises it, now usually organised as feature folders.

Use redux-persist to save chosen slices to storage and rehydrate on load, with a whitelist or blacklist, versioning and migrations. Avoid persisting server data that should be refetched.

Reducers are pure: call them with a state and action and assert the result. Selectors are pure too: pass a sample state. For connected components, render with a real store created per test rather than mocking the store.

An RTK middleware that runs effects in response to actions or state changes (startListening({ actionCreator, effect })), with async support and cancellation. It is a lighter alternative to sagas for reactive logic.

Because every change is an action applied by pure reducers, Redux DevTools records the action log and state snapshots. You can step back and forward through actions, inspect diffs, and replay or skip actions to reproduce bugs.

It builds a root reducer from an object of slice reducers; each slice reducer receives only its part of the state and every action, and the results are combined into the new root state. Each key becomes a top-level state field.

A thunk is a function dispatched as an action that receives dispatch and getState, good for straightforward async calls. Sagas use generator functions and effects to orchestrate complex flows such as cancellation, debouncing, races and background tasks, at the cost of more concepts. RTK's listener middleware covers many saga use cases.

Each action has a type describing what happened ('todos/added'). Strings are serialisable and readable in DevTools and logs. The convention is domain/eventName, describing events rather than setters.

Inject reducers when their feature loads, for example with combineSlices and inject in Redux Toolkit 2, so the initial bundle includes only the reducers needed at startup.

Redux is inspired by Flux's one-way data flow, but uses a single store and pure reducer functions instead of several stores and a dispatcher, which makes state changes easier to trace.

The single reducer passed to the store, usually built with combineReducers from feature reducers. It can also handle global actions like logout by resetting state.

Names like 'order/submitted' record what happened, so several reducers can respond and the history in DevTools reads like a log of user activity, whereas 'setLoading' style actions scatter logic across components.

Classic Redux required lots of boilerplate (constants, action creators, switch statements), manual immutable updates that were easy to get wrong, and assembling many packages for a typical setup. RTK bundles good defaults.

The older React-Redux API: a higher-order component taking mapStateToProps and mapDispatchToProps to inject state and action creators as props. Hooks have replaced it in new code.

A function that returns an action object, such as addTodo(text) => ({ type: 'todos/added', payload: text }), so actions are created consistently. createSlice generates them automatically.

Redux uses explicit actions, pure reducers and immutable updates with a single store. MobX uses observable state that you mutate directly, with automatic tracking of what components use. MobX is less code; Redux is more explicit and traceable.

1. ABy assigning to store.state
2. BBy dispatching an actionCorrect answer
3. CBy calling setState
4. DBy editing the DOM

Why: Actions are the only way to trigger changes.

1. AAsync
2. BA pure functionCorrect answer
3. CA class
4. DA generator

Why: Same input, same output, no side effects.

1. AuseReducer
2. BuseDispatch
3. CuseSelectorCorrect answer
4. DuseStore only

Why: useSelector subscribes to selected state.

1. A<Provider store>Correct answer
2. B<StoreProvider>
3. C<ReduxRoot>
4. D<Context.Store>

Why: From react-redux.

1. AMiddleware such as thunksCorrect answer
2. BReducers
3. CSelectors
4. DAction types

Why: Reducers must stay pure.

1. AStrings
2. BNumbers
3. CPlain objects
4. DNon-serialisable values like promisesCorrect answer

Why: Breaks DevTools and persistence.

1. AComponent props
2. BCSS
3. CDispatched actionsCorrect answer
4. DHTTP responses only

Why: It wraps dispatch.

1. Aimmer
2. Bredux-thunkCorrect answer
3. Credux-logger
4. Dreselect

Why: Thunks receive dispatch and getState.

1. ARouting
2. BActions
3. CMemoised derived dataCorrect answer
4. DPersistence

Why: Reselect caches results by input.

1. AIt speeds up the network
2. BIt saves disk space
3. CChanges are detected by reference comparisonCorrect answer
4. DIt is required by JavaScript

Why: New references signal changes.

1. ASelecting a number
2. BUsing createSelector
3. CSelecting a string
4. DReturning a new object from useSelectorCorrect answer

Why: New references fail equality.

1. Aredux-logger
2. Bredux-thunk
3. Creselect
4. Dredux-persistCorrect answer

Why: Rehydrates on load.

1. ARender a component
2. BUse snapshots only
3. CCall it with state and action and check the resultCorrect answer
4. DMock the store

Why: Reducers are pure functions.

1. AListener middlewareCorrect answer
2. BThunk only
3. CLogger
4. DImmer

Why: startListening.

1. AUUIDs
2. B'domain/eventName'Correct answer
3. C'SET_X'
4. DNumbers

Why: Describe events.

1. ACombines actions
2. BJoins middleware
3. CMerges stores
4. DBuilds a root reducer from slice reducersCorrect answer

Why: Each key maps to a slice reducer.

1. AAs strings
2. BAs nested arrays
3. CBy ID in lookup tablesCorrect answer
4. DIn localStorage

Why: Lookup by ID avoids duplication.

1. ARedux DevToolsCorrect answer
2. BChrome Lighthouse
3. CJest
4. DReact DevTools

Why: It records actions and states.

1. AHand-written switch reducers
2. BRedux ToolkitCorrect answer
3. CFlux
4. DMobX

Why: RTK is the official approach.

1. AThe signed-in user
2. BA shared cart
3. CFeature flags
4. DWhether one dropdown is openCorrect answer

Why: Not everything belongs in Redux.

1. AdeepEqual
2. BObject.is
3. CisEqual
4. DshallowEqualCorrect answer

Why: Exported by react-redux.

1. AconfigureStore
2. BcreateReducer
3. CcombineSlicesCorrect answer
4. DcombineReducers only

Why: Code-split reducers.

1. AGraphQL
2. BFluxCorrect answer
3. CMVC
4. DMVVM

Why: One-way data flow.

1. AA selector
2. BAn action
3. CThe single reducer passed to the storeCorrect answer
4. DA middleware

Why: Usually from combineReducers.

1. AA feature's actions and reducerCorrect answer
2. BAll reducers in one file
3. CTests and styles
4. DComponents and CSS

Why: createSlice formalises it.

1. AA class instance
2. BA promise
3. CA function
4. DA plain object with a typeCorrect answer

Why: Usually { type, payload }.

1. Areselect
2. Bredux-persist
3. Credux-sagaCorrect answer
4. Dredux-thunk

Why: Sagas yield effects.

1. Aconnect()Correct answer
2. Blink()
3. Cattach()
4. Dbind()

Why: connect is a higher-order component.

1. AA single immutable store
2. BPure reducers only
3. CAction types
4. DObservable, directly mutated stateCorrect answer

Why: Automatic tracking.

1. AGuillermo Rauch
2. BDan Abramov and Andrew ClarkCorrect answer
3. CTanner Linsley
4. DEvan You

Why: Released in 2015.