Storybookを用いた開発の流れは、どういった流れが一般的でしょうか。

Question

前提

Reactを使っています。
いくつかのコンポーネントができてから、Storybookを導入しました。

下記のコードで、Storybookのリストに載せることができました。

DemoComponent.stories.tsx

import React from "react";
import DemoComponent from "./DemoComponent";

export default {
  title: "DemoComponent",
  component: DemoComponent
};

export const Demo = () => <DemoComponent />;

---

上記の使い方だとコンポーネントが丸々とStorybookに載ります。
しかし、Stroybookが用意しているデモでは、コンポーネントというよりはボタン一つだけを載せています。

上記のやり方だと例えばDemoComponentに含まれているボタンだけをStroybookに載せる場合、DemoComponentからボタンだけを別のコンポーネントにして切り分ける必要があります。

疑問

ここで疑問に思ったのですが、どのような流れの開発をStorybookは想定しているのでしょうか。
現状の私の書き出し方だと、ボタン一つをStroybookにあげるためにコンポーネントを切り分けるのはバカバカしいなと思います。

「stroybook 流れ」「stroybook 業務」などで検索しましたが、答えは見つけられませんでした。

教えていただきたいこと

• Storybookを使う場合は、Storybookに合わせてコンポーネントを切り分けるのが一般的だ
• 細かなパーツは切り分けなくてもコンポーネントから抽出して載せることができる

など、Stroybookを絡めた開発における、開発の流れならびに考え方や方法論などをご教示いただきたいです。

Answer 1

「Storybookを使うのならコンポーネントはこの粒度で作らないといけない」という基準は聞いたことがないですし、制約もありません。なので、現状あるコンポーネントをそのままStorybookに載せられたら良いと思います。強いて言えば、コンポーネント設計として広く知られているものとして、Atomic Designがありますが、Storybookに限ったものではないですし、必ずしもそれに従う必要はないですが参考にはなると思います。(例えば、ButtonはAtomic Designで言うところのAtomsに分類されます)

付け加えると、Storybookに限らずですが、コンポーネントを小さく作っていくと再利用可能になったり複雑性が軽減されるので保守しやすくなる(やりすぎは厳禁ですが)というメリットもあります。また、Storybookは要するにコンポーネントの見た目や振る舞いを確認するツールなわけですが、コンポーネントの粒度が大きいと確認するべき項目がわかりづらくなる、確認する項目の漏れが出てくる、propsが巨大なのでStorybookの保守が大変になるというデメリットもあるということは一般的には言えると思います。