The previous lesson ended with an open question. useAssigneeFilter worked because the filter lived in App and from there flowed down to the two components that needed it. But as soon as that same filter is also needed by the router, the header, the report and a button buried six levels deep, the problems start: props that cross components that do not use them, copies of the same piece of data in two places that drift apart, and a data flow that no longer fits in your head. This lesson is about that, and it does not start with Redux: it starts with the problem, moves on to the cheaper alternatives —lifting state, Context, an external store— and only reaches Redux when the previous ones fall short, because most applications do not need Redux and saying so is part of teaching it well. You will see Redux's three principles and the action → reducer → new state → render cycle, with the direct parallel to your version-cached Board from 09-02 and your CustomEvents from 06-04; you will learn Redux Toolkit, which is the correct and current way to use it, with configureStore, createSlice, Immer, useSelector/useDispatch and createSelector's memoized selectors; you will solve asynchronous logic with createAsyncThunk and the three states of a request applied to your listTasks from 07-02, and you will get to know RTK Query as the specific tool for server state; you will see the DevTools with their time travel and why traceability is the real advantage; you will normalize 600 tasks with createEntityAdapter; and you will finish with the classic mistakes and an honest table of lightweight alternatives. All of it applied to Nómada Tasks' filter and board.

1. The problem before the tool
2. Prop drilling: the filter that crosses six components
3. Duplicated state and drift
4. The alternatives in order of cost
5. Alternative 1: lifting the state
6. Alternative 2: React Context
7. What Context is and what it is not
8. Alternative 3: an external store
9. When each one is enough
10. Redux's three principles
11. The action → reducer → new state → render cycle
12. The parallel with your Board and your CustomEvents
13. Redux Toolkit: why nobody writes Redux by hand
14. configureStore: the store
15. createSlice: actions and reducers together
16. Immer: writing mutations that produce immutable state
17. useSelector and useDispatch
18. Memoized selectors with createSelector
19. Asynchronous logic with createAsyncThunk
20. The three states of a request
21. RTK Query: the tool for server state
22. The DevTools and time travel
23. Normalizing data with createEntityAdapter
24. Nómada Tasks: the complete filter and board
25. Lightweight alternatives: Zustand, Jotai and native stores
26. Common Mistakes and Tips
27. Exercises
28. Conclusion

Redux has a bad reputation, and it earned it. For years it was the automatic answer to the question "how do I manage state?", even when the right question was "do I really need to manage global state?". Thousands of applications were written with three folders of boilerplate —actions/, reducers/, constants/— to store whether a modal was open.

That era is over. Modern Redux, through Redux Toolkit, is far more concise, and —more importantly— the industry learned to tell when it is needed and when it is not. This lesson respects that lesson learned: the problem first, then the cheap alternatives, and Redux at the end, once it has earned its place.

The problem has three faces, and it helps to look at them through Nómada Tasks' assignee filter, which is a perfectly realistic case.

Imagine that Nómada Tasks has grown. The board screen has this component structure:

The assignee filter is changed by AssigneeFilter, and it is needed by:

• TaskList, to filter.
• HeaderSummary, to say "3 of 6 tasks · 25 h".
• WorkloadReport, to highlight the filtered person.
• VisibleCount, in the footer.
• The router, to reflect the filter in the URL (?assignee=Ivan) as you did with the History API in 07-06.

If the state lives in App —which is the common ancestor—, it has to be passed downward:

That is called prop drilling: boring through the component tree with a prop that only matters in the leaves. Its costs are concrete:

An honest nuance that is almost never mentioned: with two or three levels, prop drilling is not a problem. It is explicit, it reads well, and it needs no tooling. The problem shows up with real depth and with several shared pieces of data at once. Do not rush to install anything over passing a prop two levels down.

The second symptom is more serious, and it is 10-01's problem 1 reappearing. When passing the prop becomes awkward, the temptation is for each component to keep its own copy:

Now there are two sources of truth for a single fact. As soon as one changes without the other —and it will happen—, the header says "3 of 6 tasks" while the list shows all six. The user sees a screen that contradicts itself.

This symptom has a subtler and very frequent variant: storing derived values. If in addition to assignee you store visible and visibleHours as state, you have three things to keep in sync instead of one that is computed. It is exactly the mistake from section 16 of 10-02, raised to global scale.

