Llevas dos lecciones arrastrando la misma limitación: el catálogo de CicloUrbano muestra tres tarjetas idénticas porque los datos de la bicicleta están escritos dentro de TarjetaBicicleta. Un componente así no es reutilizable: solo sirve para mostrar esa bicicleta concreta. Las props son la solución, y son uno de los dos o tres conceptos verdaderamente fundamentales de React. Una prop es un dato que un componente recibe desde fuera, de quien lo usa. Convierten un componente rígido en una plantilla parametrizable, definen el contrato entre padre e hijo y son la razón por la que puedes escribir TarjetaBicicleta una vez y usarla en cinco pantallas distintas. En esta lección aprenderás a pasarlas y recibirlas, qué tipos de valores admiten, cómo darles valores por defecto, qué es la prop especial children, por qué son de solo lectura y cómo documentar el contrato de tus componentes. Al terminar, el catálogo mostrará por fin bicicletas distintas.

1. Qué son las props y qué problema resuelven
2. Pasar props y recibirlas
3. Destructuring en la firma del componente
4. Qué tipos de valores se pueden pasar
5. Valores por defecto
6. La prop especial children
7. Las props son de solo lectura
8. Difundir props con el operador de propagación
9. Documentar el contrato de un componente
10. El catálogo de CicloUrbano, ya parametrizado

Props viene de properties. Son los datos que fluyen desde un componente padre hacia un componente hijo a través de los atributos del JSX.

La analogía más útil es la de una función: un componente es una función, y las props son sus argumentos.

Exactamente lo mismo pasa con los componentes:

La analogía no es casual: las props son literalmente los argumentos de la función componente. React recoge los atributos que escribes en el JSX, los mete en un objeto y le pasa ese objeto a tu función como primer parámetro.

Y una propiedad estructural muy importante: el flujo es unidireccional y desciende por el árbol. Un padre pasa datos a un hijo; un hijo nunca «devuelve» datos escribiendo sobre sus props. Esa restricción, que al principio parece limitante, es justo lo que hace predecible una aplicación React: para saber de dónde sale un dato, subes por el árbol; nunca tienes que buscar quién lo modificó por sorpresa.

Dos sintaxis conviven, y la diferencia es la que ya viste en la lección de JSX (01-04):

Un error clásico: precioHora="2.5" pasa la cadena "2.5", no el número. Y "2.5".toFixed(2) no existe, así que la tarjeta reventará. Si el valor no es texto, va entre llaves.

React llama a tu función con un único objeto que contiene todos los atributos que escribiste:

Tres detalles que conviene fijar desde el principio:

• El parámetro puede llamarse como quieras. props es la convención universal, pero es un parámetro normal. Llámalo props.
• Los nombres de las props los eliges tú. No hay una lista de props válidas: son el vocabulario de tu componente. Usa camelCase (precioHora, estacionId), igual que en JavaScript.
• Si no pasas un atributo, esa prop vale undefined. No da error; simplemente no está. Por eso más adelante veremos los valores por defecto.

Escribir props. delante de cada valor es ruidoso. El destructuring de ES6 permite extraer las props directamente en la firma de la función, y es la forma dominante en React moderno.

Las llaves de ({ modelo, tipo, estado }) no son un objeto: son la sintaxis de desestructuración aplicada al parámetro. Es equivalente a escribir const { modelo, tipo, estado } = props; en la primera línea del cuerpo.

Por qué es mejor:

En CicloUrbano vamos a pasar la bicicleta entera como un objeto, no campo a campo. Se puede destructurar en dos niveles:

La segunda forma es correcta, pero pierde la referencia al objeto completo y se vuelve ilegible con muchos campos. En el curso usaremos la primera: recibimos bicicleta y, si hace falta, la destructuramos en el cuerpo.

Cualquier valor de JavaScript. Literalmente cualquiera.

Veamos los casos que más se prestan a confusión.

Escribir el atributo suelto equivale a ={true}, igual que en HTML con disabled o checked. Ojo con la última línea: omitir la prop da undefined, que es falsy pero no es false. En la práctica ambos se comportan igual en una condición, pero no son el mismo valor.

