背伸びしないコンポーネントの始め方

Transcript

1. 背伸びしないコンポーネントの始め方
   @yuneco
   

   View Slide

2. 自己紹介
   Yuki Matsumoto @yuneco
   i 株式会社ICSのフロントエンドエンジニh
   i お絵描きしたりちょっとしたゲーム作った#
   i お仕事ではVueとかReactとかも書きます
   株式会社ICSってどんな会社？
   i 演出やインタラクションの得意なWeb制作の会社でi
   i TypeScript + Vue / Reactでアプリ寄りの開発もやりまi
   i で技術記事書いてます
   https://ics.media/
   

   View Slide

3. コンポーネント設計の「コスパ」は作るものによる
   LP
   イベント・特設サイト
   コーポレートサイト ブログ・SNS inBシステム
   サービス・アプリ
   メディアサイト
   一般的にコンポーネント設計の元が取りやすいのは
   長期にわたって・大勢で・継続的に機能の追加や改修を行うプロダクト
   今日は「コスパの悪い」Web制作寄りの人として、

   コンポーネント「設計」よりも手前の話をします
   

   View Slide

4. Web制作寄りのコンポーネントあるある
   Web制作ではデザインカンプが設計の拠り所
   ①まず、画面ごとにページコンポーネントを作る
   TopPage / AboutPage / ContactPage ...
   Card / Modal / Button / Header ...
   ※ 静的な比率の高いWebサイトの場合コンポーネント設計よりも

   CSS設計が中心になりますが、今回CSSの話は割愛します
   ②末端のパーツから共通コンポーネントを見つける
   

   View Slide

5. Web制作寄りのコンポーネントあるある
   中間はカオス
   
   もしくはそもそも
   
   作られない
   共通コンポーネント
   ※ 神コンポーネント：なんでもできるように大量のフラグや条件分岐を持つ、人智を超えた巨大コンポーネント
   様々なバリエーションに

   応えるため

   神コンポーネント化
   ページコンポーネント
   ロジックもレイアウトも

   全部突っ込んで
   
   神コンポーネント化
   

   View Slide

6. Atomic Designは夢の設計手法か？
   D Atomic Designはこの混沌に秩序を与えてくれそうな「気がする#
   D 現実はそんなに甘くない
   propsが20個ある
   神atom
   結局中間が難しい
   「これはMかOか？」みたいな辛い議論
   https://atomicdesign.bradfrost.com/chapter-2/
   分割・整理されないまま

   肥大化するページ
   

   View Slide

7. Atomic Designは夢の設計手法か？
   i 「わかりやすい」型が与えられた結果、見た目の型に縛られるだけになりがR
   i 目に見えないロジックや状態、その裏の責任分割までは決めてくれなe
   i 決して悪い方法ではない…はず。でもみんな結構苦労している
   https://zenn.dev/dove/articles/e940fa7e8b860d
   https://zenn.dev/sterashima78/articles/0cf4bb52112c7b
   Reactでアトミックデザインやめた話
   Atomic Design はなぜ難しいか？どうやって難しさを解消するか
   

   View Slide

8. そもそもなぜコンポーネントにしたいのか？
   コンポーネント化の（よく言われる）メリット
   再利用できる 共通化できる 拡張性が上がる 保守性が上がる
   まずは「理解しやすく保守できるコードにする」ことだけ考える
   このあたりは本当に難しいし、コスパが悪い
   

   View Slide

9. 「理解しやすく保守できる」良いコンポーネントとは
   A 大きすぎなP
   A 名前でやっていることがわかE
   A 一つのことだけうまくやる
   

   View Slide

10. ÇÅ 大きすぎない
    & 誰でもわかる・数えられる。コストも手間もかからな0
    & 長いコードは大体誰でも読みたくないし、触りたくない
    & Reactなら1ファイル100行くらいまで。150超えてきたら危s
    & Vueの場合は構造上もう少し（+2,3割）大きめになる傾X
    & コンポーネントにはテンプレート（JSX, ）やスタイルも含めY
    & コンポーネント内の関数ひとつひとつも20行くらいまでにしたい
    行数は絶対ではないが、目安としてはとても優秀
    目安は？
    

    View Slide

11. ÇÅ 大きすぎない
    40行 120行 240行
    

    View Slide

12. 2. 名前でやっていることがわかる
    )' 一つのことだけうまくやる
    … Area, Layout, View → 本当にエリアやレイアウトだけ`
    … Manager, Controller → 実際これ何やってるの`
    … （Fooコンポーネントに対する）useFooフック → ロジック部分切り出しただけ？
    抽象度の高い「ふんわりワード」が出てきたら疑う
    入出力（引数・props・戻り値）が増えてきたら疑う
    正しい名前にリネームできないならコンポーネントに機能を足してはいけない
    

    View Slide

13. おかしいと思ったら？
    W 設計自体の見直しが必要なこともあるので、本来は「とりあえず」は良くな%
    W でも分割しないよりは圧倒的にマ5
    W 本当にマズい時は分割しようとしてもうまく出来ない
    W 責務や関心に合わせて分割す”
    W 本質ではないロジックを切り出す...なy
    W 記事も書いてます
    とりあえず分割する
    どうやって？
    https://ics.media/entry/210929/
    

    View Slide

14. コンポーネント分割の障壁をいかに下げるか？
    5( 分割して壊れないことを保証する
    x TypeScriptやESLintのルールでできる限り静的にチェックすu
    x もちろんテストがあると尚良い
    

    View Slide

15. コンポーネント分割の障壁をいかに下げるか？
    DC 必要なものはできるだけまとめておく（＝コロケーション）
    † コンポーネントの構成要素が離れていると分割のハードルが一気に上が‹
    † 別ディレクトリ(components/, styles/, hooks/ ...)よりも機能ごとの1ディレクト“
    † 1ディレクトリの別ファイルよりも1ファイ˜
    † VueならSFC。Composition APIになっているとさらに良€
    † ReactならスタイルをTailwindやCSS in JSでコンポーネント内に置くのも良い
    

    View Slide

16. コンポーネント分割の障壁をいかに下げるか？
    m このボタンをとして切り出し
    たければ、単にこの部分をカット＆ペーストで別
    ファイルにすればOP
    m 関連するstate等がTSのエラーになるので、合わ
    せて移動するかpropsで渡すか、自由に決めれば
    良™
    m 基本的にTypeScriptのエラーの通りに修正すれ
    ば、この変更でアプリが壊れることはない
    コロケーションされていると分割が楽な例：React + CSS in JS(Kuma UI)の場合
    

    View Slide

17. コンポーネント分割の障壁をいかに下げるか？
    9& いつでも自由に分割できる環境とマインドをもつ
    ‚ コード差分が多く出ることを怖がらなˆ
    ‚ コンポーネントを分割するよりpropsを足してifで分岐する方が差分自体は少なˆ
    ‚ 将来理解・保守しやすいのはどっち？
    

    View Slide

18. まとめ
    i コンポーネント設計はプロダクトにあわせて無理なく考えよ0
    i 高度な設計や仕組みよりも、まずは「小さく保守しやすい」コンポーネントを目指
    i コンポーネント分割のハードルを如何に下げられるかがポイント
    

    View Slide