We've been dragging the same ugliness across two modules: BikeList receives three props called first, second and third, and writes out three cards by hand. With five bikes in domain.js it's already falling short; with fifty it would be unsustainable. This lesson settles that debt, plus an older one: lesson 01-05 said that lists need a stable identity and that the full mechanics would arrive here. You'll learn to turn an array of data into an array of JSX elements with map, to understand exactly what a key is and what it does to the reconciliation algorithm, to recognize why the array index is almost always a bad key — with an example you can reproduce and watch fail — and to combine filter, sort and map without wrecking the original data.

1. The problem: hand-written repetition
2. map: from an array of data to an array of elements
3. Returning JSX from map: the forgotten return
4. The refactor: BikeList with map
5. What key is and why React needs it
6. What works as a key and what doesn't
7. The array index: the reproducible bug
8. Keys in fragments
9. filter and sort without mutating the original array
10. Nested lists: stations with their bikes
11. A list's empty state

This is the starting point, right where the previous lesson left off:

The flaws are structural, not stylistic:

And the underlying problem: the number of cards is a piece of data, not a decision the programmer makes. It has to come from the array.

Array.prototype.map is standard JavaScript, not a React function: it walks an array and returns a brand-new array with the result of applying a function to each item. The original array is left untouched.

React's idea is exactly the same, swapping numbers for JSX elements:

And here's a JSX property you might not have expected: React knows how to paint an array of elements. If you put an array inside braces, React walks it and paints each element in order, with no separators or commas.

The mental flow, in three steps:

Notice the key={model}: it's mandatory, and we'll explain it in section 5. For now, get in the habit of writing it every time you use map to generate elements.

The function you pass to map has to return something. With arrow functions there are two ways to write it, and mixing them up produces a baffling bug: the list stays empty with no error at all.

In the third case, the function returns undefined for every item, so map produces [undefined, undefined, undefined], and React doesn't paint undefineds. Result: an empty section, no errors, no warnings. It's a classic bug that can cost you twenty minutes.

Rule of thumb: parentheses return, braces execute.

This is the module's most important change. Compare the before and the after.

And in App.jsx the three numbered props disappear:

What changed, point by point:

• One prop instead of three, and with a name that describes what the data is, not where it sits.
• All five bikes show up, not just the first three. And if twenty more arrive tomorrow, nothing needs touching.
• stationName is no longer hand-written. It used to say "Main Square" for the first two just because that happened to be true; now it's resolved from bike.stationId, which is the real data. With the stationNameById index, bici-003 correctly shows "North Park" and bici-004, "Central Station".
• The empty state is checked with bikes.length === 0 via an early return, exactly as you learned in 03-02.
• key={bike.id}: every card carries the stable identity React needs. Let's get into it.

In lesson 01-05 you saw that React compares the two trees by position, level by level, and that criterion works fine except in one case: lists that change. That's where key comes in.

A key is a string or number that tells React: "this list item is this specific piece of data, wherever it happens to sit now." React doesn't use it for anything visual — it never reaches the DOM, you can't read it from the component — only to match elements between two renders.

Say the catalogue shows three bikes and a new one arrives at the front.

Without stable keys (comparing by position), React reasons like this:

Four DOM operations, and the first three rewrite cards that hadn't actually changed.

With key={bike.id}, React compares by identity:

One single creation and zero rewrites. But the real benefit isn't performance: it's correctness. Every card keeps its internal state — an open dropdown, a half-filled hours field, a favorite mark — because React knows it's still the same card.

That last point surprises a lot of people:

If you forget the key, React doesn't break anything, but it leaves a very visible console warning: "Warning: Each child in a list should have a unique 'key' prop." Don't ignore it: it means your list is comparing by position.

There's an honest caveat about the index: it's acceptable if all three conditions hold at once.

1. The list never gets reordered or filtered.
2. Items never get inserted or removed in the middle or at the front (only appended at the end, if at all).
3. Items have no internal state and contain no form fields.

The TypeSelector from 02-04 used key={type} over a TYPES constant that never changes: there, even the index would have been harmless. But since almost no real-world list keeps all three conditions forever, the practical advice is: if the data has an id, use the id; if it doesn't, give it one.

Theory is never as convincing as watching the bug happen. Let's build it.

