Komponentenbasiertes Design mit Drupals Single Directory Component

Veröffentlicht: 2023-06-13

Drupal-Themen sind seit langem ein Bereich, der von einem radikalen Update unberührt geblieben ist. Natürlich gibt es jede Menge bereitgestellter Module, die den Arbeitsablauf ein wenig vereinfachen, aber der Standardansatz zum Erstellen eines benutzerdefinierten Designs ist mehr oder weniger derselbe geblieben. Schon seit langem wird darüber geredet, dass es im Drupal-Kern selbst eine Art komponentenbasierten Design-Mechanismus geben soll. Hier kommt Single Directory Components (SDC) zum Einsatz, das seit geraumer Zeit über ein von prominenten Drupal-Mitwirkenden – Mateu Aguilo Bosch, Mike Herchel, Lauri Eskola und Dave Reid – bereitgestelltes Modul diskutiert wird. Aber jetzt ist es in Version 10.1 im Kern von Drupal angekommen (derzeit als experimentelle Funktion).

Dieser komponentenbasierte Ansatz zur Themengestaltung einer Drupal-Anwendung ist nicht neu, hat aber endlich Einzug in den Kern gehalten. Es bietet Front-End-Entwicklern völlig neue Möglichkeiten, ihren Code so zu organisieren, dass er mit minimalem Lernaufwand wartbarer ist. Innerhalb von SDC sind alle zum Rendern der Komponente erforderlichen Dateien (Twig, CSS, JS usw.) in einem einzigen Verzeichnis zusammengefasst. SDC hat das Potenzial, die Front-End-Entwicklung in Drupal zu revolutionieren, indem es Entwicklern die Nutzung der neuesten Front-End-Techniken ermöglicht und so Drupals Position als robustes und zukunftsorientiertes CMS festigt.

Drupals aktueller Theming-Ansatz

Die einfachste Möglichkeit, an einem Drupal-Theme zu arbeiten, bestand darin, das Markup zu den html.twig-Dateien in den Vorlagenordnern hinzuzufügen. Für Stil und Verhalten erstellen wir CSS- und JS-Dateien entsprechend den Anforderungen einer Entität und platzieren sie in den CSS- bzw. JS-Ordnern. Dazu gehören thematische Kopfzeilenmenüs, Fußzeilenmenüs, Blöcke, Regionen, einzelne Inhaltstypen und ihre verschiedenen Ansichtsmodi, verschiedenen Ansichten usw. Diese Dateien werden dann in der Datei „libraries.yml“ deklariert, in der auch Abhängigkeiten (falls vorhanden) erwähnt werden können. Auf diese Weise können sie bei Bedarf geladen oder global verfügbar gemacht werden. Abgesehen davon geht jegliche Vorverarbeitungslogik in die .theme-Dateien, wir haben die Datei breakpoints.yml, die bei responsiven Designs hilft, und natürlich die Datei .info.yml, ohne die der ganze Aufwand umsonst wäre.

Während dies eine Menge Arbeit zu sein scheint, die erledigt werden muss, bevor wir tatsächlich einige nützliche Frontend-Arbeiten durchführen, gibt es einige Standardcodegeneratoren wie drush theme generic , die darauf abzielen, die Ordnerstruktur eines Themes auf interaktive Weise zu generieren und eine zu erstellen Standard-Drupal-Ordnerstruktur.

Obwohl die obige Struktur für den Start eines Projekts gut genug funktioniert und für ein kleines Projekt kein Problem darstellen kann, kann sie zu einem Engpass für Unternehmenswebsites werden, bei denen ein anspruchsvolleres Designsystem integriert werden muss.

Die Dinge beginnen sehr schnell unübersichtlich zu werden. Wir sehen, dass viele CSS- und JS-Dateien in ihren Ordnern bis zum Rand gefüllt sind.
Entwickler haben Schwierigkeiten, den Code zu finden, den sie wiederverwenden oder erweitern können.
Es treten Probleme wie Codeduplizierung, Codeverteilung über Dateien, Spezifitätshölle und CSS-Konflikte auf.
Dies führt häufig dazu, dass mehr Aufwand für die spätere Entwicklung aufgewendet wird, obwohl erwartet wird, dass die anfängliche Entwicklung später hilfreich gewesen wäre.

Unser Ansatz zur Themengestaltung in Specbee

