The previous module closed with a very concrete debt: TypeSelector keeps the chosen type in its own state and notifies the parent, but the catalogue keeps showing all five bikes no matter what; and BikeCard notifies through onSelect, but App can only do a console.log, because it has nowhere to store the selected bike. Both failures share the same cause: state is private to each component, and two siblings can never see each other's state. In this lesson you'll learn the technique that solves this — lifting state up —, apply it so CicloUrbano's filter genuinely works, understand why duplicating the same piece of data in two places is a guaranteed source of bugs, and see the price you pay for lifting state: prop drilling.

1. The problem: two siblings and one shared piece of data
2. The rule: move up to the nearest common ancestor
3. CicloUrbano's refactor, step by step
4. App gets state: chosenType and selectedBike
5. Derived state: visibleBikes isn't state
6. Unidirectional flow, seen end to end
7. A single source of truth: the duplication trap
8. Controlled and uncontrolled components, at component level
9. What NOT to lift
10. The cost of lifting: prop drilling

This is CicloUrbano's tree as it stood at the end of Module 3:

The crossed-out arrow is the problem. chosenType lives inside TypeSelector, and from there the data can only travel downward (to TypeSelector's children, which it doesn't have) or upward (notifying the parent through a function prop). What doesn't exist in React is a sideways path: a component can't read its sibling's state.

And it isn't an arbitrary limitation. If BikeList could read TypeSelector's state, the two would be coupled: you couldn't reuse the list on another screen without dragging the selector along, and to understand why the list shows what it shows you'd have to read a component that doesn't even appear in its code. React chooses this restriction on purpose, and in exchange offers a simple rule for working around it.

When two or more components need the same piece of data, that data must live in the state of their nearest common ancestor, and flow down to each of them as a prop.

The technique is called lifting state up, and it takes three moves:

The component that loses its state isn't left mute: it receives two props instead.

• The current value (chosenType), to paint itself with.
• A notification function (onTypeChange), to ask the parent to change it.

If this sounds familiar, it's because it's exactly the pattern you used in 03-04 with a controlled <input>: value + onChange. The difference is that there the controlled component was a DOM tag, and here it's a component of your own. The pattern is the same, and we'll come back to it in section 8.

This is the version from 03-01, the one we're about to replace:

And here's the new one:

What changed, and why:

• useState and its import disappear. The component no longer remembers anything: everything it paints comes from its props. It has become a pure presentational component, the kind you saw in 02-01.
• onTypeChange moves from optional to required. Before, it was an extra: the selector worked without it because it painted itself from its own state. Now it's the only way to change anything; without that prop the component would be a decoration that doesn't respond. Document it in the /** Props: … */ block.
• The active button is decided with chosenType, which now arrives from outside. The JSX hasn't changed a single line: it doesn't care where the value comes from.
• aria-pressed communicates the button's state to assistive technologies, following what you learned in 03-06: selection can't be conveyed through CSS colour alone.

What's happened here is the whole module condensed into one file:

• App finally has state, and it's exactly two pieces of data: which filter is active, and which bike is selected. Not one more.
• BikeList receives visibleBikes, not bikes. The component hasn't changed: it still receives an array and paints it with map. It doesn't even know a filter exists, and that ignorance is a virtue, because it's what makes it reusable on any screen.
• BookingPanel finally receives a real bike. The early returns you wrote in 03-02 — "Select a bike from the catalogue" when the prop is missing — stop being a hypothesis: with selectedBike starting at null, that's literally the first state the person using the app sees.
• handleConfirm clears the selection by setting it to null, which sends the panel back to its initial message. A complete cycle, no tricks.

And BikeList gets a free bonus from something you'd already written: its empty state. If you filter by "Cargo" and the only cargo bike is in maintenance, the bikes.length === 0 check you wrote in 03-03 fires and shows the message. You haven't had to write a single new line.

Data flows down through props (solid arrows), and notifications flow up through functions (dashed arrows). There isn't a single horizontal arrow: the siblings still don't talk to each other — they communicate through the parent.

When state moves up, the temptation is to move everything up. Run each piece of data through this filter before turning it into the parent's state:

In CicloUrbano, chosenType and selectedBike pass the first two questions and fail the third: there's no way to derive them from anything. They're legitimate state.

