今回は、学生時代に開発に活用していた 「Storybook」というフロントエンドワークショップを紹介したいと思います。
Storybookとは
React, Vue.js, Svelteなどのモダンフロントエンド開発における、 UIコンポーネントとページを個別に構築するためのフロントエンドワークショップです。
そもそもフロントエンドワークショップという言葉を聞いたことがない人もいるかもしれません。
フロントエンドワークショップとは、UIコンポーネントごとにアプリを起動
しなくても、一目で実行結果（個別のページ全体）を確認できるプラットフォームです。
設計デザインツールで「Figma」や「CodeSandbox」というようなサービス を使ったことがある人はイメージがつきやすいかもしれません。
一言で表すとUIカタログを作成できるツールです。 コンポーネント指向によるフロントエンド開発が人気な昨今、このUIカタログは このフロントエンド開発にとって大きなメリットを与えてくれます。
以下に個人的に考える大きなメリットを4項目挙げてみました。
このプロジェクトでは、MITライセンスの下で提供されているライブラリを使用しています。 具体的には、Storybookを使用してUIカタログのテストを行っています。
© 2024 Storybook
受けることができる具体的なメリット
- コンポーネント単位でUI上での挙動を確認することができる
- コンポーネントとページを分離して、ユースケースを検証できる
- コンポーネントやその状態を簡単にドキュメント化できる
- デザイナーがエンジニアにとって工数の低いデザインを作成しやすい
では１項目ずつメリットを深堀していきます。
コンポーネント単位でUI上での挙動を確認することができる
Storybookでは、UIコンポーネントを単体で表示することができます。 以下の画像では、表示されているボタンコンポーネントを単体で表示してくれています。
このようにStorybook上でコンポーネントを表示させるためには、storiesファイルという ファイルを別途作成する必要があります。このようにコンポーネント単体で動作を確認 しながら実装を行うことで、アプリケーションに組み込みながら実装した場合と 比較すると、意図しない依存関係が生まれてしまうことを防ぐことができます。 その結果、使い回しのしやすいコンポーネントの実装が可能になります。
コンポーネントとページを分離して、ユースケースを検証できる
モダンフロントエンドフレームワーク、またはライブラリにおけるコンポーネントは、 propsやstateなどと呼ばれる、呼び出し側からデータを受け取る機能を持ちます。 この受け取るデータによって、UIコンポーネントの状態や振る舞いを変化させることができます。
| props名 | 説明 |
|---|---|
| primary | このpropsはbooleanを受け取り、trueの時は白文字でボーダーなしのボタン、falseの時は黒文字でボーダーつきのボタンとして表示される |
| label | このpropsに渡した文字列がボタンのラベルとして表示される |
| backgroundColor | このpropsはカラーコード(文字列)を受け取り、その色をボタンの色とする |
| size | このpropsは'small'、'medium'、'large'のいずれかのテキストを受け取り、ボタンのサイズがそれに合わせて変化する |
たった4つのpropsをもつ単純なコンポーネントですが、propsに渡すデータの組み合わせは 無数に存在します。 このボタンのUIを目で見て確認したい時、Storybookを導入していれば、 あらゆる組み合わせを簡単に検証できます。
Storybookには、controlsという機能があり、適切にstoriesファイルを作成することで 以下のようなタブが表示されます。 このタブの中でpropsに渡す値を好き勝手にいじることが でき、基本的には即座にpreviewに反映されます。
コンポーネントやその状態を簡単にドキュメント化することができる
デザイナーの方が在籍されているチームでは、デザイナーの方同士でデザインを共有して コンポーネントを作成していると思います。そのデザインの状態が、フロントエンドで 開発されたコンポーネントとデザイナーの意志に相違がないか確かめるために、 コミュニケーションコストが増えてしまいます。相手が忙しい場合のこと等を考えると、 なるべくコミュニケーションコストを減らした方がいい場合もあります。
そこで、Storybookを活用して、以下の画像のように、コンポーネントやその状態を ドキュメント化して共有することにより、アプリケーションを操作して該当の画面に 遷移する等の操作なく、コンポーネントを確認してもらうことが可能になります。 これによって、相談によるコミュニケーションコストを大幅に削減できることが 期待できます。
また、静的サイトとしてデプロイすることが可能なので、クラウドを活用すれば いつでも誰でも確認できます。
デザイナーがエンジニアにとって工数の低いデザインを作成しやすい
Storybookは、プログラミングコードを触ることのできない非エンジニアであっても、 操作性のあるUIであるため、視覚的に本質を理解することができます。
したがって、プログラミングコードを触れないデザイナーさんであったとしても、 デザインを考える際に、既存コンポーネントのpropsに渡す値を変えるだけで 実現できるデザインであれば少ないコストで実装することができるわけです。
このようにStorybookにはメリットがたくさん存在し、とても便利かと思われます。 しかし何事にもデメリットは付き物です。 もちろんStorybookにもデメリットはありますが、どんなデメリットがあるか 紹介していこうと思います。
Storybookのデメリット
ファイルの管理が大変である
Storybookのデメリットの最大のポイントがこれです。 Storybookを使うためにはコンポーネントごとに .stories.jsxという形式でstoriesファイルを作成する必要があって、 さらにここにstoriesを定義する必要があります。
コンポーネントに修正が入った場合、storiesも修正しないといけない かもしれないので、忙しすぎてStorybookまで手が回らなかった場合に、 どんどんレガシー化することを避けることができません。
既存システムへの導入が大変である
もし今からコンポーネントライブラリを0から作成し、Storybookも一緒に 導入する、とあれば良いのですが、既に存在しているプロジェクトに導入 しようとしており、自分でテンプレートのようなパターンを決定していく 場合は、存在するコンポーネントファイル全て自分でコードを書いていく 必要があります。
その労力はプロジェクトの規模にもよりますが、とても図り切れません。
まとめ
このようなメリット、デメリットが存在する中で活用していくかは個人の 判断になるので、しっかり技術の取捨選択をしていくことが大切だと思います。
このようなモダンなフレームワークを学んでいくと、フロントエンド開発を より楽しく効率的に学べるのではないのでしょうか。
