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
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
2.4k
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
120
第13回 Data-Centric AI勉強会, 画像認識におけるData-centric AI
ksaito_osx
0
370
ホワイトボードチャレンジ 説明&実行資料
ichimichi
0
120
白金鉱業Meetup Vol.17_あるデータサイエンティストのデータマネジメントとの向き合い方
brainpadpr
4
300
Building Products in the LLM Era
ymatsuwitter
10
5k
自動テストの世界に、この5年間で起きたこと
autifyhq
10
8.1k
滅・サービスクラス🔥 / Destruction Service Class
sinsoku
6
1.6k
関東Kaggler会LT: 人狼コンペとLLM量子化について
nejumi
3
540
2024.02.19 W&B AIエージェントLT会 / AIエージェントが業務を代行するための計画と実行 / Algomatic 宮脇
smiyawaki0820
10
1.6k
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
120
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
3
920
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
133
9.1k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Docker and Python
trallard
44
3.3k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Faster Mobile Websites
deanohume
306
31k
Documentation Writing (for coders)
carmenintech
67
4.6k
A Philosophy of Restraint
colly
203
16k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
BBQ
matthewcrist
86
9.5k
Building an army of robots
kneath
302
45k
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 コンポーネント分割のハードルを如何に下げられるかがポイント