Storybook: katalog aplikacji.

DefinicjaStorybook to narzędzie open source do budowania, oglądania i dokumentowania komponentów interfejsu w oderwaniu od reszty aplikacji. Każdy stan komponentu, np. przycisk zwykły, wyłączony albo w trakcie ładowania, zapisuje się jako osobną „historię” (story), którą można otworzyć w przeglądarce i sprawdzić.

Jak działa Storybook?

Aplikacja składa się z komponentów, czyli powtarzalnych elementów: przycisków, pól formularza, kart produktów, okienek z komunikatami. Więcej o komponentach piszę w artykule o design systemie. W samej aplikacji wiele stanów trudno zobaczyć: żeby obejrzeć komunikat o nieudanej płatności, trzeba by tę płatność naprawdę zepsuć.

Storybook pokazuje każdy komponent osobno, na czystej stronie, ze wszystkimi stanami opisanymi jeden pod drugim. Po lewej masz listę komponentów i ich historii, po prawej wybrany stan, który możesz klikać, zmieniać mu teksty i oglądać na różnych szerokościach ekranu.

Sam Storybook jest darmowy i ma otwarty kod (storybook.js.org). Działa z najpopularniejszymi technologiami do budowy aplikacji webowych, a gotowy katalog można opublikować pod osobnym adresem, który otworzy każdy z zespołu.

Co daje Storybook klientowi?

• Wszystko widać w jednym miejscu. Zamiast prosić o zrzuty ekranu, otwierasz adres katalogu i oglądasz każdy element aplikacji, także rzadkie stany: pustą listę, błąd, bardzo długą nazwę produktu.
• Łatwiejszy odbiór zmian. Nowy komponent albo zmianę wyglądu możesz zobaczyć i skomentować, zanim trafi do aplikacji.
• Mniej niespodzianek. Komponent sprawdzony we wszystkich stanach rzadziej psuje się w miejscu, o którym nikt nie pomyślał.
• Dokumentacja dla kolejnych osób. Nowy programista albo inny wykonawca widzi, jakie elementy już są i jak ich używać, zamiast budować je od nowa.

Z katalogu korzysta cały zespół: programiści budują w nim komponenty, projektant sprawdza, czy zgadzają się z projektem, tester przegląda trudne stany, a Ty oglądasz postęp i zgłaszasz uwagi. Wszyscy patrzą na to samo, więc rzadziej słychać „u mnie wygląda inaczej”.

Jak Storybook łączy się z design systemem?

Design system to zasady i komponenty, a Storybook to najczęstsze miejsce, w którym te komponenty są pokazane w kodzie. Projektant rysuje przycisk w programie graficznym, np. w Figmie, programista buduje go w kodzie i pokazuje w Storybooku. Gdy obie wersje się zgadzają, zespół ma jedno źródło prawdy: wiadomo, który przycisk jest właściwy.

Dlatego Storybook pojawia się zwykle razem z design systemem. Może też działać sam, jako katalog komponentów jednej aplikacji.

Czy Storybook pomaga w testach?

Tak. Każda historia to gotowy przypadek testowy, bo wiadomo, jak komponent ma wyglądać i zachowywać się w danym stanie. Do Storybooka można dodać automatyczne sprawdzanie dostępności (np. kontrastu i opisów dla czytników ekranu), testy interakcji (czy po kliknięciu „Wyślij” pojawia się komunikat) i testy wizualne, które porównują wygląd komponentów przed zmianą i po niej. Testy wizualne działają zwykle jako płatna usługa w chmurze. O rodzajach testów piszę w artykule Testy oprogramowania.

Kiedy Storybook się opłaca, a kiedy nie?

Opłaca się, gdy aplikacja ma wiele ekranów i komponentów, nad projektem pracuje kilka osób (programiści, projektant, tester), produkt będzie rozwijany latami albo powstaje design system dla kilku produktów naraz.

Nie opłaca się przy prostej stronie firmowej z kilkoma podstronami. Komponentów jest tam kilkanaście, zmieniają się rzadko i wystarczy obejrzeć je na samej stronie. Storybook to dodatkowy kod do utrzymania: przy każdej zmianie komponentu trzeba poprawić też jego historie, inaczej katalog przestaje odpowiadać temu, co jest w aplikacji.

Ile kosztuje Storybook?

Licencja nic nie kosztuje. Kosztem jest czas programisty: przygotowanie historii dla komponentów i ich aktualizowanie. W aplikacji, która i tak ma testy i design system, to niewielki dodatek. W małym projekcie to zbędny wydatek, który lepiej przeznaczyć na treści albo szybkość strony.