Bei Specbee haben wir die Art und Weise, wie wir unsere Themes erstellen, standardisiert, indem wir ein NPM-Tool namens Drupal Theme Init verwenden, das wir von Grund auf entwickelt haben und das Open Source ist. Da es sich um einen Yeoman-Generator handelt, kann er problemlos mit NPM/Yarn installiert werden, was dann interaktiv bei der Generierung eines benutzerdefinierten Themes hilft. Die Idee der Drupal-Theme-Initialisierung besteht darin, einen konsistenten Ansatz für die Strukturierung von Theme-Dateien gemäß den Drupal-Praktiken zu haben und Entwicklern dabei zu helfen, mit der Arbeit am Theme zu beginnen, ohne jedes Mal, wenn sie ein neues Projekt starten, die Dateien neu festlegen zu müssen. Die Grundidee der Struktur besteht darin, SASS mithilfe der BEM-Konvention in Komponenten zu unterteilen. Für jede CSS-Datei, die mit einer Entität wie Block, Ansicht, Inhaltstyp usw. verknüpft ist, wird ein eigenes CSS generiert und entweder über die Twig-Vorlage oder durch Vorverarbeitung an diese Entität angehängt. Das Gleiche gilt für die JS-Dateien. Die umfassende Verwendung von Bibliotheken.yml hilft uns, die Menge an CSS und JS, die wir auf der Seite rendern, zu begrenzen.

Der Vorteil dieser Einrichtung des Themes besteht darin, dass wir über ein System für komponentenbasiertes Themeing verfügen, ohne auf externe Bibliotheken oder Plugins angewiesen zu sein. Es hilft uns, die CSS/JS-Bibliotheken basierend auf den auf der Seite zu ladenden Komponenten zu trennen, was der Leistung zugute kommt. Dieser Ansatz unterliegt jedoch immer noch Einschränkungen, insbesondere wenn das Projekt größer wird. Die Aufteilung der Komponenten in atomare Ebenen stellt eine gewisse Belastung dar, da wir dafür die Datei „libraries.yml“ mit den erforderlichen Abhängigkeiten verwalten müssen. Außerdem gibt es keine einfache Möglichkeit, ein Designsystem problemlos in die aktuelle Struktur zu integrieren, da wir jeden Komponentenpfad und seine Abhängigkeit auch im Designsystem selbst definieren müssen, um die Komponenten darin zu laden.

Was ist komponentenbasiertes Theming?

Während der Vanilla-Ansatz recht einfach zu sein scheint, wurden in jüngster Zeit durch bereitgestellte Module enorme Fortschritte erzielt, um bessere Ansätze zu erhalten. Einer der beliebtesten Ansätze besteht darin, sich die Benutzeroberfläche als eine Sammlung wiederverwendbarer und konsistenter Einheiten vorzustellen, die als Komponenten bezeichnet werden. In den meisten Fällen folgt dies dem Atomic Design, bei dem jede Komponente in kleinere Bausteine unterteilt wird. Module wie UI-Muster, Komponenten! oder Komponentenbibliotheken wie PatternLab, Fractal und Storybook haben innovative Wege eröffnet, die die Entwicklung von Themen effizienter und robuster gemacht haben. Komponentenbasiertes Theming hat gegenüber dem traditionellen Theming einen gewissen Vorteil:

Einer der größten Engpässe ist die Backend-Abhängigkeit, bei der die Frontend-Arbeit nicht ohne die Backend-Arbeit beginnen kann. Dadurch entsteht eine Verzögerung. Mithilfe eines komponentenbasierten Ansatzes kann das Frontend unabhängig und ohne große Kenntnisse in Drupal-Dingen arbeiten.
Komponenten können einfach aus dem verfügbaren Design mit den erforderlichen Platzhaltern erstellt werden. Die Werte für diese Platzhalter können später ausgefüllt werden, wenn die Backend-Arbeiten abgeschlossen sind
Es entsteht ein Arbeitsablauf, bei dem wir das Markup im Vorlagenordner einfach nicht ändern und es gemäß den Anforderungen formatieren. Stattdessen gestalten wir kleinere Strukturen separat und erstellen dann eine Sammlung dieser kleineren Einheiten in größeren Komponenten, die von den Drupal-Vorlagen verwendet werden können.
Dies hilft dabei, den Code für jede Komponente isoliert zu verwalten und verringert das Risiko von Nebenwirkungen.
Es bestätigt die UX-Konsistenz in der gesamten Anwendung.
Hilft dabei, den Aufwand für die Einrichtung der Funktion zu reduzieren, da an einer Stelle vorgenommene Änderungen in allen Bereichen, in denen sie verwendet wird, wirksam werden.

