CicloUrbano's store already has shape and behavior: three complete slices, business rules in the reducers, normalized entities, selectors living next to their domain, and async loading with createAsyncThunk. All of that exists today without a single component knowing about it. This lesson closes the loop with react-redux, and it does so by giving disproportionate attention to one single issue, because it's the one that separates an integration that works from one that re-renders the whole app on every action: the golden rule of identity comparison in useSelector. You'll see how a component subscribes and when it re-runs, reproduce the bug from a selector that returns a new array and fix it four different ways, rewrite CataloguePage, BookingsPage, BookingsPanel and UserMenu on top of the store, decide with real arguments what stays out of Redux, dispatch thunks while showing loading and error states, learn to read connect in legacy code, debug with the DevTools history, and organize code by feature. It closes with an honest comparison between context + reducer, Redux Toolkit and Zustand for an app like this one.

1. useSelector: how a component subscribes
2. The golden rule: identity comparison
3. The bug, reproduced
4. The four fixes
5. createSelector in practice
6. useDispatch, and why dispatch is stable
7. UserMenu on top of sessionSlice
8. CataloguePage: the URL filter and the store coexisting
9. BookingsPage and BookingsPanel on top of bookingsSlice
10. Dispatching thunks from a component
11. What stays out of Redux
12. connect and mapStateToProps: only for reading legacy code
13. Debugging with Redux DevTools
14. Code organization: folder per feature
15. An honest final comparison

What useSelector does under the hood, step by step:

1. It subscribes to the store via store.subscribe(...), using the Provider you placed in main.jsx (07-03).
2. It runs the selector function with the current state and returns the result.
3. After every dispatched action, it runs the selector function again with the new state.
4. It compares the new result with the previous one using Object.is (reference identity comparison).
5. If they differ, it triggers a re-render of the component. If they're equal, it does nothing.

That step 5 is the granular selection that context couldn't give you (07-02). A component subscribed to state.bookings.ids.length doesn't re-render when the theme changes, when someone types in the search box, or when a booking gets confirmed without changing the count.

And step 3 is the one to always keep in mind: the selector function runs after every action, no matter which domain it belongs to. session/signedIn, catalogue/searchTermChanged, bookings/bookingConfirmed: all of them make every selector in every mounted component run. Selectors must therefore be cheap.

useSelector compares with Object.is. If your selector builds a new object or array on every call, the comparison will always say "it changed," and the component will re-render on every action dispatched to the store, no matter where it came from.

It's the same identity trap you saw in 07-02 with a provider's value, in a different place and under a different name. And here it's worse, because a badly subscribed component re-renders on actions that have nothing to do with it.

The "a reference stored in state" row explains why 07-04's normalization is such a good idea: since Immer reuses the references of the branches that don't change, state.bookings.entities['res-01'] is literally the same object as long as nobody touches that booking, and identity comparison works on its own.

Let's look at the problem with the derived selector from 07-04, which is exactly the dangerous case.

Remember the selector: it ends with [...filtered].sort(...). It returns a new array every time.

Try this in the browser with DevTools open:

1. Type a letter in the search box → catalogue/searchTermChanged → the component runs. Correct: the catalogue changed.
2. Click the theme button... and nothing happens here, because the theme isn't in Redux. Good call.
3. Sign in → session/signedIn → CataloguePage runs. The catalogue hasn't changed at all.
4. Confirm a booking → bookings/bookingConfirmed → CataloguePage runs again.

With console logging you'll see the line appear on every action in the app. And it's not just a render: since visible is a new array, BikeList gets a new prop and re-renders too, with every BikeCard inside it.

In development, react-redux warns you in the console:

It's a warning that's very easy to ignore, and very expensive to ignore.

The simplest one, the fastest one, and the one people forget most often.

When what you need is two or three loose values, several useSelectors over primitives always win. There's no memoization to maintain, no dependencies to declare, and each one only re-renders when its own value actually changes.

The generalization of the previous one. A component can have as many useSelectors as it needs; the cost of each subscription is negligible.

Here ids is safe because it's the array that lives in state, not one built on the fly. Immer only replaces it when a booking is added or removed.

