¿Cómo deshacerse del código CSS no utilizado? Parte 2

Hoy publicamos la segunda parte de la traducción de material sobre la lucha contra el código CSS no utilizado.



→ La primera parte

Postprocesamiento CSS

Supongamos que en algún proyecto CSS se escribe usando Less o Sass, y luego se usa un postprocesador para compilar el código existente en CSS normal. En tal proyecto, probablemente, hay un sistema automático para deshacerse de CSS no utilizado, que comienza después del preprocesamiento de CSS. Esto puede verse así:

1. Sass.
2. PostCSS / sistema automático de prefijos.
3. Eliminar CSS no utilizado.
4. Código CSS listo para producción.

Esto, por un lado, tiene sentido y, por otro, se ve un poco extraño a mis ojos. El punto es que con este enfoque, el código fuente que contiene los comandos de estilización no se corrige, sobre la base de lo cual se crea el código CSS resultante, que también incluye CSS no utilizado. En cambio, el CSS innecesario simplemente se elimina al final del proceso de compilación. Sospecho que en JavaScript, al implementar el algoritmo de sacudida de árbol, se ha hecho algo similar durante bastante tiempo. Es decir, tal manejo con CSS no es noticia en absoluto. Pero para mí, todo esto parece estar mal, ya que la base del código CSS es algo que se puede decir que se encuentra en la superficie de los proyectos web. Tal enfoque casi incita a los desarrolladores a escribir CSS sin cuidado, para obtener todo en el código fuente CSS. Y la verdad es que el sistema eliminará CSS innecesarios automáticamente. Pero esto priva completamente a los desarrolladores del deseo de comprender exactamente cómo se diseñan sus diseños, cómo se usa exactamente CSS en ellos.

Purgecss

PurgeCSS es otro proyecto que tiene como objetivo combatir el CSS no utilizado. Aunque esto no se relaciona directamente con las capacidades de este proyecto, me gusta porque su documentación explica claramente sus diferencias con la competencia. Arriba, ya hemos dado un fragmento de comparación entre PurgeCSS y PurifyCSS. Y aquí hay otro extracto de la documentación de PurgeCSS dedicada a PurifyCSS. El punto es que el principal problema con PurifyCSS es la baja modularidad de este proyecto. Sin embargo, esta es la principal fortaleza de PurifyCSS. Como ya se mencionó, PurifyCSS considera que las palabras CSS son todas las palabras que encuentra en los archivos. Este enfoque está lleno de errores. Pero PurifyCSS resuelve este problema al hacer posible crear funciones de extractor. Dicha función toma el contenido de un archivo y extrae de él una lista de selectores CSS utilizados en él. Esto le permite resolver muy bien el problema de deshacerse del código CSS no utilizado.

El proyecto PurgeCSS ahora se ve como un jugador importante en el mercado de limpieza de código CSS. Muchos lo usan, muchos escriben sobre eso.

• Aquí hay material sobre cómo usar PurgeCSS, en particular cuando se trabaja con Bootstrap.
• De este artículo, puede aprender que PurgeCSS no eliminará selectores en circunstancias inusuales utilizando listas blancas.
• Aquí puede aprender cómo se utiliza PurgeCSS junto con los scripts npm y con PostCSS.
• Habla sobre cómo funciona PurgeCSS con Tailwind.

A pesar de que PurgeCSS necesita un ajuste especial para trabajar con Tailwind, parece que estas dos herramientas se combinan perfectamente entre sí. De hecho, incluso en la documentación de Tailwind , puede encontrar una recomendación para compartirlos. Y PurgeCSS tiene una herramienta de línea de comandos para aplicarla en el proceso de construcción de proyectos.

Creo que la esencia de esto se reduce a lo siguiente: Tailwind crea un gran archivo CSS lleno de selectores auxiliares. Pero no se supone que todos estos selectores se utilizarán en el proyecto. El desarrollador los usa para resolver todos los problemas de diseñar su código HTML, y luego PurgeCSS analiza este código HTML y elimina los selectores innecesarios, formando CSS listo para la producción.

Es cierto que PurgeCSS aún necesita estar informado sobre cada archivo HTML y JavaScript utilizado en el sitio. En otras palabras, debe configurar de forma independiente todo lo que se relaciona con los recursos externos y tener en cuenta el hecho de que los datos que ingresan al proyecto desde ciertos almacenes probablemente no puedan analizarse durante el ensamblaje del proyecto. Como resultado, el uso de PurgeCSS en el ensamblaje de proyectos implica una cantidad considerable de trabajo manual.

Mi enfoque favorito para deshacerme de CSS no utilizado

Lo que más me gusta es el siguiente enfoque para eliminar CSS innecesarios. Significa que habría alguien en el equipo de desarrollo del proyecto que esté muy familiarizado con el código CSS de este proyecto. Esta persona debe ser consciente de los problemas actuales con los estilos y debe resolverlos gradualmente. Tal vez esta es una visión obsoleta de la situación que pertenece a una persona que debe mantenerse al día. Pero para mí, en cualquier caso, parece el enfoque más práctico. Teniendo en cuenta que la tarea que estamos considerando es tan difícil de resolver, creo que la respuesta al desafío que esta tarea plantea a los desarrolladores puede ser un trabajo duro. La respuesta es una comprensión del problema y su solución gradual. Un desarrollador front-end que esté familiarizado con el proyecto y sepa qué se usa en él y qué no, puede resolver este problema.

