SCSSのネスト禁止だけじゃ足りなかった話
目次
はじめに
前回、「SCSSのネストをやめてみたら世界が変わった」という記事を書きました。
あれは本当に良い体験で、書いた自分でも「もっと早くやっておけばよかったな」と思ったぐらいです。
でも、しばらく運用しているうちに気づきました。
ネストをやめるだけでは、まだ足りなかったな、と。
今回は、その後に見えてきた課題や、僕なりに試した次のステップをまとめてみます。
ネスト禁止で良くなったところ
まず、ネスト禁止は効果絶大でした。
- どこで定義しているか一発でわかる
- 競合がほとんど起きない
- 削除や修正が怖くない
- コピペで移動もしやすい
- 他の人にも伝わりやすい
未来の自分にもやさしいし、混乱が減るので、「ネストやめてよかった〜！」と何度も思いました。
それでも残った課題
ただ、やってみると別の壁も見えてきました。
記述量が多くなる
BEMで全部書くとクラスが長くなるし、似たようなコードが並びがちです。
タイピングの負担も地味に重くなります。
ルールの統一が難しい
BEMの書き方や命名が人によって微妙に違ってしまう。block__element なのか block-element なのか、とか。
ファイル構成に迷う
FLOCSSで分けても、「これはどこに書くのが正解だろう…？」みたいに迷うことがありました。
メディアクエリの書き方
レスポンシブ対応の書き方も統一しないと、ファイルによってバラバラになりがちです。
僕が試した次のステップ
そこで、次にこんなことを試しました。
space-map / color-map / font-map を導入
以前も投稿した内容ですが、意味ベースで余白や色、フォントを一元管理しました。
これで値がバラバラになるのを防げます。
FLOCSSをさらに厳密に
.c-, .p-, .u- の役割をもっと明確にして、ファイル構成も見直しました。
命名ルールを決める
BEMの書き方や接頭辞のルールを決めて、統一感を出しました。
VSCodeのスニペットを活用
タイピングがしんどいので、スニペットを登録して爆速化しました。
結論
ネスト禁止は「いいCSS設計」のスタートラインに立つための一歩だったと思います。
でも、そこから先もまだまだやることがあって、ルールや管理の仕方まで考えないと本当に快適にはならないな、と。
完璧な正解はたぶん無いので、プロジェクトに合わせて少しずつ試していくのがいいと思います。
僕もまだ試行錯誤中ですが、もし同じように悩んでいる人がいたら参考になったら嬉しいです。