Aujourd'hui, nous publions la deuxième partie de la traduction de matériel sur la lutte contre le code CSS inutilisé.

→
La première partiePost-traitement CSS
Supposons que dans certains projets, CSS soit écrit en utilisant Less ou Sass, puis un postprocesseur est utilisé pour compiler le code existant en CSS ordinaire. Dans un tel projet, il existe probablement un système automatique pour se débarrasser du CSS inutilisé, qui démarre après le prétraitement CSS. Cela peut ressembler à ceci:
- Sass.
- PostCSS / système de préfixe automatique.
- Suppression du CSS inutilisé.
- Code CSS prêt pour la production.
Cela, d'une part, a du sens, et d'autre part - cela semble un peu étrange à mes yeux. Le fait est qu'avec cette approche, le code source contenant les commandes de stylisation n'est pas corrigé, sur la base duquel le code CSS résultant est créé, qui inclut également le CSS inutilisé. Au lieu de cela, le CSS inutile est simplement supprimé à la fin du processus de construction. Je soupçonne qu'en JavaScript, lors de la mise en œuvre de l'algorithme de tremblement d'arbre, quelque chose de similaire a été fait depuis un certain temps. Autrement dit, une telle manipulation avec CSS n'est pas du tout une nouveauté. Mais pour moi, tout cela semble être faux, car la base de code CSS est quelque chose qui peut se dire à la surface des projets Web. Une telle approche incite presque les développeurs à écrire négligemment CSS, pour s'assurer que tout est vidé dans le code CSS source. Et la vérité est que le système supprimera automatiquement les CSS inutiles. Mais cela prive complètement les développeurs du désir de comprendre exactement comment leurs conceptions sont conçues, comment exactement CSS est utilisé en elles.
Purgecss
PurgeCSS est un autre projet qui vise à lutter contre les CSS inutilisés. Bien que cela ne soit pas directement lié aux capacités de ce projet, je l'aime parce que sa documentation explique clairement ses
différences avec ses concurrents. Ci-dessus, nous avons déjà donné un fragment d'une comparaison entre PurgeCSS et PurifyCSS. Et voici un autre extrait de la documentation PurgeCSS dédié à PurifyCSS. Le fait est que le principal problème avec PurifyCSS est la faible modularité de ce projet. Cependant, c'est la principale force de PurifyCSS. Comme déjà mentionné, PurifyCSS considère les mots CSS comme tous les mots qu'il trouve dans les fichiers. Cette approche est lourde d'erreurs. Mais PurifyCSS résout ce problème en permettant de créer des fonctions d'extraction. Une telle fonction prend le contenu d'un fichier et en extrait une liste de sélecteurs CSS utilisés. Cela vous permet de résoudre très bien le problème de se débarrasser du code CSS inutilisé.
Le projet PurgeCSS ressemble désormais à un acteur majeur sur le marché du nettoyage de code CSS. Beaucoup l'utilisent, beaucoup l'écrivent.
- Voici des informations sur l'utilisation de PurgeCSS, en particulier lorsque vous travaillez avec Bootstrap.
- À partir de cet article, vous pouvez apprendre que PurgeCSS ne supprimera pas les sélecteurs dans des circonstances inhabituelles à l'aide de listes blanches.
- Ici, vous pouvez découvrir comment PurgeCSS est utilisé conjointement avec les scripts npm et avec PostCSS.
- Il explique comment PurgeCSS fonctionne avec Tailwind.
Malgré le fait que PurgeCSS nécessite un réglage spécial pour fonctionner avec Tailwind, il semble que ces deux outils soient parfaitement combinés l'un avec l'autre. En fait, même dans la
documentation Tailwind
, vous pouvez trouver une recommandation pour les partager. Et PurgeCSS dispose d'
un outil en ligne de commande pour l'appliquer dans le processus de construction de projets.
Je pense que l'essentiel de cela se résume à ce qui suit: Tailwind crée un grand fichier CSS plein de sélecteurs d'assistance. Mais il n'est pas supposé que tous ces sélecteurs seront utilisés dans le projet. Le développeur les utilise pour résoudre tous les problèmes de style de son code HTML, puis PurgeCSS analyse ce code HTML et supprime les sélecteurs inutiles, formant CSS prêt pour la production.
Certes, PurgeCSS doit toujours être informé de chaque fichier HTML et JavaScript utilisé sur le site. En d'autres termes, vous devez configurer indépendamment tout ce qui concerne les ressources externes et prendre en compte le fait que les données entrant dans le projet à partir de certains stockages ne seront probablement pas analysées lors de l'assemblage du projet. En conséquence, l'utilisation de PurgeCSS dans l'assemblage de projets implique une quantité considérable de travail manuel.
Mon approche préférée pour se débarrasser des CSS inutilisés
Ce que j'aime le plus, c'est l'approche suivante pour supprimer les CSS inutiles. Cela signifie qu'il y aurait quelqu'un dans l'équipe de développement du projet qui connaît très bien le code CSS de ce projet. Cette personne doit être consciente des problèmes actuels de style et les résoudre progressivement. C'est peut-être une vue dépassée de la situation qui appartient à une personne qui devrait suivre son temps. Mais pour moi, en tout cas, cela me semble l'approche la plus pratique. Étant donné que la tâche que nous envisageons est si difficile à résoudre, je pense que la réponse au défi que cette tâche pose aux développeurs peut être un travail difficile. La réponse est une compréhension du problème et de sa solution progressive. Un développeur front-end qui connaît le projet et sait ce qui est utilisé et ce qui ne l'est pas peut résoudre ce problème.
J'ai vu une approche extrême pour déterminer si un sélecteur de site est utilisé. Le bloc CSS a utilisé une conception comme
background-image: url(/is-this-being-used.gif?selector);
. Après son application, les journaux du serveur ont été périodiquement vérifiés afin de savoir si une demande a été faite pour recevoir l'image correspondante. S'il y avait une telle demande, alors le bloc CSS sous enquête est utilisé. Si ce n'était pas le cas, alors il n'est pas utilisé.
Mais peut-être que mon outil préféré dans la boîte à outils CSS explorer inutilisée est celui qui sera discuté dans la section suivante.
Etude de projets par régression visuelle
Cette méthode consiste dans le fait que le développeur prend autant de captures d'écran du site que possible. Ils font des copies des écrans des pages les plus importantes, et de ces pages, dont l'apparence dépend de l'état de l'application. Les captures d'écran sont prises dans différents navigateurs, avec différentes tailles d'écran. Ces captures d'écran sont créées sur la base des matériaux de la branche principale du référentiel de projet.
Ensuite, avant de fusionner toute autre branche avec la branche principale, de nouvelles captures d'écran sont créées en fonction des matériaux de la nouvelle branche et comparées à celles faites pour la branche principale. Bien sûr, cela ne se fait pas manuellement, mais par programme.
À proprement parler,
voici une vidéo dans laquelle elle est montrée.
Il convient de noter que beaucoup a déjà été dit sur le thème des outils d'étude de la régression visuelle, mais l'
auteur de cette vidéo est la seule personne à tout expliquer de façon très intelligible. Vous devez non seulement prendre des captures d'écran; vous devez les comparer et rechercher les différences entre eux. Il ne faut pas seulement trouver des différences; vous devez les accepter ou les refuser. De plus, il est nécessaire que l'adoption ou l'approbation de modifications affecte le processus de fusion des succursales dans les référentiels. De plus, le développeur devrait être en mesure de configurer le navigateur avant de prendre une copie d'écran et la possibilité d'automatiser le travail avec des captures d'écran.
CSS atomique et CSS-dans-JS
Je suis sûr que de nombreux lecteurs de ce matériel peuvent dire: "Je n'ai pas de CSS inutilisé, car les outils que j'utilise génèrent exactement le code dont j'ai besoin et rien de plus."
Si oui, alors c'est tout simplement merveilleux.
Nous parlons peut-être d'
Atomizer . Il s'agit peut-être d'un outil
Tachyons , dont les résultats sont transmis via
UnCSS et sont prudents. Peut-être - c'est une combinaison de
Tailwind +
PurgeCSS , qui est maintenant
largement entendu.
Peut-être - ils fonctionnent toujours avec des styles. Si quelqu'un relie étroitement des composants et des styles JavaScript, par exemple, comme lors de l'utilisation de React et Emotion, ou même s'il applique simplement des modules CSS avec quoi que ce soit, parmi les avantages de ces approches CSS-in-JS, il y a une réduction du volume de CSS inutilisé. dans les projets finis. De plus, puisque de nombreux projets basés sur JavaScript utilisent l'algorithme d'agitation d'arbre et les techniques de séparation de code, ces projets auront non seulement moins de CSS inutiles. Au cours de leur travail, seul ce qui est nécessaire dans chaque situation spécifique sera chargé. Mais, bien sûr,
il existe des
inconvénients à de telles approches pour travailler avec CSS.
Résumé
Voyons maintenant comment éviter l'apparition de code CSS inutile dans nos futurs projets. Je crois que l'avenir du style est la séparation entre les styles globaux et les styles appliqués aux composants individuels. La plupart des styles sont limités à la portée des composants, mais il existe des styles globaux qui peuvent être utilisés pour exploiter la nature en cascade de CSS. Par exemple, il peut s'agir de paramètres typographiques standard mondiaux.
Si la plupart des styles sont limités par la portée des composants, je pense que les styles inutiles sont moins susceptibles de pénétrer les projets prêts à l'emploi, car il est facile pour un développeur de se plonger dans les relations entre de petits fragments HTML et CSS étroitement liés. Et lorsque le composant est supprimé du projet ou développé, la stylisation quitte le projet ou se développe avec lui. Par conséquent, les assemblys CSS sont créés en fonction des composants réellement utilisés dans le projet.
La technologie CSS-in-JS évolue tout naturellement dans cette direction. Lors de l'application de ces technologies, les styles sont liés aux composants. Et c'est la chose la plus importante dans ce cas. Mais la liaison des styles aux composants est facultative. J'aime l'approche universelle, qui implique l'utilisation de
modules CSS . Il vise presque complètement à séparer la portée des styles et n'oblige pas le développeur à utiliser un cadre JavaScript spécifique.
Peut-être que tout ce qui précède vous semble quelque chose de théorique ou loin des besoins réels des développeurs Web. Vous venez d'avoir un site qui utilise Bootstrap et souhaitez réduire la taille du CSS que les utilisateurs de ce site chargent. Si c'est le cas, je vous conseille d'utiliser le code source Bootstrap plutôt que sa version standard. Ce code source est écrit en utilisant SCSS et se compose de nombreux plug-ins. Cela signifie que si vous n'avez pas besoin de certaines parties de Bootstrap, vous pouvez simplement désactiver les modules correspondants.
Suppression des modules déroulants, badges et fil d'Ariane de Bootstrap avant de créer un projetJe vous souhaite à tous bonne chance dans la lutte difficile avec le code CSS inutile.
Chers lecteurs! Comment gérez-vous le code CSS inutilisé qui entre en production?
