Sass Best Practices Tipps und Tools für Entwickler

Ähnlich wie jQuery Vanilla JavaScript revolutionierte, Sass hat Vanille-CSS revolutioniert. Die meisten Entwickler, die Sass lernen, stimmen zu, dass sie niemals zurückkehren möchten. Viele sind sich auch einig, dass das größte Problem bei neuen Entwicklern das ist Weg Sie benutzen Sass, nicht Sass selbst.

Ich habe das Web durchsucht und diesen Artikel von zusammengestellt Best Practices zum Schreiben von erweiterbarem und wiederverwendbarem Sass-Code. Vorschläge stammen aus meinen eigenen Meinungen und von vertrauenswürdigen Websites wie Sass Guidelines.

Sie müssen sicherlich nicht alle diese Funktionen in Ihren Workflow integrieren. Es lohnt sich jedoch, diese Ideen zumindest zu unterhalten und die möglichen Vorteile in Betracht zu ziehen.

Dateiorganisation

Der beste Ort, um mit der Sass-Entwicklung zu beginnen, ist die Dateiorganisation. Wenn Sie bereits mit modularem Code arbeiten, sollten Sie den Wert von Importen und Teilprodukten verstehen (dazu später mehr)..

Werfen Sie doch einen Blick auf dieses Dateistruktur-Beispiel von DoCSSa. Ich habe diese Dateistruktur neu erstellt, die Sie unten sehen können:

Dies ist nur ein Vorschlag und eine der vielen Möglichkeiten, wie Sie Ihre Dateien organisieren können. Sie können andere Methoden finden, die unterschiedliche Ordnerstrukturen verwenden, z “Globals” für standortweite SCSS und “Seiten” für seitenspezifisches SCSS.

Gehen wir den vorgeschlagenen Organisationsstil durch, um den Zweck jedes Ordners zu untersuchen:

• / globals - Enthält Sass-Dateien, die landesweit angewendet werden, z. B. Typografie, Farben und Raster
• / Komponenten - enthält Sass-Dateien mit Komponentenstilen wie Schaltflächen, Tabellen oder Eingabefeldern
• / Abschnitte - Enthält Sass-Dateien für bestimmte Seiten oder Bereiche auf einer Seite (funktioniert möglicherweise besser im Ordner / components /)
• / utils - enthält Dienstprogramme von Drittanbietern wie Normalize, die mit Tools wie Bower dynamisch aktualisiert werden können.
• main.scss - die primäre Sass-Datei im Stammordner, die alle anderen importiert.

Dies ist nur ein grundlegender Ausgangspunkt und es gibt viel Raum, um mit Ihren eigenen Ideen zu erweitern.

Unabhängig davon, wie Sie sich für die Organisation Ihres SCSS entscheiden, ist es entscheidend, dass Sie dies tun eine Organisation haben mit einer separaten Datei (oder einem separaten Ordner) für Bibliotheken wie Normalize, die aktualisiert werden müssen, plus Komponenten in Sass-Partials für Ihr Projekt.

Sass-Partials sind für moderne Best Practices unerlässlich. Diese werden vom Zurb-Designteam und von vielen anderen professionellen Frontend-Entwicklern dringend empfohlen.

Hier ist ein Zitat von der Sass-Website, in dem die Teilweisen erläutert werden:

“Sie können partielle Sass-Dateien erstellen, die kleine CSS-Ausschnitte enthalten, die Sie in andere Sass-Dateien einfügen können. Dies ist ein guter Weg zu modularisieren Sie Ihr CSS und sorgen Sie für eine einfachere Wartung. Ein Partial ist einfach eine Sass-Datei mit einem führenden Unterstrich. Man könnte es so nennen _partial.scss. Der Unterstrich lässt Sass wissen, dass die Datei nur eine Teildatei ist und nicht in eine CSS-Datei generiert werden sollte. Sass-Partials werden mit verwendet @einführen Richtlinie.”

Schauen Sie sich auch diese anderen Beiträge zur Sass-Dateistruktur an:

• Wie strukturiere ich meine Sass-Projekte?
• Aesthetic Sass: Architektur und Stilorganisation
• Verzeichnisstrukturen, die Ihnen bei der Pflege Ihres Codes helfen