So erstellen Sie komponentenbasiertes Theming in Drupal

Eine der bekanntesten Möglichkeiten, die komponentenbasierte Entwicklung zu verfolgen, ist die Verwendung von PatternLab, das vor einiger Zeit eingeführt wurde. Es kam ursprünglich mit einer Drupal-Edition, die jetzt archiviert und durch ein knotenbasiertes Paket ersetzt wird. Für die Einrichtung von PatternLab muss ein Komponentenmodul installiert werden, das dabei hilft, das Markup aus Twig-Dateien außerhalb des Vorlagenordners für Drupal abzurufen. Anschließend wird das Patternlab-Paket über npm installiert, das Optionen zum Generieren von Twig- oder Moustache-basierten Vorlagen bietet (für uns natürlich Twig). Sobald dies erledigt ist, haben wir einen fertigen Reckoner-Styleguide, einen Codebaustein, der bei der Erstellung des Styleguides hilft, und einen Musterordner, in dem wir die Komponenten gemäß den Anforderungen erstellen. Diese Komponenten werden dann in die html.twig-Dateien im Vorlagenordner eingefügt.

Obwohl alle diese Schritte problemlos durchzuführen sind, gibt es Fälle, in denen die Einrichtung etwas schwierig ist und eine gewisse Lernkurve mit sich bringt. Der größte Nachteil von Patternlab besteht darin, dass das gesamte CSS in einer einzigen Datei zusammengefasst wird, die dann auf allen Seiten abgelegt wird (was manchmal auch bei dem darin enthaltenen JS der Fall ist). Während dies zunächst keine Rolle spielt, da der Grundgedanke die Wiederverwendbarkeit der Komponente ist, wirkt sich dies mit zunehmender Größe des Projekts auf die Seitenleistung aus.

So erstellen Sie komponentenbasiertes Theming mit SDC

Da die erste Version von SDC als experimentelles Modul in den Kern ging, gab es viel Aufregung. SDC wird als die größte Änderung der Drupal-Themen seit der Einführung von Twig angepriesen. Auch hier handelt es sich bei SDC nicht um eine Komplettlösung für das Frontend-Entwicklungsteam, sondern um einen komponentengesteuerten Ansatz zur Themengestaltung mit einer sofort einsatzbereiten Grundstruktur. Dies kann noch mit einer Reihe von Modulen für eine bestimmte Art von Workflow erweitert werden. Die Grundidee besteht darin, dass alles, was mit einer Komponente zusammenhängt, in einem einzigen Verzeichnis bleibt. Dazu gehören die Komponenten-Twig-Datei, JS, CSS, andere Assets und eine einzelne Schema-YAML-Datei, die die Eigenschaften der Komponente deklariert.

Einige unmittelbare Vorteile der Verwendung von SDC:

Der gesamte Code, der sich auf eine Komponente bezieht, befindet sich in einem einzigen Verzeichnis (wie der Name schon sagt!).
Die Bibliotheken für die Komponente werden automatisch generiert, was zu einem geringeren Trauma führt, wenn sie nicht in der Datei „libraries.yml“ deklariert wird. Obwohl wir die Abhängigkeiten möglicherweise noch zur Datei „component.yml“ hinzufügen müssen, geschieht dies an einer einzigen Stelle, anstatt zur Datei „libraries.yml“ zu springen.
Die Implementierung von SDC erfordert eine weitaus geringere Lernkurve. Wenn Sie die Grundlagen des Drupal-Themings kennen, müssen Sie nur dieses Modul aktivieren und mit dem Schreiben der Komponenten beginnen.
Die Leistungsfähigkeit von Twig (einschließen/erweitern/einbetten) ist weiterhin verfügbar, was zur Wiederverwendbarkeit von Code beiträgt.
Da es sich bei den Komponenten um YML-Plugins handelt, können diese von Drupal leicht erkannt und problemlos durch eine Komponente mit derselben API-Struktur ausgetauscht werden.
Die Komponenten können auch über Render-Arrays gerendert werden!
Bietet einen guten Mechanismus zur Integration externer Bibliotheken, um ein Designsystem zu erleichtern.
Durch die Organisation der Komponenten entsteht ein einheitliches Erscheinungsbild des Endprodukts.
Der Code wird testbarer, da wir Einheiten (Lesekomponenten) haben, die unabhängig getestet werden können
Da wir das Schema innerhalb der YAML-Definition einer Komponente definieren, können Module automatisch Formulare zum Auffüllen von Daten erstellen.

