Strukturierung von Sass: Abschied von der Ambiguität des Atomdesigns

() translation by (you can also view the original English article)

Atomic Design ist eine Methode, die eine sinnvolle Codestruktur für Stylesheets beschreibt. Es hat eine große Anhängerschaft, aber ich finde, dass seine Namenskonventionen manchmal mehrdeutig sein können. Was ist ein Molekül? Was ist ein Organismus? Woher wissen wir, wo wir die Grenze zwischen den beiden ziehen sollen? Diese besonderen Fragen scheinen der größte Stolperstein für die Interpretation einer atomaren Architektur zu sein.

Atoms Molecules Organisms Templates and Pages — Atome, Moleküle, Organismen, Vorlagen und Seiten

Heute werden wir diskutieren, was ich verwende, welche Facetten der Konventionen von Atomic Design, mit denen ich zu kämpfen habe, was ich getan habe, um meine Probleme zu lösen, und wie ich Sass derzeit beispielsweise anhand des 7-1-Musters organisiere.

Atomare Struktur

"Wir entwerfen keine Seiten, wir entwerfen Systeme von Komponenten." - Stephen Heu

Ich liebe atomares Design und seine Ideologien, aber ich habe festgestellt, dass sie zusammenbrechen können, wenn sie mit Teammitgliedern zusammenarbeiten, die nicht genau wissen, wie das alles funktioniert. In der Vergangenheit habe ich folgende Ordnerstruktur verwendet:

Ordnerorganisation: root/css/src/

 - vars
 - functions
 - mixins
 - base
 - plugins
 - typography
 - atoms
 - molecules
 - organisms
 - templates
 - pages
 - states
 - utility
 style.scss

Innerhalb von style.scss werden Sass-Partials mit gulp-sass-glob-import importiert:

Sass-Importindexdatei: root/css/src/style.scss

// Config
@import "vars/*";
@import "functions/*";
@import "mixins/*";

// Bower Components
@import "../bower_components/normalize-scss/_normalize";

// General DOM selector styles
@import "base/*";

// Fonts & General Type Styling
@import "typography/*";

// 3rd Party Addons
@import "plugins/*";

// Atomic Design
@import "atoms/**/*";
@import "molecules/**/*";
@import "organisms/**/*";
@import "templates/**/*";
@import "pages/**/*";

// Variations thru Events
@import "states/*";

// General UI Helpers
@import "utility/*";

Die Reihenfolge mit diesem Setup ist ziemlich wichtig. Wenn ein "atom", ein "molecule" oder ein "organism" angepasst werden muss, überschreiben Deklarationen in Vorlagen oder Seiten die oben genannten Teile sowie alle anderen vorhergehenden Teile.

Die Reihenfolge ermöglicht zusätzlich das Überschreiben des Stils eines Plugins, falls dies erforderlich sein sollte (und dies ist meiner Erfahrung nach normalerweise der Fall).

Verzeichnisinhalt

Ein Großteil des Inhalts für jedes Atomverzeichnis (Atome, Moleküle, Organismen, Vorlagen, Seiten) enthält Teilbereiche, die theoretisch leicht zu finden und bei Bedarf leicht zu verwalten sind.

 - atoms
   - _buttons.scss
   - _links.scss
   - _inputs.scss
 - molecules
   - _navigation.scss
   - _search-form.scss
   - _contact-form.scss
 - organisms
   - _header.scss
   - _footer.scss
   - _content.scss
 - templates
   - _sticky-footer.scss
   - _grid-2column.scss
   - _grid-3column.scss
 - pages
   - _home.scss
   - _about.scss
   - _contact.scss

Die Organisation erscheint sinnvoll, wenn Sie mit Atomic Design vertraut sind, aber für jemanden, der mit dem Ansatz und der Nomenklatur nicht vertraut ist, zu kurz kommt. Ein Entwickler, der Atomic Design nicht kennt, hat keinen Sinn für die Tatsache, dass sich ein Suchformular im molecules verzeichnis befindet, und kann die Suche in anderen Bereichen starten, um Änderungen vorzunehmen, oder einfach frustriert sein un eine neue Datei erstellen. Ich habe es gesehen.

