Llevamos dos módulos arrastrando la misma fealdad: ListaBicicletas recibe tres props llamadas primera, segunda y tercera, y escribe tres tarjetas a mano. Con cinco bicicletas en el dominio.js ya se queda corta; con cincuenta sería insostenible. En esta lección se salda esa deuda y otra más antigua: en la lección 01-05 quedó dicho que las listas necesitan una identidad estable y que la mecánica completa llegaría aquí. Vas a aprender a transformar un array de datos en un array de elementos JSX con map, a entender qué es exactamente una key y qué le hace al algoritmo de reconciliación, a reconocer por qué el índice del array es casi siempre una mala clave —con un ejemplo que puedes reproducir y ver fallar—, y a combinar filter, sort y map sin destrozar los datos originales.

1. El problema: repetición escrita a mano
2. map: de un array de datos a un array de elementos
3. Devolver JSX desde map: el return que se olvida
4. El refactor: ListaBicicletas con map
5. Qué es key y por qué React la necesita
6. Qué sirve como clave y qué no
7. El índice del array: el error reproducible
8. Claves en fragmentos
9. filter y sort sin mutar el array original
10. Listas anidadas: estaciones con sus bicicletas
11. El estado vacío de una lista

Este es el punto de partida, tal como quedó al final de la lección anterior:

Los defectos son estructurales, no de estilo:

Y el problema de fondo: el número de tarjetas es un dato, no una decisión del programador. Debe salir del array.

Array.prototype.map es JavaScript estándar, no una función de React: recorre un array y devuelve otro array nuevo con el resultado de aplicar una función a cada elemento. El array original no se toca.

La idea de React es exactamente la misma, cambiando números por elementos JSX:

Y aquí entra en juego una propiedad del JSX que quizá no esperabas: React sabe pintar un array de elementos. Si pones un array dentro de unas llaves, React lo recorre y pinta cada elemento en orden, sin separadores ni comas.

El flujo mental, en tres pasos:

Fíjate en el key={modelo}: es obligatorio y lo explicaremos en el apartado 5. De momento acostúmbrate a escribirlo siempre que uses map para generar elementos.

La función que pasas a map tiene que devolver algo. Con funciones flecha hay dos formas de escribirla, y confundirlas produce un fallo desconcertante: la lista se queda vacía sin ningún error.

En el tercer caso, la función devuelve undefined para cada elemento, así que map produce [undefined, undefined, undefined], y React no pinta los undefined. Resultado: una sección vacía, sin errores ni avisos. Es un fallo clásico que puede costar veinte minutos.

Regla mnemotécnica: paréntesis devuelven, llaves ejecutan.

Este es el cambio más importante del módulo. Compara el antes y el después.

Y en App.jsx desaparecen las tres props numeradas:

Lo que ha cambiado, punto por punto:

• Una prop en lugar de tres, y con un nombre que describe qué es el dato, no dónde está.
• Las cinco bicicletas se ven, no solo las tres primeras. Y si mañana entran veinte, no hay que tocar nada.
• nombreEstacion ya no está escrito a mano. Antes decía «Plaza Mayor» para las dos primeras porque casualmente era cierto; ahora se resuelve a partir de bicicleta.estacionId, que es el dato real. Con el índice nombrePorEstacion, bici-003 muestra correctamente «Parque Norte» y bici-004, «Estación Central».
• El estado vacío se comprueba con bicicletas.length === 0 mediante un retorno anticipado, como aprendiste en 03-02.
• key={bicicleta.id}: cada tarjeta lleva la identidad estable que React necesita. Vamos a ello.

En la lección 01-05 viste que React compara los dos árboles por posición, nivel a nivel, y que ese criterio funciona bien salvo en un caso: las listas que cambian. Ahí es donde entra key.

Una clave es una cadena o número que le dice a React: «este elemento de la lista es este dato concreto, esté donde esté ahora». React no la usa para nada visual —no llega al DOM, no la puedes leer desde el componente— sino exclusivamente para emparejar elementos entre dos renders.

Supón que el catálogo muestra tres bicicletas y llega una nueva por delante.

Sin claves estables (comparando por posición), React razona así:

