Share
Atomic Design ist eine Methodik, die eine sinnvolle Codestruktur für Stylesheets beschreibt. Es hat eine große Fangemeinde, aber ich finde, dass die Namenskonventionen manchmal mehrdeutig sind. Was ist ein Molekül? Was ist ein Organismus? Woher wissen wir, wo wir die Grenze zwischen den beiden ziehen müssen? Diese besonderen Fragen scheinen der größte Stolperstein für die Interpretation einer atomaren Architektur zu sein.
Atome, Moleküle, Organismen, Vorlagen und SeitenHeute werden wir besprechen, was ich benutze, bestimmte Aspekte der Konventionen von Atomic Design, mit denen ich Probleme habe, was ich getan habe, um meine Probleme zu lösen, und wie ich Sass derzeit organisiere, beispielsweise mit dem 7-1-Muster.
Brad Frost, Autor von Atomic Design, hat seither klargestellt, dass seine Methodik eigentlich keine CSS-Struktur vorschreibt. Stattdessen bietet es ein mentales Modell zum Nachdenken über das Erstellen von Benutzeroberflächen. Entschuldigung Brad!
„Wir entwerfen keine Seiten, wir entwerfen Systeme von Komponenten.“ - Stephen Hay
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 alles funktioniert. In der Vergangenheit habe ich folgende Ordnerstruktur verwendet:
Ordnerorganisation: root / css / src /
- vars - funktionen - mixins - base - plugins - typografie - atome - moleküle - organismen - vorlagen - seiten - zustände - utility style.scss
Innerhalb style.scss Sass-Partials werden mit gulp-sass-glob-import importiert:
Sass Import Index-Datei: root / css / src / style.scss
// Config @import "vars / *"; @import "funktionen / *"; @import "mixins / *"; // Bower Components @import "… / bower_components / normalize-scss / _normalize"; // Allgemeine DOM-Auswahlstile @import "base / *"; // Schriftarten und allgemeines Schriftschnitt @import "Typografie / *"; // 3rd Party Addons @import "plugins / *"; // Atomic Design @import "Atome / ** / *"; @import "Moleküle / ** / *"; @import "Organismen / ** / *"; @import "templates / ** / *"; @import "Seiten / ** / *"; // Variationen durch Ereignisse @import "states / *"; // Allgemeine UI-Helfer @import "Dienstprogramm / *";
Die Reihenfolge bei diesem Setup ist ziemlich wichtig. Wenn ein „Atom“, ein „Molekül“ oder ein „Organismus“ 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 eines Plugins, falls dies erforderlich sein sollte (und dies normalerweise nach meiner Erfahrung)..
Ein Großteil des Inhalts jedes Atomverzeichnisses (Atome, Moleküle, Organismen, Vorlagen, Seiten) enthält Teilelemente, die theoretisch leicht zu finden und bei Bedarf einfach zu verwalten sind.
- Atome - _buttons.scss - _links.scss - _inputs.scss - Moleküle - _navigation.scss - _search-form.scss - _contact-form.scss - Organismen - _header.scss - _footer.scss - _content.scss - Vorlagen - _sticky- footer.scss - _grid-2column.scss - _grid-3column.scss - Seiten - _home.scss - _about.scss - _contact.scss
Die Organisation scheint vernünftig zu sein, wenn Sie zu Atomic Design klug sind, aber für jemanden, der mit dem Ansatz und der Nomenklatur nicht vertraut ist, nicht geeignet. Ein Entwickler, der Atomic Design nicht kennt, macht keinen Sinn, wenn sich ein Suchformular in der Datenbank befindet Moleküle Verzeichnis, und kann die Suche in anderen Bereichen starten, um Änderungen vorzunehmen, oder einfach frustriert werden und eine neue Datei erstellen; Ich habe gesehen, dass es passiert ist.
Zum Zeitpunkt der Erstellung dieses Artikels betrachte ich einen Ansatz, der Elemente vollständig als Komponenten wie Legoblöcke vorsieht, wodurch eine Benutzerfreundlichkeit für alle an der Codebase Beteiligten geschaffen wird. Schauen Sie sich die folgende Verzeichnisstruktur an:
- vars - funktionen - mixins - base - typography - plugins - toolbox - komponenten - layout - seiten - zustände - utility style.scss
Hoffentlich können Sie an diesem Beispiel erkennen, dass es ziemlich intuitiv ist, den Zweck jedes Ordners (mit Ausnahme der Toolbox) zu ermitteln. In „Toolbox“ können Helfer gespeichert werden, die nicht mit Dienstprogrammen zusammenhängen, z. B. benutzerdefinierte Klassen für Layout- und Objektmuster, benutzerdefinierte Keyframe-Animationen usw. Diese Toolbox-Elemente enden für mich normalerweise als Teile, die ich möglicherweise überschreiben möchte oder in der Zukunft möchte, und warum sie vor dem Komponentenverzeichnis importiert werden.
In dieser Phase werden Partials wie folgt in den Stilindex geladen:
// Config @import "vars / ** / **"; @import "funktionen / *"; @import "mixins / *"; // UI @import "… / bower_components / normalize-scss / _normalize"; @import "base / *"; // allgemeines Styling mit DOM-Element-Selektoren @import "typography / *"; @import "plugins / ** / *"; // Add-ons von Drittanbietern @import "toolbox / ** / *"; // Nicht-Hilfsprogramme @import "components / ** / *"; // legoblöcke @import "layout / ** / *"; @import "Seiten / ** / *"; @import "states / ** / *"; @import "Dienstprogramm / ** / *";
„Komponenten“ enthalten Teile der Benutzeroberfläche wie Schaltflächen, Eingaben, Logos, Avatare, Kopf- und Fußzeilen, Formulare und sogar Module wie die Navigation. Komponenten können alles sein, solange sie eine Sache und nur eine Sache tun, wiederverwendbar, im gesamten Projekt wiederverwendet werden und vor allem unabhängig sind; keine schlechte Definition, um allgemein verstanden zu werden, wenn Sie mich fragen. Dieser spezielle Ansatz setzt auch verschiedene Ideen von SMACSS um (Zustände) und Atomic Design (in diesem Beispiel genanntes Layout und Seiten).
In Bezug auf die Suche nach Methoden ist es viel einfacher, das Komponentenverzeichnis zu finden und den entsprechenden Schnittstellenteil zu finden, den ein Entwickler möglicherweise aufspürt. zum Beispiel:
- Komponenten - _buttons.scss - _navigation.scss - _masthead.scss - _footer.scss - _logo.scss - _avatar.scss - _contact-form.scss - _sales-calculator.scss
Im Wesentlichen handelt es sich bei Components um eine zentrale Anlaufstelle. Atomic Design mag für ein Team von einem Team oder sogar für ein Team, das sehr vertraut ist, perfekt funktionieren, aber in einem größeren Team kann die Frustration spürbar werden.
Atomic Design kann absolut verwendet werden, um die Elemente minimal zu gestalten, um sinnvolle und wiederverwendbare Schnittstellenkomponenten zu erstellen. Sie können jedoch 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 können eine andere Haltung einnehmen.
Ich würde gerne hören, wie Sie dieses Szenario selbst angehen, also lassen Sie es mich in den Kommentaren wissen. Viel Spaß beim Codieren aller!
Accentsconagua