こんにちは、リードエンジニアの @dachi_023 です。最近書きたいことが多くて今月3本目の記事です。今回はレビュー時にStorybookを使っている話です。チームによっては使うのが当たり前くらいになってきているツールでもありますが今一度「なぜ入れているのか」「どう役に立つのか」といった観点で振り返ってもらえればいいなと思っています。
新規開発時の課題
これまでUIの実装を始める時はボタンやラベルといった粒度のコンポーネントを実装して後からレイアウトを組んだりコンポーネントを埋め込んだりする、という流れで進めていました。しかし、新規アプリケーションで先にコンポーネントを実装してしまうと実際に動作しているページがなく、レビュー時に確認しづらいという課題がありました。
レビューのためのStorybook
この問題を解決するためコンポーネント実装時にStorybookへコンポーネントを追加しておき、描画されたコンポーネントを使って動作を見てもらうのはどうか？と思いやってみることにしました。また、コネヒトでのStorybookはUIカタログとして参照するのが主で、テストやレビューで使うこともほとんどなかったのでもっと活用できたらいいなという想いもありました。
ちなみに私の場合はコンポーネントを実装したらローカルで適当なページを用意してそこに描画して試す、みたいなことをやっていました。こういう非効率なやり方はどんどん改善されるべきだと思います（自戒）。
開発フローを改善する
UI開発時のフロー
- コンポーネントの実装（テスト、UI実装）
- Storybookにコンポーネントを追加
- Pull Requestを作成・レビュー依頼
これまでコードを書いてすぐレビューを依頼していたところをStorybookへの追加までをセットでPull Requestを作成するルールにしてみました。その結果、当初想定していた以上にいい効果がありました。
レビュー時の指摘がしやすい
今回の大目的であった部分は無事改善されました。Storybookを見ながらUIに対する指摘ができるのがレビュー時にとても便利で、Propsをその場で編集することで想定外の挙動をしないかなどを確認できるようになりました。他にも @storybook/addon-a11y を使うことでコンポーネントごとのWebアクセシビリティが担保されているかの確認ができるので、機械的に判定できる部分の指摘を減らせました。
| Propsの編集 | a11yチェック |
|---|---|
 |
 |
Storybookのアドオンは他にもあるので目を通してみて「うちのチームはこれ入れると便利そう」といったものを見つけてみるといいかもしれません。また、他社事例なども非常に参考になるので「Storybook 運用」などで検索するのもおすすめです。
UIのパターン漏れに気づきやすい
「エラー時に色が変わる対応が漏れていた」といったミスにレビューを出す前からある程度気付けるようになりました。過去にこういったことが何度かあったのですが、Storybookを使うようにしてからは Story を追加するにあたってどういうパターンがあるかを事前に洗い出すようにしたのでミスを大幅に減らせました。
| 通常時のUI | エラー時のUI |
|---|---|
 |
 |
Storybookの運用が安定する
必ずStorybookに追加するようにしたのでこれまで起きていた追加・修正漏れがなくなりました。開発フローの改善をするつもりでしたが結果としてStorybookの運用フローも整いました。カタログ用途として運用しているとCIが失敗するわけでもないので追加し忘れがちだったのですが解消されました。
まとめ
スナップショットテストやカタログなどチームによって用途は異なりますが、コンポーネント単位でのレビュー時に動作確認をする場としても活用できるよという話でした。また、Storybookの追加漏れ防止など運用面でもいい効果があったのでちゃんと運用されずに困っている人にもオススメです。
この記事はShodoで執筆されました
