AbemaTVにおけるCSS is too fragile問題に対する解
https://gyazo.com/e5898252b72342a05bab0067d9c49098
前提
もともとの構成
css-loader
React.jsのコンポーネントインターフェースにclassName proosを定義 上位から下位にclassNameを渡す
actions, dispatchers, stores
離れたディレクトリを触るのが大変になってる
リファクタリングしたい
container/foo/A => /foo/container/A
特定の機能に閉じた変更をしやすくした
ディレクトリを変更してデグレによりスタイルが壊れてしまう
CSS modulesのモジュール探索の順番はJSと同様に深さ優先
モジュールの依存到達順序に酔ってCSSのルールセットの順序は変わる
importの順序が変わって探索の順番が変わった
汎用的な場合、変更に対して開かれすぎたコンポーネントが生まれた
ほしかったもの
CSS modulesベース
リファクタを阻害しない
ライブラリ独自の依存が少ない
どうしたか
.video-PlayerContainer__screen
grepのためにクラス名をJSで動的に構築するのは避ける
postcss-importを使ってCSSが展開されるようにした
ルートディレクトリ内にroot.cssを用意してその中でimport
対応後の評価
スタイルの適用をしやすくなった
クラス名のユニーク化をツールに任せない
開発者側でやるようにしたことでブラウザ拡張でCSSを上書きしやすくなった
CSS modulesよりは考えることが増えた
規約をつくってコードレビュー
規約が浸透したらレビューで指摘することはない
CSSを想像しやすくなった利点のほうが大きい
パフォーマンス
誤差の範囲でサイズは増加
まだ対して影響はない
今後増えるようならデバイスやページ単位でCSSをわけてもいいかも
他の選択肢と選ばなかった理由
CSS in JSへの移行
のちのち捨てやすくした
postCSSのプラグインは標準仕様から外れるのは避ける
ディレクトリ構造の変更で探索順序を変えないように順序を変えない
並び順に一貫性がなくなる
教訓
CSS ModulesやCSS in JSは使い方を気をつけないと壊れる
サービスの段階に酔って取り入れるものを変えたほうがいいかも