Tailwind 4: ¿Componentes o utilidades? Cómo crear variantes y heredar clases sin romper tu sistema

Introducción: el dilema de extender clases en Tailwind

Cuando empiezas a trabajar con Tailwind CSS, todo parece simple: aplicas utilidades directamente en el HTML y vas componiendo tus diseños sin necesidad de escribir CSS personalizado.

Pero tarde o temprano surge la pregunta:

👉 ¿Cómo creo variantes de un componente sin duplicar código?

Un botón básico es sencillo de definir, pero ¿qué pasa cuando necesitas botones primarios, secundarios, con diferentes tamaños o estilos outline? ¿Tengo que repetir las mismas utilidades una y otra vez?

Aquí entra el debate: usar @layer components o @utility en Tailwind 4.

Y de cómo entiendas esta diferencia dependerá que tu proyecto sea escalable y fácil de mantener… o un caos de clases repetidas.

Qué es @layer components y cómo funciona

Tailwind organiza su CSS en capas: base, components y utilities.

La que más nos interesa aquí es components.

• En @layer components puedes definir clases personalizadas que combinan utilidades.
• Estas clases pueden heredarse entre sí usando @apply.

👉 Dicho en simple: @layer components es el lugar para crear componentes base y sus variantes.

Ejemplo: botón con variantes

@layer components {
  .btn {
    @apply inline-flex items-center justify-center px-4 py-2 rounded-lg font-semibold transition;
  }

  .btn-accent {
    @apply btn bg-accent text-white hover:bg-accent-dark;
  }

  .btn-outline {
    @apply btn border border-gray-300 text-gray-700 bg-white hover:bg-gray-50;
  }

  .btn-lg {
    @apply btn px-6 py-3 text-lg;
  }
}

• .btn → botón base.
• .btn-accent → variante de acento que hereda de .btn.
• .btn-outline → variante de contorno.
• .btn-lg → variante de tamaño grande.

➡️ Aquí sí hay herencia real: todas las variantes parten de .btn.
➡️ Si mañana cambias el border-radius en .btn, todas las variantes lo heredan automáticamente.

Qué es @utility y cuándo conviene usarlo

Tailwind 4 introdujo la directiva @utility, pensada para crear utilidades personalizadas que funcionan igual que las nativas (bg-red-500, flex, grid-cols-3, etc.).

Características:

• Cada @utility define una sola clase.
• No puedes hacer @apply de otra utilidad personalizada.
• Son independientes entre sí.

👉 Esto lo convierte en la opción ideal para helpers concretos, no para componentes con variantes.

Ejemplo: helper para grids

@utility content-grid {
  @apply grid gap-8 md:grid-cols-3;
}

• .content-grid siempre genera una rejilla de 3 columnas en pantallas medianas.
• Es una clase autónoma, no depende de ninguna otra.

Otro ejemplo:

@utility stack-md {
  @apply flex flex-col gap-6 md:gap-8;
}

• .stack-md alinea elementos en columna con un espaciado adaptable.
• No tiene relación jerárquica con otras clases.

Diferencias clave entre @layer components y @utility

Cómo encaja esto en WordPress y Flowtitude

En un flujo real de trabajo con WordPress (ya sea Bricks, Gutenberg o Elementor), esta distinción cobra mucho sentido:

• Componentes (@layer components):
  • Botones (.btn, .btn-accent, .btn-lg).
  • Tarjetas (.card, .card-featured).
  • Tipografía (.heading, .lead).
• Utilidades (@utility):
  • Helpers de layout (.content-grid, .stack-md).
  • Patrones de espaciado vertical.
  • Variantes de grid proporcionales.

Flowtitude organiza estas capas de forma explícita:

1. wordpress – estilos básicos de compatibilidad.
2. bricks – ajustes específicos del constructor.
3. theme – tokens y estilos globales.
4. base – tipografía, reset.
5. layouts – estructuras como .content-grid.
6. components – botones, tarjetas, formularios.
7. utilities – helpers pequeños.
8. custom – excepciones puntuales.

👉 De esta manera, el CSS manual queda relegado a un lugar claro y justificado.

Casos prácticos

Caso 1: Botones con variantes heredadas

@layer components {
  .btn {
    @apply inline-flex items-center justify-center px-4 py-2 rounded-lg font-semibold transition;
  }

  .btn-primary {
    @apply btn bg-primary text-white hover:bg-primary-dark;
  }

  .btn-secondary {
    @apply btn bg-gray-200 text-gray-900 hover:bg-gray-300;
  }

  .btn-danger {
    @apply btn bg-red-600 text-white hover:bg-red-700;
  }
}

Uso en WordPress (ejemplo en Bricks):

<button class="btn-primary">Guardar</button>
<button class="btn-secondary">Cancelar</button>
<button class="btn-danger">Eliminar</button>

➡️ Un solo componente base, múltiples variantes, sin duplicar código.

Caso 2: Layout repetido con @utility

@utility section-container {
  @apply container mx-auto px-4 md:px-8;
}

@utility content-grid {
  @apply grid gap-6 md:grid-cols-2 lg:grid-cols-3;
}

Uso en Gutenberg:

<section class="section-container">
  <div class="content-grid">
    <div class="card">Servicio A</div>
    <div class="card">Servicio B</div>
    <div class="card">Servicio C</div>
  </div>
</section>

➡️ Aquí no necesitas herencia, solo reutilizar patrones de layout.

Caso 3: Tipografía consistente

@layer components {
  .heading {
    @apply text-3xl font-bold tracking-tight md:text-4xl;
  }

  .lead {
    @apply text-lg text-gray-600 md:text-xl;
  }
}

Uso en Bricks:

<h2 class="heading">Nuestros servicios</h2>
<p class="lead">Descubre cómo podemos ayudarte a escalar tu negocio online.</p>

➡️ Roles tipográficos predecibles, sin CSS manual disperso.

Buenas prácticas para no caer en el caos

1. Define primero tus tokens (@theme en Flowtitude).
2. Reserva @layer components para patrones repetidos que requieren variantes.
3. Usa @utility para helpers de una sola responsabilidad.
4. Documenta tu sistema (qué es un componente, qué es un helper).
5. Evita duplicar: si una variante repite el 90 % de otra, hereda con @layer.
6. Limita el CSS manual a la capa custom y justifícalo.

Conclusión: herencia sí, pero con reglas claras

El gran error es pensar que Tailwind y CSS manual están en guerra.
La realidad es que Tailwind 4 te da dos herramientas distintas para organizar tu CSS:

• @layer components → Para heredar y crear variantes sin duplicar código.
• @utility → Para helpers independientes y patrones repetidos.

Si entiendes esa diferencia y la aplicas con cabeza, tu sistema será:

✅ Más consistente.
✅ Más escalable.
✅ Más fácil de mantener en WordPress.

❌ Si intentas usarlo todo como utilidades, caerás en duplicación.
❌ Si metes todo en @layer sin pensar, acabarás con “mini frameworks” difíciles de entender.

La clave está en el equilibrio.