CSS Modules以外の選択肢を探して結局CSS Modulesに戻った話
ReactではCSS Modulesを使っているのだけど、 わずかなスタイルを定義するだけでも、いちいちmodules.scssファイルを生成しないといけないのが微妙なので、 Vueみたいにコンポーネントファイル内にスタイル定義できないものかと思い、 他のものを試してみたけど、結局、CSS Modulesに戻ってきた話。
試行1) Style Components
CSS in JSの選択肢のひとつということで、試してみた。 が、以下理由から採用見送り。
疑似クラスが文字列として書くしかなさそう（＝Lintが効かない）
CSS in JSはCSS Modulesに対してパフォーマンスがイマイチという情報を見つけた
試行2) Tailwind CSS
最近、巷で結構使われるようになってきている感じで、 『WEB+DB』でも特集が組まれていたので、試してみた。
が、少し試してみたところで、
これって結局、CSSをクラス名として二重定義してしまっているだけじゃない？ なんで、CSSに対応するクラス名をわざわざ調べて書かないといけないの？ 慣れれば覚えるだろうけど、CSSに対応しているだけの3rd partyが独自で作ったクラス名を新たに覚えることに、自分の脳内リソースを使う必要性って？？
という疑念が沸いてきて、 『WEB+DB』や、各種サイトを読み返して、 Tailwind CSSが解決する課題と言われていることやメリットと謳われていることを確認しなおした。
書籍やサイトでメリットと言われている主なことは以下。
- 共通化することになるかどうかわからないもののクラス名を、毎回考えることの手間がなくなる
- プロジェクト内でクラス名やCSSのルール決めをしなくてもよくなる
前者については、ReactやVue使ってるなら、 コンポーネントに閉じたスタイル定義にしておけば、 そのコンポーネント内でだけわかるクラス名にしておけばいいだけなので、 たとえば、「button」クラスとかでも構わないのだから、 クラス名を考えるのに時間かからないよね？
後者については、本当にそうか？という疑問。 だって、paddingだけで、p-0, p-0.5, p-1, p-1.5...p-96とかのクラスが用意されていて、 これを組み合わせて、各種パーツを各々が作ったら、 Aさんがbuttonをp-1で作って、 Bさんがbuttonをp-2で作って…、 ていうことが発生しちゃうぞ。 プロジェクトとして、それはマズいだろう、と。
そうなると、結局、
const primarryButton = 'text-white hover:bg-blue-800 focus:ring-4 rounded-lg text-sm px-5 py-2.5'
みたいな定義を作ることになって、 ん？それなら、普通にCSSでクラス定義した方がLintも効くし良いよね？？ ってことになる。
「p-1の実際値をあとでまとめて変えられるから」 って言うかもしれないけど、 それ、普通にCSSに標準で用意されているvarを使えば実現できるし。 Tailwind CSSに相当数用意されているクラス名を規律無しにプロジェクトメンバーに使わせて、後からメンテナンスコスト支払うよりも、 varで、s, m, lくらいの量の定義をあらかじめ用意しておく方が、 大した手間じゃないと思うよ。
Tailwind CSSの問題点を指摘している記事はないのかいな、 と探して見つけた記事。
Tailwind CSSが私には合わなかった理由 | コリス (coliss.com)
うん、これに同意。
結局CSS Modulesに戻ったワケ
うーん。なかなか良いのがないなー。 他の候補はないかなー、と探してるうちに、 CSS Modulesの開発者が、 「将来的にCSS Modulesはdeprecatedだ」 と言っているという情報を発見。
おぉっと。じゃあ、やっぱりCSS Modules以外のものを探さねば！
と慌てたのだけど、 ↓このあたりを読んで、現時点ではCSS Modulesを使っていても問題なさそうだなと。 CSS Modulesの歴史、現在、これから - Hatena Developer Blog
Style ComponentsやTailwind CSSを試してみて、 やっぱり、Pure CSSとほぼ同じものとして書けるCSS Modulesが最終的に使い勝手が良いという結論。 将来deprecatedされたとしても、移植性高いし。
将来的な観点では、CSS Module Scriptの動向をチェックしておきつつ、 現時点では、CSS Modulesを採用。 というところに収まりました。