Cerraste el Módulo 1 sabiendo cómo React convierte tus funciones en pantalla: JSX se transforma en objetos, esos objetos forman un árbol y la reconciliación decide qué tocar del DOM real. Ahora toca subir un nivel y mirar el problema desde el diseño, no desde el motor. Un componente no es solo «una función que devuelve JSX»: es la unidad de diseño de tu aplicación, la caja en la que decides qué marcado, qué lógica y qué estilo viven juntos. Esta lección trata de la decisión más frecuente y más determinante que tomarás en React: dónde poner las líneas divisorias. Partiremos del boceto real de la pantalla de catálogo de CicloUrbano, la trocearemos en componentes con criterio, dibujaremos su jerarquía y organizaremos los ficheros para que dentro de veinte componentes sigas encontrando lo que buscas.

1. Qué encapsula realmente un componente
2. Del boceto a los componentes: la pantalla de catálogo de CicloUrbano
3. Tres criterios para decidir los límites de un componente
4. El árbol de componentes: relación padre e hijo
5. Componentes de presentación y componentes contenedores
6. Organización de ficheros y convenciones de nombres
7. Exportación por defecto frente a exportación nombrada
8. Componer: montar la pantalla completa
9. El límite que arrastramos: los datos siguen fijos

En el Módulo 1 escribiste Bienvenida y TarjetaBicicleta como funciones que devuelven JSX. Esa es la mecánica. La idea de fondo es otra: un componente agrupa en un solo sitio las tres cosas que definen un trozo de interfaz.

Durante años la buena práctica en desarrollo web fue justo la contraria: HTML en un fichero, CSS en otro, JavaScript en un tercero. React propone separar por preocupación funcional en lugar de por tecnología. El argumento es sencillo: cuando te piden «cambia cómo se ve una bicicleta en el catálogo», no tocas «el CSS» ni «el JavaScript», tocas la tarjeta de bicicleta. Que todo lo que define la tarjeta esté a la vista en un mismo fichero es lo que hace el cambio rápido y seguro.

Esto tiene tres consecuencias prácticas que conviene interiorizar desde ya:

• Un componente es reemplazable. Si TarjetaBicicleta cumple su contrato, puedes reescribirla entera sin que nada del resto de la aplicación se entere.
• Un componente es reutilizable. El mismo componente sirve en el catálogo, en el detalle de una estación y en la pantalla de reservas.
• Un componente es razonable en aislamiento. Puedes entender qué hace TarjetaBicicleta sin leer App.jsx. Cuando esto deja de ser cierto, casi siempre es porque el componente hace demasiado.

Este es el boceto de la pantalla que vamos a construir durante los próximos módulos: el catálogo de bicicletas de CicloUrbano.

El método para trocearlo es siempre el mismo: rodea con un rectángulo cada zona que tenga un nombre propio y comprueba si ese nombre describe una responsabilidad. Aplicándolo salen cinco componentes:

Fíjate en dos decisiones que no son obvias:

• ListaBicicletas existe aunque de momento parezca un simple contenedor. Le damos entidad propia porque más adelante acogerá los filtros por tipo y estado y el mensaje de «no hay resultados». Es la zona que va a crecer, y tener ya su caja evita que ese crecimiento se derrame sobre App.
• EtiquetaEstado existe aunque sea solo un <span>. El distintivo aparecerá también en el detalle de la estación y en el listado de reservas, y siempre con las mismas reglas de color. Un componente de dos líneas que se usa en tres sitios está más que justificado.

No hay una regla mecánica, pero sí tres criterios que, aplicados en este orden, resuelven casi todos los casos.

Un componente debería poder describirse en una frase sin la palabra «y».

• ✅ «TarjetaBicicleta muestra los datos de una bicicleta.»
• ❌ «Catalogo muestra la cabecera y filtra las bicicletas y pinta las tarjetas y gestiona el pie.»

Cuando la descripción necesita conjunciones, tienes un candidato a división. Ojo con el falso positivo contrario: dividir tanto que cada componente sea una etiqueta HTML disfrazada. Un <TituloSeccion> que solo devuelve <h2> no añade nada.

