CSS設計全盛期に学ぶフロントエンド設計

FROKAN x UIT #1 登壇資料

Transcript

1. CSS設計全盛期に学ぶフロントエンド設計 FROKAN x UIT #1 @Takepepe
2. About Me ▪ Takefumi Yoshii / @Takepepe ▪ DeNA / DeSC Healthcare ▪ Frontend Engineer ▪ TypeScript Meetup JP member
3. ▪ コンポーネント設計に悩んでいる方 ▪ まだまだ現場でCSS設計が必要な方 ▪ CSS設計 + VDOMライブラリ折衷設計をしたい方 ▪ CSS設計を全く知らない・興味がない方 本日の対象聴講者 あらかじめお断り：CSS設計がオワコンという話では絶対ありません
4. もう不要？CSS設計
5. CSS設計をご存知でしょうか？ CSS設計といえば、秩序をもたらすものとして、 今もなお現場で活用されているノウハウです。 もう不要？CSS設計 CSS設計を思い出す
6. メジャーなCSS設計はつぎの様なものがありました。 いずれも、それぞれ解決した課題がやや異なります。 MCSS SMACSS ITCSS BEM FLOCSS OOCSS もう不要？CSS設計 CSS設計を思い出す
7. 複数のCSS設計の良いとこどりをした独自設計も、 多くの現場で採用されていたと聞きます。 MCSS SMACSS ITCSS BEM FLOCSS OOCSS もう不要？CSS設計 CSS設計を思い出す
8. CSS設計を知らず「Scoped CSS ネイティブ」としてフロン トエンド開発に参入される方も多い現在。CSS設計に関 する話題は減りました。 もう不要？CSS設計 Scoped CSS ネイティブな現在
9. しなしながらCSS設計には、 現在にも通じるコンポーネント設計の ノウハウが凝縮されていたことは、 あまり語られていません。 もう不要？CSS設計 Scoped CSS ネイティブな現在
10. 「CSS設計全盛期・最新のソリューション」を 比較すると「設計の本質は変わっていない」 ということを、本日主張していきたいと思います。 もう不要？CSS設計 Scoped CSS ネイティブな現在
11. 線を引く技術
12. これより紹介する「4つのCSS設計」 それぞれが解決した課題は、 どんな設計にも共通する本質を突いています。 線を引く技術 メジャーなCSS設計
13. 線を引く技術 名前空間の担保 （BEM） 依存性の注入 （SMACSS） 関心の分離 （FLOCSS） 責務の線引き （ITCSS）
14. 名前空間の担保 （BEM） 依存性の注入 （SMACSS） 関心の分離 （FLOCSS） 責務の線引き （ITCSS） 線を引く技術
15. Modifier Element Block 名前空間の担保（BEM） 線を引く技術 CSS設計でまず一番気にかけなければならないのは、 名前空間の担保です。とても冗長な命名規則は 初めは「正直キモイ」と私も思いました。 <div class="p-namespace__element--blue"></div>
16. 競合しない名前空間（Block）で「線引き」することにより、 外部から影響を受けない、安全性を担保しました。 （BEM は Block、Element、Modifierの略） Modifier Element Block 線を引く技術 名前空間の担保（BEM） <div class="p-namespace__element--blue"></div>
17. プライベートな名前空間に指定が閉じられるので、 外部に影響をおよぼす憂慮なく、 コンポーネントスタイルを書くことができます。 Modifier Element Block 線を引く技術 名前空間の担保（BEM） <div class="p-namespace__element--blue"></div>
18. 最新のソリューションによる Scoped CSS の再現は、 モジュールバンドラーのハッシュ値付与により、 この名前空間を管理しているにすぎません。 線を引く技術 名前空間の担保（BEM） <div class="namespace-sc-1ph8hpw-0 gljtvd"></div> Modifier Element Block
19. 話が少しそれますが、Redux・Vuex などの状態管理ライブラリでも、 名前空間で影響範囲が閉じられています。 冗長な命名は、グロバールスコープにおける設計の基礎です。 線を引く技術 名前空間の担保（BEM） <div class="namespace-sc-1ph8hpw-0 gljtvd"></div> Modifier Element Block
20. 名前空間の担保 （BEM） 依存性の注入 （SMACSS） 関心の分離 （FLOCSS） 責務の線引き （ITCSS） 線を引く技術
21. SMACSSでは、CSSのルールを 次の5つのカテゴリに分類しています。 Module Layout Base Theme State 線を引く技術 依存性の注入（SMACSS）
22. コンポーネント粒度に応じた「線引き」がなされました。 Layout の分離は、マルチデバイス対応に効果的でした。 Module Layout Base Theme State 線を引く技術 依存性の注入（SMACSS）
23. コンポーネントは、親要素・子要素の存在を知りません。 レイアウトの責務が明瞭に分断されました。 Module Layout Base Theme State 線を引く技術 依存性の注入（SMACSS）
24. 特筆すべきなのは、BEM では許容していなかった 外部からの依存性注入です。 Module Layout Base Theme State 線を引く技術 依存性の注入（SMACSS）
25. （.is-）プレフィクスによる状態管理とテーマの注入で、 BEMよりも柔軟な指定を許容しました。 Module Layout Base Theme State 線を引く技術 依存性の注入（SMACSS）
26. Theme Provider / Container Component で 依存性を注入する、最新のソリューションとも似ています。 Module Layout Base Theme State 線を引く技術 依存性の注入（SMACSS）
27. 名前空間の担保 （BEM） 依存性の注入 （SMACSS） 関心の分離 （FLOCSS） 責務の線引き （ITCSS） 線を引く技術
28. SMACSS より多くの線をもつ、FLOCSS。 関心（コンテキスト）の「線引き」がなされました。 Layout Foundation Utility Project Component 線を引く技術 関心の分離（FLOCSS）
29. 大分類「Object」に含まれる「Component / Project / Utility」は 関心範囲の広さで区分されています。 Layout Foundation 線を引く技術 関心の分離（FLOCSS） Utility Project Component
30. 「Project」に定義された指定は、プロダクトの成長に伴い 関心範囲が広がることがあります。 Layout Foundation 線を引く技術 関心の分離（FLOCSS） Utility Project Component
31. 繰り返される指定は、汎用的なものとして線引きされ、 関心範囲の広い方へと移行します。 Layout Foundation 線を引く技術 関心の分離（FLOCSS） Utility Project Component
32. CSSプリプロセッサが支えた関心範囲の移行。 最新のソリューションでは Module システムが移行を支えます。 Foundation Utility Project Component Layout 線を引く技術 関心の分離（FLOCSS）
33. 名前空間の担保 （BEM） 依存性の注入 （SMACSS） 関心の分離 （FLOCSS） 責務の線引き （ITCSS） 線を引く技術
34. 最も後発の ITCSS は、 最も「線引き」が多いCSS設計です。 Settings Trumps Components Objects Tools Generic Base 線を引く技術 責務の線引き（ITCSS）
35. このぐらいの線の量になると、 プロダクトによっては過剰、といえるレベルです。 Settings Trumps Components Objects Tools Generic Base 線を引く技術 責務の線引き（ITCSS）
36. このCSS設計は最後の課題である セレクター詳細度の管理を解決しました。 Settings Trumps Components Objects Tools Generic Base 線を引く技術 責務の線引き（ITCSS）
37. CSSプリプロセッサ を利用することが前提であり、 変数・mixin・function のみが定義されたレイヤーがあります。 Settings Trumps Components Objects Tools Generic Base 線を引く技術 責務の線引き（ITCSS）
38. これは最新のソリューションでいうユーテリティ関数です。 責務の線引きが色濃く現れた設計といえます。 Settings Trumps Components Objects Tools Generic Base 線を引く技術 責務の線引き（ITCSS）
39. 名前空間の担保 （BEM） 依存性の注入 （SMACSS） 関心の分離 （FLOCSS） 責務の線引き （ITCSS） 4つのCSS設計が引いた線を確認しました。 線を引く技術 受け継がれるソリューション
40. 名前空間の担保 （Scoped CSS） 依存性の注入 （Dependency Injection） 関心の分離 （Atomic Design） 責務の線引き （Module System） 最新のソリューションと比較すると、本質は変わっていません 線を引く技術 受け継がれるソリューション
41. 設計の基本となるのは 「線を引く技術」です。 線を引く技術
42. 線の数はプロダクト毎に異なり、 成長過程で「増減」します。 線を引く技術
43. 各設計が示した「線引き」を参考にしつつ プロダクト毎に判断が必要です。 線を引く技術
44. 「規約」で線を引いていたCSS設計は、 JavaScript Module システムに移管することに。 線を引く技術
45. 線を引き直す技術
46. 最新のソリューションがもたらした、 CSS設計全盛期に叶わなかった課題解決は何でしょうか？ VDOM ライブラリが救ったのは、 jQuery による混沌とした実装だけではありません。 線を引き直す技術 VDOM ライブラリの福音
47. ある機能追加を境目に、 特定範囲だけの関心ごとであった指定が、 広範囲に広がる事案が発生します。 「リファクタリング」です。 線を引き直す技術 VDOM ライブラリの福音
48. CSS設計により引かれた線は リファクタリングを容易にしました。 ただ、設計規約だけでは事故を防げず、 大量の browser e2e テストによる 担保が余儀なくされました。 線を引き直す技術 VDOM ライブラリの福音
49. VDOMライブラリがもたらした福音は、 単体テストの優位性です。 Unit Test をはじめ、 Visual Regression Testing まで、 必要なものを選べる時代です。 線を引き直す技術 VDOM ライブラリの福音
50. さらに、TypeScript による型安全で テストの守備範囲が大幅に削減。 リファクタリングがし易い足場が 整ってきました。 線を引き直す技術 VDOM ライブラリの福音
51. あらためてCSS設計が担っていたことを確認します。 線を引き直す技術 VDOM ライブラリの福音 名前空間の担保 （Scoped CSS） 依存性の注入 （Dependency Injection） 関心の分離 （Atomic Design） 責務の線引き （Module System）
52. コンテキストの拡大・責務の委譲という「境界線」は CSS設計全盛期に見出されていました。 線を引き直す技術 名前空間の担保 （Scoped CSS） 依存性の注入 （Dependency Injection） 関心の分離 （Atomic Design） 責務の線引き （Module System） VDOM ライブラリの福音
53. 「線を引き・引き直す」ことを繰り返すことで、 そのときの最適な設計を導くことができます。 線を引き直す技術 名前空間の担保 （Scoped CSS） 依存性の注入 （Dependency Injection） 関心の分離 （Atomic Design） 責務の線引き （Module System） VDOM ライブラリの福音
54. 現在のフロンエンド開発現場は、エコシステムの拡充により、 圧倒的なリファクタリング優位性を手に入れました。 線を引き直す技術 VDOM ライブラリの福音 名前空間の担保 （Scoped CSS） 依存性の注入 （Dependency Injection） 関心の分離 （Atomic Design） 責務の線引き （Module System）
55. 線を引き直す技術 設計で最も重要なのは 「線を引き直す技術」です。
56. CSS設計全盛期に確立されなかった 「線を引き直す技術」は、 エコシステムの拡充により進化しました。 線を引き直す技術
57. プロダクトと向き合う設計
58. 結合度が低く・粒度が小さいほど、 リファクタリングはしやすくなります。 「技術面」で可能なことは、ここまでです。 プロダクトと向き合う設計 壁を壊すディレクション
59. 「継続的リファクタリングが設計の解」としても、 リファクタリングを阻む要因は「技術面」以外に。 BIZ都合であったり、 人員リソース都合であったり… 残されたリファクタリングの障壁 プロダクトと向き合う設計
60. リファクタリングを行いリリースに至るためには、 QAが必要になることもあるでしょう。 そのため、リファクタリング意義を言語化し チームで共有しなければいけません。 壁を壊すコミュニケーション プロダクトと向き合う設計
61. 技術的に良い設計であっても、言語化することで、 不要なリファクタリングであることに 気がつくかもしれません。 外部要因も、設計の一部です。 壁を壊すコミュニケーション プロダクトと向き合う設計
62. 新しいソリューションの導入にしても、 作り変えにしても、常日頃からその必要性を訴え 実現可能なタイミングを狙っていきましょう。 機会は与えられるものではなく作るものです。 壁を壊すディレクション プロダクトと向き合う設計
63. まとめ
64. コンポーネント設計に悩んでいる方へ まとめ コンポーネントの粒度がまちまちなのは結構なことです。 境界線を見つけた時にリファクタリングしましょう。 はじめから汎用化するのは、 オーバーエンジニアリングかもしれません。
65. まだまだ現場でCSS設計が必要な方へ まとめ jQuery + CSS設計でも設計の本質を見抜いていれば、 きちんとした設計は可能だと思います。 JavaScript Module System に頼れない分不利ですが、 そのぶん設計力が試されます。頑張ってください。
66. CSS設計 + VDOMライブラリ折衷設計をしたい方へ まとめ Scoped CSS と CSS設計が折衷になると厄介かもしれません。 思い切って「より枯れている」CSS設計のみで 実現可能か検討してみてください（Scoped CSS だけ使わない） コンポーネント指向とCSS設計はとても相性が良いです。
67. CSS設計を全く知らない・興味がない方へ まとめ CSS設計が CSS のためだけではなかったことが お分かり頂けたかと思います（そもそも呼称が悪い）。 CSS設計に後戻りすることはこの先ないでしょうが、 設計に悩んだ時、今日の話が役に立つかもしれません。
68. 設計をこれから担当する皆さんへ まとめ 基本的に最新のソリューションを選びましょう。 もしそれが叶わないのなら、CSS設計全盛期を思い出しましょう。 今後訪れるフレームワーク移管は、 線引きがしっかりされていれば、乗り越えられると思います。
69. 設計をこれから担当する皆さんへ まとめ 設計は技術要因だけでは成り立ちません。 議論を重ね・プロダクトの現状と向き合い、 各々の最適解を見つけましょう。
70. 議論に根をおろし…
71. Slackと共に生きよう…
72. CIと共にリリースを越え…
73. 型と共にリファクタをうたおう
74. ご静聴ありがとうございました