Cuatro operaciones sobre el DOM, y las tres primeras reescriben tarjetas que no habían cambiado.

Con key={bicicleta.id}, React compara por identidad:

Una sola creación y ninguna reescritura. Pero el beneficio de verdad no es el rendimiento: es la corrección. Cada tarjeta conserva su estado interno —un desplegable abierto, un campo de horas a medio rellenar, una marca de favorito— porque React sabe que sigue siendo la misma tarjeta.

Ese último punto sorprende a mucha gente:

Si olvidas la clave, React no rompe nada, pero deja un aviso muy visible en la consola: «Warning: Each child in a list should have a unique "key" prop». No lo ignores: significa que tu lista está comparando por posición.

Sobre el índice hay un matiz honesto: es aceptable si se cumplen las tres condiciones a la vez.

1. La lista nunca se reordena ni se filtra.
2. Los elementos nunca se insertan ni se eliminan por el medio o el principio (solo se añaden al final, si acaso).
3. Los elementos no tienen estado interno ni contienen campos de formulario.

El SelectorTipo de 02-04 usaba key={tipo} sobre una constante TIPOS que jamás cambia: ahí incluso el índice habría sido inocuo. Pero como casi ninguna lista real cumple las tres condiciones para siempre, la recomendación práctica es: si el dato tiene id, usa el id; si no lo tiene, dáselo.

La teoría no convence tanto como ver el fallo. Vamos a construirlo.

Y el componente que la usa, con la clave mal puesta:

1. Marca como favorita solo bici-003 (Carga Max), la tercera de la lista. Su estrella se pone en ★.
2. Pulsa «Eliminar» en bici-001 (la primera).
3. Observa la lista resultante.

Lo que esperas: bici-002, bici-003 (★), bici-004, bici-005. Lo que ocurre: bici-002, bici-003, bici-004 (★), bici-005. La estrella se ha movido a la bicicleta equivocada.

¿Por qué? Porque el estado favorita vive en el componente, y React asocia cada componente a su clave. La bicicleta favorita estaba en la posición 2, así que su estado quedó asociado a la clave 2. Al eliminar la primera, todo se desplaza y ahora en la posición 2 está bici-004… que hereda el estado de quien ocupaba esa clave antes.

El estado no se movió: se quedó pegado a la posición, y los datos se deslizaron por debajo.

Repite el experimento: la estrella permanece en bici-003 pase lo que pase. Con la clave correcta, React entiende que bici-001 ha desaparecido y que las demás son las mismas de siempre, así que conserva su estado y solo elimina un nodo del DOM.

Este mismo mecanismo explica un fallo aún más frecuente en aplicaciones reales: un campo de texto a medio rellenar que salta a otra fila al ordenar o filtrar la lista. La causa es idéntica.

A veces cada elemento de la lista necesita producir varios nodos hermanos sin un contenedor que los envuelva. El caso típico es una lista de definición o una tabla:

Esto no funciona: la sintaxis corta <>…</> no admite atributos, así que no hay dónde poner la clave y React avisa. La solución es usar la forma larga del fragmento, importándolo desde React:

La ventaja del fragmento frente al <div> es que no añade un nodo al DOM. En una <dl>, una <table> o un contenedor con display: grid, meter un <div> intermedio rompería la semántica o la maquetación.

En cuanto una lista se pinta con map, lo natural es querer filtrarla y ordenarla. Aquí hay una trampa de JavaScript que muerde con fuerza en React.

Recuerda la regla de inmutabilidad de la lección 02-04: nunca modifiques directamente unos datos que vienen de props, del estado o de un módulo importado. Si haces sort sobre el array de dominio.js, lo reordenas para toda la aplicación, sin que React se entere y sin poder volver atrás.

Las tres formas correctas de ordenar:

toSorted, toReversed, toSpliced y with son la familia de métodos no destructivos añadida a JavaScript en 2023. Están disponibles en todos los navegadores actuales y son la opción más legible. Si tu proyecto debe soportar entornos antiguos, la copia con spread hace exactamente lo mismo.

Tres observaciones importantes:

• visibles es un valor derivado, no estado. Se recalcula en cada render a partir de las props, y por eso nunca puede desincronizarse. Es exactamente la lección de 02-04 aplicada a listas.
• La cadena se lee de arriba abajo: filtrar y luego ordenar. Filtrar primero es además más eficiente, porque se ordenan menos elementos.
• Las claves siguen siendo los id. Aunque el orden cambie con cada criterio, cada tarjeta conserva su identidad y su estado interno.

Este componente es el ensayo general de lo que ocurrirá en Elevando el Estado, cuando el tipo deje de ser una prop fija y venga del SelectorTipo.

Las listas dentro de listas son habitualísimas, y solo tienen una regla nueva: cada map necesita sus propias claves, únicas entre sus hermanos. No hay ningún requisito de unicidad global.

Detalles que merecen atención:

• El map exterior usa cuerpo de bloque con return, porque necesita calcular enEstacion y libres antes de devolver el JSX. Es el caso 2 del apartado 3: si olvidas ese return, no se pinta ninguna estación.
• Dos niveles de claves independientes: key={estacion.id} en las estaciones y key={bicicleta.id} en las bicicletas de cada una. Que bici-001 y est-01 no se parezcan es irrelevante; solo importa la unicidad entre hermanos.
• enEstacion se calcula dentro del map, así que cada estación tiene su propia lista derivada, sin estado adicional.

Con los datos del dominio.js, el resultado es:

Ya lo has usado en los ejemplos, pero conviene fijarlo como patrón porque es de los que distinguen una interfaz cuidada de una descuidada. Una lista puede estar vacía por motivos muy distintos, y el mensaje debería decir cuál:

Distinguir «no hay nada» de «no hay nada que coincida» cuesta tres líneas y evita que alguien piense que la aplicación está rota. Los casos de carga y error se tratarán cuando lleguen los datos asíncronos, en Hook useEffect y Límites de Error.

• Olvidar el return dentro de un map con llaves. La lista sale vacía y no hay ningún error. Recuerda: paréntesis devuelven, llaves ejecutan.
• Usar forEach en lugar de map. forEach siempre devuelve undefined: no produce nada que pintar. Para generar elementos, map.
• Omitir la key. React avisa por consola y tu lista pasa a compararse por posición, con todos los problemas del apartado 7.
• Usar el índice como clave en una lista que se filtra, ordena o elimina. El estado interno se queda pegado a la posición y acaba en la fila equivocada.
• Usar Math.random() como clave. Cada render genera claves nuevas, así que React destruye y recrea toda la lista: pierdes el estado, el foco y el rendimiento.
• Poner la key en el elemento equivocado. Debe ir en el nodo más externo que devuelve el map, no en un hijo suyo.
• Intentar leer props.key dentro del componente. No existe. Si necesitas el identificador, pásalo también como prop normal.
• Repetir claves entre hermanos. Con dos elementos con la misma clave, React avisa y el comportamiento pasa a ser impredecible. Ojo con usar modelo como clave: bici-001 y bici-004 comparten modelo.
• Usar <>…</> cuando hace falta una clave. La sintaxis corta no admite atributos; usa <Fragment key={…}>.
• Ordenar con sort sobre las props o el estado. sort muta el array. Usa toSorted o una copia previa.
• Consejo: si tus datos no tienen id, genéralo al crearlos, no al renderizarlos. crypto.randomUUID() en el momento de añadir el elemento, guardado dentro del objeto.
• Consejo: calcula la lista visible como valor derivado, encadenando filter y toSorted justo antes del return. No la guardes en estado: se desincronizaría.
• Consejo: extrae el contenido de la iteración a un componente propio en cuanto pase de cinco o seis líneas. {bicicletas.map(b => <TarjetaBicicleta key={b.id} bicicleta={b} />)} es una línea que se entiende sola.

Este componente tiene cuatro errores relacionados con listas y claves. Identifícalos, explica el síntoma de cada uno y escribe la versión corregida.

Crea el componente ResumenPorTipo (src/componentes/ResumenPorTipo.jsx) que reciba el array bicicletas y muestre una tabla con una fila por cada tipo (urbana, electrica, carga), indicando cuántas bicicletas hay de ese tipo, cuántas están disponibles y el precio medio por hora formateado a la española.