A detail about selectedBike: we store the whole object, not its id. With static data imported from domain.js, that works perfectly. Once the data comes from a server and can be updated (Module 7), the recommended practice will be to store the id and look up the object on the fly, because an object stored in state is a frozen copy that has no idea if the original changes. It's the same warning about duplication that comes up in section 7.

This is the most common mistake when lifting state. The incorrect version:

It works… until someone adds another way to change the filter and forgets the second line. At that point the selector says "Electric" and the list shows every bike. The bug isn't in the filtering logic: it's that the same information is stored twice, and nothing guarantees the two copies agree.

You've already seen the correct version: a single line, no state.

It's recalculated on every render, exactly when it's needed, and it's impossible for it to drift out of sync because there's nothing to keep in sync. It's the same lesson from 02-04 — state versus derived value — now applied to a container component.

"Isn't filtering on every render inefficient?" With five bikes, or with five hundred, no. filter over a small array costs microseconds — far less than the complexity of keeping two states in hand-written sync. If the calculation is ever genuinely expensive, and you've measured it, useMemo exists (08-03). Measure first, optimize later.

Let's trace a click from start to finish. Someone clicks "Electric":

Notice an important detail: TypeSelector doesn't change anything by itself. You click the button and nothing visible happens until App updates its state and re-renders. The selector only requests the change. If App decided to ignore the request — say, forbidding the "Cargo" filter for customers — the button wouldn't activate. All the authority sits in one place, and that's what makes the behaviour predictable and debuggable: if something looks wrong, the wrong state is in App.

This closed loop is what's known as unidirectional data flow, and it's why a large React application can be reasoned about just by reading top to bottom.

The principle reads like this: each piece of data must have exactly one owner. Any other component that needs it receives it as a prop; no one makes a local copy.

Let's see the bug with a reproducible example. Imagine that, after lifting the state, you also leave a copy inside the child "for convenience":

At first glance it works. But it plants two time bombs:

1. useState(chosenType) only reads the prop on the first render. It's the initial value, not a permanent link. If tomorrow App adds a "Reset filters" button that does setChosenType('todos'), the parent will say "todos" and the selector will keep showing "Electric" as active. Forever.
2. There are two truths at once. Which is the actually chosen type? It depends on who you ask. And debugging that means looking at two components in DevTools and comparing them.

The practical rule, with no exceptions worth learning right now:

In 03-04 and 03-05 you applied these terms to form fields. Now they apply just the same to components you write yourself, and the distinction is exactly the same.

The same component can support both modes, and it's a pattern you'll see in many libraries. The technique: if the value prop arrives defined, the component obeys the parent; if not, it manages its own state.

The three key lines:

• const isControlled = open !== undefined; The contract is explicit: passing the prop means "I'm in charge." It's compared against undefined rather than a falsy value, because open={false} is a perfectly valid value that must still activate controlled mode.
• const isOpen = isControlled ? open : internalOpen; The rest of the component always uses this variable and never knows which mode is active. All the branching fits in one line.
• if (!isControlled) setInternalOpen(...) In controlled mode the component never touches its internal state: it only notifies. Updating both would duplicate the truth — the mistake from section 7.

Not every component of yours needs to support both modes — it adds complexity — but it's worth being able to read this pattern, because it's the design behind almost every library component you'll ever use.

Lifting is a tool, not a dogma. Moving up state that nobody else needs makes the code worse: it forces App to re-render the whole tree for changes that only affect one corner, and it clutters the root component with irrelevant data.

Clear cases of state that should stay put:

The debounced search box illustrates this well:

If text lived in App, every keystroke would trigger a render of the whole tree, including the entire catalogue. By staying inside, only the <input> repaints, and the parent finds out once, when there's actually something to do.

The control question is always the same: does anyone else need this data to render themselves or to decide something? If the answer is no, it stays where it is. And if the answer changes tomorrow, lifting it is a ten-minute refactor: there's no need to anticipate it.

Lifting has a cost, and it's worth being upfront about it. When the common ancestor is far away, the data has to pass through every component in between, even though none of them have any use for it. It's called prop drilling.

Imagine CicloUrbano grows and the card needs to know the user's role (usr-02 is an operator and can flag maintenance):

The symptoms are easy to spot:

• Intermediate components with props that only get forwarded, never used.
• Adding a new piece of data means touching four files just to get it to one.
• Renaming the prop means a find-and-replace across the whole chain.
• The intermediate components lose reusability: they demand a prop they don't even care about.

