The previous lesson ended with an unanswered question: if props come from outside and are read-only, how does anything change in a React application? CicloUrbano's catalogue already shows real bikes, but it's a snapshot: it doesn't react to anything. When the user picks a bike type, books a unit, or filters by station, something has to change inside the application and trigger a new paint. That something is state: a component's own memory, the only data a component can modify, and the trigger for the render cycle you studied in lesson 01-05. In this lesson you'll see why an ordinary JavaScript variable won't do, how state is declared with useState, why state is isolated per instance, how to update it without losing updates, why objects and arrays must be copied instead of mutated, and — perhaps most importantly — what deserves to be state and what doesn't.

1. What state is
2. State vs. props
3. Why a plain variable doesn't work
4. useState: declaring, reading, and updating
5. Updating state triggers a render
6. State is local and isolated per instance
7. Updates based on the previous value
8. Immutability: objects and arrays in state
9. What should be state and what can be derived
10. CicloUrbano: TypeSelector and the docks-available counter

State is a set of data that a component keeps between renders and that, when it changes, makes React re-render it.

Notice the two halves of this definition, because both are essential:

• It persists between renders. An ordinary variable declared inside a component is born and dies on every render. State survives.
• When it changes, it triggers a render. It isn't just storage: it's storage wired to the screen.

In lesson 01-05 you saw that two things trigger a render: the initial render and a state change. Now you know how to handle the second one.

Examples of state in CicloUrbano:

And examples of what is not state:

Both are sources of data for a component, and confusing them is the most common conceptual mistake when starting out.

A rule of thumb that settles almost every doubt:

Does the component itself change this data? If yes, it's state. If it comes from outside and the component only reads it, it's a prop.

And a nuance that arrives in Module 4: when two sibling components need the same changing data, the state moves up to their common parent and comes back down to the children as props. That pattern is called lifting state up and is covered in Lifting State Up. In this lesson all state stays inside a single component.

Let's try it the "obvious" way and see exactly where it breaks. This component shows the free docks at the Main Square station and should subtract one when the button is pressed.

Run it and press the button three times. The console says 11, 10, 9… and the screen still shows 12.

There are two independent bugs, and understanding them separately is the key to the whole lesson:

Modifying a JavaScript variable is a private JavaScript operation. React doesn't watch your variables: nothing connects them to the screen. Without a state change, there's no render trigger, and without a render the screen doesn't update. It's exactly what you saw in 01-05: a render is triggered by mount or by a state change, and neither has happened here.

And even if we forced a render some other way, it still wouldn't work. A component is a function, and React calls it again on every render. Each call executes let free = 12; again, from scratch. The previous value is gone: it was a local variable of a call that already finished.

Conclusion: a component needs something that (a) React watches to trigger a render and (b) survives the function being re-executed. That something is state, declared with useState.

useState is a hook: a special React function that lets a function component tap into engine capabilities. Module 5 covers hooks in depth, and useState covers this one in full detail. Here we'll stick to the basic usage, which covers 90% of cases.

That single line packs in four things:

About that destructuring: useState returns [value, updaterFunction], and the square brackets pull out the two elements and name them. You choose the names; the universal convention is something and setSomething, in that order.

Now the version that works:

Compared to the broken version, there are only three changes: importing useState, declaring the state, and calling setFree instead of assigning. The rest of the component is identical. Press the button: now the screen drops to 11, 10, 9…

About onClick: here we're using it as the bare minimum needed to trigger a change. Event handlers — their full syntax, the event object, propagation — are the subject of Handling Events. For now, keep this rule: the function is passed without parentheses.

Hooks have strict usage rules. For now, two:

1. Always at the top level of the component. Never inside an if, a loop, a nested function, or after a conditional return.
2. Only inside components (or custom hooks). Not in just any helper function.

The reason — React identifies each piece of state by the order in which it's declared — and the rest of the rules are explained in Hooks: Introduction and Basic Use.

A component can declare as many as it needs, and that's the norm:

Keeping them separate is preferable to bundling them into a single object: each piece of data updates on its own and the code stays much clearer. When several values always change together under complex rules, there's a dedicated tool, useReducer, covered in 05-05.

This connects directly to lesson 01-05. When you call setFree(11), this sequence happens:

Three consequences you need to internalize:

a) The value doesn't change on the next line. The free variable in this render is a constant: it holds whatever it held when React called the function. The new value shows up on the next render.

This isn't a bug or a delay: it's consistency. Throughout an entire render, every value stays fixed, which prevents a whole class of bugs where parts of the screen get ahead of others.

b) React batches updates. If you call updater functions several times inside the same handler, React doesn't render once per call: it batches them and does a single render at the end. This is known as batching.

c) If the value doesn't change, there's no render. React compares the new value with the current one. If they're equal (using Object.is comparison), it skips the work.

