缺口三 · 同一个 Todo 换成 Redux ToolkitGap 3 · the same Todo app, moved to Redux Toolkit

The old way needed three pieces: action type constants, action creators, and a reducer built around one big switch. createSlice folds the three into one — you only write the reducers object and it generates the matching action creator and type (the type is "todos/added", that is, sliceName/reducerName).

The Immer part has to be said clearly: state.items.push(...) looks like it breaks “state is read-only”, but what you hold is a draft proxy — your edits get recorded and Immer produces a new object at the end, leaving the original state untouched byte for byte. The test proves it with two assertions: expect(next).not.toBe(empty) and “the original state still has length 0”.

But there is a boundary to remember: this mutate-anyway privilege only holds inside createSlice / createReducer. In components, in selectors, in your own plain functions, every immutability rule still applies.

prepare is the bonus point of this question. Generating the id needs nanoid(), and a reducer has to be pure — no random numbers, no clock (otherwise the same state + action gives different results and time travel is dead). prepare lets you generate the id while the action is being created, so the reducer only puts it in place.

The component has three useSelector calls: the visible list, the remaining count, the current filter. Each one re-renders only when its own slice changes.

Compare with Context (the variant 5 question): the moment the context value changes, every useTheme() component re-renders, even one that only uses theme while what changed was toggleTheme. That is the “Context has no fine-grained subscription” point from interview #349, in concrete form.

One trap you have to know: a selector must not return a new object. useSelector compares its result with === by default, and a fresh object like { a, b } is never equal, so any change anywhere in the store re-renders — the optimization cancels itself out.
Fixes: split it into several useSelector calls (what this implementation does, and the simplest), memoize with createSelector, or pass shallowEqual as the second argument.

Note that selectVisible is derived from items, and filtering does not touch the underlying data — the same rule as “writes have to act on the complete data” in variant 1. One test is there to verify that after filtering the underlying data still has two entries.

How to phrase the conclusion (for when they ask “should we bring in Redux?”): at this size Redux is over-engineering — one component’s own list is fine with useState. Redux pays off when the same state is read and written by many unrelated components, or when you need to trace a bug action by action.
Saying “I would use useState here, but if the requirement were XX I would reach for Redux” shows more judgment than silently writing the whole Redux setup.

One real benefit that falls out of this: because the reducer is a pure function, five of the eight tests render no component at all — they assert on reducer(state, action) directly. The tests run faster and the failure messages are more precise.