Strategien importieren

Über den Wert des Sass-Imports und der Partials kann nicht genug gesagt werden. Die Code-Organisation ist der Schlüssel zu einer funktionierenden Importstruktur und einem Workflow.

Am besten beginnen Sie mit einem Globalsheet, das Importe, Variablen und Mixins zusammen enthält. Viele Entwickler ziehen es vor, Variablen und Mixins zu trennen, was jedoch auf die Semantik zurückzuführen ist.

Denken Sie daran, dass Mixins sind Eine Möglichkeit, Sass-Code zu importieren bzw. zu kopieren. Sie sind unglaublich mächtig, sollten aber nicht verwendet werden “statisch” Code. Denken Sie daran, dass es einen Unterschied zwischen Mixins, Extensions und Platzhaltern gibt, die alle in der Sass-Entwicklung zum Einsatz kommen.

Mixins werden am besten mit dynamischen Werten verwendet, die für Codeänderungen an das Mixin übergeben werden. Schauen Sie sich zum Beispiel dieses Sass-Mixin an, das einen Hintergrundverlauf zwischen zwei Farben erstellt.

@mixin linearGradient ($ top, $ bottom) Hintergrund: $ top; / * Alte Browser * / background: -moz-linearer Gradient (oben, $ oben 0%, $ unten 100%); / * FF3.6 + * / background: -webkit-gradient (linear, links oben, links unten, Farbstopp (0%, $ oben), Farbstopp (100%, $ unten)); / * Chrome, Safari4 + * / Hintergrund: -webkit-linearer Gradient (oben, $ oben 0%, $ unten 100%); / * Chrome10 +, Safari5.1 + * / Hintergrund: -o-linearer Gradient (oben, $ oben 0%, $ unten 100%); / * Opera 11.10+ * / Hintergrund: -ms-linearer Gradient (oben, $ oben 0%, $ unten 100%); / * IE10 + * / background: linearer Gradient (nach unten, $ oben 0%, $ unten 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Das Mixin nimmt zwei Werte an: eine obere Farbe und eine untere Farbe. Sie können verschiedene Mixins für verschiedene Arten von Farbverläufen schreiben, die 3 oder 4 oder mehr Farben enthalten. Auf diese Weise können Sie den Mixin-Code importieren und klonen, während Sie die Parameter für benutzerdefinierte Optionen ändern.

Das Beispiel von Code Responsible sieht folgendermaßen aus:

.button @ include linearGradient (#cccccc, # 666666); 

In Verbindung mit dem Mixin steht der Platzhalter von Sass, der vor allem bei der Erweiterungsrichtlinie nützlich ist. Es ist zwar komplexer als Mixins, aber das kann ein Weg sein kombinieren Sie Selektoren, ohne überschüssigen Code zu überschreiben.

Während Sass nur über eine @import-Methode verfügt, habe ich Mixins und Platzhalter eingefügt, um die Flexibilität von Code zu demonstrieren, der in eine Datei geschrieben werden kann, jedoch an beliebiger Stelle eingefügt werden kann.

Denken Sie beim Erstellen einer Importstruktur daran, die Konzepte der DRY-Codierung zu befolgen..

Regeln der Namensgebung

Allgemeine Regeln für Namenskonventionen gelten für Variablen, Funktionen und Mixins. Wenn Sie etwas in Sass benennen, wird dies empfohlen Verwenden Sie zum Trennen alle Kleinbuchstaben mit Bindestrichen.

Die Sass-Code-Syntax basiert eigentlich auf dem Regelsatz der CSS-Richtlinien. Hier sind einige empfohlene Vorgehensweisen, die Sie beachten sollten:

• zwei (2) Leerzeichen Einrückungen, keine Tabulatoren
• Idealerweise 80 Zeilen breite Zeilen oder weniger
• sinnvolle Verwendung von Whitespace
• Verwenden Sie Kommentare, um CSS-Operationen zu erklären

Dies sind keine erforderlichen Elemente für einen gültigen Sass-Code. Diese Vorschläge stammen jedoch von professionellen Entwicklern, die haben festgestellt, dass diese Regelsätze die einheitlichste Codierungserfahrung bieten.

In Bezug auf Namenskonventionen können jedoch zwei verschiedene Strukturen vorhanden sein: eine für Sass-Namen und eine für CSS-Klassennamen. Einige Entwickler bevorzugen BEM gegenüber Sass-Vorschlägen. Keiner ist mehr oder weniger richtig; einfach anders mit verschiedenen Betriebsverfahren.

Das Problem ist, dass BEM sich nicht gut auf Sass-Variablen oder Mixins überträgt, da sie nicht über die Block / Element / Modifier-Struktur (BEM) verfügen. Ich persönlich ziehe es vor, Sass-Namenskonventionen zu verwenden, aber Sie könnten alles von camelCase bis zu Ihrer eigenen internen Syntax versuchen.

Beim Organisieren Ihrer Variablen und Mixins wird dies empfohlen Teilen Sie sie nach Kategorien auf und listen Sie sie in alphabetischer Reihenfolge auf. Das macht die Bearbeitung um einiges einfacher, da Sie genau wissen, wo Sie etwas finden können.

Um beispielsweise eine Link-Farbe zu ändern, öffnen Sie Ihre Variablendatei (möglicherweise _variables.scss) und suchen Sie den Abschnitt für die Farbvariablen. Suchen Sie dann den Link anhand des Namens (Kopfzeilenlink, Textlink usw.) und aktualisieren Sie die Farbe. Einfach!

Um sich ein Bild von der Strukturierung eines Inhaltsverzeichnisses für Ihre Sass-Dateien zu machen, checken Sie die Einstellungsdatei von Foundation aus.

 // Grundeinstellungen für Sites-Einstellungen // ----------------------------- // // Inhaltsverzeichnis: // // 1 Global // 2. Haltepunkte // 3. Das Gitter // 4. Basistypografie // 5. Typografie-Helfer… // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // usw

Eine andere Benennungspraxis betrifft ansprechende Haltepunkte. Versuchen Sie bei der Benennung von Sass-Haltepunkten, gerätespezifische Namen zu vermeiden. Es ist besser, Namen wie small, med, lg und xlg zu schreiben, weil sie sind relativ zueinander.

Dies ist besser für interne Beziehungen zwischen Haltepunkten, aber auch für Teams, in denen Entwickler möglicherweise nicht wissen, welche Geräte miteinander in Beziehung stehen.

Was das eigentliche Aufschreiben von Namen angeht, so wird dies empfohlen so spezifisch wie möglich sein, ohne überlange Variablen. Du solltest übernehmen Sie standortunabhängige Namenskonventionen, die leicht zu merken sind während der Codierung.

Geben Sie spezifische Namenskonventionen für alles wie Farben, Ränder, Schriftstapel und Strichhöhen an. Die Namen können nicht nur schnell abgerufen werden, sondern auch macht Ihre Arbeit einfacher, wenn Sie neue Variablennamen schreiben, die einer vorhandenen Syntax entsprechen müssen.

Aber es gibt eine feine Grenze zwischen Spezifität und Faltung. Diese Übung hilft Ihnen dabei, diese Zeile zu finden. Das Schreiben von einprägsamen Namen erleichtert das Kopieren von Code in andere Projekte.

Verschachtelung und Looping

Diese beiden Sass-Techniken unterscheiden sich stark in der Aktion, beide haben jedoch die Missbrauchsfähigkeit, wenn nicht rücksichtsvoll eingesetzt wird.

Verschachtelung ist der Prozess von Hinzufügen von durch Einrückung verschachtelten Selektoren, um mit weniger Code mehr Spezifität zu erzeugen. Sass verfügt über eine Schachtelanleitung, die Beispiele für die Verschachtelung von Code veranschaulicht. Aber es ist leicht, sich vom Schachteln hinreißen zu lassen. Wenn Sie übereifrig sind, können Sie Code bekommen, der so aussieht:

body div.content div.container … body div.content div.container div.articles … body div.content div.container div.articles> div.post … 

Viel zu spezifisch und fast unmöglich zu überschreiben, vereitelt diese Art von Code den Zweck der Kaskadierung von Stylesheets.

Beim Überfliegen dieses SitePoint-Leitfadens finden Sie drei goldene Regeln für das Schachteln:

• Gehen Sie niemals mehr als 3 Stufen tief.
• Stellen Sie sicher, dass die CSS-Ausgabe sauber und wiederverwendbar ist.
• Verwenden Sie die Verschachtelung, wenn dies sinnvoll ist, nicht als Standardoption.

Der Entwickler Josh Broton schlägt, wenn nötig, eine Verschachtelung vor, den Rest als allgemeine Syntaxregel einrücken.

Das Einrücken Ihrer Selektoren verursacht keine kaskadierenden CSS-Effekte. Sie können jedoch leichter Ihre Sass-Datei überfliegen, um herauszufinden, welche Klassen miteinander in Beziehung stehen.

Schleifen können auch übermäßig verwendet werden, wenn sie nicht ordnungsgemäß angewendet wird. Die drei Sass-Schleifen sind @zum, @während, und @jeder. Ich werde nicht ins Detail gehen, wie sie alle funktionieren, aber wenn Sie interessiert sind, lesen Sie diesen Beitrag.

Stattdessen möchte ich das Thema abdecken Zweck für die Verwendung von Schleifen und wie sie in Sass funktionieren. Diese sollten verwendet werden, um Zeit beim Schreiben von Code zu sparen, der automatisiert werden kann. Beispiel: Hier ein Codeausschnitt aus dem Clubmate-Beitrag, der Sass-Code gefolgt von der Ausgabe enthält:

/ * Sass-Code * / @für $ i von 1 bis 8 $ width: Prozentsatz (1 / $ i) .col - # $ i width: $ width;  / * Ausgabe * / .col-1 Breite: 100%; .col-2 Breite: 50%; .col-3 Breite: 33.333%; .col-4 Breite: 25%;  .col-5 Breite: 20%; .col-6 Breite: 16,666%; .col-7 Breite: 14,285%; .col-8 Breite: 12,5%;

Diese Spaltenklassen können in Verbindung mit einem Rastersystem verwendet werden. Sie können sogar weitere Spalten hinzufügen oder Spalten entfernen, indem Sie einfach den Schleifencode bearbeiten.

Schleifen sollte nicht verwendet werden, um Selektoren oder Eigenschaften für einen Selektor zu duplizieren; Dafür sind Mixins da.

Beim Schleifen gibt es auch sogenannte Sass-Maps, die Schlüssel speichern: Wertepaare von Daten. Fortgeschrittene Benutzer sollten wann immer möglich davon Gebrauch machen.

Normale Sass-Schleifen sind jedoch einfach und effektiv, um die Codeausgabe ohne Wiederholung bereitzustellen. Der beste Grund für die Verwendung von Schleifen ist mit CSS-Eigenschaften, die die Datenausgabe variieren.

Hier können Sie überprüfen, ob Ihre Schleife hilfreich ist: Fragen Sie sich Wenn Sie das CSS auf andere Weise ausgeben können, benötigen Sie weniger Codezeilen. Wenn nicht, ist die Schleifensyntax wahrscheinlich eine großartige Idee.

Wenn Sie jemals verwirrt sind oder Feedback zu Verschachtelungen oder Sass-Schleifen wünschen, sollten Sie eine Frage entweder in / r / sass / oder / r / css /, in aktiven Reddit-Communities mit sehr erfahrenen Sass-Entwicklern, posten.

Modularisierung

Das Schreiben von modularem Sass ist für die meisten Projekte eine absolute Notwendigkeit (würde ich behaupten, jedes Projekt). Modularisierung ist der Prozess von ein Projekt in kleinere Module zerlegen. Dies kann in Sass mit erreicht werden partials.

Die Idee hinter modularem Sass ist das Schreiben einzelner SCSS-Dateien mit einem bestimmten Zweck, der auf globale Inhalte (Typografie, Raster) oder Seitenelemente (Registerkarten, Formulare) abzielt..

Die Definition des Sass-Moduls ist ziemlich klar und macht einen sehr spezifischen Vorschlag: Beim Import eines Moduls sollte niemals Code ausgegeben werden.

Die Idee der obligatorischen Ausgabe für alle Module wäre ein Albtraum für die Optimierung. Stattdessen sollten Sie Module einzeln erstellen Rufen Sie nur die an, die Sie brauchen. Module können durch Mixins oder Funktionen definiert werden, aber es können auch Module erstellt werden, die Selektoren enthalten.

In einem Sass-Way-Artikel wird jedoch vorgeschlagen, alle Selektoren als Mixins zu schreiben und sie nur nach Bedarf aufzurufen. Ob Sie dies übernehmen oder nicht, ist letztlich Ihre Wahl. Ich denke, es hängt von der Größe des Projekts und Ihrem Komfort beim Umgang mit Mixins ab.

Zitat von John Long aus seinem Beitrag auf The Sass Way:

“Module sind für mich zu den grundlegenden Einheiten oder Bausteinen meiner Sass-Projekte geworden.”

Wenn Sie wirklich nach einer Sass-Routine suchen, empfehle ich, voll modular zu sein. Erstellen Sie fast alles als modulares Partial, das in eine primäre CSS-Datei eingefügt wird. Dieser Arbeitsablauf mag auf den ersten Blick entmutigend erscheinen, ist aber in größerem Umfang sinnvoll - insbesondere bei großen Projekten.

Außerdem ist es viel einfacher, Module von einem Projekt in ein anderes zu kopieren, wenn sie sich in separaten Dateien befinden. Flexibilität und wiederverwendbarer Code sind die Eckpfeiler der modularen Entwicklung.

Weitere Informationen zu Sass-Modulen und Modularisierungstechniken finden Sie in den folgenden Beiträgen:

• CSS-Module: Willkommen in der Zukunft
• Die Vor- und Nachteile von Modular Sass
• Modulare CSS-Organisation mit SMACSS & SASS

Finden Sie Ihren perfekten Workflow

Jedes Team und jeder Entwickler hat seine eigenen Praktiken, die am besten funktionieren. Sie sollten Praktiken anwenden, die für Sie persönlich am besten geeignet sind, oder diejenigen, die am besten für Ihr Team funktionieren.

Verwenden Sie auch Gulp oder Grunt für die Projektautomatisierung und die Minimierung des Codes. Dadurch wird viel manuelle Arbeit eingespart und Automatisierungswerkzeuge gehören heute zweifellos zu den Best Practices für die moderne Frontend-Entwicklung.

Durchlaufen Sie Open-Source-Bibliotheken wie Foundation SCSS auf GitHub, um mehr über die Best Practices anderer Bibliotheken zu erfahren.

Die beste Vorgehensweise ist, dass sie Ihre Arbeit meistens wirklich verbessern, aber es gibt viele Alternativen. Probieren Sie einfach Dinge aus und sehen Sie, wie sie sich fühlen. Sie werden immer lernen, so dass sich Ihre Best Practices im Laufe von 5 Jahren schnell ändern können.

Ein abschließender Vorschlag, den ich für den gesamten Sass-Prozess habe, lautet: Entscheidungen treffen, die klar sind. Schreiben Sie Code, der Ihre Arbeit erleichtert. Machen Sie ein Projekt nicht zu kompliziert, wenn es einfacher ist.

Sass soll die Erfahrung in der CSS-Entwicklung verbessern Arbeiten Sie mit Klarheit und Best Practices um die bestmögliche Erfahrung zu erhalten.

Einpacken

Die Überlastung eines Sass-Workflows kann korrigiert werden, indem Codestile angepasst und bewährte Methoden befolgt werden. In diesem Beitrag habe ich einige Vorschläge von Sass-Blogs und professionellen Entwicklern vorgestellt.

Der beste Weg, um mehr zu lernen, ist die Anwendung dieser Praktiken in Ihrem Workflow und sehen was funktioniert. Im Laufe der Zeit werden Sie feststellen, dass einige Aktivitäten vorteilhafter sind als andere. In diesem Fall sollten Sie dies tun behalten was auch immer funktioniert und lassen was nicht.

Unter diesen Links finden Sie weitere Tipps und Best Practices für die Sass-Entwicklung:

• Sass-Richtlinien
• Eine Vision für unseren Sass
• 8 Tipps, mit denen Sie das Beste aus Sass herausholen können
• In Sass erweitern, ohne ein Chaos zu schaffen
• Sass Best Practices - Schachteln Sie mehr als 3 Ebenen tief