Es la misma doble llave que ya viste en style={{ color: 'red' }}: las de fuera abren una expresión JSX, las de dentro son el literal de objeto.

Pasar funciones como props es el mecanismo con el que un hijo avisa a su padre de que algo ha ocurrido. Aquí solo necesitas saber que se puede y que la sintaxis es esta; el patrón completo de comunicación hijo → padre se estudia en Elevando el Estado, y los manejadores de eventos en Manejo de Eventos.

Una prop puede contener interfaz. Esto abre la puerta a componentes muy flexibles:

Si el padre no pasa una prop, esta llega como undefined. Para que el componente siga funcionando, se le dan valores por defecto con los parámetros por defecto de JavaScript, directamente en la desestructuración:

Un matiz que causa sorpresas: el valor por defecto se aplica solo si la prop es undefined, no si es null, 0 o cadena vacía.

En código antiguo verás esta otra forma:

defaultProps está eliminado para componentes de función a partir de React 19. Si lo encuentras, es código anterior y hay que traducirlo a parámetros por defecto. En componentes de clase sigue funcionando, porque una clase no tiene una firma donde escribir los valores por defecto.

Hay una prop que no se pasa como atributo: todo lo que escribes entre la etiqueta de apertura y la de cierre de un componente llega en la prop children.

El componente que lo recibe:

children es la base del patrón de composición: escribes componentes que aportan una estructura o un comportamiento y dejas que quien los use decida el contenido.

Un mismo Panel, dos contenidos completamente distintos. Sin children habría que inventar props para cada caso posible, o duplicar el componente.

Cosas que conviene saber sobre children:

• Puede ser cualquier cosa: texto, un elemento, varios elementos, un array, o nada (undefined).
• children no se puede pasar también como atributo. Si escribes <Panel children="hola">adiós</Panel>, el contenido entre etiquetas gana.
• Un componente puede tener varias «zonas» de contenido pasando elementos JSX por props con nombre (cabecera={<…/>}, pie={<…/>}). Es lo que a veces se llama slots.

Este patrón tiene mucho más recorrido —contenedores genéricos, envoltorios, especialización de componentes— y se profundiza en Composición vs Herencia.

Esta es la regla más importante de la lección, y no admite excepciones:

Un componente nunca debe modificar sus propias props. React funciona bajo la premisa de que un componente, ante las mismas props, produce siempre el mismo resultado. A eso se le llama ser una función pura.

Depende de qué estés mutando, y ninguno de los dos escenarios es bueno:

El segundo caso es el peligroso: silencioso, difícil de depurar y capaz de producir «datos que cambian sin que nadie los pinte». En CicloUrbano, mutar bicicleta.estado dentro de la tarjeta modificaría el array bicicletas importado de dominio.js para toda la aplicación.

• Si solo necesitas un valor transformado para pintarlo, calcula una variable local. Eso es perfectamente correcto: lo prohibido es escribir en la prop, no leerla ni derivar de ella.

• Si el dato tiene que cambiar de verdad, no es una prop: es estado, y lo verás en la próxima lección. Y si el cambio lo origina el hijo pero el dato pertenece al padre, el hijo avisa mediante una función recibida por props (04-01).

El operador de propagación (...) permite pasar todas las propiedades de un objeto como props de golpe:

Y el componente las recibe como props sueltas:

También se puede combinar con props explícitas, y el orden manda: lo que se escribe después gana.

Es una herramienta cómoda que se abusa con facilidad. Los inconvenientes:

Los usos legítimos son los componentes envoltorio que reenvían props que no conocen:

Aquí ...resto recoge todas las props que no hemos desestructurado (type, disabled, onClick…) y las reenvía. Ese es el caso en el que el operador brilla.

Regla del curso: en CicloUrbano pasaremos el objeto completo como una prop con nombre —bicicleta={bici}— en lugar de difundirlo. El contrato queda explícito y la firma del componente se lee sola.

Las props son el contrato público de tu componente. En JavaScript puro, nada impide pasar un número donde se espera un objeto, así que conviene dejarlo escrito.

Cuesta treinta segundos y resuelve el 80 % de los casos.