The rule that solves both faces: for every fact in the application there must be a single place where it lives, and everything else is computed from it. The remaining question is where that place is, and that is where you have to choose a tool.

This is the most important table of the lesson. Read it top to bottom and stop at the first row that solves your problem.

The last row is the trap half the industry falls into. Before deciding which store to use, decide what state you have. If you take an inventory of a real application, the split usually looks like this:

That 5% is Redux's territory. If you have done the split properly, a large application's global store is surprisingly small. When somebody says "Redux is too much boilerplate for this", what is almost always happening is that they are putting the 60% that does not belong there into Redux.

An important detail for Nómada Tasks: the assignee filter belongs to the URL-state row. That Marta can send the link ?assignee=Ivan over chat and her colleague sees the same thing is a feature, not a whim. The cheapest solution for the filter is neither Redux nor Context: it is the URL, which you already know how to handle from 07-06. We will use it as an example all the same because it illustrates the mechanism well, but it is worth keeping in mind.

It is what you already did in 10-02 and in your plain-JavaScript app.js with the state object. The data moves up to the nearest common ancestor of everyone who needs it.

In favor: zero cost, explicit flow, anyone reading the code sees where each piece of data comes from, no new dependencies.

Against: when the common ancestor is the root and there are five levels in between, section 2's prop drilling appears.

Before dismissing it, there is a technique that takes it much further than people think: compose with children instead of drilling.

The element is created in App, where the state lives, and placed in Panel, which only provides the structure. Panel gets its honest signature and its reusability back. This technique eliminates an enormous amount of prop drilling with no library at all, and that is why it comes before Context in the cost list.

Context lets a component make a value available to its whole subtree, without passing it through the intermediate props.

And the consumption, from any depth:

The intermediate components (Header, Panel) get their clean signature back. The prop drilling disappears.

Here is the most widespread misunderstanding in all of React, and it deserves to be explicit:

Context is a transport mechanism, not a state manager.

Context solves "how do I get this value down there". It does not solve "how do I organize the changes", "how do I avoid unnecessary renders" or "how do I know who changed what". The state still lives in an ordinary useState; Context only avoids the prop staircases.

And it has a technical limitation with real consequences: when the context's value changes, every component that consumes it re-renders, regardless of which part of the value they use.

If filter changes, the component that only reads theme repaints too. With a small context and infrequent changes (the signed-in user, the language, the light/dark theme) it is completely irrelevant. With a context that changes on every keystroke and forty consumers, it is a measurable performance problem.

The two usual mitigations:

1. Split into several contexts by rate of change: one for what almost never changes (user, theme) and another for what changes a lot (filters). It is the same idea as 09-05's manualChunks by rate of change.
2. Separate value and actions into two contexts: components that only dispatch actions do not repaint when the value changes, because the functions are stable.

The practical conclusion: Context + useState covers the vast majority of applications perfectly. If that combination is enough for you, you need nothing more and this is the end of the lesson for you. The following sections explain what happens when it is not enough.

A store is an object that lives outside the component tree, holds the state, lets you subscribe to it and notifies subscribers when it changes.

The decisive difference from Context is selective subscription: each component declares which slice of the state it cares about, and only re-renders if that specific slice changes. It is, conceptually, the difference between broadcasting to everyone and notifying the interested parties — and if that sounds familiar, it is because it is exactly the difference between the virtual DOM and 10-01's signals, applied to state instead of to the screen.

And something that is appreciated later: since the store lives outside React, it can be used from outside React. Your BoardChannel from 07-04 can dispatch actions when it receives a WebSocket message without being inside any component. A service worker can query it. A test can set it up without rendering anything.

Redux is a store of that kind, with three very specific decisions on top. Let us get to them.

Before getting into Redux, the decision table that avoids 90% of the mistakes:

Redux is defined by three rules. They are not arbitrary: each one buys a specific property.

Principle 1 · A single source of truth. All of the application's state lives in one object, inside one store.

• What it buys: there are no copies to drift apart, the complete state can be dumped to a file, saved in localStorage (07-01), sent in a bug report or restored as it is.

Principle 2 · The state is read-only. The only way to change it is to dispatch an action: a plain object that describes what has happened.

• What it buys: every change goes through a single point. They can be logged, recorded, replayed and rolled back. Nobody can change the state behind your back.