When the selector actually has to compute something — filter, sort, aggregate — the answer is memoizing it. That's the whole of section 5.

useSelector accepts a second argument: a function that decides whether two results are equal.

shallowEqual compares key by key with Object.is. The object is still new on every call, but since its surface content is equal, useSelector doesn't re-render.

RTK also offers a useSelector with createSelector already built in, and react-redux exports useDebugValue-friendly helpers, but in practice these four options are enough.

Which to pick:

Order of preference: 1 → 2 → 3 → 4. The fourth comes last because shallowEqual walks the object on every comparison and doesn't save the selector's own work, only the re-render.

createSelector comes from Reselect, and RTK re-exports it. It takes a list of input selectors and a combiner function, and it memoizes: if the inputs are identical to the previous call's, it returns the previous result without recomputing, and with the same reference.

What happens now in section 3's scenario:

Three important warnings about createSelector:

1. Input selectors must be cheap and stable. They always run; what you save is the combiner function. If an input returned a new object every time, memoization would never hit and the selector would be worse than not having one.

2. Memoization has a size. Historically, Reselect kept only one cached result, so a selector with an argument used from two components with different arguments would keep invalidating each other on every call. In Reselect 5 — the one RTK 2 ships — the default memoization (weakMapMemoize) handles several arguments well, and that problem disappears in most cases. If you need the classic behavior with several consumers, the pattern is a selector factory:

3. Don't memoize what costs nothing. createSelector wrapped around (state) => state.session.user is noise: there's no computation to save, and the reference is already stable. Memoize when the selector builds something.

createSelector and useMemo solve the same problem at different layers: one memoizes over the store's state and serves every component; the other memoizes inside a single component. The details of when memoizing pays off are in 08-03.

useDispatch returns the store's dispatch function, which is always the same one: the store is created once, in store.js, and its dispatch never changes for the life of the app.

Practical consequences:

• A component that only dispatches never re-renders because of Redux. It isn't subscribed to anything. It's the automatic equivalent of the state/actions split that in 07-02 had to be set up by hand with two contexts.
• dispatch can go in a useEffect's dependencies without causing loops. In fact, the hooks linter will ask you to include it, and doing so is correct.
• There's no need to memoize handlers that only dispatch, out of fear for identity: the function that does the work is stable.

Notice the project's naming pattern applied to Redux: handleClick is the component's internal handler and bookingConfirmed is the action creator imported from the slice. The "handlers handleX inside, props onX outward" convention still holds; what changes is that now, instead of calling an onConfirm prop, many components dispatch directly.

A design nuance worth thinking about: not every component should dispatch. A BikeCard that dispatches actions stops being reusable and stops being testable without a store. The sensible rule is that pages and panels connect; presentational components receive props. BikeList and BikeCard keep receiving bikes and onSelect just as before.

The simplest case, and the one that teaches fix 1.

Three points that sum up half the lesson:

• selectIsOperator returns a boolean. It's derived state computed in the selector (07-04), and being a primitive, identity comparison works perfectly.
• open stays in useToggle. It's exactly the example from section 11.
• signedOut() is called with no arguments and returns { type: 'session/signedOut' }. And remember from 07-04 that bookingsSlice reacts to that very action in its extraReducers, clearing out the bookings: one dispatch, two domains updated, no coupling between components.

This is the most interesting design decision of the lesson, and it's been pending since 07-04.

The problem: ?tipo= has lived in the URL since 06-02, and catalogueSlice has a type field. Two sources of truth for the same piece of data is exactly what 07-01 forbids.

The decision: the type stays in the URL and disappears from the slice. The URL is the source of truth because the filter needs to be shareable by link and survive a reload, and no client store gives you that. The slice keeps searchTerm and sort, which aren't link-shareable by product decision, and selectVisibleBikes receives the type as an argument, exactly as written in section 5.

What's worth remembering from this component:

• Three sources of state coexist without duplicating anything: the filter in the URL, the search term and the catalogue in the store, and the selection in a local useState. Each one where it belongs, following 07-01's taxonomy.
• useEffect with [dispatch] as its only dependency works precisely because dispatch is stable. And the thunk's condition (07-04) keeps StrictMode's double render from firing two requests.
• BikeList and TypeSelector don't know about Redux. They still receive props. They're presentational components, and staying that way keeps them testable and reusable.
• The alternative that was NOT chosen: keeping type in the slice and syncing it with the URL through a useEffect. It would have worked almost all the time, and would have failed on the hard cases — pasting a URL, the "back" button, opening in a new tab — on top of adding an extra render on every filter change. When there are two candidates for source of truth, you pick one and the other stops existing.

This pair of components illustrates Redux's most efficient pattern with lists, and it's worth explaining well:

• The parent selects only the identifiers. ids is the array that lives in state; it only changes reference when a booking is added or removed. Confirming a booking doesn't re-render BookingsPage.
• Each child selects its own entity by identifier. Thanks to Immer, entities['res-01'] keeps its reference as long as nobody touches that booking, so confirming res-01 re-renders only the res-01 row.

With a list of two hundred bookings, the difference between this pattern and selecting the full array in the parent is two hundred renders versus one. It's the practical payoff of why state was normalized in 07-04.

A thunk is dispatched just like an action: dispatch(fetchBikes()). The difference is that it returns a promise with useful methods.

Important points:

• .unwrap() turns the thunk's result into something you can use try/catch with: it returns the fulfilled payload, or throws the rejected error. Without it, await dispatch(...) always resolves, even when the request failed, and the catch never runs. It's the most common mistake when dispatching thunks.
• Loading and error are read from the store, not from a parallel useState. A single source of truth, and one visible in DevTools too.
• Navigation and the notice happen in the component, not in the thunk. A reducer doesn't navigate, and a thunk shouldn't know about the router: UI logic stays in the UI.
• disabled={submitting} and aria-busy (03-06) prevent a double submit from the UI; the thunk's condition (07-04) prevents it from the store too. Both things, not just one.

Having a store doesn't mean putting everything in it. Here's the reasoned list for CicloUrbano.

The rule that sums up the table: something belongs in Redux when its change is a domain event worth recording. "The user opened a menu" isn't one. "The user cancelled a booking" is.

⚠️ This section exists solely so you can read projects written before 2019. connect still works and react-redux still maintains it, but it isn't used in new code. It won't appear again in the course.

Before hooks, connecting was done with a higher-order component:

The hooks equivalent:

Why it was abandoned: connect adds a wrapping component for every connection — which clutters the tree in DevTools —, forces you to split the "dumb" component from the "connected" one, has an API with four different ways of writing mapDispatchToProps, and is notoriously hard to type. Hooks do the same thing with less indirection.

What is worth keeping from that era is the conceptual distinction between presentational and connected components. connect enforced it; with hooks you have to keep it up by discipline, and it's the rule from section 6: pages and panels connect, presentational components receive props.

Now that the app dispatches real actions, the tool from 07-03 is worth what it promised. A concrete example of how the way you search for a bug changes.

The symptom: "sometimes, when confirming two bookings in a row, the second one shows up cancelled."

Without Redux, the investigation would be: put a console.log in three handlers, try to reproduce it, suspect a closure problem, suspect a race condition, add more logging.

With Redux DevTools:

1. Reproduce the bug once.
2. Look at the action list. There's the whole real sequence:

   session/signedIn
   catalogue/fetchBikes/pending
   catalogue/fetchBikes/fulfilled
   bookings/bookingConfirmed     ← payload: 'res-01'
   bookings/bookingCancelled     ← payload: 'res-02'   ⚠️ where does this come from?
   bookings/bookingConfirmed     ← payload: 'res-02'
   

3. The extra action is identified in twenty seconds. The bug isn't in the reducer or the state: there's an onClick dispatching bookingCancelled when it shouldn't, probably a mis-wired handler on the second row's button.
4. Hit skip on that action and check that without it the result is correct: confirms the diagnosis without touching any code.
5. Look at the Diff panel for the suspicious action to see exactly what changed.

And if a user reported the bug, they can export the history as JSON and you can import it: you reproduce their exact session on your own machine.