With two levels it isn't a problem, and it's not worth fixing before it hurts. With four or five, it is. React has an answer for this: the Context API, which lets you make a value available to an entire subtree without passing it hand to hand. You'll see it in useContext and, at the scale of a whole application, in Module 7, where external state managers also show up. Here we've only put a name to the problem.

• Copying a prop into the child's state. useState(props.value) only reads the prop once, on the first render. From then on, the two copies diverge and never match again. If you need to both read and change the data, receive it as a prop and notify upward.
• Storing in state what can be computed. visibleBikes, totals, counters, formatted text — all of that is derived. Every extra piece of state is one more chance for things to drift out of sync.
• Lifting too high "just in case." The right destination is the nearest common ancestor, not the root. Putting everything in App turns the root component into a dumping ground and causes unnecessary renders.
• Forgetting to pass the callback. If you turn a component into a controlled one and forget the change prop, you get an inert component that doesn't respond to clicks, with no error in the console. Document required props and consider a warning in development.
• Passing the value but not the handler (or the other way around). A controlled component needs both props: with only one, it's left half-working, just like an <input value> without onChange ends up read-only.
• Tip: look at DevTools. Select App in React DevTools and you'll see its two pieces of state change live as you click filters and cards. It's the best way to confirm the source of truth lives where you think it does.
• Tip: name your props like a contract. The pair chosenType / onTypeChange reads like value / onChange. Keeping that symmetry across the whole project means components can be used without ever reading their code.

Exercise 1. Lift the state of BookingPanel. Right now it receives hours as a fixed prop with value 2, so it can't be changed. Make App store bookingHours in its state (initial value 2), and have BookingPanel receive hours and a new prop onHoursChange, with two buttons ("−" and "+") that never go below 1 hour. The total should recalculate on its own. Explain why the total must not be state.

Exercise 2. Add an accessible results counter to App. Below TypeSelector, show text along the lines of "Showing 2 of 5 bikes," with correct singular/plural agreement, inside an element with aria-live="polite" (03-06). Don't add any new state: the text must come entirely from visibleBikes and bikes.

Exercise 3. Spot and fix the desync bug. This component has the mistake from section 7. Describe it with a concrete case that makes it fail, and rewrite it correctly.

Solution 1.

The total isn't state because it's fully derived from bike.pricePerHour and hours. Storing it would force you to recalculate it in two places (when the hours change and when the bike changes), and forgetting just one would be enough to show a false price. The lower bound is enforced in App, the data's owner, not in the panel: that way the rule lives right next to the state.

Solution 2.

No new state: both numbers come from arrays that already exist. aria-live="polite" makes the screen reader announce the change once it finishes reading whatever it's currently reading, so someone filtering with the keyboard knows how many results remain even without seeing the list.

Solution 3. The bug: useState takes the model exactly once, on the first render. Since selectedBike starts as null, model is 'None' forever; click all five cards and the text will never change. Not even a later change of bike fixes it, because the state is already initialized. It's the classic mistake of copying a prop into state.

The component becomes a pure function of its props: same props in, same output out, always. Impossible for it to drift out of sync.

Lifting state up is the technique that turns a bunch of loose components into an application. The rule fits in one sentence: shared state lives in the nearest common ancestor, flows down as props, and flows back up as notifications. Applying it, CicloUrbano has settled the debt it had been carrying since Module 2: TypeSelector has become a controlled component with no state of its own, App stores chosenType and selectedBike, visibleBikes is computed as a derived value — never as state — and BookingPanel finally receives a real bike. The catalogue genuinely filters now.

You've also seen the technique's limits. Lifting too much makes the code worse: genuinely local state — a search box's text, whether a panel is collapsed — should stay put. And lifting across a long distance has a cost with a name of its own, prop drilling, whose answer arrives with useContext and Module 7.

There's one open question left, and it surfaces as soon as the interface grows: App is already starting to accumulate sections, and soon you'll need to wrap the catalogue in a layout with a header and sidebar, show notices of several kinds, and build reusable panels. In other languages, the answer would be inheritance: a BasePanel that CataloguePanel and BookingsPanel inherit from. In React that answer is the wrong one, and the right one has a different name. The next lesson is Composition vs Inheritance, where you'll learn to build components out of other components without ever inheriting once.