Notice the vocabulary: the action describes what has happened (assigneeChanged), not what to do (changeAssignee). It is a convention with consequences: a single action can affect several parts of the state, and the action log reads like a chronicle of what the user did.

Principle 3 · Changes are made with pure functions. A reducer is a function (currentState, action) => newState. Pure: no effects, no requests, no Math.random(), no Date.now(), no mutating the input.

• What it buys: the same sequence of actions always produces the same state. That is what makes time travel, bug replay and trivial testing possible.

And yes, the word "reducer" is the one from 04-05: the signature (accumulated, item) => newAccumulated is identical to reduce's. Your application's state is literally the result of reducing the action history over an initial state.

Five properties of this cycle worth fixing:

1. It is unidirectional. Data always travels in the same direction. There are no shortcuts: a component cannot write to the state directly.
2. Its core is synchronous. dispatch → reducers → new state happens in one go. Asynchrony is handled outside, in the middleware (section 19).
3. It is serializable. Actions and state are plain data, so they can be saved, sent and replayed.
4. It is auditable. Every change has a name and some data. None of them is anonymous.
5. It is interceptable. Middleware can log, delay, cancel or transform actions without touching reducers or components.

Now the part that stops all this from sounding abstract. You have already built the three pieces of this cycle, separately and under other names.

The equivalence of the last two rows is especially exact. Your Board does this:

And Redux's createSelector does exactly the same, with one difference: where you compare a version counter, it compares the references of the inputs. Since the state is immutable, if the reference has not changed, neither has the content. Immutability makes the version counter unnecessary: the reference is the counter.

And there is a real difference in Redux's favor worth acknowledging. Your CustomEvents are a broadcast mechanism: anyone can listen, there is no central registry of who listens to what, and to follow the flow you have to search for the string 'task:advanced' across the whole project. Redux enforces that every change goes through a point that can be observed. That is the real advantage, and it is not about performance: it is about traceability.

Classic Redux required writing, for every change, a constant, an action creator, a switch case and an immutable update by hand:

Multiply that by forty actions and by nested updates of the kind {...state, tasks: {...state.tasks, [id]: {...state.tasks[id], status: 'done'}}} and you will understand the bad reputation.

Redux Toolkit (RTK) is the official answer, and today it is the correct way to use Redux. It is not an alternative or an optional layer: the official documentation advises against writing Redux without it. It brings four things:

Two packages: @reduxjs/toolkit (the store, independent of the view) and react-redux (the hooks that connect it with React).

And the connection with React, once only, at the root:

configureStore comes with things enabled by default that are worth knowing about, because they are among the most helpful day to day:

• The DevTools are connected with no configuration at all.
• A mutation checker warns in development if any reducer mutates the state outside Immer.
• A serializability checker warns if you put something into the state that is not plain data: a Date, a Map, a promise, a class instance. This is annoying at first and appreciated later, because it is what protects principle 1.

That last point has a direct consequence for Nómada Tasks: your Task instances with their private #status cannot go into the store. In Redux, the state is plain data and the rules live in functions. It is the same trade you already accepted in 10-02 when choosing object literals for React's state, now turned into a checked norm.

A slice is a portion of the state with its actions and its reducer, defined in one go:

What createSlice generates automatically:

• The action creators: assigneeChanged('Iván') returns { type: 'filter/assigneeChanged', payload: 'Iván' }. The type is composed from name + the reducer's name, so there are no constants to maintain and no risk of collision.
• The combined reducer, which dispatches internally by type.

Compare with section 13's classic Redux: four places have become one.

state.assignee = action.payload looks like it violates principle 3. It does not, and understanding why avoids a lot of mistrust.