Si un fragmento aparece —o va a aparecer— en más de un sitio con la misma pinta y las mismas reglas, es un componente. Este criterio es el que justifica EtiquetaEstado: el mapeo de disponible a verde y de mantenimiento a rojo es una decisión que queremos escrita una sola vez. Si estuviera copiada en tres pantallas, el día que cambie la paleta habrá que acordarse de los tres sitios.

Cuidado con el reverso: no crees un componente reutilizable antes de tener el segundo uso. Diseñar para una reutilización imaginaria produce componentes con contratos retorcidos que al final no encajan en el segundo caso real.

No hay un número mágico de líneas, pero sí señales fiables de que un componente se ha pasado de tamaño:

Y una señal de que has dividido demasiado: para entender una pantalla sencilla tienes que abrir siete ficheros y saltar entre ellos. La fragmentación excesiva también es deuda técnica.

Cuando estudies el estado (lección State) aparecerá un criterio adicional muy potente: lo que cambia junto, vive junto. Las partes de la interfaz que se actualizan a la vez suelen pertenecer al mismo componente. De momento quédate con los tres primeros.

Cuando un componente usa a otro dentro de su JSX, se establece una relación padre → hijo. El conjunto de todas esas relaciones forma el árbol de componentes, que es el mapa mental de tu aplicación.

Tres precisiones importantes sobre este diagrama:

• Padre e hijo no es herencia. TarjetaBicicleta no hereda nada de ListaBicicletas; simplemente aparece dentro de su JSX. React no usa herencia entre componentes, usa composición, y ese contraste se estudia a fondo en Composición vs Herencia.
• Un mismo componente aparece tantas veces como se use. En el árbol hay tres nodos TarjetaBicicleta porque hay tres bicicletas en pantalla. Cada uno es una instancia independiente: comparten el código, no los datos ni el estado.
• La información baja por el árbol. El flujo de datos en React es unidireccional: de padre a hijo. Es exactamente el camino que recorrerán las props en la lección Props.

Este árbol es también lo que verás en la pestaña Components de React DevTools, la extensión que instalaste en la lección 01-02. Ábrela mientras construyes: comparar el árbol que has dibujado con el que React muestra es la forma más rápida de detectar que tu estructura mental y tu código se han separado.

Con el tiempo notarás que tus componentes caen de forma natural en dos familias.

La utilidad de la distinción es práctica, no dogmática: empuja la lógica hacia arriba y deja las hojas del árbol tontas. Un TarjetaBicicleta que no sabe de dónde vienen sus datos se puede colocar en cualquier pantalla, se puede probar con dos líneas y se puede rediseñar sin miedo.

Un matiz honesto: en la comunidad de React esta separación se aplicaba antes de forma muy estricta (se hablaba de componentes «tontos» e «inteligentes»). Con los hooks, la línea se ha vuelto más difusa y hoy se considera una guía, no una ley. Aun así, preguntarte «¿esto pinta o esto decide?» sigue siendo una de las mejores formas de aclarar un componente confuso.

Con cinco componentes cualquier organización funciona. Con cincuenta, no. Estas son las convenciones que usaremos en todo el curso.

Las reglas, y el motivo de cada una:

Sobre la estructura de carpetas hay dos escuelas: por tipo (componentes/, datos/, hooks/) y por funcionalidad (catalogo/, reservas/, estaciones/). Para una aplicación pequeña como la nuestra, la primera es más sencilla y es la que seguiremos. En el Módulo 11, cuando CicloUrbano tenga varias secciones, revisaremos si merece la pena migrar a la segunda.

Cada fichero de componente tiene que exportar algo para que otros puedan importarlo. Hay dos formas, y conviene entender bien la diferencia.

Hay como máximo una exportación por defecto por fichero. Es la convención dominante en React para «el componente principal de este fichero».

Puede haber tantas como quieras por fichero. Es la forma natural cuando un módulo expone varias cosas, como nuestro dominio.js.

