En la primera lección del módulo dijimos que un componente encapsula tres cosas: marcado, lógica y estilo. Las dos primeras ya están resueltas: el marcado vive en el JSX y la lógica en el cuerpo de la función. El estilo, en cambio, sigue amontonado en un único src/index.css que crece sin control y donde nada impide que dentro de tres meses dos personas distintas definan una clase .tarjeta con reglas incompatibles. React no impone ninguna solución a esto: te ofrece varias estrategias y espera que elijas con criterio. En esta lección verás las cuatro que se usan en la práctica, todas aplicadas al mismo componente —TarjetaBicicleta— para poder compararlas de verdad, aprenderás a construir nombres de clase dinámicos a partir del estado de una bicicleta, ordenarás la paleta de CicloUrbano con variables CSS y adoptarás la estrategia que el proyecto usará de aquí en adelante.

1. El problema: el estilo también es parte del componente
2. Estrategia 1: CSS global importado
3. Estrategia 2: estilos en línea con objetos
4. Estrategia 3: CSS Modules con Vite
5. Estrategia 4: CSS-in-JS y frameworks de utilidades
6. Clases condicionales según el estado de la bicicleta
7. Variables CSS para la paleta de CicloUrbano
8. Comparativa final y decisión del curso

Hoy TarjetaBicicleta está incompleta como unidad: su marcado y su lógica están en TarjetaBicicleta.jsx, pero sus reglas de estilo están a cien líneas de distancia, en un fichero que comparte con todo lo demás. Eso produce cuatro problemas concretos:

React no resuelve esto por ti, pero sí te da el ingrediente que faltaba: el componente puede decidir sus clases en tiempo de ejecución, porque className es una expresión JavaScript como cualquier otra.

Las cuatro estrategias que existen se pueden ordenar por dónde vive el estilo:

Es la que has usado hasta ahora, y consiste en escribir CSS normal e importarlo.

Vite también permite importar un .css desde el propio componente, lo cual mejora algo la organización:

Pero cuidado: esto no lo hace local. Vite recoge todos los .css importados y los junta en la hoja de estilos de la página. El fichero está más cerca del componente, sí, pero sus clases siguen siendo globales.

Imagina que dentro de dos meses alguien añade una pantalla de reservas con su propia hoja:

Ese fichero se importa y, sin que nadie lo pretenda, las tarjetas del catálogo pierden su borde y su ancho máximo. No hay error, no hay aviso: solo un diseño roto que aparece al navegar en cierto orden. Depurarlo lleva media tarde.

Las mitigaciones tradicionales existen y funcionan a medias:

• Convenciones de nombres tipo BEM: .tarjeta-bicicleta__titulo, .tarjeta-bicicleta--urbana. Reducen mucho el riesgo, pero dependen de la disciplina de todo el equipo, para siempre.
• Prefijos por componente: la misma idea, con la misma fragilidad.

Cuándo usarlo: para lo que debe ser global. Reinicios (box-sizing), tipografía base, colores del body y, sobre todo, las variables CSS de la paleta, como verás en el apartado 7.

React permite pasar un objeto JavaScript al atributo style:

Recuerda de la lección 01-04 las reglas de este objeto:

• Doble llave: las de fuera abren la expresión JSX, las de dentro son el literal de objeto.
• Propiedades en camelCase: borderRadius, no border-radius.
• Valores como cadenas, con unidades incluidas. Los números sin unidad se interpretan como píxeles: padding: 16 equivale a 16px.

Este es su caso legítimo, y es real. Una barra de ocupación de una estación cuyo ancho depende de los datos no se puede expresar con una clase CSS, porque el porcentaje solo se conoce al ejecutar:

Aquí la división del trabajo es la correcta: la clase aporta todo lo estático (colores, altura, bordes) y el estilo en línea aporta el único valor que depende de los datos.

Cuándo usarlo: solo para valores dinámicos que el CSS no puede conocer —anchos porcentuales, posiciones, transformaciones calculadas— y siempre combinado con una clase que aporte el resto. Nunca como estrategia principal.

Un CSS Module es un fichero CSS normal cuyo nombre acaba en .module.css. Vite lo detecta automáticamente —sin ninguna configuración— y hace dos cosas: renombra cada clase para que sea única en toda la aplicación y te devuelve un objeto que traduce tus nombres a los generados.