RTK includes Immer, a library that wraps the state in a Proxy (the same mechanism as Vue's reactivity in 10-04). That proxy intercepts the writes and, instead of applying them to the real object, notes down what you wanted to change. When the reducer finishes, Immer builds a new object applying those changes, reusing everything that was not touched.

The value of this really shows with nested state. Without Immer:

With Immer:

And a valuable property that gets overlooked: Immer produces structurally shared updates. The tasks that do not change keep their exact reference. That is precisely what 10-02's React.memo needs in order not to repaint the 599 cards that have not changed.

Three Immer rules to respect:

1. Either you mutate the draft, or you return a new value. Never both.

2. To replace the whole state, return it, do not reassign the parameter:

3. Immer only works inside RTK's reducers. Outside —in a component, in a selector— 04-07's immutability rules still apply exactly as they were.

The two hooks that connect components with the store:

Notice what has disappeared: this component receives no prop related to the filter. Neither value nor onChange. Section 2's six levels of prop drilling have evaporated, because the component talks to the store directly from wherever it is.

useSelector(fn) runs fn(state) and returns the result, subscribing to it. And here is the key difference from Context: the component only re-renders if the selector's result changes, not if anything in the store changes. Changing state.tasks does not repaint this <select>.

The comparison is done by default with Object.is, the same reference comparison from 10-02. Out of that comes the most frequent mistake with Redux:

Three solutions, in order of preference:

useDispatch() returns the dispatch function. It is stable between renders, so it can be used in effect dependencies with no problem — unlike the functions you create yourself.

A selector is a function that extracts or computes something from the state. Writing them separately has two advantages: they are reusable, and they decouple components from the shape of the state. If tomorrow state.filter.assignee moves to state.ui.filters.assignee, only the selector changes.

How createSelector works, which is where the parallel with 09-02 closes:

1. It runs the input selectors, which are cheap.
2. It compares their results with those of the previous call using Object.is.
3. If all of them are identical, it returns the cached result without running the computation.
4. If any of them changed, it recomputes and stores.

It is your version cache, with the immutable state's reference acting as the version number. And it has an effect that is not about performance but about correctness: since it returns the same reference as long as the inputs do not change, it solves the previous section's useSelector problem. Without memoization, filter creates a new array every time and the component always repaints.

Two warnings:

• By default the cache has size one. If two components call the same selector with different states —typical with selectors parameterized by id—, they cancel each other out. RTK offers ways to create one instance per component or to enlarge the cache.
• Memoizing trivial selectors contributes nothing. (s) => s.filter.assignee does not need createSelector: it computes nothing and already returns a stable reference. It is the same warning as in 09-01 and 10-02: memoizing has a cost.

Reducers are pure: they cannot request data. Asynchrony lives in the middleware, and RTK ships the thunk already configured, which lets you dispatch a function instead of an object.

createAsyncThunk builds that function and automatically dispatches three actions per request:

Three important details:

• signal comes free. RTK creates an AbortController for each execution of the thunk and cancels it if promise.abort() is called or if the request is discarded. Your fetchJson from 07-03 accepts it as it is: zero adapters.
• rejectWithValue exists because an Error is not serializable and would violate principle 1. You store a plain object with whatever you want to display.
• Deduplication can be configured with the condition option, so as not to fire the same request if one is already in flight.

Each thunk dispatches tasks/load/pending, tasks/load/fulfilled and tasks/load/rejected. The slice picks them up in extraReducers:

And the consumption:

Four points:

• 10-02's race condition still exists. If two loads are dispatched, the last one to arrive wins. The fix is to abort the previous one, as here, or to use condition.
• A single phase field instead of three booleans: 10-02's impossible-state rule.
• statusChanged implements R6 in the reducer, with the same NEXT table from your plain-JavaScript domain. The business rules have not moved into Redux: they are consulted from it.
• The reducer is pure and therefore trivial to test with Jest, without mounting React or the store: reducer(previousState, action) and you check the output. It is Redux's best property for 08-03's tests.

The previous section works, but repeat it for fifteen resources and 10-02's questions will appear: who caches?, who deduplicates?, who invalidates when a task is created?, who refreshes when you come back to the tab?

RTK Query is the answer RTK ships with, with the same philosophy as TanStack Query:

What has disappeared from this code: the useEffect, the AbortController, the loading state, the error state, the manual dispatch and —most importantly— the reload after the mutation. The tag system does it by itself.

10-01's conclusion is confirmed: if 60% of your state is server state and RTK Query manages it, what is left for the manual slices is very little. And that is exactly what should be left.

With the Redux DevTools extension installed and configureStore, you get this with no configuration at all:

Time travel works because of principle 3: since reducers are pure, the state at moment n can be recomputed by replaying the first n actions over the initial state. No copies of the state are stored: the history is stored and the state is recomputed. It is the same reasoning as in 03-07 about deterministic functions, applied to a whole application.

And here is Redux's real advantage, which is neither performance nor prop drilling:

When somebody says "my filter gets cleared when I come back from the detail view and I do not know why", with Redux you open the DevTools, reproduce the journey and see the action that did it, with its name and its origin. Without Redux, you search across the project and guess.

Compare with your situation in Nómada Tasks: to debug why the board changes unexpectedly, you have console.log, breakpoints and searching for emit( across the whole codebase. It works —you did it in 08-01— but it is reconstructing by hand what here is recorded. In an application of twenty screens and six people, that difference is measured in days.

The price is just as clear: for this to work, every change has to be a named action. That discipline is the cost, and it is only paid gladly when the application is big enough to need the traceability.

With the 600 tasks from 09-01's load test, storing a flat array has the problems you already measured in 09-02: looking up by id is O(n), and updating a task with map creates a new 600-position array.

Normalizing means storing the data as a dictionary by id plus a list of ids:

It is your Map index from 09-02, expressed with plain objects because the state must be serializable. createEntityAdapter manages it for you:

Concrete advantages, with 09-02's numbers:

And a real disadvantage: to paint the list the array has to be rebuilt, which is what selectAll does. That is why it comes memoized. With six tasks, normalizing is complicating things for the fun of it; with six hundred and frequent updates, it is the difference between smooth and sticky — the same boundary 09-02 drew for the Map index.

Let us put the pieces together in the module's target screen. The domain stays the same, in plain JavaScript:

The tasks slice:

The selectors, with the assignees included:

The components, without a single filter prop:

Check the canonical numbers: with no filter, "6 of 6 tasks · 45 h open". With "Iván", "3 of 6 · 25 h". With "Lucía", "1 of 6 · 14 h". With "Marta", "2 of 6 · 6 h". On pressing "Start" on Carpentry workshop quote, tasks/statusAdvanced is dispatched with {id: 6}, and in the DevTools you see the action, that task's exact diff and you can go back.

And now this section's honest balance sheet, which is what 10-01 asked for:

Does it pay off for Nómada Tasks as it stands? No. With one screen and two consumers of the filter, 10-02's lifted state —or the URL directly— is the right answer, and adding Redux is complexity with no counterpart. Would it pay off in the product version for twenty workshops? Yes, and because of the table's last row more than any other.

Redux is not the only way to have an external store, and for years it has not been the most popular one for new mid-sized projects.

Zustand — a minimalist store with hooks and selective subscription:

No Provider, no actions, no reducers, no boilerplate. And with the same selective subscription as useSelector.

Jotai — atomic state: instead of one big object, many small atoms that compose. Derived values are declared from other atoms, in the style of 10-01's signals:

The honest table:

How to decide, without dogma:

• Start with nothing. useState + lifting + composition with children goes much further than people think.
• If 60% is server state, solve it with a data cache; the global problem almost disappears.
• If you need a store and the team is small, Zustand or Jotai. Less ceremony, same result.
• If you need traceability, conventions for six people and an application that will live for years, Redux Toolkit wins on the last row: the action history and the DevTools.
• If you already work in Vue or Angular, their native stores —Pinia and services with signals— are integrated and are usually the right answer. You will see them in 10-04 and 10-05.

Installing Redux out of habit. It is the ecosystem's historical mistake. The right question is "what state do I have and of what kind?". If, once you take the inventory, it turns out that almost everything is server and local state, Redux is unnecessary.

Putting server state in manual slices. It is 60% of the state and it has rules of its own (staleness, refresh, invalidation, retries). It goes in RTK Query or TanStack Query. Putting it in slices is writing a worse cache by hand.

Storing derived values in the state. If openHours follows from tasks, it is not stored: it is computed with a selector. Storing it creates two sources of truth and reintroduces 10-01's problem 1. It is the same mistake as deriving state with useEffect in 10-02.

Returning new objects or arrays from useSelector. A new reference on every call, a render on every store action. Use primitive selectors or memoize with createSelector.

Mutating the state outside a reducer. Immer only works inside RTK's reducers. In a component, a thunk or a selector, mutating the state breaks change detection and corrupts time travel. configureStore's checker warns in development: listen to it.

Mixing mutation and return in the same reducer. Either you mutate the draft, or you return a new value. Both at once has undefined behavior.

Putting non-serializable things in the state. Dates, Maps, Sets, promises, functions, class instances with private fields. They break principle 1, the DevTools and persistence. Store ISO strings (like your dueDate) and plain objects.

Naming actions as commands. setAssignee describes what to do; assigneeChanged describes what happened. The second form lets several reducers react to the same fact and makes the history readable.

One giant slice. Split by domain: filter, tasks, session. A 400-line slice is as hard to maintain as any other 400-line file.

Tip: reducers are the best place to test the logic. They are pure functions: reducer(previousState, action) and you compare the output, with nothing rendered. It is the cheapest thing Redux offers for 08-03's tests.

Tip: store in the URL whatever has to be shareable. Filters, page, sorting and active tab belong in the URL, not in the store. Marta sending ?assignee=Ivan over chat is a free feature, and you have known how to do it since 07-06.

Tip: when in doubt, start with no store. Adding Redux to an application with well-modeled state is a day's work. Removing it from one where everything goes through it is a quarter.

For each of these five pieces of data in the product version of Nómada Tasks, decide where it should live, choosing between: local state, lifted, URL, server-data cache, or global store. Justify it with a criterion from this lesson and say what would happen if you put it in the wrong place.

1. Whether a card's action menu is open.
2. The task list returned by listTasks().
3. The assignee currently being filtered by.
4. The signed-in user and their permissions.
5. The text Marta has typed so far in the new-task form, unsubmitted.

Write a sessionSlice for the product version, with this initial state and these three actions:

• signedIn: receives { user, permissions } and stores them.
• signedOut: returns to the initial state.
• themeToggled: switches between 'light' and 'dark'.

Then write:

1. A selectCanEdit selector that returns true if the permissions include 'tasks:edit'.
2. A memoized selectEditableTasks selector that, combining selectVisible and the permissions, returns the tasks the user can edit: all of them if they have the permission, and only their own (where they are the assignee) if they do not.
3. A Jest test of the reducer, without rendering anything.

An additional question: why does themeToggled carry no payload?

This is a real fragment of your plain-JavaScript Nómada Tasks:

1. Translate it into the Redux cycle: identify which part is the action, which the reducer, which the dispatch and which the render.
2. Write the complete equivalent in Redux Toolkit.
3. Explain three concrete things that are gained with the translation and two that are lost.
4. What happens in each version if changeStatus throws a RuleError for violating R6?

Solution 1

Item 3 deserves a comment: it is the case most people get wrong, precisely because "several components share it" sounds like global state. But sharing it between components is a transport problem; that it survives a reload and travels in a link is a product requirement, and only the URL satisfies it. A modern router lets you read and write query parameters as if they were state, so the ergonomics are the same.

Solution 2

The test, with no React and no store:

Why themeToggled carries no payload: because the new value is derived from the current one, it is not supplied by whoever dispatches. It is the same reason 10-02 used setCount((n) => n + 1) instead of setCount(count + 1). If the component computed the new theme and sent it as a payload, two presses in quick succession could send the same value. With the decision inside the reducer, which always sees the most recent state, that is impossible.

The last test deserves attention: freezing the input state with Object.freeze is an excellent technique for verifying that a reducer really is pure, and it is the testing equivalent of the checker configureStore enables in development.

Solution 3

1 · The translation of the pieces:

An important note: in the original, emit and changeStatus are two separate things — first you mutate and then you announce. In Redux they are the same thing: the dispatch is simultaneously the announcement and the cause of the change. That unification is what makes the action history complete by construction; in your version, somebody can call changeStatus without emitting the event, and then the announcement is lost.

2 · The complete equivalent:

3 · Three things that are gained:

• Complete traceability. Every advance is recorded in the DevTools history with its id and its diff, and you can go back. In the original version, to find out why a task ended up as 'done' you have to set a breakpoint and reproduce the journey.
• The logic is testable without a DOM. reducer(state, statusAdvanced({id: 6})) is a function call. The original version needs jsdom, a container, a template and a simulated click (08-05).
• A single path for the change. It is not possible to change a task's status without dispatching the action, so no mutation stays outside the log. In the original version, board.changeStatus(6, 'done') from the console changes the model without telling anybody and without repainting.

Two things that are lost:

• Immediacy and weight. Four new files, two dependencies, ~13 kB and a layer of indirection: to follow what the button does you have to go from the component to the action, from the action to the slice and from the slice to the selector. In the original version it is all in twenty consecutive lines.
• The domain's rich objects. The state is plain data: you lose the Task class with its private #status, its getters and its methods, which guaranteed R6 by encapsulation (05-03). In Redux the guarantee is by convention: nothing stops another reducer from writing task.status = 'done' and skipping NEXT.

4 · What happens if R6 is violated. In the original version, changeStatus throws a RuleError, the exception propagates up through the click handler and —if nobody catches it— dies in the console: the interface never finds out and nothing is shown to the user. In the Redux version a reducer cannot throw: it must be pure and total. The invalid transition becomes state (lastError), which the interface can display as an accessible warning. It is a difference of philosophy worth understanding: in Redux, the domain's foreseeable errors are data, not exceptions; exceptions are reserved for what is genuinely unexpected. It is, by the way, exactly the same reasoning with which 02-05 distinguished between expectable errors and programming faults.

You have learned state management starting where you had to start: with the problem. You know its three faces —the prop drilling of the filter crossing six components that do not use it, the duplicated state that makes the header and the list contradict each other, and the stored derived values that reintroduce 10-01's problem 1 inside the framework that came to solve it. And you have the table of alternatives in order of cost, with the instruction to stop at the first row that solves your case: nothing, lifting the state, Context, a lightweight store, Redux. With the inventory almost nobody takes: in a real application, 60% of the state is server state, 25% local, 10% URL and only 5% genuinely global — and that 5% is Redux's territory.

You know that lifting the state goes much further with composition: passing already-created elements as children or as content props removes prop drilling without installing anything. You know what Context is —a transport mechanism, not a state manager— and what its real limitation is: all consumers repaint when the value changes, with the two mitigations of splitting by rate of change and separating value from actions. And you know what an external store adds: selective subscription, and the possibility of using it from outside React —from your BoardChannel of 07-04, from a test, from anywhere.

You know Redux's three principles and, more importantly, what each one buys: a single source of truth (nothing to drift apart, serializable and restorable state), read-only state through actions (every change through an observable point), and changes with pure functions (the same sequence always produces the same state, which is what makes time travel possible). You have the action → reducer → new state → render cycle with its five properties, and the exact parallel with what you had already built: your state object, your CustomEvents with emit, your handler that applied the change and called render(), and your version cache from 09-02 — where immutability makes the version counter unnecessary because the reference is the counter.

You are fluent in Redux Toolkit as the correct and current way: configureStore with its mutation and serializability checkers, createSlice that turns four places into one, Immer with its proxy that records writes and produces new state while structurally sharing what was not modified —with its three rules: do not mix mutation and return, return in order to replace entirely, and do not expect magic outside reducers—, useSelector with its selective subscription and its new-reference trap, and createSelector as memoization of derived values. You know how to solve asynchrony with createAsyncThunk and its three automatic actions, with the signal that integrates your AbortController from 07-03 and rejectWithValue so as not to put exceptions in the state; and you know that server state has a tool of its own, RTK Query, with cache by key, invalidation by tags, automatic refresh and optimistic mutations.

You are clear about where Redux's real advantage lies, which is neither performance nor transport: it is traceability. The history of named actions, the diff per action, the time travel that works because reducers are pure, and the possibility of exporting somebody else's state and reproducing their bug on your machine. And you know how to normalize with createEntityAdapter when there are 600 tasks, which is your Map index from 09-02 expressed in plain data, with the same boundary: below a certain size, it complicates without gaining anything.

You have seen Nómada Tasks' filter and board in Redux, with App carrying not one filter prop and the canonical numbers intact, and the honest balance sheet: zero props crossing the tree and complete traceability, in exchange for four files, two dependencies, 13 kB and a layer of indirection. With the conclusion 10-01 asked for: for Nómada Tasks as it stands, it does not pay off; for the product version for twenty workshops, it does. And you know the lightweight alternatives —Zustand, Jotai, and other ecosystems' native stores— with the table that says when each one is the reasonable answer.

Everything seen so far has happened inside the same model: function components, virtual DOM, immutable state, manual memoization. The next lesson changes all three. You are going to see the same screen in a framework that groups template, logic and styles in a single file, that detects dependencies automatically with proxies instead of comparing trees, and where the equivalent of useMemo is not an optimization but the natural way to write. It is 10-01's family 2 of reactivity, in its most polished form: Vue.js Basics.