And the component that uses it, with the key placed wrong:

1. Mark only bici-003 (Cargo Max), the third one in the list, as favorite. Its star turns to ★.
2. Click "Delete" on bici-001 (the first one).
3. Look at the resulting list.

What you expect: bici-002, bici-003 (★), bici-004, bici-005. What actually happens: bici-002, bici-003, bici-004 (★), bici-005. The star has moved to the wrong bike.

Why? Because the favorite state lives inside the component, and React associates each component instance with its key. The favorite bike was at position 2, so its state got tied to key 2. When you delete the first one, everything shifts, and now position 2 holds bici-004… which inherits the state of whoever held that key before.

The state didn't move: it stayed stuck to the position, and the data slid underneath it.

Repeat the experiment: the star stays on bici-003 no matter what. With the right key, React understands that bici-001 is gone and the rest are the same as ever, so it keeps their state and only removes one DOM node.

This exact mechanism explains an even more common bug in real apps: a half-filled text field that jumps to a different row when the list is sorted or filtered. The cause is identical.

Sometimes each list item needs to produce several sibling nodes with no wrapping container. The typical case is a definition list or a table:

This doesn't work: the short <>…</> syntax doesn't accept attributes, so there's nowhere to put the key and React warns about it. The fix is to use the fragment's long form, imported from React:

The fragment's advantage over a <div> is that it adds no node to the DOM. Inside a <dl>, a <table>, or a display: grid container, slipping in an intermediate <div> would break the semantics or the layout.

Once a list is painted with map, it's natural to want to filter and sort it. There's a JavaScript trap here that bites hard in React.

Remember the immutability rule from lesson 02-04: never modify data that comes from props, state, or an imported module directly. If you sort the array from domain.js, you reorder it for the whole application, without React ever knowing and with no way back.

The three correct ways to sort:

toSorted, toReversed, toSpliced and with are the family of non-destructive methods added to JavaScript in 2023. They're available in every current browser and are the most readable option. If your project has to support older environments, the spread copy does exactly the same thing.

Three important observations:

• visible is a derived value, not state. It's recomputed on every render from the props, so it can never fall out of sync. It's exactly the 02-04 lesson applied to lists.
• The chain reads top to bottom: filter, then sort. Filtering first is also more efficient, since fewer items end up being sorted.
• The keys are still the ids. Even though the order changes with each criterion, every card keeps its identity and its internal state.

This component is the dress rehearsal for what happens in Lifting State Up, when type stops being a fixed prop and starts coming from TypeSelector.

Lists inside lists are extremely common, and they add exactly one new rule: each map needs its own keys, unique among its own siblings. There's no global uniqueness requirement.

Details worth noting:

• The outer map uses a block body with return, because it needs to compute bikesAtStation and free before returning the JSX. It's case 2 from section 3: forget that return and no station renders at all.
• Two independent levels of keys: key={station.id} on the stations and key={bike.id} on the bikes within each one. Whether bici-001 and est-01 look alike is irrelevant; only uniqueness among siblings matters.
• bikesAtStation is computed inside the map, so each station gets its own derived list, with no extra state.

With the data from domain.js, the result is:

You've already used it in the examples, but it's worth pinning down as a pattern, because it's one of the things that separates a polished interface from a sloppy one. A list can be empty for very different reasons, and the message should say which one:

Telling "there's nothing" apart from "there's nothing that matches" costs three lines and stops anyone from thinking the app is broken. The loading and error cases will be handled once async data arrives, in useEffect Hook and Error Boundaries.

