Wie werden Sie nicht verwendeten CSS-Code los? Teil 2

Heute veröffentlichen wir den zweiten Teil der Übersetzung von Material zum Kampf gegen nicht verwendeten CSS-Code.



→ Der erste Teil

CSS-Nachbearbeitung

Angenommen, in einigen Projekten wird CSS mit Less oder Sass geschrieben, und dann wird ein Postprozessor verwendet, um den vorhandenen Code in reguläres CSS zu kompilieren. In einem solchen Projekt gibt es wahrscheinlich ein automatisches System zum Entfernen von nicht verwendetem CSS, das nach der CSS-Vorverarbeitung gestartet wird. Das könnte so aussehen:

1. Sass.
2. PostCSS / automatisches Präfixsystem.
3. Unbenutztes CSS entfernen.
4. CSS-Code für die Produktion bereit.

Das macht einerseits Sinn und andererseits - es sieht in meinen Augen etwas seltsam aus. Der Punkt ist, dass bei diesem Ansatz der Quellcode, der Stilisierungsbefehle enthält, nicht korrigiert wird, basierend auf dem der endgültige CSS-Code erstellt wird, der nicht verwendetes CSS enthält. Stattdessen wird unnötiges CSS am Ende des Erstellungsprozesses einfach entfernt. Ich vermute, dass in JavaScript bei der Implementierung des Tree-Shaking-Algorithmus seit einiger Zeit etwas Ähnliches getan wird. Das heißt, ein derartiger Umgang mit CSS ist überhaupt nicht neu. Aber für mich scheint das trotzdem falsch zu sein, da die CSS-Codebasis etwas ist, von dem man sagen kann, dass es auf der Oberfläche von Webprojekten liegt. Ein solcher Ansatz veranlasst Entwickler fast, unachtsam CSS zu schreiben, um sicherzustellen, dass alles in den Quell-CSS-Code geschrieben wird. Und die Wahrheit ist, dass das System unnötiges CSS automatisch entfernt. Dies entzieht den Entwicklern jedoch den Wunsch, genau zu verstehen, wie ihre Designs gestaltet sind und wie genau CSS in ihnen verwendet wird.

Purgecss

PurgeCSS ist ein weiteres Projekt zur Bekämpfung von nicht verwendetem CSS. Obwohl dies nicht direkt mit den Fähigkeiten dieses Projekts zusammenhängt, gefällt es mir, weil die Dokumentation die Unterschiede zu den Mitbewerbern klar erklärt. Oben haben wir bereits ein Fragment eines Vergleichs zwischen PurgeCSS und PurifyCSS angegeben. Und hier ist ein weiterer Auszug aus der PurgeCSS-Dokumentation, die PurifyCSS gewidmet ist. Der Punkt ist, dass das Hauptproblem bei PurifyCSS die geringe Modularität dieses Projekts ist. Dies ist jedoch die Hauptstärke von PurifyCSS. Wie bereits erwähnt, betrachtet PurifyCSS CSS-Wörter als alle Wörter, die es in Dateien findet. Dieser Ansatz ist mit Fehlern behaftet. PurifyCSS löst dieses Problem jedoch, indem es die Erstellung von Extraktorfunktionen ermöglicht. Eine solche Funktion nimmt den Inhalt einer Datei und extrahiert daraus eine Liste der darin verwendeten CSS-Selektoren. Auf diese Weise können Sie das Problem, nicht verwendeten CSS-Code loszuwerden, sehr gut lösen.

Das PurgeCSS-Projekt sieht jetzt aus wie ein wichtiger Akteur auf dem Markt für die Bereinigung von CSS-Code. Viele benutzen es, viele schreiben darüber.

• Hier finden Sie Informationen zur Verwendung von PurgeCSS, insbesondere bei der Arbeit mit Bootstrap.
• In diesem Artikel erfahren Sie, dass PurgeCSS Selektoren unter ungewöhnlichen Umständen nicht mithilfe von Whitelists entfernt.
• Hier erfahren Sie, wie PurgeCSS in Verbindung mit npm-Skripten und mit PostCSS verwendet wird.
• Es geht darum, wie PurgeCSS mit Tailwind zusammenarbeitet.

Obwohl PurgeCSS für die Arbeit mit Tailwind ein spezielles Tuning benötigt, scheinen diese beiden Tools perfekt miteinander kombiniert zu sein. Selbst in der Dokumentation zu Tailwind finden Sie eine Empfehlung für die gemeinsame Nutzung. Und PurgeCSS verfügt über ein Befehlszeilentool, mit dem es beim Erstellen von Projekten angewendet werden kann.