Antes de que TypeScript se generalizara, la comprobación de tipos en React se hacía con la librería prop-types, que valida en tiempo de ejecución y solo en desarrollo, imprimiendo un aviso en consola:

Lo mencionamos porque lo encontrarás en muchísimo código existente, pero hoy está desaconsejado para proyectos nuevos: prop-types es una dependencia extra, solo avisa cuando el error ya ha ocurrido y no ayuda al editor.

Es la respuesta moderna: los tipos se comprueban antes de ejecutar, el editor autocompleta las props y renombrar un campo se propaga solo.

El tipado serio de componentes es el contenido de TypeScript con React. Hasta entonces, en CicloUrbano usaremos el nivel 1: un comentario claro encima de cada componente reutilizable.

Es el momento de romper el techo. Vamos a convertir TarjetaBicicleta y EtiquetaEstado en componentes parametrizados y a pintar bicicletas distintas.

La clase se construye con una plantilla: estado--${estado} produce estado--disponible, estado--alquilada o estado--mantenimiento, que son las clases CSS que definimos en la lección 02-01. Toda la regla «qué color corresponde a qué estado» vive ahora en un solo sitio.

Lo que ha pasado aquí, punto por punto:

• { bicicleta, nombreEstacion = '…' }: destructuring en la firma, con un valor por defecto para la prop opcional.
• precioFormateado: una variable derivada de la prop. Leemos la prop y calculamos; no la modificamos. toFixed(2) da "2.50" y el replace lo convierte al formato decimal español, "2,50".
• tarjeta-bicicleta--${bicicleta.tipo}: la clase de variante ya no está escrita a mano; sale del dato. urbana, electrica o carga.
• <EtiquetaEstado estado={bicicleta.estado} />: TarjetaBicicleta es padre de EtiquetaEstado y le pasa una prop. Las props descienden por el árbol de nivel en nivel.

Sí, tres props numeradas es una solución fea, y lo es a propósito: es el síntoma de que falta una herramienta. Esa herramienta es recorrer un array con map, y llega en Listas y Claves. Fíjate en que el problema ya no es de props, sino de repetición.

Guarda y mira el navegador. Por fin:

Tres tarjetas distintas producidas por un único componente. Ese es el momento en el que React empieza a rentabilizarse: cualquier cambio de diseño en la tarjeta se escribe una vez y se aplica a las tres.

Todas las flechas apuntan hacia abajo. Ninguna sube. Eso es el flujo unidireccional de React.

• Pasar números como cadenas. precioHora="2.5" entrega el texto "2.5", y cualquier operación aritmética o toFixed fallará. Si no es texto literal, va entre llaves.
• Olvidar las llaves de la desestructuración. function TarjetaBicicleta(bicicleta) recibe el objeto props completo bajo el nombre bicicleta, así que bicicleta.modelo es undefined. La firma correcta es function TarjetaBicicleta({ bicicleta }).
• Mutar una prop de tipo objeto. bicicleta.estado = 'alquilada' no da error y por eso es tan peligroso: modificas el dato del padre sin que React lo sepa. Si el dato debe cambiar, es estado.
• Ejecutar la función al pasarla. alReservar={reservar()} llama a reservar durante el render y pasa su resultado. Sin paréntesis: alReservar={reservar}.
• Confiar en el valor por defecto ante un null. Solo se aplica con undefined. Si el padre puede enviar null, gestiónalo explícitamente.
• Abusar de {...objeto}. Cómodo de escribir, caro de mantener. Resérvalo para envoltorios que reenvían props desconocidas.
• Usar defaultProps en un componente de función. Eliminado en React 19. Usa parámetros por defecto.
• Consejo: la firma es documentación. function TarjetaBicicleta({ bicicleta, destacada = false }) dice más que cualquier comentario. Cuida los nombres de las props: son el vocabulario público del componente.
• Consejo: si un componente recibe más de cinco o seis props, sospecha. O hace demasiadas cosas, o varias props deberían viajar agrupadas en un objeto.
• Consejo: inspecciona las props en DevTools. La pestaña Components muestra las props reales de cada instancia. Es la forma más rápida de descubrir que estás pasando undefined.