• Forgetting the return inside a map with braces. The list comes out empty with no error at all. Remember: parentheses return, braces execute.
• Using forEach instead of map. forEach always returns undefined: it produces nothing to paint. For generating elements, use map.
• Omitting the key. React warns in the console and your list starts comparing by position, with all the problems from section 7.
• Using the index as a key in a list that gets filtered, sorted or has items removed. The internal state stays stuck to the position and ends up on the wrong row.
• Using Math.random() as a key. Every render generates new keys, so React destroys and recreates the whole list: you lose state, focus, and performance.
• Putting the key on the wrong element. It must go on the outermost node the map returns, not on one of its children.
• Trying to read props.key inside the component. It doesn't exist. If you need the identifier, pass it as a regular prop too.
• Repeating keys among siblings. With two elements sharing a key, React warns and the behavior becomes unpredictable. Watch out for using model as a key: bici-001 and bici-004 share the same model.
• Using <>…</> when a key is needed. The short syntax doesn't accept attributes; use <Fragment key={…}>.
• Sorting with sort on props or state. sort mutates the array. Use toSorted or a copy made beforehand.
• Tip: if your data has no id, generate one when you create it, not when you render it. crypto.randomUUID() at the moment you add the item, stored inside the object.
• Tip: compute the visible list as a derived value, chaining filter and toSorted right before the return. Don't store it in state: it would fall out of sync.
• Tip: extract the iteration's content into its own component as soon as it grows past five or six lines. {bikes.map(b => <BikeCard key={b.id} bike={b} />)} is a one-liner that reads itself.

This component has three bugs related to lists and keys. Identify them, explain the symptom of each one, and write the corrected version.

Create the SummaryByType component (src/components/SummaryByType.jsx) that receives the bikes array and shows a table with one row per type (urbana, electrica, carga), stating how many bikes there are of that type, how many are available, and the average price per hour.

Requirements:

• Reuse the TYPES constant, without the 'todos' value.
• Don't mutate the received array.
• If a type has no bikes at all, its row should show "—" for the average price instead of NaN.
• Use appropriate keys.

Starting from the FavoritesList component in section 7, extend it so it also lets you move a bike to the front of the list with a "Move to front" button. Then:

1. Run it with key={index}, mark bici-005 (the last one) as favorite, and move it to the front. Describe what happens to the star and explain why.
2. Change it to key={bike.id} and repeat. Explain the difference in terms of reconciliation.

Solution 1.

The three bugs:

Solution 2.

With the data from domain.js the result is:

The key is type, because types are unique among themselves and stable: the BIKE_TYPES array never gets reordered. The check on the average price avoids the NaN that dividing by zero would otherwise produce.

Solution 3.

The addition to the component:

1. With key={index}. You mark bici-005 (position 4) as favorite: the favorite: true state gets tied to key 4. When you move it to the front, bici-005 moves to key 0, and key 4 is now taken by bici-004. React sees that key 0 still holds a FavoriteRow of the same type, so it reuses the component and its state, only updating the props. Result: the star stays at position 4, meaning on bici-004, while bici-005, now at the front, shows up unmarked. The state traveled to the wrong bike.

2. With key={bike.id}. React matches elements by identity, not by position: it recognizes that bici-005 still exists — it has simply moved — and moves its DOM node along with its state, without recreating it. Every other component isn't even touched. Result: the star follows bici-005 all the way to the front of the list, exactly what anyone would expect.

The difference, in reconciliation terms: with the index, React matches position to position, so a move gets interpreted as "all these elements changed their content." With the id, it matches identity to identity, so a move gets interpreted as what it is: a move.

This lesson settles both debts the course had been carrying. The first was practical: BikeList no longer receives first, second and third, nor writes cards by hand; instead it receives the full array and walks it with map, also resolving each station's name from stationId instead of having it hand-written. All five bikes from domain.js show up, and if fifty arrive tomorrow, not a single line will need touching. The second debt went back to lesson 01-05: now you know exactly what a key does — matching elements between renders by identity instead of by position — and you've seen the bug it prevents, with a favorite mark that ends up on the wrong row when an item is deleted.

Along the way you've learned the full mechanics: that map turns an array of data into an array of elements, and that React knows how to paint arrays; that block braces demand a return and parentheses don't; that a key must be unique among siblings and stable across renders, that the domain id is almost always the right answer, and that the index, Math.random() and repeated fields are not; that fragments with a key are written <Fragment key={…}> because the short syntax doesn't accept attributes; that filter is safe and sort mutates, so you should use toSorted or a copy made beforehand; and that nested lists only need keys unique among siblings, not globally.

CicloUrbano's catalogue is now complete as an interactive showcase: it paints from the data, reacts to clicks, adapts to each bike's status, and knows what to say when there's nothing to show. What the app still can't do is collect information. A booking needs a chosen bike, a date, a number of hours, and acceptance of the terms; and that requires form fields whose value is controlled by React, not by the DOM. That's the next step: Controlled Forms.