Vi un enfoque extremo para descubrir si se usa un selector de sitio. El bloque CSS utilizó un diseño como background-image: url(/is-this-being-used.gif?selector); . Después de su aplicación, los registros del servidor se verificaron periódicamente para averiguar si se realizó una solicitud para recibir la imagen correspondiente. Si hubo tal solicitud, se utiliza el bloque CSS bajo investigación. Si no fue así, entonces no se usa.

Pero quizás mi herramienta favorita en el kit de herramientas del explorador CSS no utilizado es la que se discutirá en la siguiente sección.

Estudio de proyectos por regresión visual.

Este método consiste en el hecho de que el desarrollador toma tantas capturas de pantalla del sitio como sea posible. Hacen copias de las pantallas de las páginas más importantes, y esas páginas, cuya apariencia depende del estado de la aplicación. Las capturas de pantalla se toman en diferentes navegadores, con diferentes tamaños de pantalla. Estas capturas de pantalla se crean en base a materiales de la rama master del repositorio del proyecto.

Luego, antes de fusionar cualquier otra rama con la rama master , se crean nuevas capturas de pantalla basadas en los materiales de la nueva rama y se comparan con las realizadas para la rama master . Esto, por supuesto, no se hace manualmente, sino mediante programación.

Estrictamente hablando, aquí hay un video en el que se muestra.

Cabe señalar que ya se ha dicho mucho sobre el tema de las herramientas para estudiar la regresión visual, pero el autor de este video es la única persona que explicó todo de manera muy inteligible. No solo debe tomar capturas de pantalla; necesitas compararlos y buscar diferencias entre ellos. Uno no solo debe encontrar diferencias; necesitas aceptarlos o rechazarlos. Además, es necesario que la adopción o aprobación de cambios afecte el proceso de fusión de sucursales en repositorios. Además, el desarrollador debe poder configurar el navegador antes de tomar una copia de pantalla y la capacidad de automatizar el trabajo con capturas de pantalla tomadas.

CSS atómico y CSS-in-JS

Estoy seguro de que muchos de los lectores de este material pueden decir: "No tengo CSS sin usar, ya que las herramientas que uso generan exactamente el código que necesito y nada más".

Si es así, entonces esto es simplemente maravilloso.

Tal vez estamos hablando de Atomizer . Quizás esta es una herramienta de Tachyons , cuyos resultados se pasan a través de UnCSS y están siendo cuidadosos. Tal vez, esta es una combinación de Tailwind + PurgeCSS , que ahora se escucha ampliamente .

Tal vez, todavía funcionan con estilos de alguna manera. Si alguien vincula estrechamente los componentes y estilos de JavaScript, por ejemplo, como cuando usa React and Emotion, o incluso solo aplica módulos CSS con cualquier cosa, una de las ventajas de estos enfoques CSS-in-JS es una reducción en el volumen de CSS no utilizado en proyectos terminados. Además, dado que muchos proyectos basados ​​en JavaScript utilizan el algoritmo de sacudidas de árboles y las técnicas de separación de código, dichos proyectos no solo tendrán menos CSS innecesario. En el curso de su trabajo, solo se cargará lo que se necesita en cada situación específica. Pero, por supuesto, hay inconvenientes en tales enfoques para trabajar con CSS.

Resumen

Ahora pensemos en cómo evitar la aparición de código CSS innecesario en nuestros proyectos futuros. Creo que el futuro del estilo es la separación entre estilos globales y estilos aplicados a componentes individuales. La mayoría de los estilos están limitados al alcance de los componentes, pero existen estilos globales que pueden usarse para explotar la naturaleza en cascada de CSS. Por ejemplo, puede ser algo así como la configuración tipográfica estándar global.

Si la mayoría de los estilos están limitados por el alcance de los componentes, entonces creo que es menos probable que los estilos innecesarios penetren en proyectos ya preparados, ya que es fácil para un desarrollador profundizar en las relaciones entre fragmentos HTML y CSS pequeños y estrechamente relacionados. Y cuando el componente se elimina del proyecto o se desarrolla, la estilización abandona el proyecto o se desarrolla con él. Como resultado, los ensamblados CSS se crean en función de los componentes realmente utilizados en el proyecto.

La tecnología CSS-in-JS se mueve de forma bastante natural en esa dirección. Al aplicar tales tecnologías, los estilos están vinculados a los componentes. Y esto es lo más importante en este caso. Pero enlazar estilos a componentes es opcional. Me gusta el enfoque universal, que implica el uso de módulos CSS . Está casi completamente destinado a separar el alcance de los estilos y no obliga al desarrollador a usar ningún marco de JavaScript específico.

Quizás todo lo anterior le parezca algo teórico o lejos de las necesidades reales de los desarrolladores web. Simplemente tiene un sitio que usa Bootstrap y le gustaría reducir el tamaño de CSS que cargan los usuarios de este sitio. Si es así, le aconsejaría que use el código fuente Bootstrap en lugar de su compilación estándar. Este código fuente está escrito usando SCSS y consta de muchos complementos. Esto significa que si no necesita algunas partes de Bootstrap, simplemente puede deshabilitar los módulos correspondientes.


Eliminar módulos desplegables, insignias y migas de pan de Bootstrap antes de construir un proyecto

Les deseo a todos buena suerte en la difícil lucha con el innecesario código CSS.

Estimados lectores! ¿Cómo manejas el código CSS no utilizado que entra en producción?