はじめに
みなさんはStorybookを導入しているでしょうか？
僕の場合は、あまりスタイルをいじらないので、ずっとその恩恵がわからなかった。というのがあります。
ただ、チームで導入していいなと思うことがいくつかあったので今回記事にしようと思いました。
Storybookとは？
色々なことができてしまうので、定義が難しいのですが、
- UI（コンポーネント）作成
- テスト
- ドキュメント作成
みたいなことができるツールです。
何がいいの？
1. UIの検証・構築をアプリケーションを介さずにできる
UIの検証・構築がアプリケーションを立ち上げることなくできます。
Controlsという項目でコンポーネントとパラメータを変更することができます。
以下のようにargsを定義しておくことで実現可能です。
import { Button } from './Button';
export default {
/* 👇 The title prop is optional.
* See https://storybook.js.org/docs/react/configure/overview#configure-story-loading
* to learn how to generate automatic titles
*/
title: 'Button',
component: Button,
};
const Template = (args) => ({
//👇 Your template goes here
});
export const Primary = Template.bind({});
Primary.args = {
variant: 'primary',
};
export const Primary = {
args: {
variant: 'primary',
},
};
構文も簡単ですし、コンポーネント側で型をきちんと書いておけば推論もしてくれるので作るのも苦になりません。
2. デザイナーとの意思疎通ができる
デザイナーから他のUIと統一感のないコンポーネントがFigmaやXDでもらうことがしばしばあるかと思います。
特に
- ユーザーのITリテラシーが高くないサイト
- 日常的に使うサービスではなく、使い方がわからないサイト
などの場合、ある程度機能のオンボーディングが必要となったりして、その場その場で強調したいコンテンツなどが変わり、デザインの統一がしづらかったりします。
ただ、統一感のないデザインは逆にユーザーのことを惑わせたりもします。
なので、これは共通化すべきだ、これは共通化しなくてもいい。
というのは実装を行うエンジニアとデザイナーがコミュニケーションをとりつつやる必要があります。
Figmaなどで共通認識をとる方法もありますが、Storybookもおすすめです。
なぜなら、コンポーネント名や引数名を共通言語とすることができるからです。
共通言語があるというのはコミュニケーションにおいてとても大切です。スムーズに物事が伝わります。
3. テストが行える
コンポーネント変更により意図しない変更が入っていないか？UIが崩れていないかを検証するんですね。
ビジュアルリグレッションテスト
僕たちのチームでは、ビジュアルリグレッションテストを行っています。
CI上で前回のmainブランチとの差分を検知し、変わったコンポーネントを表示します。
インタラクションテスト
これは僕たちのチームではできていないですが、インタラクションテストも実現可能です。
ワークフローを書き、実際にユーザーがアクションを起こした場合どういう挙動をするのかテストすることができます。
ミニE2Eのようなものかなと思います。
小さな単位でこの検証ができるのはとても良いですよね。
まとめ
Storybookについて紹介してみました。
デザイナーとの共通認識を取ったり、現状のシステムに組み込むのも少し難しいので、導入コストが少し高いですが、うまく運用していけるとかなり強力な武器になってくれるのでぜひ使ってみてください。