Redux 与 TypeScript · 六问6 questions on Redux and TypeScript

In one line — and this is the key sentence: they do not solve the same problem. Context is a delivery mechanism (how a value reaches something deep in the tree); Redux is a state management solution (how state is organised, changed and debugged).

“Can Context replace Redux?” — strictly speaking, Context plus useReducer covers Redux’s basic features, but three things are missing:

• No fine-grained subscription. When the context changes, every consumer re-renders, even one that only reads a single field. Redux’s useSelector re-renders only when the slice you selected changes. That is the biggest practical difference.
• No middleware. Handling async, logging and persistence in one place is all yours to build.
• No DevTools. No time travel, no action log, no state diff.

Follow-up: “Do people still use Redux?” — answer honestly: plenty of projects moved pure client state to Zustand or Jotai (lighter); server data goes to TanStack Query or SWR (caching, deduping and retries are their day job, and Redux doing it is a stretch). Redux’s remaining strength is complex client state with a lot of interaction logic that you need to be able to trace, and you should always use Redux Toolkit rather than write it by hand.

In one line: a one-way loop — the view dispatches an action, middleware handles it, a reducer computes the new state, the store updates, and the subscribed components re-render.

Five roles:

• store — the single container for state, exposing getState, dispatch and subscribe.
• action — a plain object that describes what happened and must have a type. It only describes; it does nothing.
• reducer — (state, action) => newState, and it has to be pure.
• middleware — intercepts the action on its way to the reducer (#354).
• selector — picks the part of the store a component needs.

What Redux Toolkit (RTK) changed — you have to cover this, because nobody hand-writes Redux any more:

• createSlice generates the reducer, the action creators and the action types at once, cutting more than half the boilerplate.
• Immer is built in, so you can write what looks like a mutation — state.list.push(x) — and still get a new object out. Just remember this only holds inside createSlice.
• thunk and DevTools are wired up by default.
• createAsyncThunk handles the three async states (pending / fulfilled / rejected).

Follow-up: “Why does it have to be one-way?” — because there is exactly one path a change can take, so when something breaks you can walk back through the action log step by step. In a two-way binding framework, “who actually changed this value” is often unanswerable.

Three of them, and each one needs a “why”:

1. Single source of truth — one store for the whole app.
   Why: one copy of the state cannot disagree with itself, and the entire app state can be serialised — which is what makes “save and restore the session” and SSR dehydration possible.
2. State is read-only — you change it only by dispatching an action.
   Why: it narrows “who can change state” down to one entrance, so every change can be logged, intercepted and replayed.
3. Changes are made by pure functions (reducers) — (state, action) => newState.
   Why: a pure function always gives the same result for the same state and action, so it can be replayed and tested, and that is what makes time-travel debugging work.

The three are one package: a single source of truth makes state serialisable, read-only makes changes loggable, and pure reducers make changes replayable — together they add up to time travel in DevTools. Tying them together like this is much stronger than reciting them one by one.

Follow-up: “What can and cannot a reducer do?” — it cannot mutate the state it was given, make requests, read Date.now() or Math.random(), or dispatch other actions. All of that belongs in middleware or an action creator.
“Does state.push() in RTK break rule 2?” — no. Immer hands you a draft proxy, records your edits, and produces a new object; the original state is untouched.

In one line: middleware is a layer between “an action is dispatched” and “the reducer receives it”. It can intercept, rewrite, delay or even swallow an action.

The signature is curried three levels deep — the shape itself gets asked about: store => next => action => {}. Several middlewares chain together through next, and it is the same pattern as Express middleware.

Why you need it: because the reducer has to be pure, async work and side effects have nowhere to live. Middleware is the place reserved for side effects.

The common ones:

• redux-thunk — lets you dispatch a function instead of only an object, and do your async work inside it. Simplest option, and RTK installs it by default.
• redux-saga — describes complex async flows with generators (cancellable, retryable, able to orchestrate several requests). Powerful, but a steep learning curve.
• redux-logger — prints the state before and after each action.

Follow-up: “thunk or saga?” — thunk is enough for most projects; saga only earns its complexity when you need cancellation, debouncing or real flow orchestration.
“Could you write one?” — yes, and interviewers often ask you to write a logger on the spot.

In one line: TS is a superset of JS — it adds static types, and after compilation it is ordinary JS with nothing of TS left at runtime.

Stress the “nothing of TS at runtime” line, because two important conclusions follow from it:

• Types cannot validate anything at runtime. Whether the data an API returns really matches the interface you wrote is beyond TS — for that you need something like zod. This is the biggest beginner misconception.
• An as assertion is just “trust me” and checks nothing. Overusing as and any is the same as turning TS off.

The costs — bring them up yourself: an extra build step, a learning curve (generics, conditional types, unknown vs any), writing your own declarations when a library ships none, and error messages for complex types that are hard to read.

Follow-up: “interface or type?” — interface can be declared again and merged and suits object and class contracts; type can do unions, intersections, mapped and conditional types, so it is more capable. In practice: “interface for object shapes, type for everything else” — but a consistent team choice matters more than which one you pick.

In one line: without running the code, purely by analysing the source, it finds places where the types do not line up. “Static” just means “at compile time, not at run time”.

Four concrete benefits — give examples, do not speak in the abstract:

• Errors surface earlier — a typo like user.nmae, a forgotten null case, a missing argument: they go red in the editor instead of arriving as a user report after release.
• Types are documentation — a signature says what it wants and what it gives back. And this documentation cannot go stale, because changing the code without changing the types fails the build.
• Refactoring with confidence — rename one field and every affected place errors. This is TS’s most underrated value, and on a large codebase it is more useful than bug prevention.
• Editor power — accurate completion, jump to definition, safe rename.

The limits — saying them is what shows you get it: it only guarantees the types are right, not that the logic is — fully typed code can still calculate the wrong salary. And it has no reach over external data at runtime (see #355), so type checking is not a substitute for tests.

Follow-up: “Do you turn on strict?” — always on a new project. The most valuable piece is strictNullChecks — it turns an entire class of “forgot the null check” runtime errors into compile errors.
A real example to go with it: npm run build on the source project for the React course fails precisely because tsc reports 10 errors (the test file is missing the vitest globals) — which shows type checking is part of the build, not an optional lint.