Convención del curso: exportación por defecto para componentes (un componente por fichero) y exportación nombrada para datos y funciones auxiliares. Es la mezcla más extendida en proyectos con Vite y la que verás en la mayoría del código real.

Vamos a escribir los componentes nuevos y a ensamblar la pantalla. Recuerda: los datos siguen escritos a mano dentro de cada componente, igual que en la lección 01-03.

Dos líneas, y sin embargo es un componente legítimo: concentra la decisión de cómo se representa un estado. Cuando en la lección Props reciba el estado desde fuera, la clase estado--disponible pasará a calcularse y este componente será el único sitio del proyecto donde esa regla exista.

Aquí ocurre algo nuevo: un componente que usa a otro componente. Cabecera importa Bienvenida exactamente igual que App la importaba. No hay ninguna jerarquía especial: cualquier componente puede usar a cualquier otro que importe.

Como Bienvenida ahora vive dentro de un <header>, hay que quitarle el suyo para no anidar dos cabeceras, que sería incorrecto semánticamente:

Este ajuste ilustra algo que verás continuamente: los límites de los componentes se renegocian. Bienvenida nació como la cabecera entera porque no había nada más; ahora que aparece la navegación, su papel se reduce al mensaje de bienvenida y Cabecera asume el marco. Refactorizar límites es trabajo normal, no un síntoma de haberlo hecho mal.

Este componente es un contenedor en formación: hoy solo agrupa, pero es la caja preparada para recibir los filtros del Módulo 3.

Observa la clase tarjeta-bicicleta--urbana: la variante por tipo que fijamos en el diseño de CicloUrbano. En la lección Estilos dejará de estar escrita a mano y pasará a construirse a partir del tipo.

Mira lo que ha pasado con App: se ha quedado en tres líneas de JSX que se leen como un índice de la pantalla. Ese es el objetivo. Un componente raíz que se lee como un esquema es la mejor señal de que la descomposición está bien hecha; un App.jsx de doscientas líneas es la señal contraria.

Añade los estilos de las piezas nuevas a src/index.css:

Abre el navegador y verás la pantalla del boceto… con tres bicicletas idénticas, las tres «Urbana Clásica, disponible, Plaza Mayor». La estructura es correcta; los datos, no.

La causa es la misma que en la lección 01-03: cada componente lleva sus datos escritos dentro. Y esto es exactamente lo contrario de lo que queremos, porque rompe el criterio de reutilización: un componente cuyos datos están dentro solo sirve para mostrar esos datos.

La pieza que falta son las props, y es el contenido de la lección Props: Pasando Datos a Componentes. Allí TarjetaBicicleta recibirá una bicicleta del dominio.js y las tres tarjetas mostrarán por fin bici-001, bici-002 y bici-003. Pintar el array completo sin escribir las tarjetas una a una llegará algo después, en Listas y Claves.

• Crear componentes «por si acaso». Extraer TituloSeccion, ParrafoGris o ContenedorFlex antes de tener un problema real solo añade indirección. Extrae cuando el componente tenga un nombre de dominio evidente o cuando aparezca el segundo uso.
• Dejar que App.jsx crezca sin control. Es el vertedero natural de la aplicación. Si App empieza a contener marcado detallado en vez de una lista de secciones, extrae ese marcado a un componente.
• Definir un componente dentro de otro. Escribir function TarjetaBicicleta() {…} dentro del cuerpo de ListaBicicletas compila, pero en cada render se crea una función nueva; para la reconciliación que estudiaste en 01-05 es un tipo distinto, así que destruye y recrea el subárbol entero y pierde su estado. Define siempre los componentes en el nivel superior del módulo.
• Nombrar por aspecto en lugar de por rol. CajaVerde deja de tener sentido el día que el diseño cambia a azul. EtiquetaEstado sigue siendo correcto pase lo que pase con la paleta.
• Confundir el árbol de componentes con el árbol del DOM. Cabecera no genera ninguna etiqueta <cabecera>: genera lo que hay en su return. Un componente puede producir muchos nodos, uno o ninguno.
• Consejo: dibuja el árbol antes de escribir código. Cinco minutos con un boceto y un rotulador ahorran una tarde de reorganización. Y compáralo después con la pestaña Components de React DevTools.
• Consejo: aplica la prueba del nombre. Si no consigues ponerle a un componente un nombre corto y descriptivo, el problema no es el nombre: son sus límites.

