Storybook – mehr als ein lebendiger Styleguide?

Was ist Storybook?

Storybook ist ein Open-Source-Frontend-Tool zur Erstellung und Dokumentation von UI-
Komponenten. Es ist eine Art lebendiger Styleguide, der dazu beitragen soll, die Arbeit von
Designern und Entwicklern aufeinander abzustimmen. Es verwendet die eigentliche
Komponentenimplementierung, um die Komponentendokumentation anzuzeigen. Das
Basiselement von Storybook wird Story genannt. Jede Story stellt einen bestimmten
Komponentenzustand dar. Storybook ist nicht statisch, wie einige der anderen Tools. Sie
können daher alle Komponentenvariationen an einem Ort überprüfen, ohne dass Ihre
Anwendung überhaupt ausgeführt werden muss.

Hauptziel und Nutzen der Storybook-Pflege

Der größte Vorteil einer gut gepflegten Komponentenbibliothek besteht darin, dass alle am
Projekt Beteiligten, seien es Designer, Stakeholder oder Entwickler, eine einzige Quelle der
Wahrheit haben.

Außerdem ist es für neue Entwickler viel einfacher, in das Projekt einzusteigen, wenn sie diesen
Überblick über alle Komponenten, ihre Variationen und Eigenschaften an einer Stelle
dokumentiert haben.

Mit dem Einsatz von Storybook sollte der Entwurfsprozess neuer Seiten strukturierter werden,
d. h. vorhandene Komponenten sollten nach Möglichkeit wiederverwendet und neue nur dann
erstellt werden, wenn dies wirklich erforderlich ist. Hier kommt es einfach darauf an, dass die
Komponenten auf verschiedenen Seiten derselben Website konsistent verwendet werden - und
Storybook kann dabei sehr hilfreich sein. Schließlich kann es in gängige Design-Tools wie
Figma integriert werden.

Allerdings kann es auch vorkommen, dass der Entwickler nicht weiß, dass es eine ähnliche
Komponente bereits gibt, und sie nicht als eine weitere Variante, sondern als eine völlig neue
Komponente implementiert. Dies kann vor allem bei größeren Projekten vorkommen, bei denen
einige Komponenten tief in der Anwendung „versteckt“ sind oder eine bestimmte Reihe von
Aktionen erfordern, um auf die Seite zu gelangen, auf der die Komponente tatsächlich sichtbar
ist. Storybook löst dieses Problem, indem es alle Komponenten an einem Ort anzeigt, an dem
Sie mit den Eigenschaften spielen und alle möglichen Zustände selbst überprüfen können. Sie
müssen also keine spezifischen und komplexen Szenarien in der eigentlichen Anwendung
durchspielen. Sie brauchen die Anwendung nicht einmal zu starten, sondern können einfach
Storybook verwenden.

Storybook ist viel mehr als nur die Dokumentation
von Komponenten

Storybook beschreibt sich selbst als „Tool für die Entwicklung von Benutzeroberflächen“, was
viel mehr ist als nur ein Styleguide. Dies ist der größte Unterschied, wenn wir es mit Tools wie
dem KSS-Styleguide vergleichen, den ich in diesem Blogbeitrag beschrieben habe.

Zunächst einmal ist die Arbeit mit Storybook für Entwickler viel einfacher, da wir nicht für jede
Komponente, die wir dokumentieren wollen, eine Menge HTML kopieren und einfügen müssen.
Damit wird das große Problem vermieden, das wir oft mit allen Arten von Unterlagen haben,
nämlich sie ständig aktualisieren zu müssen. Storybook wird automatisch aus dem Code der
Komponente generiert, wodurch dieses Problem gelöst wird.

Einfaches Entdecken aller Komponentenzustände

Für mich besteht einer der größten Vorteile von Storybook darin, dass ich jede Komponente
jederzeit in jedem ihrer Zustände überprüfen kann. Einige Elemente, die nur in bestimmten
Szenarien sichtbar sind (z. B. Fehlermeldungen), sind oft umständlich zu bearbeiten und
erfordern entweder die Wiederholung eines bestimmten Ablaufs in der Anwendung, das
Mocking bestimmter Zustände oder das Auskommentieren von Teilen des Codes. In Storybook
können Sie alle Komponenteneigenschaften direkt aus dem Styleguide heraus ändern und prüfen, wie sie aussehen. Auf diese Weise können Sie bei Bedarf schnell auf alle möglichen
Komponentenzustände zugreifen - alles von einem Ort aus. Das macht die Fehlersuche viel
einfacher.