What really changes isn't the speed, it's the nature of the question. Without Redux you ask "why is the state wrong?" With Redux you ask "which action left it like this?", and that question always has an answer, because it's right there in the list.

Three functions you'll use daily:

So far CicloUrbano is organized by type: components/, pages/, hooks/, contexts/, reducers/. With Redux, the community recommends something else.

Rules that make this work:

1. components/ holds only what's genuinely shared. If only one domain uses something, it lives in that domain's folder.
2. A domain never imports from inside another one. If bookings needs something from catalogue, it's imported from that folder's root, and if that starts happening a lot, the boundary between domains is drawn wrong.
3. routes.jsx stays at the root, and it does import from several domains: it is, by definition, the map that ties them together.
4. The migration is gradual. You move one domain at a time, and the app keeps working at every step.

In a project the size of CicloUrbano, organizing by type still holds up. The reason to switch isn't aesthetic: it's that folder-per-feature makes coupling visible. When bookings/ needs five things from catalogue/, it shows up right in the imports, and it's a design signal, not a filing detail.

With the whole module behind you, here's the comparison for an app like CicloUrbano.

And the recommendation, plainly stated:

For CicloUrbano, honestly: it's a small app with a small team, and context + useReducer would still be enough. Redux got introduced because it's what you'll run into on the job, because the mental model — actions, pure reducers, selectors, normalized state — transfers whole to Zustand and to Jotai, and because DevTools are a tool worth having used at least once. What we're not going to do is pretend it was essential.

One last warning, the most important one in the module and the thread leading into the next lesson: once 07-06 pulls the bikes, stations and bookings out of the store into a server-state cache, what's left in Redux will be very little. In many real apps, after that move client state fits in two contexts, and that's a legitimate conclusion to reach — after understanding Redux, not by avoiding it.

Mistake 1: a selector that returns a built object or array. The number one mistake, by far. Causes re-renders on every action in the app. Primitives, state references, or createSelector.

Mistake 2: grouping several values into an object "for convenience." useSelector((s) => ({ a: s.x, b: s.y })) without shallowEqual is mistake 1 in disguise. Two useSelectors are simpler and faster.

Mistake 3: forgetting .unwrap() when dispatching a thunk. await dispatch(thunk()) always resolves, so the catch never runs and failures get swallowed silently.

Mistake 4: selecting the whole array in a list's parent. Select the identifiers in the parent and the entity in each child: from N re-renders down to one.

Mistake 5: connecting presentational components. A BikeCard with useSelector stops being reusable and stops being testable without a store. Pages and panels connect; everything else receives props.

Mistake 6: duplicating in Redux something that already lives in the URL and syncing it with an effect. Pick one source of truth and delete the other.

Mistake 7: reading state with store.getState() inside a component. It doesn't subscribe to anything, so the component doesn't re-render when it changes. getState() is for thunks and middleware.

Tip 1: turn on the unstable-selector warning. react-redux already emits it in development. Don't ignore it: every one of those warnings is a component re-rendering more than it should.

Tip 2: name selectors selectX and export them from the slice. A component should never write state.bookings.entities directly.

Tip 3: measure with the Profiler before memoizing. createSelector on a trivial selector is cost with no benefit. Module 8 teaches you how to measure it (08-05).

Tip 4: keep the store small on purpose. Every field you add is a field someone will have to understand. The table in section 11 is a decision-making tool, not a closed list.

Exercise 1. This component causes a re-render on every action in the store, has three distinct problems, and also fails on submit. Find them and rewrite it.

Exercise 2. Write a memoized selector selectBookingsSummary that returns { active, confirmed, cancelled, totalHours } from bookingsSlice's normalized state, and a BookingsBadge component that consumes it, showing only the number of active bookings. Explain why the component shouldn't use that selector as-is, and what you'd do instead.

Exercise 3. Translate this legacy component to hooks, keeping its behavior.

Solution 1. The three performance problems and the submit one:

1. The first useSelector returns an object literal. New reference on every call: re-render on every action.
2. The second useSelector returns the result of a filter. New array on every call: the same problem, a second time.
3. bikes and stations are selected and never used. A free subscription to two branches of state, for nothing.
4. .unwrap() is missing: await dispatch(fetchBikes(...)) resolves even when the thunk ends up rejected, so the catch never runs and a network failure would show "Fleet updated."

The two useless subscriptions are gone, the filter is memoized with a factory — so two FleetSummarys for different stations don't invalidate each other — and the submit correctly reports the failure.

Solution 2.

Why BookingsBadge shouldn't use it as-is: the selector returns an object, and even though createSelector memoizes it, it recomputes — and returns a new object — every time any booking changes. If the badge only shows the number of active bookings, it would re-render when a booking gets cancelled, when another gets confirmed, or when a third one's hours change, even though the number of active bookings stays the same.

The fix is to select the primitive:

The memoized selector does the computation once and shares it across every consumer; each component pulls out just the primitive it needs, and useSelector compares that number. It's fixes 1 and 3 combined, and it's the recommended pattern for selectors that return aggregates: memoize the aggregate, select the field.

Solution 3.

Four improvements the translation brings for free:

• The wrapping component that connect inserted into the tree is gone.
• loading is a boolean derived in the selector, not an object: perfect identity comparison.
• <li onClick> becomes a <button> inside the <li>. The original wasn't accessible: an <li> doesn't receive focus or respond to the keyboard (03-06). Migrating legacy code is a good time to fix this.
• dispatch in the effect's dependencies is correct and doesn't cause loops, precisely because it's stable.

The loop is closed. useSelector subscribes a component to the store, runs its selector function after every action, and compares the result with Object.is, which is where the golden rule comes from: a selector that builds a new object or array on every call causes re-renders on every action in the app, no matter which domain it comes from. The four fixes, in order of preference: select primitives, split into several useSelectors, memoize with createSelector — remembering that input selectors must be cheap and that memoization only pays off when there's real computation —, and, as a last resort, an equality function like shallowEqual. useDispatch returns the store's dispatch function, which is forever stable: a component that only dispatches never re-renders because of Redux, and dispatch can go in an effect's dependencies without any worry.

CicloUrbano ends up connected with judgment. UserMenu reads two primitives from sessionSlice and keeps its dropdown in useToggle. CataloguePage makes three sources of state coexist without duplicating any of them: the filter in the URL — still the source of truth, with the type passed as an argument to the memoized selector —, the search term and the catalogue in the store, and the selection in a local useState. BookingsPage selects only the identifiers, and BookingPanel selects its own entity, so confirming a booking re-renders exactly one row: the direct payoff of having normalized the state. Thunks are dispatched with .unwrap() so try/catch works, and loading and error are read from the store, not from a parallel useState. And the table of what stays out — theme, modals, URL filter, catalogue selection, form draft, notices — sums up the whole module's rule: something belongs in Redux when its change is a domain event worth recording.

You also know how to read connect, mapStateToProps and mapDispatchToProps without ever writing them, how to use the DevTools history to turn "why is the state wrong?" into "which action left it like this?", and how to organize code by feature instead of by type, with components/ reserved for what's genuinely shared. The final comparison is an honest one: for an app the size of CicloUrbano, context + useReducer would have been enough; Redux Toolkit pays for itself once there's a team, scale and logic worth auditing; and Zustand sits at a very reasonable middle ground.

What's left is the biggest piece, and the one that's going to shift the balance of everything above. Today the store has a bikes field loaded with a createAsyncThunk, and it's already been said twice that it was there provisionally: data coming from a server isn't application state. It doesn't belong to you, it goes stale on its own, it's shared across tabs and users, and it arrives late. Treating it as client state forces you to hand-write loading, error, cancellation, race conditions, deduplication, revalidation, invalidation, retries and pagination — for every single resource. In the next lesson you'll set up a fake API with json-server, get to know TanStack Query, understand the lifecycle of a cached piece of data, perform mutations with optimistic updates and their rollback, rewrite useFetchBikes as useBikes, and settle CicloUrbano's final architecture: Redux for client state, Query for server state. The next lesson is Server State: Requests, Caching and Synchronization.