Hasta el momento en el Manual de Tailwind CSS hemos aprendido a usar las clases de utilidad que nos facilita el framework, lo que ha estado muy bien. Sin embargo, queda mucho por ver y en este artículo comenzamos con una de las partes más interesantes de la herramienta, que distingue a Tailwind de cualquier otro framework CSS existente hasta la fecha: su capacidad de personalización.

Tailwind ofrece una cantidad enorme de clases de utilidad. Su enfoque es ofrecer gran cantidad de clases para que tú no tengas que editar prácticamente nada de CSS, salvo cuidarte para no repetir código. En esencia este workflow ya lo explicamos en el artículo anterior, dedicado a explicar el enfoque de clases de utilidad.

Ahora bien, muchas de las clases de Tailwind están pensadas para servir de modo general, para que encajen en la mayoría de los proyectos, sin embargo puede que no sea exactamente lo que necesitamos para algún diseño en particular. Por ello en ocasiones es necesario personalizar el generador de código CSS para que se adapte a unas necesidades concretas. Esta tarea la realizaremos dentro del archivo de configuración de Tailwind, que habíamos generado anteriormente en el proyecto, llamado "tailwind.config.js".

Este archivo de configuración ofrece una gama de posibilidades impresionante. Ahora vamos a explicar varias de sus posibilidades, centradas en la declaración "themes".

Configuración predeterminada de Tailwind

Recuerda que el archivo de configuración de Tailwind lo generamos con el comando:

npx tailwind init

Como resultado se generó el archivo "tailwind.config.js" con unas declaraciones pero sin ningún dato. Tal como está, es lo mismo que no tener nada y básicamente lo que hará el framework es tomar la configuración predeterminada.

Es una buena idea ver cómo es esa configuración por defecto, ya que nos va a servir de guía para que nosotros podamos crear las configuraciones personalizadas. Para ello lanzamos el mismo comando npx tailwind init, indicando otro nombre de archivo donde almacenar la configuración predeterminada y el flag --full.

npx tailwind init tailwind-full.config.js --full

Esto generará un archivo llamado tailwind-full.config.js que no servirá para nada más que permitirnos observar la configuración completa y predeterminada de la generación de clases de utilidad presentes en Tailwind. Son más de 800 líneas de código en las que se modelizan absolutamente todas las posibilidades del framework para la generación de las clases.

Esas posibilidades se mezclan para generar miles de combinaciones de clases distintas, las que ofrece Tailwind si no lo optimizamos.

Para editar estas configuraciones tenemos dos alternativas posibles.

• Sobreescribir configuraciones existentes, o
• Añadir nuevas configuraciones personalizadas, que se unen a las existentes.

Sobreescribir configuraciones de Tailwind

Vamos a comenzar explicando cómo sobreescribir las configuraciones ofrecidas de manera predeterminada.

Al principio del archivo de configuración global encontramos la declaración "theme", que empieza con este código:

theme: {
    screens: {
      sm: '640px',
      md: '768px',
      lg: '1024px',
      xl: '1280px',
    },
    // ...
}

Bien, los "screen" definidos en el theme son los distintos tamaños de los breakpoints que podemos usar para el diseño responsive, que el framework transformará en mediaqueries sobre las que puedes definir estilos personalizados a distintos tamaños de pantallas.

Para modificar este apartado de configuración tenemos toda la flexibilidad imaginable:

• Podemos cambiar los nombres de los saltos, por otros que nos resulte más sencillo de recordar. Por ejemplo, cambiar "md" por "tablet" o "lg" por "desktop".
• Podemos cambiar el valor en píxeles de cada breakpoint. Por ejemplo, igual necesitamos que el primer breakpoint se produzca a los 500px en vez de 640px.
• Podemos eliminar saltos si no los vamos a utilizar
• Podemos agregar nuevos breakpoints si los necesitamos.

Obviamente, cuantos más saltos tengamos, más combinaciones de todas las clases de utilidad de Tailwind existirán y por tanto aumentará el tamaño del archivo de CSS. Por tanto, una buena vía para comenzar la optimización sería reducir el tamaño de breakpoints. Pero tranquilo, tampoco pasa nada si los dejas, puesto que luego con PostCSS podremos hacer un vaciado de todos los estilos que no vamos a utilizar.