Watch out for this when state is an object: if you mutate the object and pass the same reference, React concludes nothing has changed and doesn't render. This causes half of the "the screen won't update" bugs you'll run into in your life, and it's the reason for section 8.

Every time you use a component in JSX you create a separate instance, and each instance has its own state, completely independent.

Three counters on screen. Press the first one's button: it drops from 20 to 19 and the other two don't budge. They share the code, not the data.

This property has important consequences:

• State is private. No other component can read or write it. Not even the parent. That encapsulation is what makes a component reasonable to think about in isolation.
• If two components need to share it, the state is in the wrong place. It has to move up to their common parent (04-01).
• State is tied to position in the tree. If React destroys the component — because it changes type or disappears from the screen — its state is lost. This is exactly the reconciliation heuristic you studied in 01-05, now seen from the other side.

The updater function supports two usage forms, and the difference matters.

In the functional form, React calls your function with the most recent state value and uses whatever you return as the new value.

Imagine a button that frees up three docks at once:

If free is 12, you'd expect 15. You get 13. The reason: free is a fixed constant throughout this render, with value 12. All three calls literally say "set state to 13," three times. And since React batches updates, the final result is 13.

With the functional form:

React queues the three functions and applies them in order, each on the result of the previous one. Now: 15.

Rule of thumb: if the state variable appears in the argument, use the functional form. It's always correct, costs nothing, and avoids an entire family of bugs, including ones that only show up with asynchronous code.

Here's the most important trap in React state.

Never modify an object or array in state directly. Create a new copy.

The reason is what you saw in section 5: React decides whether to render by comparing references. If you mutate the object, the reference doesn't change, React concludes nothing has changed, and it doesn't render.

Suppose a component keeps the selected bike in its state and we want to mark it as booked.

The spread operator copies every property of the original object into a new one, and status: 'alquilada', coming after, overwrites that key. The result is a different object, with a new reference, and React renders.

And with the functional form, which is the recommended one:

Notice the parentheses wrapping the braces: previous => ({ … }). Without them, JavaScript reads the braces as the arrow function's body and returns undefined. It's a classic typo.

A component that keeps a list of bikes in its state:

Array methods split into two groups, and this table is worth keeping handy:

Marking a bike as booked inside an array combines both ideas: you have to copy the array and copy the object that changes.

That last detail is elegant and deliberate: the elements that don't change keep their reference, which lets React — and the optimizations in Module 8 — safely skip work.

An important warning: { ...bike } is a shallow copy. It copies the first level of properties; if there were nested objects, they'd still be shared. Our domain is flat, so it doesn't affect us, but keep it in mind.

It might look like an unnecessary complication, but comparing references is an instant operation, while deeply comparing two large objects on every render would be very expensive. Immutability is the price you pay for cheap change checks, and as a bonus it makes data easier to reason about and debug.

This section will save you more bugs than any other.

If a value can be computed from props or from other state, DON'T store it in state. Compute it during render.

A value computed during render is always in sync, because it's recalculated every time. A value duplicated in state has to be remembered and kept up to date, and the day someone forgets, the screen will lie.

A checklist to decide:

The usual worry — "won't recalculating on every render be expensive?" — is almost always unfounded: a filter over a few dozen or a few hundred elements is negligible. And when there really is an expensive calculation, there's a dedicated tool to memoize it, useMemo, covered in 08-03. Optimizing before measuring is, as you saw in 01-05, the most effective way to complicate code without gaining anything.

Let's add two stateful pieces to the catalogue.

Point by point:

• const TYPES = [...] outside the component. It's a constant that never changes. Declaring it outside avoids recreating the array on every render, and it also makes clear that it isn't state.
• useState('todos'): state starts at 'todos', the value that shows the whole fleet.
• onClick={() => setChosenType(type)}: the arrow function lets each button pass its own type. Without it, setChosenType(type) would run during render.
• The conditional class highlights the active button by comparing type === chosenType. It's a derived value: no separate activeButton state is needed.
• {TYPES.map(...)} generates the four buttons; key is required on lists, as you saw in 01-05. The full technique is the subject of Lists and Keys; here it's used on a fixed constant so we don't repeat the same button four times.

Click the buttons: the selection changes, the active button gets highlighted, and the text below updates. The component has memory.

It still doesn't filter anything, and that's on purpose: the state lives inside TypeSelector and BikeList can't see it, because state is private. For the filter to actually work, the state will have to move up to their common parent. That's exactly the problem Lifting State Up solves.

In lesson 02-01 you wrote FleetSummary with the numbers "5, 3, 2" by hand. Now they're computed:

With the data from domain.js: 5 total, 3 available, 1 rented, 1 in maintenance. And if a new bike gets added to the array tomorrow, the summary updates itself. A component with no state isn't a poor component: it's a component that can't fall out of sync.

And the styles for the new pieces:

Open React DevTools, select TypeSelector, and you'll see its state in the right-hand panel, changing live with every click. It's the best tool for understanding what's going on.

