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

Transcript

1. 背伸びしないコンポーネントの始め方 @yuneco
2. 自己紹介 Yuki Matsumoto @yuneco i 株式会社ICSのフロントエンドエンジニh i お絵描きしたりちょっとしたゲーム作った# i お仕事ではVueとかReactとかも書きます 株式会社ICSってどんな会社？ i 演出やインタラクションの得意なWeb制作の会社でi i TypeScript + Vue / Reactでアプリ寄りの開発もやりまi i で技術記事書いてます https://ics.media/
3. コンポーネント設計の「コスパ」は作るものによる LP イベント・特設サイト コーポレートサイト ブログ・SNS inBシステム サービス・アプリ メディアサイト 一般的にコンポーネント設計の元が取りやすいのは 長期にわたって・大勢で・継続的に機能の追加や改修を行うプロダクト 今日は「コスパの悪い」Web制作寄りの人として、
 コンポーネント「設計」よりも手前の話をします
4. Web制作寄りのコンポーネントあるある Web制作ではデザインカンプが設計の拠り所 ①まず、画面ごとにページコンポーネントを作る TopPage / AboutPage / ContactPage ... Card / Modal / Button / Header ... ※ 静的な比率の高いWebサイトの場合コンポーネント設計よりも
 CSS設計が中心になりますが、今回CSSの話は割愛します ②末端のパーツから共通コンポーネントを見つける
5. Web制作寄りのコンポーネントあるある 中間はカオス もしくはそもそも 作られない 共通コンポーネント ※ 神コンポーネント：なんでもできるように大量のフラグや条件分岐を持つ、人智を超えた巨大コンポーネント 様々なバリエーションに
 応えるため
 神コンポーネント化 ページコンポーネント ロジックもレイアウトも
 全部突っ込んで 神コンポーネント化
6. Atomic Designは夢の設計手法か？ D Atomic Designはこの混沌に秩序を与えてくれそうな「気がする# D 現実はそんなに甘くない propsが20個ある 神atom 結局中間が難しい 「これはMかOか？」みたいな辛い議論 https://atomicdesign.bradfrost.com/chapter-2/ 分割・整理されないまま
 肥大化するページ
7. Atomic Designは夢の設計手法か？ i 「わかりやすい」型が与えられた結果、見た目の型に縛られるだけになりがR i 目に見えないロジックや状態、その裏の責任分割までは決めてくれなe i 決して悪い方法ではない…はず。でもみんな結構苦労している https://zenn.dev/dove/articles/e940fa7e8b860d https://zenn.dev/sterashima78/articles/0cf4bb52112c7b Reactでアトミックデザインやめた話 Atomic Design はなぜ難しいか？どうやって難しさを解消するか
8. そもそもなぜコンポーネントにしたいのか？ コンポーネント化の（よく言われる）メリット 再利用できる 共通化できる 拡張性が上がる 保守性が上がる まずは「理解しやすく保守できるコードにする」ことだけ考える このあたりは本当に難しいし、コスパが悪い
9. 「理解しやすく保守できる」良いコンポーネントとは A 大きすぎなP A 名前でやっていることがわかE A 一つのことだけうまくやる
10. ÇÅ 大きすぎない & 誰でもわかる・数えられる。コストも手間もかからな0 & 長いコードは大体誰でも読みたくないし、触りたくない & Reactなら1ファイル100行くらいまで。150超えてきたら危s & Vueの場合は構造上もう少し（+2,3割）大きめになる傾X & コンポーネントにはテンプレート（JSX, <template>）やスタイルも含めY & コンポーネント内の関数ひとつひとつも20行くらいまでにしたい 行数は絶対ではないが、目安としてはとても優秀 目安は？
11. ÇÅ 大きすぎない 40行 120行 240行
12. 2. 名前でやっていることがわかる )' 一つのことだけうまくやる … Area, Layout, View → 本当にエリアやレイアウトだけ` … Manager, Controller → 実際これ何やってるの` … （Fooコンポーネントに対する）useFooフック → ロジック部分切り出しただけ？ 抽象度の高い「ふんわりワード」が出てきたら疑う 入出力（引数・props・戻り値）が増えてきたら疑う 正しい名前にリネームできないならコンポーネントに機能を足してはいけない
13. おかしいと思ったら？ W 設計自体の見直しが必要なこともあるので、本来は「とりあえず」は良くな% W でも分割しないよりは圧倒的にマ5 W 本当にマズい時は分割しようとしてもうまく出来ない W 責務や関心に合わせて分割す” W 本質ではないロジックを切り出す...なy W 記事も書いてます とりあえず分割する どうやって？ https://ics.media/entry/210929/
14. コンポーネント分割の障壁をいかに下げるか？ 5( 分割して壊れないことを保証する x TypeScriptやESLintのルールでできる限り静的にチェックすu x もちろんテストがあると尚良い
15. コンポーネント分割の障壁をいかに下げるか？ DC 必要なものはできるだけまとめておく（＝コロケーション） † コンポーネントの構成要素が離れていると分割のハードルが一気に上が‹ † 別ディレクトリ(components/, styles/, hooks/ ...)よりも機能ごとの1ディレクト“ † 1ディレクトリの別ファイルよりも1ファイ˜ † VueならSFC。Composition APIになっているとさらに良€ † ReactならスタイルをTailwindやCSS in JSでコンポーネント内に置くのも良い
16. コンポーネント分割の障壁をいかに下げるか？ m このボタンを<CounterButton>として切り出し たければ、単にこの部分をカット＆ペーストで別 ファイルにすればOP m 関連するstate等がTSのエラーになるので、合わ せて移動するかpropsで渡すか、自由に決めれば 良™ m 基本的にTypeScriptのエラーの通りに修正すれ ば、この変更でアプリが壊れることはない コロケーションされていると分割が楽な例：React + CSS in JS(Kuma UI)の場合
17. コンポーネント分割の障壁をいかに下げるか？ 9& いつでも自由に分割できる環境とマインドをもつ ‚ コード差分が多く出ることを怖がらなˆ ‚ コンポーネントを分割するよりpropsを足してifで分岐する方が差分自体は少なˆ ‚ 将来理解・保守しやすいのはどっち？
18. まとめ i コンポーネント設計はプロダクトにあわせて無理なく考えよ0 i 高度な設計や仕組みよりも、まずは「小さく保守しやすい」コンポーネントを目指 i コンポーネント分割のハードルを如何に下げられるかがポイント