はじめに
こんにちは、@zomysan です。Storybookの代替として評判のLadleを触ってみたので簡単な記事にまとめます。
Ladle の UI はざっくりこんな感じ。右側に並んでいるのはコンポーネントの一覧です。見た目はスッキリしており、動作も軽いです。
この記事について
対象読者
- フロントエンドエンジニア
- Storybook を使っているが、Ladle が気になっている人
- コンポーネントカタログを使ってみたい人
書いてあること
- プロジェクトへの Ladle の導入手順
- React を使ったフロントエンドアプリケーションで Ladle を使ってみた感想
書いていないこと
- コンポーネントカタログの意義
- 詰まったこととその解決策は別記事を参照
コンポーネントカタログっていいよね
ふだん業務においてコンポーネントカタログとして Storybook を使っています。Storybookのおかげでサーバーからのレスポンスやユーザー操作を再現しなくても、いつでも任意のコンポーネントの状態を確認でき、開発がスムーズになっています。
Storybookの活用状況については以下の記事でも紹介しているので、「そもそもコンポーネントカタログって何？」という方はこちらもどうぞ。
なんで Ladle？
プロジェクトの規模のせいもありますが、Storybook については若干立ち上がり速度やリロードまでの時間について課題感があります。個人開発プロダクトにコンポーネントカタログが必要になってきたので、今回は昨今人気の Ladle を導入してみました。
Storybook の代替ツール候補については ChatGPT の Deep Research に調査いただき、これを大いに参考にさせてもらいました。調査結果のリンクも載せておきます。（公開の予定がなかったのでちょっと言葉が雑ですみません）
Ladle を導入して使ってみる
インストール
詳細なセットアップ手順はここでは省きますが、カタログの起動まではとても簡単です。
詳細を知りたい方は以下の公式ドキュメントをごらんください。
pnpm add @ladle/react
でインストールして、
pnpm ladle serve
何も Story はないので当然空っぽですが、これだけでとりあえずカタログが立ち上がります！設定ファイルなどが一切なくても大丈夫です。
Story の作成
基本的なStory
Story を作成するには、Storybookと同じで *.stories.tsx というファイルを追加し、その中から Story として表示したいコンポーネントを export するだけです。
import Page from './sct.page';
export const Default = () => <Page />;
export const ViewOnly = () => <Page viewOnly={true} />;
これで先ほど立ち上げたLadleのサービスにStoryが表示されます。プロバイダやモックが必要ない単純なStoryであれば、この時点でも引き続き設定ファイルなどは不要です。
カスタマイズ
Storyのタイトルや表示幅などをカスタマイズすることも可能です。
Provider の設定
Ladleは components.tsx というファイルから export した Provider というコンポーネントを自動でグローバルなプロバイダとして適用してくれます。
// Next Router 用のプロバイダ例
export const NextRouterProvider = ({ children }) => {
return (
<RouterContext.Provider
...
>
{children}
</RouterContext.Provider>
);
};
// MUI の theme 用のプロバイダ例
export const MuiThemeProvider = ({ children }) => {
return (
<ThemeProvider
...
>
{children}
</ThemeProvider>
);
};
// すべてのProviderをまとめたProvider
// 自動でこの Provider が適用される
export const Provider: GlobalProvider = ({ children }) => {
return (
<NextRouterProvider>
<MuiThemeProvider>
{children}
</MuiThemeProvider>
</NextRouterProvider>
);
};
MSW のセットアップ
MSWとは
MSW（Mock Service Worker）は、モックサーバーなどを作成しなくても本番と同じAPIのやりとりを再現できるライブラリです。
Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.
コンポーネントカタログにおけるMSW
コンポーネントによっては、そのコンポーネント自身が API リクエストを行い、そのレスポンス次第で自らの表示方法や状態を動的に変えることもあります。そのようなさまざまな状態を MSW と Ladle を組み合わせることによってカバーできます。
例えば、マイページでは以下のようなパターンが考えられます。
- ログアウト中、会員登録前（登録を促す表示）
- ログイン中、フリープラン（会員ステータスの表示）
- ログイン中、有料プラン加入中（会員ステータス＋有料専用メニュー表示）
これらの状態を実際の操作で再現して動作確認するとなると大変ですが、コンポーネントカタログでひとめで確認できたら便利ですよね。
補足: Container/Presentational パターンで実装している場合は MSW 不要
プロジェクトによっては、MSWが不要な場合もあります。
Container/Presentational パターンのように完全にAPIリクエストなどのロジックとビューのコードが分離されているかもしれません。
その場合、Presentational Component に対しての Story を用意すればモックを用意することなく動作確認ができます。
APIモックを使ったStoryの実例
使ってみた感想
コンポーネントを表示するだけの用途としては全く問題なかった。
よかったこと
- とにかく起動・リロードが早い
- 特に何も設定しない状態から徐々に設定を追加していくのがよかった
- 設定、Storyの書き方が単純明快
イマイチだったこと
- Storybook のようにディレクトリ階層を自動で反映してくれない
- AI エージェントに依頼してディレクトリ階層を Title に反映するようにしている
- あくまで暫定対応で、ファイル移動などしたときに反映されないのでどうするか悩むところ
- ファイルが増えたときに ladle コマンドの再起動が必要
- msw のハンドラが独自の Ladle 用
mswをインポートする必要があり、他ツールとの統合が一筋縄ではいかない - たまに hot-reload が効いたり効かなかったりする
- 条件はあるんだろうがよくわかっていない
- Storybookに比べ、Ladleについての情報はWeb上に少ない
おわりに
この先やりたいこと
- Playwright との連携
- VRT導入
まとめ
早い、軽い、設定が大変じゃない、という3点で大満足です。あまりボリュームが大きくないプロジェクトで、とりあえずコンポーネントカタログを導入したい、という場合ならとりあえず使ってみてもいいのではないかと思います。
「イマイチだったこと」のボリュームがもりもりになってしまいましたが、ネガティブな気持ちが大きいというより、期待がこもってのことと受け取っていただければ 🙏
今回は個人開発プロダクトのコンポーネントカタログとして Ladle を導入してみました。以前導入していたStorybookと比べて簡単にセットアップできたので、今後 MSW との連携など細かいところを試していきたいと思います。
Discussion