Storybook でサクサクコンポーネント開発

こんにちは、Gaji-Labo 鈴木です。
今回はフロントエンド開発時に使っている、コンポーネントを開発するためのオープンソースツール Storybook をご紹介します。

Storybook の良いところ

機能実装とは分離された場所にコンポーネントをのせていくことで、スムーズに開発ができ、プロジェクトを前進させるのに有効なツールだと感じています。
実際にどんなところが良いのかを以下に解説していきます。

作りやすい

Gaji-Labo では開発時にコンポーネント単位でタスクを進めるようにしています。
最小単位のコンポーネントが切られているので、その粒度でコンポーネントを作ることができます。
コンポーネントを実装して Storybook に追加するまでを1タスクとすると、作業分担もしやすく他のメンバーと並行しての作業もスムーズです。

レビューされやすい

Storybook 駆動開発の場合、基本的に1コンポーネント1 PullRequest になることが多いです。
作業内容を表すと、以下のような流れになります。

• コンポーネントの実装
• コンポーネントのスタイリング
• Storybook へのコンポーネント追加
• テストの追加

このような作業内容だとレビュアーはコンポーネントが期待通り実装されているかにフォーカスしてレビューすることができます。
また、 Storybook を起動すれば実際にコンポーネントの動作を確認することもできます。
このような理由により、レビュアーへの負担が少なくレビューされやすい状態を整えることができると感じています。

マージされやすい

前述のとおり、Storybook 駆動開発では1コンポーネント1 PullRequest でレビューがされやすくなります。
そして、実装したコンポーネントは Storybook への追加のみで、機能実装への組み込みはありません。
マージすることでの影響範囲が狭く、結果として PullRequest がマージされやすくなります。

このように、開発・レビュー・マージのサイクルを小さく速く回すことで、スムーズな開発に繋がっていると思います。

まとめ

一見遠回りに感じる Storybook での開発ですが、実際にこのフローに沿って開発をしていると、それぞれの作業がサクサクすすむことで結果的に高速な開発に繋がっていると感じています。

他にも開発フローに Storybook を採用していてこんな良い使い方もあったよ、などありましたらぜひ教えてください！