Fíjate en los nombres: .tarjeta, .titulo, .dato. Cortos y genéricos, porque el ámbito local hace innecesario el prefijo. No hay ningún riesgo de que choquen con las .tarjeta de otro componente.

import estilos from './TarjetaBicicleta.module.css' no importa texto: importa un objeto que Vite genera al procesar el fichero.

Y el HTML que llega al navegador:

Ese sufijo se calcula a partir del nombre del fichero y de su contenido, de modo que es imposible que dos componentes distintos generen la misma clase. El problema de las colisiones desaparece por construcción, no por disciplina.

Dos detalles de sintaxis útiles:

• estilos[bicicleta.tipo]: acceso por corchetes. Como bicicleta.tipo vale 'urbana', 'electrica' o 'carga', obtenemos la clase de variante correspondiente. Así se conectan los datos con el estilo sin ningún if.
• Clases con guiones: si nombras una clase .tarjeta-destacada, en JS tendrás que escribir estilos['tarjeta-destacada']. Por eso en CSS Modules se estila usar camelCase: .tarjetaDestacada → estilos.tarjetaDestacada.

Esta es la estrategia por defecto de CicloUrbano a partir de ahora, por tres razones: no añade ninguna dependencia, resuelve el problema real (las colisiones) sin pedirte disciplina, y sigue siendo CSS, de modo que todo lo que sabes de la cascada te sirve igual.

Cuando dos componentes necesitan las mismas reglas, hay dos vías limpias:

composes es una funcionalidad propia de CSS Modules: la clase resultante incluye las dos. La alternativa, más sencilla, es poner esas reglas comunes en el CSS global y combinarlas con el helper del apartado 6: className={clases('caja', estilos.tarjeta)}.

Las dos alternativas restantes son muy populares y conviene conocerlas aunque no las usemos en el curso.

Librerías como styled-components o Emotion permiten escribir CSS dentro de JavaScript y obtener un componente ya estilado:

Su gran atractivo es que las props determinan el estilo de forma directa, con toda la potencia de CSS. Sus inconvenientes: una dependencia más, un coste en tiempo de ejecución (los estilos se generan mientras la aplicación corre), fricción con el renderizado en servidor y una tendencia clara del ecosistema a alejarse de este enfoque a favor de soluciones que resuelven en tiempo de compilación (zero-runtime), como Vanilla Extract o Panda CSS.

El enfoque opuesto: en lugar de escribir CSS, se componen clases atómicas predefinidas directamente en el JSX.

Ventajas: no se cambia de fichero para estilar, el CSS final es diminuto porque solo se incluyen las utilidades usadas, y el sistema de diseño (espaciados, colores, tipografías) viene impuesto, lo que da mucha consistencia. Inconvenientes: el JSX se llena de clases y pierde legibilidad, hay una curva de aprendizaje de nombres, y componer condicionales largos exige una librería auxiliar.

Cualquiera que sea la estrategia, hay una necesidad constante: elegir clases en función de los datos. En CicloUrbano, el distintivo de estado debe ser verde si la bicicleta está disponible, naranja si está alquilada y rojo si está en mantenimiento.

La forma más directa, y la que ya usaste en EtiquetaEstado:

estado--${estado} produce estado--disponible, estado--alquilada o estado--mantenimiento. Una sola línea cubre los tres casos y añadir un cuarto estado no exige tocar el componente, solo el CSS.

Cuidado con un límite importante: esto funciona con CSS global, pero no con CSS Modules, porque las clases de un módulo están renombradas. Ahí hay que acceder al objeto:

Cuando la clase depende de un booleano:

Esto se vuelve ilegible enseguida. Con tres o cuatro condiciones aparecen plantillas monstruosas, espacios dobles y undefined colándose en el atributo.

La solución es una función que junte los nombres válidos y descarte lo demás. Ocupa tres líneas y la usarás en todos tus proyectos:

Cómo funciona, paso a paso:

• ...nombres es un parámetro rest: recoge todos los argumentos en un array.
• .filter(Boolean) elimina los valores falsy del array: false, undefined, null, '' y 0. Es un atajo idiomático equivalente a .filter(valor => Boolean(valor)).
• .join(' ') une los que quedan separados por espacios, que es justo el formato de className.