• Modifying state directly. free = 5 or fleet.push(newBike) trigger no render at all. Always go through the updater function, and always with copies.
• Expecting the new value right after updating. setFree(11); console.log(free); prints the old value. The new value arrives on the next render.
• Chaining updates with the direct form. Three setFree(free + 1) in a row add one, not three. If the value depends on the previous one, use setFree(prev => prev + 1).
• Returning an object without parentheses in the functional form. prev => { ...prev, x: 1 } returns nothing. You need to write prev => ({ ...prev, x: 1 }).
• Storing something in state that can be computed. Duplicating data guarantees it will fall out of sync someday. Derive it during render instead.
• Putting something that arrives via props into state for no reason. useState(props.bike) freezes the initial value: if the parent passes a different bike, the state never finds out. This is only done in the very specific case of an initial value the component then takes over, and it helps to name the prop initialBike so it's clear.
• Declaring useState inside an if. It breaks the order of hooks and produces baffling errors. Always at the top level.
• Tip: start with the minimum state. It's easier to add a piece of state than to discover you have four that contradict each other.
• Tip: use the Components tab in DevTools. Seeing a component's actual state at any given moment solves most doubts faster than any console.log.

Create BookingPanel in src/components/BookingPanel.jsx. It should receive a bike prop and manage the number of booking hours in its own state, with an initial value of 1. Show the bike's model, the selected hours, and the total price (hours × pricePerHour), with two buttons: one that adds an hour and one that subtracts an hour, never going below 1.

Use the functional form for both updates and use judgment to decide whether the total price should be state or a derived value.

This component is meant to mark a bike as 'alquilada' when the button is pressed, but the screen never changes. Explain why, precisely, and fix it.

For each of these CicloUrbano data points, decide whether it should be state, a prop, a derived value, or a constant outside the component, and justify it in one sentence.

1. The bikes array imported from domain.js and used by App.
2. The text the user types into the catalogue search box.
3. The number of bikes that match the current filter.
4. The list of valid types: ['todos', 'urbana', 'electrica', 'carga'].
5. The specific bike a BikeCard receives.
6. Whether a station's detail panel is expanded.
7. A booking's total price, computed from the hours and the price per hour.
8. The station name shown on a card.

Solution 1.

The key decisions:

• hours is state: it changes with interaction and can't be deduced from anything else.
• totalPrice is derived: storing it in state would force us to update it in both handlers, and forgetting just one would make the total lie.
• Functional form in both handlers: the new value depends on the previous one, so it's the correct choice by definition.
• The lower bound lives inside the update, applied to previous, not to the render's variable. That way it stays correct even with several updates queued up.

Solution 2.

Why it fails. There are two chained problems:

1. Mutating state. fleet[0].status = 'alquilada' modifies the object inside the state array. Worse still: useState(bikes) stores a reference to the array imported from domain.js, so the mutation contaminates the whole module for the entire application.
2. Same reference. setFleet(fleet) hands React the exact same array it already had. React compares references, concludes nothing has changed, and triggers no render. The data in memory did change; the screen never finds out.

Fixed version:

map returns a new array (new reference → render happens) and the object at index 0 is replaced with a modified copy ({ ...bike, status: 'alquilada' }), leaving the original and every other element untouched.

One more improvement: identifying the bike by its id instead of its index, bike.id === 'bici-001', is more robust against reordering.

Solution 3.

State is a component's memory and the second trigger for a render. You now know why a plain variable won't do — React doesn't watch it, and it resets on every function call besides — and how the alternative is declared: const [value, setValue] = useState(initial), always at the top level of the component. You know the read variable is fixed throughout a render and the new value arrives on the next one, that React batches updates, and that it doesn't render if the value hasn't changed.

You also have the three rules that prevent most state-related bugs:

1. Functional form (prev => …) whenever the new value depends on the previous one.
2. Immutability: copy objects with { ...obj } and arrays with map, filter, or [...arr], never mutate, because React compares references.
3. Don't store what can be computed: derived values are recalculated during render and so can never fall out of sync.

In CicloUrbano you've added a TypeSelector that remembers the chosen type and a FleetSummary that, deliberately, has no state, because all its numbers are derived from the fleet. And you've discovered this lesson's limit: state is private and local, so TypeSelector can't filter BikeList because no one else can see its state. Solving that is the goal of Lifting State Up, and the full mechanics of useState await you in 05-01.

One piece remains to close out the module. Your components already encapsulate markup and logic, but styling is still scattered across a global index.css that keeps growing unchecked, where two classes with the same name are bound to collide sooner or later. In the final lesson, Styling Components: CSS, Modules and Utilities, you'll see the four strategies for styling a component in React — global CSS, inline styles, CSS Modules, and utility classes — all applied to BikeCard so you can compare them, and we'll adopt the one CicloUrbano will use from then on.