Eine Komponentenstruktur

Zum Zeitpunkt dieses Schreibens verfolge ich einen Ansatz, bei dem Elemente vollständig als Komponenten wie Legoblöcke betrachtet werden, wodurch eine Benutzerfreundlichkeit für alle an der Codebasis Beteiligten geschaffen wird. Schauen Sie sich die folgende Verzeichnisstruktur an:

 - vars
 - functions
 - mixins
 - base
 - typography
 - plugins
 - toolbox
 - components
 - layout
 - pages
 - states
 - utility
 style.scss

Hoffentlich können Sie an diesem Beispiel erkennen, dass es ziemlich intuitiv ist, den Zweck jedes Ordners zu erfassen (mit Ausnahme der toolbox). In "Toolbox" können Helfer gespeichert werden, die nichts mit Dienstprogrammen zu tun haben, z. B. benutzerdefinierte Klassen für Layout- und Objektmuster, benutzerdefinierte Keyframe-Animationen usw. Diese Werkzeugbox-Elemente werden für mich normalerweise als Teile angezeigt, die ich möglicherweise überschreibe oder in Zukunft verwenden möchte, und warum sie vor dem Komponentenverzeichnis importiert werden.

Zu diesem Zeitpunkt werden Partials wie folgt in den Styles-Index geladen:

// Config
@import "vars/**/**";
@import "functions/*";
@import "mixins/*";

// UI
@import "../bower_components/normalize-scss/_normalize";
@import "base/*"; // general styling using DOM element selectors
@import "typography/*";
@import "plugins/**/*"; // 3rd party add-ons
@import "toolbox/**/*"; // Non-Utility Helpers
@import "components/**/*"; // lego blocks
@import "layout/**/*";
@import "pages/**/*";
@import "states/**/*";
@import "utility/**/*";

"Components" enthalten Teile der Benutzeroberfläche wie Schaltflächen, Eingaben, Logos, Avatare, Kopf- und Fußzeilen, Formulare und sogar Module wie Navigation. Komponenten können alles sein, solange sie eine Sache und nur eine Sache tun, wiederverwendbar, projektübergreifend wiederverwendet und vor allem unabhängig; Keine schlechte Definition, um allgemein verstanden zu werden, wenn Sie mich fragen. Dieser spezielle Ansatz implementiert auch verschiedene Ideen aus SMACSS (Status) und Atomic Design (Vorlagen - in diesem Beispiel Layout genannt - und Seiten).

In Bezug auf die Suche ist es viel einfacher, das Komponentenverzeichnis zu finden und den entsprechenden Schnittstellenteil zu finden, den ein Entwickler möglicherweise aufspürt. beispielsweise:

 - components
   - _buttons.scss
   - _navigation.scss
   - _masthead.scss
   - _footer.scss
   - _logo.scss
   - _avatar.scss
   - _contact-form.scss
   - _sales-calculator.scss

Komponenten sind im Wesentlichen ein One-Stop-Shop. Atomic Design funktioniert möglicherweise perfekt für ein Team von einem oder sogar für ein Team, das sehr vertraut ist, aber in einem größeren Team ist die Frustration zu spüren.

Abschluss

Atomic Design kann absolut verwendet werden, um das Design der Elemente auf ein Minimum zu beschränken und aussagekräftige und wiederverwendbare Schnittstellenkomponenten zu erstellen. Aber Sie können bestimmte Aspekte verwirrend finden. Entscheiden Sie selbst, was für Sie am besten funktioniert, und ziehen Sie daraus Schlussfolgerungen. Wie bei allem ist dies nur meine Erfahrung und andere mögen eine andere Haltung einnehmen.

Ich würde gerne hören, wie Sie sich diesem Szenario selbst nähern. Lassen Sie es mich in den Kommentaren wissen. Viel Spaß beim Codieren!