You've been dragging the same limitation through two lessons now: CicloUrbano's catalogue shows three identical cards because the bike data is written inside BikeCard. A component like that isn't reusable: it can only ever show that one specific bike. Props are the fix, and they're one of the two or three truly fundamental concepts in React. A prop is a piece of data a component receives from outside, from whoever uses it. Props turn a rigid component into a parameterizable template, define the contract between parent and child, and are the reason you can write BikeCard once and use it on five different screens. In this lesson you'll learn to pass and receive them, what kinds of values they accept, how to give them default values, what the special children prop is, why they're read-only, and how to document your components' contract. By the end, the catalogue will finally show different bikes.

1. What props are and what problem they solve
2. Passing and receiving props
3. Destructuring in the component signature
4. What kinds of values can be passed
5. Default values
6. The special children prop
7. Props are read-only
8. Spreading props with the spread operator
9. Documenting a component's contract
10. CicloUrbano's catalogue, now parameterized

Props comes from properties. They're the data that flows from a parent component down to a child component through JSX attributes.

The most useful analogy is a function: a component is a function, and props are its arguments.

Exactly the same thing happens with components:

The analogy isn't a coincidence: props are literally the function component's arguments. React collects the attributes you write in the JSX, puts them into an object, and passes that object to your function as its first parameter.

And a very important structural property: the flow is one-way and flows down the tree. A parent passes data to a child; a child never "returns" data by writing to its props. That restriction, which looks limiting at first, is exactly what makes a React application predictable: to find out where a piece of data comes from, you go up the tree; you never have to hunt for who changed it behind your back.

Two syntaxes coexist, and the difference is the same one you already saw in the JSX lesson (01-04):

A classic mistake: pricePerHour="2.5" passes the string "2.5", not the number. And "2.5".toFixed(2) doesn't exist, so the card will crash. If the value isn't literal text, it goes in braces.

React calls your function with a single object that holds every attribute you wrote:

Three details worth nailing down from the start:

• The parameter can be called whatever you like. props is the universal convention, but it's an ordinary parameter. Call it props.
• You choose the names of the props yourself. There's no list of valid props: they're your component's vocabulary. Use camelCase (pricePerHour, stationId), just like the rest of JavaScript.
• If you don't pass an attribute, that prop is undefined. It doesn't throw an error; it simply isn't there. That's why we'll look at default values further down.

Writing props. in front of every value gets noisy. ES6 destructuring lets you pull the props out directly in the function signature, and it's the dominant form in modern React.

The braces in ({ model, type, status }) are not an object: they're destructuring syntax applied to the parameter. It's equivalent to writing const { model, type, status } = props; on the first line of the body.

Why it's better:

In CicloUrbano we're going to pass the entire bike as an object, not field by field. You can destructure it at two levels:

The second form is valid, but it loses the reference to the whole object and becomes unreadable once there are many fields. In the course we'll use the first one: receive bike and, if needed, destructure it in the body.

Any JavaScript value. Literally any.

Let's look at the cases that cause the most confusion.

Writing the bare attribute is equivalent to ={true}, just like in HTML with disabled or checked. Watch out for the last line: omitting the prop gives undefined, which is falsy but isn't false. In practice both behave the same in a condition, but they aren't the same value.

It's the same double brace you already saw in style={{ color: 'red' }}: the outer ones open a JSX expression, the inner ones are the object literal.

Passing functions as props is the mechanism a child uses to let its parent know something happened. Here you just need to know it's possible and this is the syntax; the full child → parent communication pattern is covered in Lifting State Up, and event handlers in Handling Events.

A prop can hold interface. That opens the door to very flexible components:

If the parent doesn't pass a prop, it arrives as undefined. To keep the component working, you give it default values with JavaScript's default parameters, right in the destructuring:

One nuance that catches people off guard: the default value applies only when the prop is undefined, not when it's null, 0, or an empty string.

In older code you'll see this other form:

defaultProps has been removed for function components as of React 19. If you find it, it's older code, and you should translate it to default parameters. It still works on class components, because a class has no signature where default values could be written.

There's one prop that isn't passed as an attribute: everything you write between a component's opening and closing tags arrives in the children prop.

The component that receives it:

children is the foundation of the composition pattern: you write components that contribute structure or behavior and let whoever uses them decide the content.

One Panel, two completely different contents. Without children you'd have to invent a prop for every possible case, or duplicate the component.

Things worth knowing about children:

• It can be anything: text, one element, several elements, an array, or nothing (undefined).
• children can't also be passed as an attribute. If you write <Panel children="hi">bye</Panel>, the content between the tags wins.
• A component can have several content "zones" by passing JSX elements through named props (header={<…/>}, footer={<…/>}). This is sometimes called slots.

This pattern has a lot more mileage — generic containers, wrappers, component specialization — and gets covered in depth in Composition vs Inheritance.

This is the single most important rule in the lesson, and it has no exceptions:

A component must never modify its own props. React operates on the premise that a component, given the same props, always produces the same result. That's called being a pure function.

It depends on what you're mutating, and neither scenario is good:

The second case is the dangerous one: silent, hard to debug, and capable of producing "data that changes without anyone repainting it." In CicloUrbano, mutating bike.status inside the card would modify the bikes array imported from domain.js for the entire application.

• If you just need a transformed value to paint, compute a local variable. That's perfectly fine: what's forbidden is writing to the prop, not reading it or deriving from it.

• If the data genuinely needs to change, it isn't a prop: it's state, and you'll see that in the next lesson. And if the change originates in the child but the data belongs to the parent, the child notifies it through a function received via props (04-01).

The spread operator (...) lets you pass every property of an object as props in one go:

And the component receives them as loose props:

It can also be combined with explicit props, and order matters: whatever's written later wins.

It's a convenient tool that's easy to overuse. The downsides:

The legitimate uses are wrapper components that forward props they don't know about:

Here ...rest collects every prop we haven't destructured (type, disabled, onClick…) and forwards them. That's the case where the operator earns its keep.

Course rule: in CicloUrbano we'll pass the whole object as a named prop — bike={bike} — instead of spreading it. The contract stays explicit and the component's signature speaks for itself.

Props are your component's public contract. In plain JavaScript, nothing stops you from passing a number where an object is expected, so it's worth writing it down.

Takes thirty seconds and solves 80% of the cases.

Before TypeScript became widespread, type checking in React was done with the prop-types library, which validates at runtime, and only in development, printing a warning to the console:

We're mentioning it because you'll find it in a huge amount of existing code, but it's discouraged for new projects today: prop-types is an extra dependency, it only warns after the error has already happened, and it doesn't help your editor.

This is the modern answer: types are checked before running anything, the editor autocompletes props, and renaming a field propagates on its own.

Properly typing components is the subject of TypeScript with React. Until then, in CicloUrbano we'll use level 1: a clear comment above every reusable component.

Time to break through the ceiling. Let's turn BikeCard and StatusBadge into parameterized components and paint different bikes.

The class gets built from a template: status--${status} produces status--disponible, status--alquilada, or status--mantenimiento, the CSS classes we defined in lesson 02-01. The entire "which color goes with which status" rule now lives in one single place.

Here's what happened, point by point:

• { bike, stationName = '…' }: destructuring in the signature, with a default value for the optional prop.
• formattedPrice: a variable derived from the prop. We read the prop and compute; we do not modify it. toFixed(2) gives us "2.50", already in the decimal-point format we want.
• bike-card--${bike.type}: the variant class is no longer hand-written; it comes from the data. urbana, electrica, or carga.
• <StatusBadge status={bike.status} />: BikeCard is StatusBadge's parent and passes it a prop. Props flow down the tree level by level.

Yes, three numbered props is an ugly solution, and it's ugly on purpose: it's the symptom of a missing tool. That tool is looping over an array with map, and it arrives in Lists and Keys. Notice that the problem is no longer about props — it's about repetition.

Save and check the browser. Finally:

Three different cards, produced by a single component. That's the moment React starts paying off: any design change to the card gets written once and applies to all three.

Every arrow points down. None point up. That's React's one-way data flow.

