Ein schneller CSS-Audit und allgemeine Notizen zu Design Systemen

Ich habe in letzter Zeit eine Menge CSS auditiert und dachte, es wäre nett, aufzuschreiben, wie ich das mache. Ich bin sicher, es gibt unzählige Möglichkeiten, dies zu tun, abhängig von der Größe und Skalierung Ihrer App und wie Ihr CSS intern funktioniert, also nehmen Sie das bitte mit Vorsicht zur Kenntnis.

Zuerst ein paar Haftungsausschlüsse: Bei Gusto, dem Unternehmen, für das ich heute arbeite, schreiben unsere Ingenieure und Designer alle in Sass und verwenden Webpack, um diese Dateien in CSS zu kompilieren. Unsere Produktionsumgebung minimiert den gesamten Code zu einer einzigen CSS-Datei. Unser CSS besteht jedoch aus drei separaten Domänen, daher habe ich sie alle auf meinen Desktop heruntergeladen, weil ich sie einzeln testen wollte.

Hier ist, was diese Dateien tun

• manifest.css: eine Datei, die aus all unseren Sass-Funktionen und Mixins generiert wird und alle unsere Standard-HTML-Stile und Utility-Klassen enthält.
• components.css: eine Datei, die aus unseren React-Komponenten wie Button.scss, Card.scss usw. besteht. Diese und manifest.css stammen beide aus unserem Component Library-Repository und werden in unsere Hauptanwendung importiert.
• app.css: eine Sammlung von Stilen, die unsere Komponenten und das Manifest überschreiben. Heute befindet sie sich in unserem Hauptanwendungs-Repository.

Nachdem ich alles heruntergeladen hatte, habe ich es in einen S3-Bucket geworfen und durch CSS Stats laufen lassen. (Ich konnte kein Befehlszeilentool finden, das mir gefiel, also bin ich bei diesem Tool geblieben.) Das Coolste an CSS Stats ist, dass es viel Klarheit über den Zustand und die Qualität des CSS einer Website und damit über ein Designsystem gibt. Dies geschieht durch die Anzeige der Anzahl eindeutiger font-size und eindeutiger background-color CSS-Deklarationen sowie eines Spezifitätsgraphen für diese bestimmte CSS-Datei.

Ich wollte zuerst unsere Datei manifest.css besser verstehen. Wie bereits erwähnt, enthält diese Datei alle unsere Utility-Klassen (wie padding-top-10px und c-salt-500) sowie unsere Normalize- und Reset-CSS-Dateien, daher ist sie für alles andere ziemlich grundlegend. Ich begann, die Ergebnisse zu durchsuchen:

Hier gibt es einige offensichtliche Probleme, wie die Tatsache, dass es 101 eindeutige Farben und 115 eindeutige Hintergrundfarben gibt. Warum ist das ein großes Problem? Nun, es ist mir ein wenig auffällig, da unser Team bereits eine Sammlung von Sass-Funktionen erstellt hatte, um eine sehr spezifische Anzahl von Farben auszugeben. In unserem Figma UI Kit und variables_color.scss (das in unsere Manifestdatei kompiliert wird) deklarieren wir insgesamt 68 eindeutige Farben

Woher kommen also all diese zusätzlichen Farben? Nun, ich nehme an, sie kommen von Bootstrap. Als wir mit dem Aufbau der Anwendung begannen, bauten wir hastig auf den Stilen von Bootstrap auf, ohne die Dinge zu refaktorieren, während wir vorangingen. Es gab einen bestimmten Moment, als dies schmerzhaft wurde, als wir visuelle Inkonsistenzen in unserer gesamten Anwendung feststellten und Hunderte von Codezeilen geschrieben wurden, die Bootstrap einfach überschrieben. In einem eher galanten CSS-Refactor habe ich Bootstrap-CSS aus unserer Hauptanwendung entfernt und sie in manifest.css archiviert, in der Erwartung des Tages, an dem wir zu ihr zurückkehren und alles refaktorieren könnten.

Diese zusätzlichen Farben stammen wahrscheinlich aus dieser alten Bootstrap-Datei, aber es lohnt sich wahrscheinlich, sie genauer zu untersuchen. Auf jeden Fall ist das eigentliche Problem für mich, dass mein Verständnis des Designsystems anders ist als das, was im Frontend vorhanden ist. Das ist ein großes Problem! Wenn mein Verständnis des Designsystems anders ist als die Funktionsweise des CSS, dann gibt es ein enormes Potenzial für Ingenieure und Designer, sich falsche Muster anzueignen und Verwirrung in unserer Organisation zu verbreiten. Denken Sie an den zusätzlichen Bloat und mangelnde Wartbarkeit, ganz zu schweigen von anderen Implikationen.