Ich denke, das Wesentliche dabei ist Folgendes: Tailwind erstellt eine große CSS-Datei voller Hilfsselektoren. Es wird jedoch nicht davon ausgegangen, dass alle diese Selektoren im Projekt verwendet werden. Der Entwickler verwendet sie, um alle Probleme beim Stylen seines HTML-Codes zu lösen. Anschließend analysiert PurgeCSS diesen HTML-Code und entfernt unnötige Selektoren, wodurch CSS für die Produktion vorbereitet wird.

Richtig, PurgeCSS muss immer noch über jede auf der Site verwendete HTML- und JavaScript-Datei informiert werden. Mit anderen Worten, Sie müssen alles, was sich auf externe Ressourcen bezieht, unabhängig konfigurieren und berücksichtigen, dass die aus bestimmten Speichern in das Projekt eingehenden Daten während der Zusammenstellung des Projekts möglicherweise nicht analysiert werden. Infolgedessen ist die Verwendung von PurgeCSS bei der Zusammenstellung von Projekten mit einem erheblichen manuellen Aufwand verbunden.

Mein Lieblingsansatz, um unbenutztes CSS loszuwerden

Was mir am besten gefällt, ist der folgende Ansatz, um unnötiges CSS zu entfernen. Dies bedeutet, dass es jemanden im Projektentwicklungsteam gibt, der mit dem CSS-Code dieses Projekts sehr vertraut ist. Diese Person sollte aktuelle Probleme mit Stilen kennen und diese schrittweise lösen. Vielleicht ist dies eine veraltete Ansicht der Situation, die einer Person gehört, die mit der Zeit Schritt halten sollte. Aber für mich scheint es auf jeden Fall der praktischste Ansatz zu sein. In Anbetracht der Tatsache, dass die Aufgabe, die wir uns überlegen, so schwer zu lösen ist, kann die Antwort auf die Herausforderung, die diese Aufgabe für Entwickler darstellt, harte Arbeit sein. Die Antwort ist ein Verständnis des Problems und seiner schrittweisen Lösung. Ein Front-End-Entwickler, der mit dem Projekt vertraut ist und weiß, was darin verwendet wird und was nicht, kann dieses Problem lösen.

Ich habe einen extremen Ansatz gesehen, um herauszufinden, ob ein Site Selector verwendet wird. Der CSS-Block verwendete ein Design wie background-image: url(/is-this-being-used.gif?selector); . Nach der Anwendung wurden die Serverprotokolle regelmäßig überprüft, um festzustellen, ob eine Anforderung zum Empfang des entsprechenden Abbilds gestellt wurde. Wenn es eine solche Anfrage gab, wird der zu untersuchende CSS-Block verwendet. Wenn dies nicht der Fall ist, wird es nicht verwendet.

Aber vielleicht ist mein Lieblingswerkzeug im unbenutzten CSS-Explorer-Toolkit dasjenige, das im nächsten Abschnitt besprochen wird.

Untersuchung von Projekten durch visuelle Regression

Diese Methode besteht darin, dass der Entwickler so viele Screenshots der Site wie möglich macht. Sie erstellen Kopien der Bildschirme der wichtigsten Seiten und der Seiten, deren Erscheinungsbild vom Status der Anwendung abhängt. Screenshots werden in verschiedenen Browsern mit unterschiedlichen Bildschirmgrößen aufgenommen. Diese Screenshots werden basierend auf Materialien aus dem Hauptzweig des Projektarchivs erstellt.

Vor dem Zusammenführen eines anderen Zweigs mit dem Hauptzweig werden dann neue Screenshots auf der Grundlage der Materialien des neuen Zweigs erstellt und mit den für den Hauptzweig erstellten verglichen. Dies geschieht natürlich nicht manuell, sondern programmgesteuert.

Genau genommen ist hier ein Video, in dem es gezeigt wird.

Es ist anzumerken, dass bereits viel zum Thema Tools für das Studium der visuellen Regression gesagt wurde, aber der Autor dieses Videos ist die einzige Person, die alles sehr verständlich erklärt. Sie müssen nicht nur Screenshots machen. Sie müssen sie vergleichen und nach Unterschieden zwischen ihnen suchen. Man muss nicht nur Unterschiede finden; Sie müssen sie akzeptieren oder ablehnen. Darüber hinaus ist es erforderlich, dass die Übernahme oder Genehmigung von Änderungen den Prozess der Zusammenführung von Zweigen in Repositorys beeinflusst. Darüber hinaus sollte der Entwickler in der Lage sein, den Browser vor dem Erstellen einer Bildschirmkopie zu konfigurieren und die Arbeit mit den aufgenommenen Screenshots zu automatisieren.