Por ejemplo, podríamos definir estos breakpoints (solo a modo de ejemplo, no digo que sean o no los adecuados para un diseño en particular).

theme: {
  screens: {
    bigMobile: '420px',
    tablet: '768px',
    desktop: '1024px',
  },
  extend: {},
},

Ten en cuenta que después de cambiar el fichero de configuración tendrás que recompilar el código CSS generado para que tenga efecto y si usas "watch" tendrás que volverlo a arrancar.

Gracias a esta configuración tendrás algunas clases como: tablet:border-red-700, tablet:hover:bg-green-900, bigMobile:py-3, desktop:mt-5… Sin embargo, se habrán eliminado las antiguas convenciones del framework para breakpoints como "sm", "md", etc., ya que no están ya definidas como propiedad en el objeto "screens".

Añadir nuevas configuraciones personalizadas al tema

Ahora vamos a aprender cómo podemos agregar configuraciones al tema existente, en vez de sobre escribir las que se ofrecen de manera predeterminada. Esto es muy útil en gran cantidad de casos, porque muchas veces simplemente queremos añadir un color que no está presente en Tailwind, por ejemplo, pero no queremos perder todas las definiciones de colores que ya existen de antemano.

Vamos a imaginar que queremos trabajar con un color primario y uno secundario. Esos colores puede que no estén justamente en la paleta de Tailwind (siempre habrá uno parecido, pero quizás necesites usar un RGB exacto forzado por la imagen de marca de tu cliente), pero además es muy probable que quieras llamarles justamente así "primary" y "secondary" a lo largo de todo tu diseño.

Podríamos pensar que esta situación se solucionaría de la siguiente manera:

theme: {
  colors: {
    primary: '#fe3',
    secondary: '#ba0',
  },
},

Sin embargo, si pruebas esa configuración verás que, aunque funciona, se habrán eliminado todas las clases de todos los colores existentes. Solucionarlo es fácil, mediante la extensión en vez de la sobreescritura.

theme: {
  extend: {
    colors: {
      primary: '#fe3',
      secondary: '#ba0',
    },
  },
},

En el código anterior habrás visto que hay justamente una propiedad llamada "extend", que nos sirve para agregar configuraciones al tema. Justamente lo que necesitamos. Ahora podemos usar clases con los colores "primary" y "secondary", pero todavía podemos seguir trabajando con los colores definidos en el framework como "gray-400".

<div class="p-4 bg-primary text-gray-400">
  Esto es un <span class="text-secondary">test!!</span>
</div>

Existen muchos otros casos en los que la extensión de un tema será la solución más óptima, por ejemplo cuando necesitamos definir una medida extra para una anchura. Por ejemplo necesitamos definir medidas de unos elementos en un tamaño que no está definido en el framework. Deseamos agregarlo, pero no deseamos prescindir de las medidas que ya estaban representadas anteriormente en las clases de utilidad.

Conclusión

Hemos aprendido a mejorar los temas de diseño de Tailwind por medio de la configuración definida en la propedad "theme" de tailwind.config.js. De esta manera podemos aumentar la versatilidad que nos ofrece el framework de diseño, sin quedarnos restringidos a un conjunto de opciones predefinidas.

Cuando vi estas posibilidades por primera vez me resultaron especialmente interesantes, ya que me ayudan a mantener un control estrecho de los estilos y posibilidades de diseño que se pueden conseguir. Creo que representan una diferencia fundamental con otros frameworks, que hacen que Tailwind gane bastantes enteros.

Para acabar sólo me queda comentar que podríamos pretender ser muy minuciosos y quitar manualmente del archivo de configuración todas las declaraciones que no pensamos utilizar, como colores, tamaños, breakpoints, etc. Con eso ganaríamos en optimización. La verdad es que no deja de ser cierto, pero no es la mejor manera de conseguir ahorrar espacio en el CSS generado. En el siguiente artículo dedicado a la optimización de Tailwind veremos opciones mejores y más sencillas de producir.