La aplicación de CicloUrbano necesita una pantalla de detalle de estación. El boceto es este:

Identifica los componentes que emplearías, indica cuáles ya existen y cuáles habría que crear, y clasifica cada uno como de presentación o contenedor. Justifica cada decisión con uno de los tres criterios del apartado 3.

Un compañero ha escrito este componente. Detecta los problemas de diseño y propón una descomposición mejor, sin escribir el código completo: basta con el árbol resultante y el nombre y la responsabilidad de cada pieza.

Crea el componente ResumenFlota en src/componentes/ResumenFlota.jsx. Debe mostrar, dentro de una <section className="resumen-flota">, un <h2> con el texto «Resumen de la flota» y tres líneas con los totales de la flota de CicloUrbano según el dominio.js: total de bicicletas, disponibles y no disponibles. Escribe los números a mano (todavía no sabemos calcularlos desde los datos) y colócalo en App.jsx entre la cabecera y la lista. Después dibuja el árbol de componentes actualizado.

Solución 1.

Lo relevante del ejercicio es que cuatro de los seis componentes ya estaban escritos. Eso es lo que se gana con unos límites bien trazados: la segunda pantalla cuesta mucho menos que la primera.

Solución 2.

Problemas de diseño:

1. Sin responsabilidad única. Todo hace de cabecera, navegación, catálogo, tarjeta y pie a la vez; su descripción necesitaría cuatro «y».
2. Cero reutilización. El marcado de la tarjeta está duplicado literalmente, y el del distintivo de estado también. Cualquier cambio de diseño hay que aplicarlo dos veces.
3. Nombre inútil. Todo no describe ninguna responsabilidad, lo cual es el síntoma clásico de límites mal trazados.
4. Marcado no semántico. <div> para las tarjetas y para la navegación, en lugar de <article> y <nav>.

Descomposición propuesta:

Solución 3.

Árbol actualizado:

Los números «5, 3, 2» salen de contar a mano el dominio.js, y ese es precisamente el problema: si mañana entra una bicicleta nueva, el resumen mentirá. Derivar esos totales de los datos es cuestión de una lección.

Un componente es la unidad de diseño de React: encapsula marcado, lógica y estilo de un trozo de interfaz, y su valor depende sobre todo de dónde traces sus límites. Ahora tienes un método para trazarlos: partir del boceto, rodear las zonas con nombre propio y validar cada candidato contra tres criterios —responsabilidad única, reutilización y tamaño manejable—, evitando tanto el componente que lo hace todo como la fragmentación en piezas triviales.

Has convertido el boceto del catálogo de CicloUrbano en un árbol de componentes real: App ensambla Cabecera, ListaBicicletas y PieDePagina; Cabecera contiene Bienvenida; ListaBicicletas contiene TarjetaBicicleta, y esta contiene EtiquetaEstado. Sabes distinguir componentes de presentación de componentes contenedores y usar esa distinción para empujar la lógica hacia arriba y dejar las hojas reutilizables. Y tienes fijadas las convenciones que seguirá todo el curso: un componente por fichero en src/componentes/, PascalCase, extensión .jsx, exportación por defecto para componentes y nombrada para datos.

También has visto el techo con el que chocamos: la estructura es correcta pero las tres tarjetas son idénticas, porque los datos siguen escritos dentro de los componentes.

Antes de romper ese techo, hay una parada obligatoria. Todo lo que has escrito son componentes de función, pero en cualquier proyecto React con algunos años de vida te encontrarás componentes escritos con clases: otra sintaxis, con this, render() y constructor. No vas a escribir código nuevo así, pero sí necesitas saber leerlo. Ese es el tema de la siguiente lección: Componentes Funcionales vs de Clase.