Keine Daten? Kein Problem

Storybook ist auch nützlich, wenn Sie an einem Projekt arbeiten, für das es noch keine
Datenquelle gibt. Dies kann an der fehlenden Integration mit ERP liegen, an der Notwendigkeit,
die Daten von einer älteren Plattform zu migrieren, usw. Jedenfalls kann es Sie davon abhalten,
mit der Frontend-Entwicklung zu beginnen, oder Sie zwingen, Zeit für die Erstellung von
Mocked-Daten und die anschließende Arbeit mit diesen Daten aufzuwenden. Mit Storybook
können Sie sich dafür entscheiden, die Komponenten getrennt zu bearbeiten, bis die echten
Daten zur Verfügung stehen.

Storybook-Testmöglichkeiten

Wenn Sie sich für die Nutzung von Storybook entscheiden, erhalten Sie viele Testmöglichkeiten
fast „umsonst“. Storybook wird mit Add-ons geliefert, die Sie leicht einrichten können, um Ihre
Storybook-Instanz mit Tests zu erweitern, die helfen, UI-Probleme zu erkennen.

Verwendung der Story-Konfiguration für die Tests

Wenn Sie Tests für Ihre Komponenten schreiben, müssen Sie die Szenarien erstellen, die
Komponenten mit Eigenschaften füttern und sich auch um alle Anbieter (Thema, Routing,
Übersetzungen) kümmern, damit sie korrekt dargestellt werden. Doch wenn Sie Storybook
verwenden, haben Sie genau das bereits für Ihre Storys getan. Anstatt all das zu wiederholen,
können Sie die @storybook/testing-react Bibliothek benutzen. Damit können Sie das Setup
Ihrer Storys in den React-Tests wiederverwenden (es gibt auch Bibliotheken, mit denen Sie das
Gleiche in Vue und Angular tun können).

Visuelle Tests

Es gibt zwei Ansätze zur Implementierung visueller Regressionstests für Storybook-
Komponenten.

Eine Möglichkeit ist die Nutzung von Chromatic, einem Cloud-Dienst, der für Storybook
entwickelt wurde. Das Einrichten von visuellen Tests in Chromatic ist sehr einfach und es bietet
viele Möglichkeiten. Jedoch handelt es sich hierbei um eine kostenpflichtige Lösung, die nicht
für jedes Projekt geeignet ist.

Wenn Sie eine selbstverwaltete Lösung bevorzugen, können Sie die gleichen Schritte befolgen,
wie in einem meiner früheren Blogbeiträge beschrieben: Automatisierte Front-End-Tests mit
BackstopJS und dem KSS-Styleguide. Dabei werden Sie natürlich Storybook anstelle von KSS
verwenden, aber die Idee bleibt die gleiche - visuelle Regressionstests gegen Styleguide-
Komponenten durchzuführen.

Snapshot-Tests

Diese Art der Prüfung ist in gewisser Weise mit der visuellen Prüfung vergleichbar. Während
visuelle Tests Bilder von Komponenten erfassen und sie mit Bild-Baselines vergleichen,
machen Snapshot-Tests das Gleiche, allerdings auf dem DOM. Es ist natürlich primitiver, da
dieser Test möglicherweise keine Veränderungen im Erscheinungsbild erfasst, aber aufgrund
der einfachen Einrichtung ist es eine Überlegung wert. Eine regelmäßige Ausführung während
der Entwicklung hilft, unbeabsichtigte Änderungen im DOM anderer Komponenten zu erkennen.

Zugänglichkeitstests

Diese wichtige Art von Tests wird von den Entwicklern oft übersehen. Storybook bietet eine
großartige a11-Erweiterung, mit der Sie direkt in Storybook Zugänglichkeitsprobleme in Ihren
Komponenten erkennen können. Sie wird nicht 100 % aller Probleme aufdecken, aber bietet einen guten Ausgangspunkt, um die Zugänglichkeit Ihrer Komponenten bei der
Implementierung im Auge zu behalten.

