Cuando construyes una interfaz con Tailwind CSS y notas que repites las mismas clases una y otra vez en componentes como tarjetas o botones, existe una técnica que te ayuda a mantener el código limpio sin perder el enfoque Utility first. Se llama extracción de componentes y se apoya en la directiva @apply.

¿Qué es la extracción de componentes en Tailwind?

La extracción de componentes es una práctica que la propia documentación de Tailwind recomienda cuando un mismo conjunto de utilidades aparece más de una vez en tu interfaz. En lugar de duplicar diez o quince clases en cada card, las agrupas dentro de una única clase CSS reutilizable.

La idea no es abandonar el principio Utility first, sino aplicarlo con criterio. Tailwind sigue siendo la base; solo reorganizas las utilidades en una clase con nombre propio cuando el patrón se repite.

¿Cuándo conviene extraer un componente en Tailwind? Cuando vas a usar el mismo bloque de clases en más de un lugar, como tarjetas, botones o badges. Si el estilo aparece una sola vez, déjalo inline.

¿Cómo funciona la directiva @apply en Tailwind CSS?

@apply es la directiva que permite tomar utilidades de Tailwind y aplicarlas dentro de una clase CSS personalizada. La documentación muestra un ejemplo claro con un botón llamado btn-indigo, donde varias utilidades se agrupan bajo una sola clase.

El flujo es directo:

• Defines una clase nueva en tu hoja de estilos.
• Dentro de esa clase, usas @apply seguido de las utilidades de Tailwind que quieres reutilizar.
• Llamas la clase desde tu HTML como cualquier otra.

Esto te deja un marcado más legible y centraliza los estilos en un solo lugar.

¿Dónde escribo la clase personalizada?

La clase se escribe en la hoja principal de Tailwind, esa que vive en source y donde haces la importación de las directivas base. Ahí declaras tu selector con punto inicial, abres llaves y colocas el @apply con las utilidades que necesites.

Por ejemplo, para una tarjeta el bloque queda así: defines .card, y dentro aplicas todas las utilidades que antes vivían inline en el HTML. Después, en el componente, reemplazas esa larga lista de clases por una sola palabra: card.

¿Por qué necesito correr el build de Tailwind tras crear la clase?

Aquí está el detalle que muchos pasan por alto. Tailwind trabaja con un archivo de configuración que necesita compilarse para que los cambios surtan efecto. Si creas la clase .card con @apply y vas directo al navegador, no verás nada distinto.

Para que la nueva clase se procese y se incluya en el CSS final, debes ejecutar el comando de build en la terminal:

bash npm run tailwind:build

Una vez que la terminal confirma que el build se hizo correctamente, refrescas el navegador y los estilos aparecen aplicados a través de la clase extraída.

¿Qué pasa si no corro el build después de usar @apply? Tu clase personalizada no se compila y el navegador la ignora. Tailwind no aplica los estilos hasta que regeneres el CSS final.

¿Debo extraer todas mis clases de Tailwind a componentes?

No. Y este punto es clave para no malinterpretar la herramienta. Tailwind no está diseñado para que conviertas absolutamente todas tus utilidades en clases personalizadas. Si lo haces, terminas escribiendo CSS tradicional con pasos extra y pierdes la velocidad del enfoque Utility first.

La recomendación práctica es evaluar tu interfaz y preguntarte:

• ¿Este componente aparece más de una vez?
• ¿El conjunto de utilidades es estable y poco propenso a cambiar entre instancias?
• ¿Mejora la legibilidad si lo agrupo bajo un nombre semántico?

Si respondes que sí, extrae. Si es un estilo único o muy variable, déjalo inline.

Conceptos clave que aparecen en la clase

• Utility first: filosofía de Tailwind donde construyes interfaces combinando utilidades pequeñas directamente en el HTML.
• Extracción de componentes: técnica para agrupar utilidades repetidas en una clase CSS con nombre propio.
• Directiva @apply: instrucción de Tailwind que inyecta utilidades dentro de una clase personalizada.
• Build de Tailwind: proceso de compilación que genera el CSS final a partir de tu configuración y tus directivas.

¿Ya identificaste qué componentes de tu proyecto se repiten lo suficiente como para extraerlos? Cuéntame en los comentarios cuáles vas a convertir en clases reutilizables y cómo te fue al correr tu primer build después del cambio.