Obwohl es derzeit als experimentelle Funktion im Kern enthalten ist, ist die Einrichtung von SDC recht einfach. Vorausgesetzt, es liegt eine Drupal 10.1.x-Installation vor:

1. Aktivieren Sie das experimentelle SDC-Kernmodul.

2. Erstellen oder verwenden Sie ein benutzerdefiniertes Design, um SDC hinzuzufügen. Für unseren Zweck haben wir ein benutzerdefiniertes Thema namens Ice Cream mit Olivero als Basisthema erstellt.

3. Für unseren Zweck verwenden wir die Basisseite, die im Lieferumfang enthalten ist. Ich habe es umgestaltet, indem ich ein benutzerdefiniertes Titelfeld hinzugefügt und einige Anpassungen an der Anzeige vorgenommen habe, die dann so aussieht:

4. Die Twig-Vorlagendatei besteht aus Basiscode:

5. Erstellen Sie in Ihrem benutzerdefinierten Design einen Ordner mit dem Namen „components“ . Dies ähnelt dem Ordner „Templates“ für Drupal-Vorlagen.

6. Die Grundidee besteht zunächst darin, den Titel und die Beschreibung so zu gestalten, dass sie wiederverwendbar sind. Erstellen wir eine Komponente namens simple-article. Wir benötigen die Dateien simple-article.component.yml und simple-article.twig. Darüber hinaus werden wir auch simple-article.css für das Styling hinzufügen.

7. Erstellen wir die Datei simple-article.twig . Wir werden dafür ein grundlegendes Markup haben.

8. Fügen Sie die Datei simple-article.component.yml mit dem in https://www.drupal.org/node/3352951 genannten Schema hinzu. Die Idee besteht darin, die Eingaben für die Twig-Datei zu definieren. Bei uns wird es etwa so aussehen:

9. Fügen wir der Komponente in simple-article.css einige grundlegende Stile hinzu.

10. Leeren Sie den Cache.

11. Abrakadabra! Die Komponente ist nun einsatzbereit. Aber es muss trotzdem genutzt werden. Andernfalls verbleibt die Komponente im Komponentenordner im Leerlauf.

12. Fügen Sie diese Komponente in die erforderliche Vorlagendatei (dies ist die Datei html.twig im Vorlagenordner im benutzerdefinierten Design) mit dem Format [Themenname:Komponentenname] ein. Beachten Sie die Include-Anweisung, in der wir die Twig-Variablen hinzufügen, die in der Komponente verwendet werden sollen.

13. Die Komponente wird jetzt mit unserem neuen Markup und besserem Stil gerendert.

14. Beachten Sie das Markup. Wenn Twig-Debug aktiviert ist, erhalten wir beim Rendern unserer SDC-Komponente auch einige spezielle Symbole.

Und das ist es!

Verweise

https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components
https://www.drupal.org/project/sdc
https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal

Abschließende Gedanken

Aufgrund der Art und Weise, wie SDC aufgebaut ist, wird es eine intensive Entwicklung rund um das SDC geben. Einer der beliebtesten Wege ist, dass Module Komponenten automatisch erkennen und ihre jeweiligen Formulare in Layout Builder, CKEditor, Absätze, Blöcke, Felder usw. einfügen! Darüber hinaus arbeitet SDC derzeit gut mit Storybook über ein beigesteuertes Modul namens CL Server zusammen (das von SDC-Projektbetreuern gepflegt wurde). Es gibt bereits andere Module wie CL Devel, CL Generator und sogar UI Patterns, die auf SDC basieren.

Dies wird uns auch dabei helfen, unseren eigenen Theme-Generator (Drupal Theme Init) zu aktualisieren, den wir zuvor besprochen haben, um die Möglichkeit zu geben, SDC zusammen mit einem vorhandenen Design-System, vorzugsweise Storybook, zu verwenden. Dies wird jedem helfen, die SDC-Implementierung sofort anzukurbeln und den Weg für eine bessere Themenentwicklung zu ebnen.

Wenn Sie weitere interessante Inhalte zu Drupal lesen möchten, abonnieren Sie noch heute unseren wöchentlichen Newsletter!