Convierte TarjetaEstacion (creada en la lección 01-03 con datos fijos) en un componente parametrizado. Debe recibir una prop estacion con la forma del dominio.js y una prop opcional bicicletasEnEstacion (número, por defecto 0), y mostrar el nombre, el barrio, el total de plazas y el número de bicicletas. Después úsalo en App.jsx para pintar las tres estaciones de CicloUrbano, escribiéndolas una a una.

Crea el componente Panel descrito en el apartado 6 (src/componentes/Panel.jsx), con props titulo (cadena, obligatoria) y children. Añádele una prop opcional pie que admita un elemento JSX y se pinte debajo del contenido si se proporciona. Luego úsalo dos veces en App.jsx: una envolviendo la lista de bicicletas y otra con un aviso de texto.

Pista: para pintar el pie solo si existe, recuerda que en JSX {undefined} no pinta nada.

Este componente tiene cuatro errores relacionados con las props. Encuéntralos, explica qué provoca cada uno y escribe la versión corregida.

Solución 1.

Fíjate en plazasLibres: es un valor derivado de las props, calculado en cada render. No es una prop ni hace falta guardarlo en ningún sitio. Esa distinción entre lo que se guarda y lo que se calcula será central en la próxima lección.

Solución 2.

El mismo componente envuelve una lista completa en un caso y un párrafo en el otro: eso es lo que aporta children. La expresión {pie && <div…>} es renderizado condicional, que se estudia a fondo en Renderizado Condicional; aquí basta con saber que si pie es undefined, no se pinta nada.

Solución 3.

Los cuatro errores:

1. Firma incorrecta. function FilaBicicleta(bicicleta, precioHora = 0) trata las props como dos parámetros distintos. React siempre pasa un único objeto como primer argumento, así que bicicleta acaba siendo el objeto props entero y precioHora nunca recibe nada: se queda en su valor por defecto, 0. Hay que desestructurar: ({ bicicleta, precioHora = 0 }).
2. Mutación de una prop. bicicleta.modelo = bicicleta.modelo.toUpperCase() modifica el objeto del dominio.js, afectando a toda la aplicación y sin disparar ningún render. Hay que calcular una variable nueva.
3. Número pasado como cadena. precioHora="2.5" entrega el texto "2.5"; "2.5".toFixed no existe y lanza TypeError. Debe ser precioHora={2.5}.
4. Contrato incoherente. precioHora ya viene dentro del objeto bicicleta; pasarlo además por separado duplica la fuente de verdad y permite que las dos se contradigan. Debe leerse de la bicicleta.

Versión corregida:

Las props son el mecanismo con el que un componente recibe datos del exterior, y con ellas el catálogo de CicloUrbano ha dejado de ser una maqueta: un solo TarjetaBicicleta pinta ahora tres bicicletas distintas con su modelo, su precio, su variante de color y su distintivo de estado. Sabes pasarlas como atributos —texto entre comillas, todo lo demás entre llaves—, recibirlas con destructuring en la firma, darles valores por defecto con parámetros por defecto (y que defaultProps ya no existe para funciones en React 19), pasar cualquier tipo de valor —incluidos objetos, funciones y elementos JSX— y usar la prop especial children para construir contenedores como Panel que envuelven contenido arbitrario.

Y tienes clara la regla que sostiene todo el modelo: las props son de solo lectura. Un componente las lee y deriva valores de ellas, pero nunca las escribe. El flujo de datos baja por el árbol y no sube, lo que hace que rastrear el origen de cualquier dato sea siempre posible. También sabes que difundir props con {...objeto} es cómodo pero borra el contrato, y que ese contrato conviene documentarlo, hoy con un comentario y en el futuro con TypeScript.

Queda una pregunta abierta, y es grande: si las props vienen de fuera y no se pueden modificar, ¿cómo cambia algo en una aplicación React? Cuando el usuario elige un filtro, reserva una bicicleta o pulsa un botón, algo tiene que cambiar y provocar un nuevo render. Ese algo es el estado: la memoria propia de un componente, el dato que sí puede cambiar y que, al hacerlo, dispara el ciclo de renderizado que estudiaste en 01-05. Es el tema de la siguiente lección: State: Gestión del Estado del Componente.