Requisitos:

• Reutiliza la constante TIPOS sin el valor 'todos'.
• No mutes el array recibido.
• Si un tipo no tiene ninguna bicicleta, la fila debe mostrar «—» en el precio medio en lugar de NaN.
• Usa claves adecuadas.

Partiendo del componente ListaFavoritas del apartado 7, amplíalo para que además permita mover una bicicleta al principio de la lista con un botón «Subir al principio». Después:

1. Ejecútalo con key={indice}, marca como favorita bici-005 (la última) y súbela al principio. Describe qué ocurre con la estrella y explica por qué.
2. Cámbialo a key={bicicleta.id} y repite. Explica la diferencia en términos de reconciliación.

Solución 1.

Los cuatro errores:

Solución 2.

Con los datos del dominio.js el resultado es:

La clave es tipo porque los tipos son únicos entre sí y estables: el array TIPOS_BICICLETA nunca se reordena. El if del precio medio evita el NaN que produciría dividir entre cero.

Solución 3.

El añadido al componente:

1. Con key={indice}. Marcas bici-005 (posición 4) como favorita: el estado favorita: true queda asociado a la clave 4. Al subirla al principio, bici-005 pasa a la clave 0, y la clave 4 la ocupa ahora bici-004. React ve que en la clave 0 sigue habiendo un FilaFavorita del mismo tipo, así que reutiliza el componente y su estado, y solo actualiza las props. Resultado: la estrella se queda en la posición 4, es decir, sobre bici-004, mientras que bici-005, ya al principio, aparece sin marcar. El estado ha viajado a la bicicleta equivocada.

2. Con key={bicicleta.id}. React empareja los elementos por identidad, no por posición: reconoce que bici-005 sigue existiendo —simplemente se ha movido— y mueve su nodo del DOM junto con su estado, sin recrearlo. Los demás componentes no se tocan siquiera. Resultado: la estrella acompaña a bici-005 hasta el principio de la lista, que es lo que cualquiera esperaría.

La diferencia, en términos de reconciliación: con el índice, React empareja posición con posición, así que un movimiento se interpreta como «todos estos elementos han cambiado de contenido». Con el id, empareja identidad con identidad, así que un movimiento se interpreta como lo que es: un movimiento.

Con esta lección se cierran las dos deudas que arrastraba el curso. La primera era práctica: ListaBicicletas ya no recibe primera, segunda y tercera ni escribe las tarjetas a mano, sino que recibe el array completo y lo recorre con map, resolviendo además el nombre de cada estación a partir de estacionId en lugar de tenerlo escrito a mano. Las cinco bicicletas del dominio.js se ven, y si mañana hay cincuenta no habrá que tocar ni una línea. La segunda deuda venía de la lección 01-05: ahora sabes qué hace exactamente una key —emparejar elementos entre renders por identidad en lugar de por posición— y has visto el fallo que evita, con una marca de favorito que se queda en la fila equivocada al eliminar un elemento.

Por el camino has aprendido la mecánica completa: que map transforma un array de datos en un array de elementos y que React sabe pintar arrays; que las llaves de bloque exigen return y los paréntesis no; que la clave debe ser única entre hermanos y estable entre renders, que el id del dominio es casi siempre la respuesta correcta y que el índice, Math.random() y los campos repetidos no lo son; que los fragmentos con clave se escriben <Fragment key={…}> porque la sintaxis corta no admite atributos; que filter es seguro y sort muta, por lo que hay que usar toSorted o una copia previa; y que las listas anidadas solo requieren claves únicas entre hermanos, no globalmente.

El catálogo de CicloUrbano está completo como escaparate interactivo: se pinta desde los datos, reacciona a los clics, se adapta al estado de cada bicicleta y sabe qué decir cuando no hay nada que mostrar. Lo que todavía no puede hacer la aplicación es recoger información. Una reserva necesita elegir bicicleta, indicar una fecha, unas horas y aceptar las condiciones; y para eso hacen falta campos de formulario cuyo valor esté bajo el control de React, no del DOM. Ese es el siguiente paso: Formularios y Componentes Controlados.