Die Idee hinter Storybook ist, das Entwickeln von Komponenten zu vereinfachen und übersichtlicher zu gestalten und das ganze isoliert von jeglicher Business Logic.
Storybook ist ein Open Source Tool, welches in ein Projekt integriert wird und so koexistiert.
Storybook existiert schon seit mehreren Jahren und wird laufend weiterentwickelt. Die aktuell (stable) Version liegt derzeit bei 6, wobei sich Version 7 schon in der Pre-Release Phase befindet und voraussichtlich in den nächsten Wochen bis Monaten (als stable Version) verfügbar sein wird. Es gibt die Dokumentation sowohl für pures JavaScript, als auch für die gängigsten JavaScript Frameworks, wie zum Beispiel Angular, Vue oder React.
Für jede Komponente, die ein Teil von Storybook sein soll, legen wir eine “.stories”-Datei an. In dieser definieren wir dann Stories mit Mock-Daten, die wir gern testen möchten. In den “.stories”-Dateien wird definiert, wie die Komponente heißt, die in Storybook hinzugefügt werden soll, welche Werte zum Testen zur Verfügung stehen sollen und wie Kombinationen aus Komponenten (auch das ist möglich) miteinander zusammenspielen sollen.
Konkret sieht das dann in unserem Fall so aus:
Die Beschreibungen, Namen und Standardwerte der Inputs holt sich Storybook ganz magisch 😉 selbst aus dem Code. Et voilà, die Komponente kann in Storybook getestet werden. Werte können direkt im Browser geändert werden und deren Verhalten und Aussehen getestet werden.
Im Browser schaut das ganze dann so aus:
Unsere Erfahrungen
Es sind die verschiedensten Frameworks gut verständlich dokumentiert, dadurch ist Storybook schnell aufgesetzt und es kann ohne viel Aufwand gleich damit gestartet werden.
Durch den Einsatz von Storybook nehmen wir uns automatisch mehr Zeit, Komponenten und deren Features genau durchzudenken. Komponenten werden zunächst am Reißbrett gedacht, ohne sich zu sehr mit den speziellen Anforderungen für die App aufzuhalten. Das hat uns automatisch dazu gebracht, die Komponenten granularer zu denken und so aufs Wesentliche zu reduzieren und mehr auf Wiederverwendbarkeit zu achten. Im zweiten Schritt kann dann noch genauer überlegt werden, wie die Komponenten für die spezielleren Einsatzzwecke erweitert werden müssen oder ob dafür weitere Komponenten nötig sind.
Uns passiert es oft, dass im Laufe eines Projekts das Kommentieren des Codes vernachlässigt wird und wir uns dann Monate später beim Weiterentwickeln ärgern, dass Kommentare fehlen. Da Storybook Kommentare von Datenfeldern erkennt und als Beschreibung darstellt, laufen wir weniger Gefahr, das Kommentieren zu vernachlässigen.
Wenn wir an die Weiterentwicklung von Projekten denken, dann sehen wir den größten Vorteil von Storybook darin, Anpassungen und deren Auswirkungen von Komponenten effizienter testen zu können. Denn durch die verschiedenen Stories, die im Vorfeld angelegt wurden, kann so jeder Use Case durchgetestet werden. Vor allem auch Use Cases, die nicht oft vorkommen und daher leicht übersehen werden können.
Zum Beispiel soll eine Komponente, die mehrere Status hat, die die Darstellung jener Komponente beeinflussen, weiterentwickelt werden. Angenommen, es kommt ein neuer Status dazu, durch den Änderungen am Layout notwendig sind. Durch die schon vorher definierten Use Cases (bzw. Storys), kann jetzt Story für Story kontrolliert werden, ob und welche Auswirkungen die Änderungen auf die Komponente haben.
Zusammenarbeit mit Design
Bevor wir Entwickler:innen mit dem Programmieren loslegen, bekommen wir von unseren Designer:innen einen Style Guide. Dieser definiert unter anderem das zu verwendende Farbschema, Typographie und Spacing-System. Das sieht dann zum Beispiel so aus:
Aber nicht nur das, im Style Guide sind ebenfalls alle Komponenten und deren Zustände genauestens beschrieben. Hier ein kleiner Auszug wie so etwas aussieht:
Genau da kommt Storybook zum Einsatz. Mithilfe von Storybook entwickeln wir die Komponenten genau nach Vorgabe des Style Guides. Zusätzlich gibt es laufende Abstimmungen mit unseren Designer:innen während der gesamten Entwicklungszeit, um sicherzugehen, dass die Komponenten genauso aussehen und genauso funktionieren, wie von unseren Designer:innen konzipiert. Diese Kombination aus Dokumentation und Abstimmungen zwischen den Abteilungen hilft uns enorm bei der Qualitätssicherung.
Fazit
Für mich hat Storybook nur Vorteile. Es verbessert die technische Dokumentation, hilft bei der Weiterentwicklung von Projekten (oder Teilen davon), hilft bei der Abstimmung mit anderen Teilen des Teams oder das Übergeben des Projekts an Kolleg:innen, hilft langfristig die technical debt zu reduzieren, hilft bei der Qualitätssicherung und beim Testen, … . Wie man sieht, könnte ich noch ewig so weitermachen ;).
Deshalb ist für mich Storybook die bessere Kitchensink.
Hast du schon mit Storybook gearbeitet? Welche Erfahrungen hast du mit Storybook gemacht?
