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