Ich las Matthew Ströms Artikel Who Are Design Systems For? und wurde hellhörig, als er einen Vortrag von Julie Ann-Horvath zitierte, in dem sie sagte: „Ein Designsystem existiert nicht, bis es in Produktion ist.“ Wenn wir dieser Logik folgen, ist es klar, dass das Designsystem, das wir zu haben glaubten, eigentlich nicht existierte.

Zurück zu manifest.css: Der Spezifitätsgraph für diese Datei sollte perfekt abgestuft sein, und doch gibt es einige klare Spitzen, die zeigen, dass wahrscheinlich noch etwas mehr CSS darin refaktorieren werden muss

Nun, als nächstes kommt unser components.css. Denken Sie daran, dass dies die Datei ist, aus der unsere Stile für unsere Komponenten stammen, also dachte ich im Voraus, dass sie zwangsläufig etwas unordentlicher sein würde als unsere Manifestdatei. Wenn wir sie in CSS Stats werfen, erhalten wir Folgendes

CSS-Stats zeigt einige der gleichen Probleme – wie zu viele Schriftgrößen (was zum Teufel ist mit dieser riesigen Schriftgröße los?) – aber es gibt auch viel zu viele benutzerdefinierte Farben und Hintergrundfarben. Ich hatte bereits eine Ahnung, was das größte Problem mit dieser CSS-Datei war, bevor ich anfing, und ich glaube nicht, dass das Problem hier in diesen Daten überhaupt gezeigt wird.

Ich werde es erklären.

Eine große Anzahl unserer Komponenten waren früher Bootstrap-Dateien verschiedener Art. Nehmen wir zum Beispiel unsere Accordion.jsx React-Komponente. Sie importiert eine accordion.css-Datei, die dann mit dem gesamten CSS der anderen Komponenten zu einer components.css-Datei kompiliert wird. Das Problem dabei ist, dass einige Accordion-Stile weit mehr als nur diese Komponente beeinflussen. CSS aus dieser Datei sickert in andere Muster und Klassen, die nicht nur an eine Komponente gebunden sind. Es ist eine Art Gift in unserem System und das wirkt sich auf unser Team aus, weil es schwierig ist, Änderungen an einer einzelnen Komponente zuverlässig vorzunehmen. Es führt auch zu einer sehr fragilen Codebasis.

Ich sage also, dass Werkzeuge wie CSS Stats wundersame Dinge sind, die uns helfen, grundlegende Vitalparameter für die CSS-Gesundheit zu überprüfen, aber ich glaube nicht, dass sie jemals das vollständige Bild erfassen werden.

Nun, als nächstes kommt die Datei app.css

Das ist das „Monolith“ – die Codebasis, die unser Designsystem-Team derzeit besser zu verstehen und hoffentlich in eine Reihe von flexiblen und wartbaren React-Komponenten zu refaktorieren versucht, die andere immer wieder verwenden können.

Was mir an dieser Codebasis Sorgen macht, ist die Spezifität all dessen, was passiert, wenn sich etwas in manifest.css oder in unserer components.css ändert? Werden diese Stile im Monolith überschrieben? Was passiert mit den schönen und ordentlichen Komponentenstilen, die wir in ein neues Projekt importieren?

Anschließend weiß ich nicht mehr, wo ich das gestohlen habe, aber ich sage es in letzter Zeit sehr oft – Sie sollten immer vorhersagen können, was Ihr CSS tun wird, sei es eine einzige Codezeile oder eine riesige Codebasis mit vermischten Stilen. Darum geht es bei Designsystemen – die Gestaltung und der Bau von vorhersagbaren Benutzeroberflächen für die Zukunft. Und wenn unser kompilierter CSS all diese unvorhersehbaren und unbekannten Teile enthält, dann müssen wir alle zusammenbringen, um es zu beheben.

Jedenfalls habe ich nach all dem einige der Daten in ein Dropbox Paper-Dokument geworfen, um sicherzustellen, dass wir beginnen, diese Probleme anzugehen und im Laufe der Zeit allmähliche Verbesserungen zu sehen. Das sieht heute ungefähr so aus

Wie haben Sie Ihren CSS-Code auditiert? Überprüft Ihr Team CSS-Code? Gibt es Tricks und Tipps, die Sie empfehlen würden? Hinterlassen Sie unten einen Kommentar!