Sass @use & @forward: Modulare Architektur für skalierbares CSS

Sass: Vom veralteten @import zur modernen modularen Architektur mit @use und @forward

In der Welt der Frontend-Entwicklung, wo Projekte immer komplexer werden und Codebasen wachsen, wird eine effiziente Styles-Verwaltung entscheidend. Sass, als einer der führenden CSS-Preprocessoren, hat bedeutende Veränderungen durchlaufen, um die Modularität und Wartbarkeit des Codes zu verbessern. Ein entscheidender Schritt in dieser Entwicklung war der Abschied vom veralteten @import-Direktiv zugunsten der leistungsstarken und flexiblen @use und @forward.

Lange Zeit war @import die einzige Methode, um Sass-Dateien einzubinden, doch es brachte erhebliche Nachteile mit sich: globale Namensraumverschmutzung, hohes Konfliktrisiko und Code-Duplikation. Mit der bevorstehenden Veröffentlichung von Dart Sass 3.0.0 ist @import offiziell veraltet und wird vollständig entfernt, was die Umstellung auf das neue modulare System für jeden modernen Entwickler unerlässlich macht.

Die @use-Direktive: Isolation und Namensräume

@use ist ein grundlegender Bestandteil des neuen modularen Systems von Sass. Sie lädt eine Sass-Datei (Modul) und macht deren Inhalte (Variablen, Mixins, Funktionen) im aktuellen Datei verfügbar, isoliert sie jedoch in einem eigenen Namensraum. Das ist der entscheidende Unterschied zu @import, der globale Konflikte verhindert und Abhängigkeiten explizit macht.

Grundlegende Nutzung:

@use 'path/to/file';

Standardmäßig leitet Sass den Namensraum aus dem letzten Teil des Dateipfads ab, ohne Unterstriche oder Erweiterungen. Bei @use '../helpers/colors'; sind Variablen und Funktionen aus _colors.scss über den Präfix colors. erreichbar:

// helpers/_colors.scss
$primary: blue;
$secondary: gray;

// components/_button.scss
@use '../helpers/colors';

.button {
  color: colors.$primary; // Über den "colors"-Namensraum aufgerufen
  background-color: colors.$secondary;
}

Namensraum mit as ändern:

Aus Bequemlichkeit oder Klarheit können Sie einem Modul mit dem Schlüsselwort as einen benutzerdefinierten Namen zuweisen:

@use 'helpers/colors' as myColors;

.button {
  color: myColors.$primary; // Über "myColors" aufgerufen
}

Beim Benennen von Namensräumen sollten Sie die Sass-Identifier-Regeln beachten:

• Erlaubt: Buchstaben (a-z, A-Z), Ziffern (0-9, aber nicht am Anfang), camelCase, PascalCase.
• Nicht erlaubt: Bindestriche (-), Leerzeichen, Sonderzeichen, mit Ziffer beginnend.

Die integrierten Sass-Module nutzen

Sass stellt eine Reihe integrierter Module für gängige Aufgaben wie mathematische Operationen, Listen, Maps, Farben und Strings bereit. Diese werden mit dem Präfix sass: importiert:

@use 'sass:math';
@use 'sass:list';
@use 'sass:map';
@use 'sass:color';
@use 'sass:string';

Beispiele für die Nutzung von Funktionen aus integrierten Modulen:

$width: math.div(100%, 3); // Division
$len: list.length((10px, 20px, 30px)); // Listenlänge
$color: color.adjust(#336699, $lightness: 20%); // Farbanpassung
$index: string.index('hello world', 'world'); // Substring-Suche

Wichtig: Integrierte Module müssen wie normale Module explizit in jeder Datei importiert werden, in der ihre Funktionen genutzt werden. Sie werden nicht über andere Imports vererbt.

Code-Organisation und Modulzugriff

Das modulare Sass-System fördert einen Ansatz, bei dem jede SCSS-Datei ihre Abhängigkeiten zu Beginn explizit deklariert. Das sorgt für Transparenz und erleichtert Refactoring. Mixins und Funktionen aus benutzerdefinierten Dateien sind ebenfalls über Namensräume verfügbar.

Beispiel für eine Mixin-Definition:

// helpers/_mixins.scss
@mixin flex-center {
  display: flex;
  align-items: center;
  justify-content: center;
}

Und ihre Nutzung:

// components/_card.scss
@use '../helpers/mixins';

.card {
  @include mixins.flex-center;
}

Empfohlene Ordnerstruktur:

Ein gut strukturiertes Sass-Projekt könnte so aussehen:

scss/
  helpers/
    _colors.scss
    _variables.scss
    _mixins.scss
  components/
    _button.scss
    _card.scss
  pages/
    _about-page.scss
  template.scss // Haupt-Build-Datei

Beispiel einer Komponenten-Datei mit mehreren Modulen:

// components/_button.scss
@use '../helpers/colors' as myColors;
@use '../helpers/variables';
@use '../helpers/mixins';

.button {
  background-color: myColors.$primary;
  padding: variables.$spacing-md;
  @include mixins.border-radius;
}

Vorteile des modularen Ansatzes mit Namensräumen:

• Klarheit: Sofort ersichtlich, aus welchem Modul eine Variable oder ein Mixin stammt – verbessert die Lesbarkeit.
• Keine Konflikte: Isolierte Namensräume verhindern Kollisionen bei gleichnamigen Variablen und Mixins aus verschiedenen Modulen.
• Einfacheres Refactoring: Änderungen in einem Modul wirken sich nicht auf andere aus, solange deren API erhalten bleibt – erleichtert Skalierung und Anpassung.
• IDE-Unterstützung: Moderne Entwicklungsumgebungen arbeiten besser mit expliziten Namensräumen und bieten präzise Autovervollständigung.
• Skalierbarkeit: Der Code bleibt auch in sehr großen Projekten verständlich und handhabbar.

Module mit @use ... with() konfigurieren

Die Direktive @use ... with() bietet einen mächtigen Mechanismus, um Module beim Import zu konfigurieren. Sie erlaubt, Variablen mit !default zu überschreiben, indem neue Werte direkt beim Import übergeben werden.

Funktionsweise von !default:

Eine mit !default deklarierte Variable nimmt ihren Wert nur an, wenn er zuvor nicht gesetzt wurde. Ist der Wert bereits definiert (z. B. in einer anderen Datei oder via @use ... with()), wird !default ignoriert.

// helpers/_theme.scss
$bg-color: #ffffff !default; // Standardwert
$text-color: #333333 !default; // Kann überschrieben werden

Werte mit with() überschreiben:

Sie können neue Werte für !default-Variablen in den Klammern von with() beim Modul-Import übergeben:

// pages/dark-theme.scss
@use '../helpers/theme' with (
  $bg-color: #1a1a1a,
  $text-color: #f0f0f0
);

body {
  background: theme.$bg-color; // Wird #1a1a1a
  color: theme.$text-color; // Wird #f0f0f0
}

Wichtige Hinweise zu with():

• @use ... with() funktioniert nur beim ersten Import eines bestimmten Moduls in einer Datei. Spätere Versuche, dasselbe Modul mit anderen with()-Werten zu importieren, werden ignoriert.
• Viele Drittanbieter-Sass-Bibliotheken nutzen !default für Einstellungen, was eine einfache Anpassung ihres Verhaltens via with() ermöglicht.

Die @forward-Direktive: Eine öffentliche API erstellen

@forward ist eine Direktive, die es erlaubt, Inhalte eines oder mehrerer Module weiterzuleiten und sie für andere Dateien verfügbar zu machen, die eine Zwischendatei importieren. Sie dient der Erstellung eines einzigen Einstiegspunkts (öffentliche API) für eine Gruppe von Modulen, ohne deren Inhalte direkt in der @forward-Datei zugänglich zu machen.

Beispiel: _core.scss als zentraler Einstiegspunkt:

// _core.scss
@forward 'helpers/colors';
@forward 'helpers/variables';
@forward 'base/fonts';
@forward 'helpers/mixins';

Statt jede Datei einzeln zu importieren, reicht nun der Import von _core.scss:

// pages/about-page.scss
@use '../core.scss';

.button {
  color: core.$blue; // Variable aus helpers/colors
  border-radius: core.$border-radius-medium; // Variable aus helpers/variables
  @include core.flex-center; // Mixin aus helpers/mixins
}

Vor- und Nachteile des _core.scss-Ansatzes:

• Vorteil: Vereinfacht Imports in nutzenden Dateien und schafft eine klare API für das gesamte Projekt.
• Nachteil: Alle weitergeleiteten Elemente nutzen den core-Namensraum (oder Ihren angegebenen), was die Zuordnung zur Ursprungsdatei erschweren kann, ohne _core.scss zu prüfen.

Interne Nutzung weitergeleiteter Module:

Falls die _core.scss-Datei selbst Variablen oder Mixins aus den weitergeleiteten Modulen benötigt, muss sie diese explizit mit @use importieren:

// _core.scss
@forward 'helpers/colors'; // Weiterleiten nach außen
@use 'helpers/colors' as c; // Für interne Nutzung in _core.scss

body {
  background: c.$bg-color; // Funktioniert dank @use
}

Erweiterte @forward-Funktionen:

• Selektives Weiterleiten (show / hide): Ermöglicht explizite Angabe, welche Elemente eines Moduls weitergeleitet werden sollen.

```scss

@forward 'colors' show $primary, $secondary; // Nur diese Variablen weiterleiten

@forward 'mixins' hide private-mixin; // Alles außer private-mixin weiterleiten

```

• Konfiguration via with() beim Weiterleiten: Ähnlich wie bei @use ... with() können !default-Variablen im weitergeleiteten Modul überschrieben werden.

```scss

// helpers/_theme.scss

$bg-color: #fff !default;

// _index.scss (Datei, die _theme.scss weiterleitet)

@forward 'theme' with (

$bg-color: #f0f0f0

);

```

Modulabhängigkeiten verwalten

Im modularen Sass-System muss jede Datei ihre Abhängigkeiten explizit deklarieren. Das gilt auch, wenn eines Ihrer Module (z. B. _variables.scss) Variablen aus einem anderen Modul (_colors.scss) nutzt. Selbst wenn _variables.scss und _colors.scss beide über _core.scss weitergeleitet werden, muss _variables.scss _colors.scss explizit importieren.

// _variables.scss
@use 'colors'; // Explizite Abhängigkeit zu _colors.scss

$button-bg: colors.$primary;

Warum das wichtig ist:

• Klarheit: Sofort ersichtlich, von welchen Modulen jede Datei abhängt – vereinfacht das Verständnis der Struktur.
• Zuverlässigkeit: Bei Verschieben oder Umstrukturieren von Dateien bleiben Abhängigkeiten intakt und nachvollziehbar.
• IDE-Unterstützung: Statische Analysetools und Autovervollständigung funktionieren präziser.
• Refactoring: Einfach nachzuverfolgen, wo bestimmte Module und Variablen verwendet werden.

Wichtige Erkenntnisse

• @use und @forward ersetzen das veraltete @import und bieten echte Modularität in Sass.
• Namensräume verhindern Konflikte und machen Abhängigkeiten explizit – verbessert die Skalierbarkeit.
• @use ... with() ermöglicht flexible Modulkonfiguration durch Überschreiben von !default-Variablen.
• @forward dient der Erstellung einzelner Einstiegspunkte (öffentliche APIs) und vereinfacht die Verwaltung vieler Module.
• Explizite Deklaration von Abhängigkeiten in jeder Datei ist entscheidend für Wartbarkeit und Vorhersagbarkeit von Sass-Code.

— Editorial Team