Entendiendo css-in-js
El desarrollo de aplicaciones web ha pasado de estar centrado en HTML a hacer uso de JS para prácticamente todo. Incluso manejar estilos.
Hace unos días estuve dando una charla sobre CSS y cómo manejar el caos que puede ocasionar cuando un proyecto crece y no se tiene organización ni conocimientos sólidos de especificidad, entre los temas que abordamos estuvieron css modules y css-in-js.
Quiero aclarar que css-modules es básicamente css-in-js ya que depende de JS para poder aplicarse.
Como lo mencioné css-in-js es un enfoque que se basa en escribir código CSS que será agregado vía JS. Básicamente eso es todo.
Esto no nos exime de saber CSS pero facilita la forma de manejar nuestros estilos para “arreglar” algunas “carencias” del estándar que enfrentamos en nuestro día a día.
css-in-js puede ser usado de varias formas y hay algunas que se adaptan mejor a nuestro modo de trabajo pero al final el objetivo es administrar los estilos de nuestra aplicación.
Estilos definidos en JS usando strings u objetos (emotion, styled components)
Estilos definidos en hojas de estilos e importados por JS (css modules)
Ambas formas nos dan ventajas como el mantener el scope de nuestros estilos limitados al lugar donde lo usamos, esto se logra de distintas maneras algunos agregan los estilos en línea directamente en un elemento y otros crean una clase cuyo nombre contiene un hash para evitar la duplicidad en el nombre de la clase, lo cual tendría efectos visuales no deseados
Normalmente evitamos este tipo de conflictos usando metodologías como BEM pero conforme un proyecto va creciendo se vuelve complicado.
Al tener nuestros estilos limitados el eliminar CSS también se hace más fácil ya que no tenemos que preocuparnos por efectos adversos, aunque esto también trae como consecuencia que “reutilizar” sea un poco más complicado
No todo es bueno, al final nos alejamos un poco del estándar y cómo funciona la web de manera nativa, lo cual puede traer problemas como acoplarnos a cierto modo de trabajo (lo cual puede tener consecuencias en migraciones) y queramos o no siempre habrá CSS externos (design systems, bibliotecas, etc) entonces tenemos que buscar en más de un lugar al momento de resolver problemas.
Estilos definidos en JS
Algo interesante de este enfoque es que evita la duplicidad de estilos, ya que generan un caché donde guardan hashes de los estilos definidos al usar estas bibliotecas y si se usan exactamente los mismos estilos se usa la clase que ya está definida.
Una de las cosas geniales de esto es que permiten quitarnos tooling en nuestro building, los que usamos webpack normalmente usamos loaders para cargar nuestro CSS (style-loader y css-loader), aunque en el caso de algunos pueden complementarse con loaders (style9). Las desventaja es que estos estilos se agregan en runtime y puede traer problemas de performance.
Al ser en runtime y no generar archivos adicionales no es posible guardar nuestro css en un CDN y agilizar el proceso de carga (la carga de css bloquea el renderizado)
Algunas bibliotecas son agnósticas (no ligadas a un framework ui), otras están directamente ligadas a frameworks y otras tienen módulos agnósticos que son usados en implementaciones concretas para cada framework
La ventaja de tener bibliotecas acopladas a los frameworks es que nos permiten organizar, reutilizar y componer nuestros componentes UI para crear interfaces complejas.
La desventaja de esto es el poder desacoplar los estilos y reutilizar en otras partes (lo cual se puede arreglar con organización) y otra es que tienes que aprender cómo funcionan estas bibliotecas para sacarle provecho.
Estilos definidos en hojas de estilos
En particular yo uso este enfoque debido a que está más cercano al estándar de cómo funciona la web y en los proyectos que he trabajado (los cuales tienen css-legacy) se adapta muy bien.
La migración puede ser compleja o simple dependiendo las características usada css modules, por ejemplo si usamos una característica llamada composes es complicado migrar fuera de css modules pero es muy útil si usas atomic css/functional css.
Una desventaja comparado con el enfoque anterior es que no evita la duplicidad de estilos pero se integra con el tooling normal que usamos en la mayoría de las aplicaciones sin depender de otras bibliotecas
En contraparte esta técnica si nos permite generar los estilos en un archivo aparte el cual podemos servir mediante un CDN
Conclusión
El usar css-in-js es decisión personal pero debes ser consciente de que también puede traer problemas si no tienes orden en la manera en cómo trabajas con tu CSS.