Con él, el JSX vuelve a ser legible:

Si destacada es false, la expresión destacada && estilos.destacada vale false, y filter(Boolean) la descarta. Sin ternarios, sin cadenas vacías, sin espacios sobrantes.

En proyectos reales verás la librería clsx (o classnames), que hace esto mismo con más funcionalidades. Nuestro helper de tres líneas cubre el caso habitual sin añadir dependencias.

Y las clases que faltan en el módulo:

Los colores de CicloUrbano llevan repitiéndose literalmente desde la lección 01-03: #12805c en cinco sitios, #d9e2ec en otros tantos. Cambiar el verde de marca implicaría hoy una búsqueda y sustitución por todo el proyecto, con el riesgo de dejarse alguno.

Las variables CSS (propiedades personalizadas) resuelven esto de forma nativa, sin herramientas ni preprocesadores:

Y ahora cualquier fichero de estilo del proyecto puede usarlas, incluidos los .module.css, porque las variables sí atraviesan el ámbito local: lo que CSS Modules renombra son las clases, no las propiedades personalizadas.

Ventajas concretas:

Ese último punto merece un ejemplo, porque combina lo mejor de las estrategias 2 y 3:

El JavaScript solo aporta el dato; toda la presentación —incluida la transición, imposible en un estilo en línea— sigue en el CSS. Es el patrón recomendado para estilos dinámicos.

No es «elegir una y descartar el resto»: las estrategias se complementan, y este reparto es el que verás en la mayoría de proyectos con Vite:

Estructura de ficheros resultante:

Con esto, TarjetaBicicleta es por fin una unidad completa: su marcado, su lógica y su estilo están en la misma carpeta, con el mismo nombre, y se pueden borrar juntos sin dejar rastro. Esa era la promesa de la primera lección del módulo.

• Usar class en lugar de className. El error más repetido de React. class es palabra reservada de JavaScript.
• Olvidar el .module en el nombre del fichero. TarjetaBicicleta.css es global; solo TarjetaBicicleta.module.css activa el ámbito local. El síntoma es que el import estilos llega vacío y las clases no se aplican.
• Escribir className={estilos} en lugar de className={estilos.tarjeta}. estilos es un objeto; React acabará pintando [object Object] como clase.
• Referirse a una clase que no existe en el módulo. estilos.tarjeat vale undefined y el elemento se queda sin clase, sin ningún error. Es el fallo más difícil de ver: revisa siempre el HTML generado en el inspector.
• Escribir CSS con guiones en un módulo y acceder con punto. .tarjeta-destacada obliga a estilos['tarjeta-destacada']. Usa camelCase en los módulos.
• Insertar false en una plantilla de clase. `tarjeta ${destacada && 'destacada'}` produce literalmente "tarjeta false" cuando la condición es falsa. Usa el helper clases o un ternario con cadena vacía.
• Poner unidades donde React ya las pone, o no ponerlas donde hacen falta. En style, width: 300 es 300px, pero width: '80%' necesita ser cadena. Y flex: 1 o zIndex: 10 van sin unidad.
• Intentar :hover con estilos en línea. No existe. Si lo necesitas, hace falta una clase.
• Consejo: empieza por las variables CSS. Antes de escribir el primer componente de un proyecto, define la paleta en :root. Ahorra una refactorización garantizada.
• Consejo: nombra las clases de un módulo por su papel, no por su aspecto. .titulo y .precio envejecen bien; .textoVerde no.
• Consejo: si un componente necesita más de tres o cuatro clases condicionales, revisa su diseño. Suele ser señal de que hacen falta dos componentes distintos.
• Nota sobre accesibilidad: el color nunca debe ser el único portador de información. Nuestro EtiquetaEstado acierta al mostrar también el texto del estado junto al color. Esto se trata a fondo en Accesibilidad en Componentes Interactivos.

Migra EtiquetaEstado de CSS global a CSS Modules. Crea src/componentes/EtiquetaEstado.module.css con una clase base y una clase por cada estado (disponible, alquilada, mantenimiento), usando las variables CSS de la paleta. Adapta el componente para que combine la clase base con la del estado recibido por props, y añade un efecto de :hover que aumente ligeramente la opacidad.