Wenn Sie die Zugänglichkeitstests automatisieren möchten, können Sie den Test-Runner von
Storybook implementieren. Er verwendet Playwright, um Ihre Storys im Browser auszuführen
und die Tests gegen sie laufen zu lassen. Hier können Sie eine Beispielkonfiguration des Test-
Runners sehen.

Interaktionstests

Moderne Komponenten, die in Webanwendungen verwendet werden, können sehr dynamisch
sein und ihr Aussehen aufgrund von Benutzerinteraktionen - Klicken, Tippen usw. - erheblich
verändern. Interaktionstests sind ein ideales Instrument, um diese Art von Verhalten zu testen.
Kurz gesagt, Interaktionstests gehen vom Ausgangszustand der Komponente aus und
simulieren nach dem Rendering die von Ihnen definierten Benutzerinteraktionen.

Genau wie die Zugänglichkeitstests können sie sowohl direkt in Storybook als auch über einen
Test-Runner ausgeführt werden.

Wann lohnt es sich, Storybook zu implementieren
und zu pflegen?

Wie Sie sehen, bringt Storybook viele Vorteile mit sich und ist weit mehr als nur eine
Komponentenbibliothek. Andererseits erfordert die Implementierung von Storybook, die
Wartung aller Komponenten und die Bereitstellung von Storybook zusätzliche Arbeit und Zeit -
und Zeit ist Geld. Für einige Teams mag ein Tool wie Storybook von entscheidender Bedeutung
sein, für andere wird es jedoch nur eine zusätzliche Belastung darstellen. Lassen Sie uns
versuchen, einige Aspekte näher zu betrachten, die Sie in Betracht ziehen sollten, wenn Sie
darüber nachdenken, Storybook in Ihren Projekt-Stack aufzunehmen.

Der Tech-Stack des Projekts

Storybook funktioniert am besten mit den gängigsten komponentenorientierten Frameworks und
Bibliotheken: React, Vue und Angular. Sie werden alle von Storybook Core gehandhabt, die
Integrationen sind gut dokumentiert und es gibt eine Vielzahl von Add-ons und Plugins, die
Ihnen helfen, Storybook in Ihre Anwendung zu integrieren.

Storybook unterstützt auch reines HTML, allerdings ist das Schreiben von Storys für HTML-
Komponenten deutlich mühsamer. Falls Sie eine Templating-Engine wie Twig in Shopware 6
verwenden, ist Storybook keine durchführbare Option.

Größe des Teams

Ein weiterer Aspekt ist die Größe des Teams. Ich würde sagen, je mehr Menschen an der
Gestaltung und Entwicklung der Komponenten beteiligt sind, desto mehr wird sich ein
Instrument wie Storybook auszahlen. Wenn die Rotation der Entwickler im Projekt recht hoch
ist, hilft das auch Neueinsteigern, sich schneller zurechtzufinden.

Art des Projekts

Handelt es sich nur um eine einfache Website, die von einem kleinen Team entwickelt wurde
und für die keine Pläne zur Wiederverwendung ihrer Komponenten in anderen Projekten
bestehen? Auch in diesem Fall kann Storybook hilfreich sein, z. B. um die neuen Designs mit
den bestehenden Komponenten konsistent zu halten. Oder handelt es sich um einen von vielen
Shops, die zum selben Unternehmen gehören und dieselben Elemente nutzen sollten? In
diesem Szenario kann Storybook als Basis für das gesamte Designsystem dienen, das
projektübergreifend eingesetzt wird.

Wie so oft, gibt es auch auf diese Frage keine eindeutige Antwort. Sie müssen die hier
erörterten Aspekte bewerten und eine Entscheidung treffen. Obwohl es wahrscheinlich
einfacher ist, von Anfang an mit Storys zu arbeiten, ist es auch möglich, Storybook zu einem
späteren Zeitpunkt einzubinden. Dies ist ebenfalls eine Option.

Schlussfolgerung

Ich hoffe, dass Sie nach diesem Artikels besser verstehen, was Storybook ist bzw. was es nicht
ist. Ich bin sicher, dass es bei der Lösung einiger Probleme helfen kann, auf die viele Front-
End-Teams früher oder später stoßen werden.

Wenn Sie den Quellcode der Demo-Anwendung einsehen möchten, mit der einige der
Storybook-Funktionen in diesem Blogbeitrag vorgestellt wurden, besuchen Sie dieses
Repository auf unserem GitHub.

• Front-End-Tests