Atomic CSS und CSS-in-JS

Ich bin sicher, dass viele Leser dieses Materials sagen können: "Ich habe kein unbenutztes CSS, da die von mir verwendeten Tools genau den Code generieren, den ich benötige, und nichts weiter."

Wenn ja, dann ist das einfach wunderbar.

Vielleicht sprechen wir über Atomizer . Möglicherweise handelt es sich um ein Tachyonen- Tool, dessen Ergebnisse über UnCSS übermittelt werden und das vorsichtig ist. Vielleicht - dies ist eine Kombination aus Rückenwind + PurgeCSS , die mittlerweile weit verbreitet ist.

Vielleicht - sie arbeiten immer noch irgendwie mit Stilen. Wenn jemand JavaScript-Komponenten und -Stile eng miteinander verknüpft, z. B. bei der Verwendung von React and Emotion, oder einfach CSS-Module mit irgendetwas anwendet, verringert sich unter den Vorteilen solcher CSS-in-JS-Ansätze das Volumen nicht verwendeter CSS in fertigen Projekten. Da viele JavaScript-basierte Projekte den Tree-Shaking-Algorithmus und Codetrennungstechniken verwenden, werden solche Projekte nicht nur weniger unnötiges CSS enthalten. Im Laufe ihrer Arbeit wird nur das geladen, was in der jeweiligen Situation benötigt wird. Es gibt jedoch natürlich Nachteile bei solchen Ansätzen für die Arbeit mit CSS.

Zusammenfassung

Lassen Sie uns nun darüber nachdenken, wie Sie das Auftreten von unnötigem CSS-Code in zukünftigen Projekten vermeiden können. Ich glaube, dass die Zukunft des Stils die Trennung zwischen globalen Stilen und Stilen ist, die auf einzelne Komponenten angewendet werden. Die meisten Stile sind auf den Umfang der Komponenten beschränkt, es gibt jedoch globale Stile, mit denen die Kaskadierbarkeit von CSS ausgenutzt werden kann. Beispielsweise kann es sich um globale typografische Standardeinstellungen handeln.

Wenn die meisten Stile durch den Umfang der Komponenten begrenzt sind, ist es meiner Meinung nach weniger wahrscheinlich, dass nicht benötigte Stile in fertige Projekte eindringen, da ein Entwickler die Beziehungen zwischen kleinen und eng verwandten HTML- und CSS-Fragmenten leichter untersuchen kann. Und wenn die Komponente aus dem Projekt entfernt oder entwickelt wird, verlässt die Stilisierung das Projekt oder entwickelt sich mit ihm. Infolgedessen werden CSS-Assemblys basierend auf den tatsächlich im Projekt verwendeten Komponenten erstellt.

Die CSS-in-JS-Technologie bewegt sich ganz natürlich in diese Richtung. Bei der Anwendung solcher Technologien werden Stile an Komponenten gebunden. Und das ist in diesem Fall das Wichtigste. Das Binden von Stilen an Komponenten ist jedoch optional. Ich mag den universellen Ansatz, der die Verwendung von CSS-Modulen beinhaltet . Es zielt fast vollständig darauf ab, den Bereich der Stile zu trennen, und zwingt den Entwickler nicht, ein bestimmtes JavaScript-Framework zu verwenden.

Vielleicht scheint Ihnen all das theoretisch oder weit von den tatsächlichen Bedürfnissen der Webentwickler entfernt zu sein. Sie haben nur eine Site, die Bootstrap verwendet, und möchten die CSS-Größe reduzieren, die Benutzer dieser Site laden. In diesem Fall empfehle ich Ihnen, den Bootstrap-Quellcode anstelle des Standardbuilds zu verwenden. Dieser Quellcode wird mit SCSS geschrieben und besteht aus vielen Plug-Ins. Das heißt, wenn Sie einige Teile von Bootstrap nicht benötigen, können Sie die entsprechenden Module einfach deaktivieren.


Entfernen von Dropdown-, Badge- und Breadcrumb-Modulen aus Bootstrap, bevor ein Projekt erstellt wird

Ich wünsche Ihnen allen viel Glück im schwierigen Kampf mit unnötigem CSS-Code.

Sehr geehrte Leser! Wie gehen Sie mit nicht verwendetem CSS-Code um, der in die Produktion gelangt?