Pista: la clase del estado hay que obtenerla del objeto de estilos, no construirla con una plantilla de cadena.

Crea el componente DisponibilidadEstacion completo (src/componentes/DisponibilidadEstacion.jsx y su módulo CSS). Debe recibir una estacion del dominio y un número de plazas ocupadas, y mostrar el nombre, el recuento y una barra de progreso. El ancho de la barra debe pasarse como variable CSS desde el componente, y el color debe cambiar según la ocupación: verde por debajo del 60 %, naranja entre el 60 % y el 85 %, rojo por encima.

Usa el helper clases para elegir la clase de color.

Para cada situación, indica qué estrategia de estilo elegirías y por qué. Justifica en dos o tres frases.

1. El reinicio de márgenes y el box-sizing de toda la aplicación.
2. El color de fondo de una fila de tabla que depende del estado de la bicicleta (tres valores posibles).
3. La posición exacta de un tooltip, calculada a partir de las coordenadas del ratón.
4. Un botón de marca reutilizable con estados :hover, :focus y :disabled.
5. La paleta de colores corporativa de CicloUrbano.

Solución 1.

El punto clave: className={`estado estado--${estado}`} deja de funcionar con módulos, porque las clases están renombradas. Hay que consultarlas en el objeto con estilos[estado]. Y si llegara un estado inesperado, estilos[estado] sería undefined y el helper clases lo descartaría sin romper nada: la etiqueta se pintaría sin color de fondo en lugar de fallar.

Solución 2.

Reparto de responsabilidades: el componente calcula solo el dato (porcentaje y nivel), el módulo CSS aporta toda la presentación —incluida la transición— y el estilo en línea se limita a entregar una variable. Tanto porcentaje como nivel son valores derivados: ninguno es estado, como estudiaste en la lección anterior.

Solución 3.

Ya sabes dar estilo a un componente de React con criterio, no por costumbre. Has visto las cuatro estrategias sobre el mismo TarjetaBicicleta: el CSS global, cómodo pero con un espacio de nombres compartido donde las colisiones son cuestión de tiempo; los estilos en línea, imbatibles para valores calculados en ejecución e inútiles para todo lo demás —sin :hover, sin media queries, sin animaciones—; los CSS Modules, que Vite soporta de serie y que resuelven el ámbito local por construcción; y las alternativas del ecosistema, CSS-in-JS y frameworks de utilidades, con sus compromisos bien identificados.

CicloUrbano adopta la combinación que mejor equilibrio ofrece: variables CSS en :root para la paleta y las formas, un .module.css junto a cada componente para todo su estilo, y estilos en línea solo para entregar valores calculados, preferiblemente en forma de variable CSS para que la presentación siga viviendo en el CSS. Por el camino has incorporado dos herramientas que usarás constantemente: construir clases a partir de los datos con estilos[bicicleta.tipo] y componer clases condicionales con el helper clases, que descarta los valores falsos sin ensuciar el JSX.

Con esto cierras el Módulo 2. Sabes qué es un componente como unidad de diseño y cómo trazar sus límites; sabes leer el código heredado escrito con clases y por qué todo lo nuevo se escribe con funciones; sabes parametrizar un componente con props de solo lectura y componer contenido con children; sabes darle memoria con estado, actualizarlo de forma inmutable y distinguir lo que se guarda de lo que se deriva; y ahora sabes vestirlo sin que el estilo se descontrole. TarjetaBicicleta es, por fin, una unidad completa: marcado, lógica y estilo en la misma carpeta.

Pero el catálogo sigue siendo un escaparate. El SelectorTipo guarda el tipo elegido y no filtra nada; ContadorPlazas resta plazas que no le importan a nadie más; no hay formularios, no hay validación y las listas se escriben tarjeta a tarjeta. Falta la interacción de verdad. En el Módulo 3: Trabajando con Eventos aprenderás a manejar los eventos de React con todas sus reglas, a mostrar u ocultar partes de la interfaz con renderizado condicional, a pintar colecciones completas con map y a entender por fin para qué sirven las claves que viste en la reconciliación, a construir formularios controlados y a validarlos, y a hacer que todo ello sea accesible. La próxima lección es Manejo de Eventos en React, y a partir de ahí CicloUrbano dejará de mirarse y empezará a responder.