• Passing numbers as strings. pricePerHour="2.5" delivers the text "2.5", and any arithmetic operation or toFixed will fail. If it's not literal text, it goes in braces.
• Forgetting the destructuring braces. function BikeCard(bike) receives the entire props object under the name bike, so bike.model is undefined. The correct signature is function BikeCard({ bike }).
• Mutating an object-type prop. bike.status = 'alquilada' doesn't throw an error, which is exactly why it's so dangerous: you modify the parent's data without React ever knowing. If the data needs to change, it's state.
• Executing the function when passing it. onBook={book()} calls book during render and passes its result. No parentheses: onBook={book}.
• Relying on the default value against a null. It only applies with undefined. If the parent can send null, handle it explicitly.
• Overusing {...object}. Convenient to write, expensive to maintain. Save it for wrappers that forward unknown props.
• Using defaultProps in a function component. Removed in React 19. Use default parameters.
• Tip: the signature is documentation. function BikeCard({ bike, featured = false }) says more than any comment. Take care with prop names: they're your component's public vocabulary.
• Tip: if a component takes more than five or six props, be suspicious. Either it's doing too much, or several props should travel grouped in an object.
• Tip: inspect props in DevTools. The Components tab shows every instance's real props. It's the fastest way to discover you're passing undefined.

Turn StationCard (created in lesson 01-03 with hard-coded data) into a parameterized component. It should receive a station prop shaped like domain.js, and an optional bikesAtStation prop (number, defaults to 0), and show the name, the district, the total docks, and the number of bikes. Then use it in App.jsx to paint CicloUrbano's three stations, writing them out one by one.

Create the Panel component described in section 6 (src/components/Panel.jsx), with a title prop (string, required) and children. Add an optional footer prop that accepts a JSX element and gets painted below the content when provided. Then use it twice in App.jsx: once wrapping the bike list, and once with a text notice.

Hint: to only paint the footer when it exists, remember that {undefined} paints nothing in JSX.

This component has four props-related bugs. Find them, explain what each one causes, and write the corrected version.

Solution 1.

Notice freeDocks: it's a value derived from the props, computed on every render. It's not a prop, and there's no need to store it anywhere. That distinction between what gets stored and what gets computed will be central to the next lesson.

Solution 2.

The same Panel wraps a whole list in one case and a paragraph in the other: that's what children brings to the table. The expression {footer && <div…>} is conditional rendering, covered in depth in Conditional Rendering; here it's enough to know that if footer is undefined, nothing gets painted.

Solution 3.

The four bugs:

1. Wrong signature. function BikeRow(bike, pricePerHour = 0) treats the props as two separate parameters. React always passes a single object as the first argument, so bike ends up being the entire props object and pricePerHour never receives anything: it stays at its default, 0. You need to destructure: ({ bike, pricePerHour = 0 }).
2. Mutating a prop. bike.model = bike.model.toUpperCase() modifies the object from domain.js, affecting the whole application without triggering any render. You need to compute a new variable instead.
3. A number passed as a string. pricePerHour="2.5" delivers the text "2.5"; "2.5".toFixed doesn't exist and throws a TypeError. It should be pricePerHour={2.5}.
4. Inconsistent contract. pricePerHour already lives inside the bike object; passing it separately as well duplicates the source of truth and lets the two contradict each other. It should be read from the bike.

Corrected version:

Props are the mechanism a component uses to receive data from outside, and with them CicloUrbano's catalogue has stopped being a mockup: a single BikeCard now paints three different bikes, each with its own model, price, color variant, and status badge. You know how to pass them as attributes — quoted text, everything else in braces — receive them with destructuring in the signature, give them default values with default parameters (and that defaultProps no longer exists for functions in React 19), pass any type of value — including objects, functions, and JSX elements — and use the special children prop to build containers like Panel that wrap arbitrary content.

And you have the rule that holds the whole model together crystal clear: props are read-only. A component reads them and derives values from them, but never writes to them. Data flow goes down the tree and never up, which means tracing the origin of any piece of data is always possible. You also know that spreading props with {...object} is convenient but erases the contract, and that the contract is worth documenting — today with a comment, and in the future with TypeScript.

There's one big open question left: if props come from outside and can't be modified, how does anything ever change in a React application? When the user picks a filter, books a bike, or clicks a button, something has to change and trigger a new render. That something is state: a component's own memory, the data that can change and that, when it does, triggers the render cycle you studied in 01-05. That's the subject of the next lesson: State: Managing Component State.