今日はJavascriptのUI開発コミュニティーで、最も有名なツールであるStorybookを紹介していきます。僕は、2016年頃に初めて使いましたが、年々パワーアップしていき、今では機能も、ドキュメンテーションを非常に充実しています。まだ使ったことがない方には、是非ともトライしてもらいたいオープンソース（つまり無料）のツールです。
Contents
Storybookとは何か？
Storybookとは、React, Vue, Angularを採用したプロジェクトにおいて最も有名なUI開発ツールです。プロダクト（開発するサイトやソフトウエア）とは完全に切り離して、UI開発を行う環境を提供してくれます。
具体的に言えば、まだAPIなどバックエンドの開発は進んでないけど、CardComponentには以下のようなデータが渡り、Card Componentはそのデータを表示するという場合には、バックエンド側の開発を待たずに、UI開発のみを進めることができます。
Prop = {
firstName: “Wata”,
lastName: “Blog”,
age: 30
}コンポーネントが受け取るデータ型のみ定義しておけばUIコンポーネントの開発を進めることができます。
Github, Airbnb, Dropbox, Lonely Planetなど、名だたる企業が使用しているオープンソースのツールです。僕自身もこれまでのReact プロジェクトでは全て採用してきました。
まずは公式が公開しているデプロイされたStorybookのリンクをサラッと見てください。
これで、Storybookのイメージがだいたい掴めるはずです。
Storybookをプロジェクトで使う利点
僕自身、実際にいくつかのプロジェクトでStorybookを使ってきたので、Storybookを使って良かったことを挙げておきます。
１プロジェクトとは切り離してUI開発を進めることができる
Storybookでは、サンプルデータを渡して、UI開発を進めることができます。
このコンポーネントが受け取るのは、こういう型のデータだから、それを表示するコンポーネントの開発を進めよう！つまり、見た目部分にフォーカスしたUI開発を進めることができます。
現在のUI開発では、ロジックとビジュアルの部分は切り離して開発するのが良いとされます。その理由は、コンポーネントを再利用しやすいし、ユニットテストも書きやすいし、ロジックのみか、UIのみの変更を加える場合にも、どこに変更を加え、どこを確認したら良いのかクリアになるからです。
Storybookは、独立したUI開発を促進してくれるツールでもあります。
プロジェクトのUIライブラリーとして使える
StorybookでUIライブラリーを構築しておけば、そのプロジェクトには、どんなコンポーネントが用意されていて、何が足りないのかはっきりします。
似たようなコンポーネントがあるのに、チームに加わったばかりのエンジニアが新しいコンポーネントを一から作り、時間を無駄にすると言うような単純なミスを避けることができます。
SketchとかFigmaで作成したデザインがあるから、必要ないだろと思うかもしれませんが、コードベースのコンポーネントと、デザイナーが作成したデザインコンポーネントが常にマッチするケースは意外と少ないものです。実務の現場では、デザイナーのデザインとは違うものが実際には運用されているケースは多々あります。そのような場合でも、Storybookであれば、実際のコードベースで運用されているので最新のコンポーネントを確認することができます。
ビジュアルのテストケースとして使える
Storybookでは、一つのコンポーネントに対していくつかのストーリー（テストケース）を書くことができます。あとで解説しますが、簡単な例でいえば、カードコンポーネントを作って、カードのタイトルが長い場合や、もしくは極端に短い場合、タイトルが不明な場合などには、カードコンポーネントの見た目は崩れないか、簡単にテストすることができます。
Storybookの大まかなワークフロー
Storybookでは、一つのコンポーネントに対していくつかストーリーを書いていきます。この‘stories’ が、テストケースとなります。
例えば、カードコンポーネントの‘stories’ （テストケース）は、
- デフォルト
- 長いカードタイトル
- 長いカードのデスクリプション
などが、考えられます。２の例でいえば、長いタイトルがコンポーネントに渡ってきたときに、UIが壊れないか視覚的に確認すると言う意味です。
ここでよくある質問に？「毎回すべてstories（テストケース）をクリックして確認しないといけないの？」というのがあります。コンポーネントの数が少ないときは、まだましですが、これが、50とか100になるとUIの変更ごとにすべてのUIのテストケースを確認するのは現実的ではありません。ではどうするか？
Storyshots addon を追加することで、この問題は解決します。詳細は以下で解説します。
StorybookできるUIのテスト
StorybookにはUIコンポーネントをテストする方法が、いくつかあります。
- マニュアルテスト：コンポーネントをStorybookに追加し、stories（テストケース）を書いていきながら、開発者が実際に目で、UIの見た目を確認する。
- Snapshot テスト：コンポーネントをレンダーした出力結果であるマークアップをキャプチャーし、その差分を確認する。詳細は以下で解説。
Snapshot テストとは？
Jestを使ったことがある人はイメージ出来ると思いますが、Snapshotテストは、コードの変更箇所をハイライトすることで、確認するべきコードを抽出してくれるツールです。リグレッションを回避してくれます。言い換えると、想定していないコンポーネントに変更が加えられていないか、簡単にチェックできます。
たまに、何をやっているのか理解しておらず、スナップショットの変更を確認しないで開発を進めているエンジニアもいるので、ここで説明しておきます。
ワークフローとして、
- UI第一号を追加する。コードのアウトプットがスナップショット（保存）にされる。ここでは、新しく追加したコンポーネントについては、‘stories’ （テストケース）をクリックしてそれぞれ確認する。（目で見て確認する）
- 既存のUIの一部に変更を加えると、以前のスナップショットと、今回のスナップショットに違いが生じる。ここでテストはFailすべき。無事にFailしたらその変更箇所のみ確認し、自分が意図した変更となっているか確認する。OKであれば、スナップショットを新しいモノに更新します(press `u` to updateとCLIに表示される)。こうすることで、これまで追加してきたすべての‘stories’ （テストケース）を確認する必要がなくなります。
Snapshot テストを使う際の注意
コンポーネントに渡すサンプルデータは、毎回同じモノにする
コンポーネントに渡るデータに変更があれば当然Snapshotテストはフェイルします。つまり、毎回確認するべきスナップショットの差分が無駄に増えます。コンポーネントに渡すサンプルデータに、Dateとか、Math.random()とか、含めないように注意してください。
チーム内でSnapshotテストの運用方法を浸透させる
先ほど述べたように、UIに変更したらスナップショットは、まずFailすべきです。そして、スナップショットの差分を確認し、OKであれば、スナップショットを更新するというプロセスが正解です。が、ついつい差分を確認しないまま、スナップショットを更新して、終わりというケースがあるようです。これだといつの間に、UIが壊れてしまいます。これが積み重なることで、メンテナンス不可能な状態へと陥ります。この問題を避けるためには、まずチーム内でSnapshotテストの運用方法を浸透させることが一番でしょう。
Storybookでどうしてもコンテイナーをレンダーしないといけない時
基本的には、見た目を担当するコンポーネントをStorybookに追加するべきですが、どうしてもコンテイナーをレンダーする必要があるケースというのがあります。
例えば、あるコンポーネントのチャイルドコンポーネントにコンテイナーが含まれているようなケースです。コンテイナーには、よく何かのcontextがパスされていたり、サービスとコネクトされていたりします。例えば、Redux Store とか、Apollo Client などです。当然ながらStorybookからこれらにアクセスできないので、モックする必要があります。React、Apollo、Relayなど主要なライブラリーについてモックする方法が用意されていますので、問題ありません。
Storybookをデプロイしてチーム内で共有も可能
yarn build-storybook というコマンドが用意されているので、それを実行すると、Storybook-staticフォルダにビルドされたものが格納されます。そのフォルダをデプロイするだけです。僕は、https://www.netlify.com/ をよく使います。これで、チーム内での共有も楽です。適当なドメインでよければ、無料で利用可能です。
Storybookをスタイルガイドとして活用することも可能
オフィシャルアドオンのDocsを使用することにより、Storybookをスタイルガイドとして活用することも可能です。これは、エンジニア不足だったり、UIUXデザイナーを雇う余裕のないスタートアップなどには役立つ機能だと思います。
豊富なAddonsがあるので、欲しい機能を追加できる
アドオンを追加することで、Storybookの機能を拡張することができます。先ほどのDocsもそうですが、web accessibility のバリデーションを追加するものや、様々なスクリーンサイズでUIのレスポンシブネスをテストするためのアドオンなどがあります。
詳細は、Storybookオフィシャルアドオンのリストで確認してください。全て追加しないといけないという物ではなく、プロジェクトに必要な物だけ追加すれば良いでしょう。
Storybookを使うときの課題
スタートアップなどの小さめの組織、開発スピード重視される組織においては、いつの間に誰もメンテナンスしなくなり、放置されるケースというのがあるようです。と言うのも、例えばデザイナーがいなくて、フロントエンドエンジニアも一人だけというようなチームだと、UIを気にするのがStorybookを構築している本人のみになってしまいます。セッかく構築したのに、誰も使っていない状態です。笑
放置されるのは悲しいですが、それでも開発の初期段階では、UI開発の面において大いに役立つはずなので、Storybookを採用する価値はあると思います。
Storybookをセットアップするのは比較的イージーですが、鍵となるのは、Storybookを導入し、チームのメンバーに浸透させ、情熱を保ちながらメンテナンスを続けることができるフロントエンドエンジニアの仕事力にあると、僕は思います。
