この記事は STYLY Advent Calendar 2024 の記事です。
STYLY の Web フロントエンド開発で扱っている技術について書きます（XR との直接的な関係はありません、、悪しからず！）。
はじめに
皆さん、フロントエンド開発において Storybook は活用していますか？
Storybook とは、とーーーってもざっくり言うと UI Component のカタログを作れるライブラリです。
Component の Story を書くと Storybook 上で Props の値を変更して挙動を見たり、Addon を追加することで Component に対して test を実行したりすることができます。
様々な機能がある Storybook ですが、現場によってその活用方法は様々だと思います。この記事では STYLY の Web フロントエンド開発における Storybook の活用方法を紹介したいと思います。
活用方法
STYLY では Storybook をいくつかの開発工程で活用しています。工程ごとのどのように活用しているか紹介したいと思います。
実装時
Component の実装時は、それが UI Component であれば基本的には Story を書くようにしています。
Story を書くメリットはいくつか挙げられます。
-
Component 毎に Preview することができる
Web ページとしてレンダリングする必要がないため、例えば外部 API 依存するページでのみ使用する Component でも繋ぎこみを行わずに Component の実装を進めることができます。
Component の実装が完全にフロントエンドに閉じるため、フロントエンド外の実装（バックエンドや STYLY の場合はアプリ）がボトルネックになることなく作業を進めることができます。 -
Component 分割の指標になる
Story を書くときは必ず Component の状態「全て」を書くようにしています。
テストでも同じことが言えますが、Story が書きにくい（状態が複雑だったり、Component 内にロジックを詰め込み過ぎてしまっている）場合は Component の分割を検討します。そうすることで Component をシンプルに保つことができるようになります。
テスト
Storybook の play 関数によるテストは行っていません。Component のテストは代わりに React Testing Library を用いて jest や vitest で書いています。これは Storybook を導入した時点で Storybook のテストでは Coverage を取得することが出来なかったためです。
ゆくゆくは Coverage を取ることが出来るようになるらしいので、他の Coverage とうまく結果をマージ出来るようになれば Component に関する事は Storybook に寄せることを検討してもいいかもしれません。
https://github.com/storybookjs/storybook/releases/tag/v8.5.0-alpha.14
Storybook 絡みのテストをまったくやっていないのか？と言われるとそうではありません。Story を活用して Component 単位での VRT を行っています。
Component 単位での VRT より先に Playwright を用いたページ単位での VRT を行っていました。この Playwright と Storybook を組み合わせて Component 単位でも「言語ごと」や「画面サイズごと」の VRT を行っています。
Playwright と Storybook との連携方法について詳しく気になる方は去年のアドカレに書いていますのでそちらをご覧ください 👇
とはいえ Component によっては複数の画面サイズでレンダリングを確認する必要が無かったり、そもそも VRT を行わないようにしたい場合がありました。
そこで Story の tag に特定の文字列を入れることで制御できるように工夫を入れています。
また多少の手間を省くために Story の Document をカスタマイズし、設定されている tag や VRT のスクリーンショット更新用のコマンド等を Storybook から確認できるようにしています。
カスタマイズ方法については公式ドキュメントを参照ください 👇
何故 Component 単位での VRT を行っているのか？
元々まったくテストの書かれていないプロジェクトに対して単体テストなどのテストの導入を行いました。それを行う過程でテストが書きにくい Component の存在が問題になりました。
安易に Component の分割や修正を行うと Style 崩れが起きてしまう可能性があります。テストを書くたびに Style が崩れていないか動作確認をする、しかも複数言語・複数画面サイズで、となると手動ではとてもやってられません。
というわけでその確認工程を自動化するために VRT を導入するに至りました。
レビュー
Storybook を用いてデザインレビューを行っています。
PR トリガーの CI によって S3 へ Storybook の build をアップロードすることで PR 段階での Storybook を Preview できるようにしています。
この Preview を使ってデザイナーにデザインレビューを依頼しています。PR 毎にレビューを行うことでレビューによる手戻りを最小限に抑えることが可能になるほか、どんな Component でも変更を push してリンクを共有するだけで Preview が可能になるため、デザイナーとの細かいデザイン仕様に関するコミュニケーションが速いサイクルで可能になりました。
ちなみにデザインレビューをアプリケーションの Preview を使わず Storybook の Preview を使用している理由としましては、実装時のセクションで書いたことと同じではありますが、フロントエンド外の仕様を考慮しなくても良くなるからです。ログイン必須のページのコンポーネントや特定のユーザー状態でしか再現しない Component の状態のデータ等を用意する手間が省けます。
おわりに
以上が STYLY での Web フロントエンド開発における Storybook の活用方法でした！
Storybook は多機能になっている分そのすべてを試して実行していくことは実装工数や保守工数を考えると現実的ではありません。プロジェクト毎に何が必要で不必要なのか、開発メンバー間で価値観を共有しつつ、利点を見極め活用（もしくは使わないという選択）をしていくべきだと思います。