コンポーネントの分割に関する考察

コンポーネントの分割 に関する考察 @pirosikick

自己紹介 • 穴井宏幸 • @pirosikick • ヤフー株式会社 エンジニア • 最近はApex Legendsで強くなるために CoD WW IIをやっています

絶賛発売中 WEB+DB PRESS Fastlyで 柔軟&高機能! 最新CDN入門 Vol.109 2019 高速化、エッジコンピューティング、セキュリティ強化 基本からSpring、Java資産活用まで Kotlin ヘッドレスChromeでテスト&スクレイピング [速習] Puppeteer Ruby 2.6徹底解剖 Epsilon----Java11の「GCしないGC」 キャパシティプランニング どんとこいフロントエンド開発 そこのジュンク堂書店にバックナンバーもありましたよ!

今日話すこと コンポーネントの分割について考えたことをしゃべります。

免責事項 • Reactとは?Vueとは?コンポーネント指向とは? については話しません。 • ReactやVue等で開発している人が前提の話となります • LTをやるという決断を今日下したので 深い考察はできておりません

今日見たTweet (・ヨ・) @ahomu フォロー中 コンポーネント分類論に成り下がった Atomic Design はおおよそ失敗してると思われます が、各位進捗どうでしたか。 11:34 - 2019年3月20日 7件のリツイート 14件のいいね 3 7 14 返信をツイート https://twitter.com/ahomu/status/1108195189418422272

Atomic Design • パーツ単位で定義していくUIデザイン手法 • パーツを5段階に分類 • Atoms、Molecules、Organisms、Templates、Pages • 左から、小さい ⇔ 大きい

今日見たTweet (・ヨ・) @ahomu フォロー中 コンポーネント分類論に成り下がった Atomic Design はおおよそ失敗してると思われます が、各位進捗どうでしたか。 11:34 - 2019年3月20日 7件のリツイート 14件のいいね 3 7 14 返信をツイート https://twitter.com/ahomu/status/1108195189418422272

わかる • 過去2度、Atomic Designをやった • Nuxt.jsの案件、React+Reduxの案件 • デザインシステムがあるわけではなく、 エンジニア主導でのコンポーネントの分割 • あんまりうまくいかなかった

うまくいかない • 分類方針が人によってバラバラ • リファクタやデザイン修正などで分類を移動する コンポーネントが発生する • MoleculesとOrganisms、わからん

個人の見解 • Atomic Designは • コンポーネントの分割の方針として導入するのは 微妙なのでは

なぜコンポーネントを 分割するのか • エンジニア視点ではだいたいこんな感じで? • 再利用性を高める • 保守性を高める • 長いコンポーネントは読むのが大変 • コンポーネントをシンプルに保つことで 可読性を高める

コンポーネントの分割の 指針を考えてみた • いきなり分割しない • 名前があるものを分ける • 変更する理由が違うものを分ける

いきなり分割しない • プログラミングにおいて早すぎる最適化は悪 • ドナルド・クヌース • YAGNI • コンポーネントにも同じことが言えないか? • 再利用が必要になったタイミング、 保守性が下がったタイミングで コンポーネントを分割すればよいのではないか?

名前があるものを分ける • UIとして一般的な名前があるもの分ける • Button、Field、Modal、Pulldown、Nav、、、 • コンポーネント名からだいたい何をしているかわかる • UIフレームワークから名前を借用するのもよいかも • Bootstrap、Material UI、、、

変更する理由が 違うものを分ける • 単一責任の原則(SRP) • 変更する理由の例 • UI(HTML構造、スタイル)の変更 • UIに関わるロジックの変更 • データ構造の変更 ... etc

変更する理由が 違うものを分ける • 変更する理由が違うものが同居するとどうなるか • 変更の頻度が高まる • そのコンポーネントを触る人が増える • 変更時に同居している別の部分への影響を 気にする必要があり、保守が難しくなる

まとめ • Atomic Designは デザイナーとエンジニアの共同作業が必要で、 どちらかしか関わっていない場合は運用が難しそう • コンポーネントはpropsを引数にUIを吐く「関数」なので プログラミング一般のリファクタは効きそう • 変更しやすいコンポーネント設計のほうが大事 • テストがある • 依存関係が複雑でない etc

まとめ • とはいえ、「これに従っとけばOK」みたいな 明確な方針が無いと辛いのはわかる • コンポーネントも platoのようなツールがあるとよいのかも • ジャストアイデアですが。 • JSの品質 • 品質を監視し、やばいやつを直していけたらよい

俺たちの戦いは まだこれからだ!

ありがとうございました