Redux (Redux Toolkit)

The Redux core idea: one predictable state machine. Redux keeps all shared application state in a single store (one big JavaScript object). You never mutate it directly. Instead you dispatch actions — plain objects describing what happened ({ type: 'cart/itemAdded', payload }) — and pure functions called reducers compute the next state from the current state and the action. Because the only way state changes is 'dispatch an action → reducer returns new state,' the data flow is strictly one-directional and every change is traceable. That predictability is Redux's whole reason for existing.

Why unidirectional flow and immutability matter. Reducers must be pure (no side effects, no mutation) and must return a new state object rather than editing the old one. This immutability is what powers Redux's superpowers: React can cheaply detect changes by reference comparison, the devtools can record every past state and 'time-travel' between them, and bugs are reproducible because state is a deterministic function of the action log. The cost, in classic Redux, was verbose immutable-update code and lots of boilerplate — which is exactly what Redux Toolkit fixes.

Redux Toolkit (RTK) is the official, batteries-included way. Modern Redux is written with RTK; hand-writing action-type constants, action creators, and switch-statement reducers is obsolete. RTK gives you createSlice (generates actions + reducer together), configureStore (sets up the store with good defaults — the thunk middleware, devtools, and dev-time immutability/serializability checks), createAsyncThunk (async flows), createSelector (memoised selectors, re-exported from Reselect), and createApi/RTK Query (full server-state caching). The React docs and Redux docs both recommend RTK as the default.

createSlice: state + reducers + auto-generated actions in one place. A slice owns one region of the store. You give createSlice a name, an initialState, and a reducers object; it returns a reducer plus a matching action creator for every reducer key. So writing an addExpense(state, action) reducer automatically gives you an addExpense(payload) action creator — no separate action-type constant, no boilerplate creator. This colocation (state shape, its transitions, and its actions in one file) is the single biggest ergonomics win over classic Redux.

Immer: write 'mutating' code that is actually immutable. The reducers inside createSlice run through Immer. Immer hands your reducer a draft proxy of the state; you write natural mutations like state.items.push(item) or state.filter = 'all', Immer records those operations against the draft, and then produces a brand-new immutable state from them. So the syntax is ergonomic and mutable-looking, but the store update is fully immutable. The one rule: this only applies inside RTK reducers — never mutate state anywhere else, and do not both mutate the draft and return a value from the same reducer.

configureStore and full TypeScript typing. configureStore({ reducer: { expenses: expenseReducer, cart: cartReducer } }) combines slice reducers into the root store and wires the sensible middleware defaults automatically. From it you derive two types that make everything type-safe: RootState = ReturnType<typeof store.getState> and AppDispatch = typeof store.dispatch. Best practice is to export pre-typed hooks — useAppSelector and useAppDispatch — so every call site is typed without repeating generics, and thunks are dispatchable with correct types.

Reading and writing from components. Components connect via react-redux hooks. useSelector(selectorFn) subscribes the component to a slice of state and re-renders it only when that selected value changes (by reference, using strict equality by default) — this is the fine-grained subscription Context lacks. useDispatch() returns the store's dispatch, which you call with an action creator: dispatch(addExpense(newExpense)). The Provider from react-redux (<Provider store={store}>) wraps the app so the hooks can reach the store — internally that Provider uses React Context.

Async with createAsyncThunk. Reducers are synchronous and pure, so side effects (API calls) live in thunks. createAsyncThunk('users/fetch', async () => …) returns a thunk you dispatch; it automatically dispatches three lifecycle actions — pending, fulfilled, and rejected — which you handle in the slice's extraReducers (via the builder callback) to set loading, data, and error state. This gives async data a clean, standard three-state shape without hand-writing action types for each phase.

Selectors and memoisation with createSelector. A selector is a function that reads a value out of state (state => state.cart.items). Inline selectors are fine for simple reads, but for derived data (a filtered list, a computed total) you want createSelector, which memoises: it recomputes only when its input selectors' results change, and returns the same reference otherwise. That stable reference prevents needless re-renders and avoids recomputing expensive transforms on every dispatch. Colocating selectors in the slice file (selectCartTotal) keeps state access encapsulated so components do not reach into the state shape directly.

RTK Query — server state inside the Redux ecosystem. Rather than hand-writing thunks to fetch and cache API data, RTK Query (createApi) generates fully-typed hooks (useGetUsersQuery, useAddUserMutation) that handle caching, deduping, background refetch, loading/error state, and cache invalidation via tags — the same job TanStack Query does, but integrated into the Redux store and devtools. If you are already on Redux, RTK Query is the recommended way to handle server state so you do not confuse it with client state.

When Redux is worth its cost — and when it is not. Redux shines for large apps with complex, frequently-updated, cross-cutting client state shared by many components, big teams that benefit from a strict, auditable, one-way data flow, and cases where the devtools' time-travel and action log are genuinely useful. It is overkill for small apps, for local UI state (use useState), for a couple of siblings (lift state), or for a stable global value (Context). And server data belongs in RTK Query/TanStack Query, not in hand-managed slices. Reach for Redux when the predictability and tooling pay for the ceremony — RTK has made that ceremony small, but it is not zero.

The mental model (memorise this). Redux is a single immutable state machine: components dispatch actions (facts about what happened), pure reducers compute the next state, and components subscribe to slices via selectors that re-render only on change. Redux Toolkit makes this ergonomic — createSlice colocates state and auto-generates actions, Immer lets you write mutating-looking reducers that stay immutable, configureStore wires it up and types it, thunks handle async, createSelector memoises derived data, and RTK Query owns server state.