Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
背伸びしないコンポーネントの始め方
Search
yuki
October 03, 2023
Technology
7
3.5k
背伸びしないコンポーネントの始め方
yuki
October 03, 2023
Tweet
Share
More Decks by yuki
See All by yuki
ビジュアル表現のためのCSS & SVG & JavaScriptの最新事情
yuneco
3
1.3k
xojoでコールバックとかスレッドとかアニメーションとかを ゆるーく使える 「Nekonote」 のおはなし
yuneco
0
640
Other Decks in Technology
See All in Technology
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
1
1.1k
株式会社EventHub・エンジニア採用資料
eventhub
0
4.2k
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
130
High Performance PHP
cmuench
0
140
第13回 Data-Centric AI勉強会, 画像認識におけるData-centric AI
ksaito_osx
0
360
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
7
1k
2.5Dモデルのすべて
yu4u
2
610
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
450
Developer Summit 2025 [14-D-1] Yuki Hattori
yuhattor
19
5.1k
プロセス改善による品質向上事例
tomasagi
1
1.6k
君はPostScriptなウィンドウシステム 「NeWS」をご存知か?/sunnews
koyhoge
0
720
Tech Blogを書きやすい環境づくり
lycorptech_jp
PRO
0
120
Featured
See All Featured
A Tale of Four Properties
chriscoyier
158
23k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
Building Applications with DynamoDB
mza
93
6.2k
4 Signs Your Business is Dying
shpigford
182
22k
How to train your dragon (web standard)
notwaldorf
90
5.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Typedesign – Prime Four
hannesfritz
40
2.5k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Docker and Python
trallard
44
3.3k
How to Ace a Technical Interview
jacobian
276
23k
Transcript
背伸びしないコンポーネントの始め方 @yuneco
自己紹介 Yuki Matsumoto @yuneco i 株式会社ICSのフロントエンドエンジニh i お絵描きしたりちょっとしたゲーム作った# i お仕事ではVueとかReactとかも書きます
株式会社ICSってどんな会社? i 演出やインタラクションの得意なWeb制作の会社でi i TypeScript + Vue / Reactでアプリ寄りの開発もやりまi i で技術記事書いてます https://ics.media/
コンポーネント設計の「コスパ」は作るものによる LP イベント・特設サイト コーポレートサイト ブログ・SNS inBシステム サービス・アプリ メディアサイト 一般的にコンポーネント設計の元が取りやすいのは 長期にわたって・大勢で・継続的に機能の追加や改修を行うプロダクト
今日は「コスパの悪い」Web制作寄りの人として、 コンポーネント「設計」よりも手前の話をします
Web制作寄りのコンポーネントあるある Web制作ではデザインカンプが設計の拠り所 ①まず、画面ごとにページコンポーネントを作る TopPage / AboutPage / ContactPage ... Card
/ Modal / Button / Header ... ※ 静的な比率の高いWebサイトの場合コンポーネント設計よりも CSS設計が中心になりますが、今回CSSの話は割愛します ②末端のパーツから共通コンポーネントを見つける
Web制作寄りのコンポーネントあるある 中間はカオス もしくはそもそも 作られない 共通コンポーネント ※ 神コンポーネント:なんでもできるように大量のフラグや条件分岐を持つ、人智を超えた巨大コンポーネント 様々なバリエーションに 応えるため 神コンポーネント化
ページコンポーネント ロジックもレイアウトも 全部突っ込んで 神コンポーネント化
Atomic Designは夢の設計手法か? D Atomic Designはこの混沌に秩序を与えてくれそうな「気がする# D 現実はそんなに甘くない propsが20個ある 神atom 結局中間が難しい
「これはMかOか?」みたいな辛い議論 https://atomicdesign.bradfrost.com/chapter-2/ 分割・整理されないまま 肥大化するページ
Atomic Designは夢の設計手法か? i 「わかりやすい」型が与えられた結果、見た目の型に縛られるだけになりがR i 目に見えないロジックや状態、その裏の責任分割までは決めてくれなe i 決して悪い方法ではない…はず。でもみんな結構苦労している https://zenn.dev/dove/articles/e940fa7e8b860d https://zenn.dev/sterashima78/articles/0cf4bb52112c7b
Reactでアトミックデザインやめた話 Atomic Design はなぜ難しいか?どうやって難しさを解消するか
そもそもなぜコンポーネントにしたいのか? コンポーネント化の(よく言われる)メリット 再利用できる 共通化できる 拡張性が上がる 保守性が上がる まずは「理解しやすく保守できるコードにする」ことだけ考える このあたりは本当に難しいし、コスパが悪い
「理解しやすく保守できる」良いコンポーネントとは A 大きすぎなP A 名前でやっていることがわかE A 一つのことだけうまくやる
ÇÅ 大きすぎない & 誰でもわかる・数えられる。コストも手間もかからな0 & 長いコードは大体誰でも読みたくないし、触りたくない & Reactなら1ファイル100行くらいまで。150超えてきたら危s & Vueの場合は構造上もう少し(+2,3割)大きめになる傾X
& コンポーネントにはテンプレート(JSX, <template>)やスタイルも含めY & コンポーネント内の関数ひとつひとつも20行くらいまでにしたい 行数は絶対ではないが、目安としてはとても優秀 目安は?
ÇÅ 大きすぎない 40行 120行 240行
2. 名前でやっていることがわかる )' 一つのことだけうまくやる Area, Layout, View → 本当にエリアやレイアウトだけ`
Manager, Controller → 実際これ何やってるの` (Fooコンポーネントに対する)useFooフック → ロジック部分切り出しただけ? 抽象度の高い「ふんわりワード」が出てきたら疑う 入出力(引数・props・戻り値)が増えてきたら疑う 正しい名前にリネームできないならコンポーネントに機能を足してはいけない
おかしいと思ったら? W 設計自体の見直しが必要なこともあるので、本来は「とりあえず」は良くな% W でも分割しないよりは圧倒的にマ5 W 本当にマズい時は分割しようとしてもうまく出来ない W 責務や関心に合わせて分割す W
本質ではないロジックを切り出す...なy W 記事も書いてます とりあえず分割する どうやって? https://ics.media/entry/210929/
コンポーネント分割の障壁をいかに下げるか? 5( 分割して壊れないことを保証する x TypeScriptやESLintのルールでできる限り静的にチェックすu x もちろんテストがあると尚良い
コンポーネント分割の障壁をいかに下げるか? DC 必要なものはできるだけまとめておく(=コロケーション) コンポーネントの構成要素が離れていると分割のハードルが一気に上が 別ディレクトリ(components/, styles/, hooks/ ...)よりも機能ごとの1ディレクト
1ディレクトリの別ファイルよりも1ファイ VueならSFC。Composition APIになっているとさらに良 ReactならスタイルをTailwindやCSS in JSでコンポーネント内に置くのも良い
コンポーネント分割の障壁をいかに下げるか? m このボタンを<CounterButton>として切り出し たければ、単にこの部分をカット&ペーストで別 ファイルにすればOP m 関連するstate等がTSのエラーになるので、合わ せて移動するかpropsで渡すか、自由に決めれば 良 m
基本的にTypeScriptのエラーの通りに修正すれ ば、この変更でアプリが壊れることはない コロケーションされていると分割が楽な例:React + CSS in JS(Kuma UI)の場合
コンポーネント分割の障壁をいかに下げるか? 9& いつでも自由に分割できる環境とマインドをもつ コード差分が多く出ることを怖がらな コンポーネントを分割するよりpropsを足してifで分岐する方が差分自体は少な 将来理解・保守しやすいのはどっち?
まとめ i コンポーネント設計はプロダクトにあわせて無理なく考えよ0 i 高度な設計や仕組みよりも、まずは「小さく保守しやすい」コンポーネントを目指 i コンポーネント分割のハードルを如何に下げられるかがポイント