この記事は2020年11月14日にWCAN 2020 Frontend Specialというイベントで行うLTのスライドと原稿です。
投稿時点ではまだイベントは始まっていませんが、先んじて公開します。
以下が実際の内容です。
それでは「CSS in JSで変わること変わらないこと」と題して私のLTを始めます。
なお今回のスライドと台本は既にアップしてあります。今日は相当早口で進めてしまいますが、後でまた読んでいただけたら非常に嬉しいです。
みなさんこんにちは。エイチームグループのIncrements株式会社でデザイナーをしている綿貫佳祐と言います。
少しだけご紹介しますと、Incrementsではこれらのサービスを展開しています。
- プログラミングに特化した情報共有コミュニティのQiita
- 社内向け情報共有のためのQiita Team
- エンジニアの採用を支援するQiita Jobs
私はデザイナーでありますが、これらのプロダクトのフロントエンドまで、ある程度担当しています。
個人開発でもCSS in JSを使用しており、普段から使用する中で見えてきたCSSとの変わること・変わらないことについてお話します。
まずは変わることです。色々ありますが、絞ってこの3つ。
- スタイルの競合と命名規則
- ロジックによるスタイル分岐のしやすさ
- ライブラリを理解する必要性
はじめのスタイルの競合については、CSS in JSが分かりやすく魅力的に映るポイントではないでしょうか？
例はEmotionでのコードです。コンポーネントAとBでそれぞれsomeClassという命名でスタイルを指定しても、ハッシュがついたクラス名に変換されて競合しなくなります。
コンポーネントのコード量とかにもよりますが、クラス名をほとんど考えなくても良くなる場合も結構多いんですね。
今まで人間がBEMなどの規則を用いて解消していたクラス名の衝突は、最早意識しなくて良い存在へと変化します。
次にロジックによるスタイルの分岐ですが、CSSとJSが同じ世界にあることで格段にやりやすくなりました。
どういうことか？これまでのCSSだと「ほとんど一緒なんだけどわずかに違う」スタイルを実装する際はそのパターン数と同じだけクラスを作り、modifierとして定義する必要がありました。
この例でいうとerrorとかsuccessのmodifierを定義しています。
しかしCSS in JSの場合はpropsがあります。なんでもかんでも制限なく渡せてしまうのは良くないですが、上手に使うと非常に柔軟です。
自分のポートフォリオではFigmaの活動をGItHubの芝っぽく表示していますが、これは1つのコンポーネントにpropsを渡すだけで青色の濃淡の調整が出来ています。
事前に網羅的に宣言しないといけなかったのが、変化した内容を受けて対応出来るように変わっています。
そして変わることの最後。ライブラリを理解する必要性です。
色々ライブラリがある中で自分はEmotionが好きなのですが、このような書き方が出来ずハマったことがあります。
あるcss propを他のcss propの中でだけオーバーライドするのが出来ません。
ハックした書き方をすれば一応解消出来るのですが、とにかく生のCSSとは違いライブラリの機能に依存して書き方を考えないといけない場面も出てくる、というお話です。
次は変わらないこと。こちらも3つに絞りますと
- CSS設計の必要性
- タイプセレクターの扱い
- マークアップとの関わり方
まずCSS設計の必要性です。ときどき「CSS in JSになればCSS設計は要らないよね？」と聞かれるんですが、私は必要だと思っています。
と言っても今までの設計内容と同じではありません。自分がよく考えるのは調整系のスタイルの扱い方についてです。
例えばFLOCSSでいうUtilityやITCSSでいうTrumpsのスタイル。どこかでまとめて宣言して各コンポーネントで呼ぶのはアリとするのか？
「毎回同じ記述するのはダルい」と「ユーティリティーを用いたらせっかくコンポーネントに閉じ込めた意味がなくなる」はどちらの主張も分かるので、線引きは難しいです。
厳密な命名規則を考える……とかからは開放されますが、CSS設計という概念自体は変わらず必要だと思っています。
次にタイプセレクターの話。
画像は1番最初に例に出したものと同じです。クラス名にハッシュがついてユニークになったとは言え、結局はグローバルに宣言された存在でしかありません。
CSS in JSでもこのようにネストしてタイプセレクターを使えば、あるコンポーネントの内側にあるdiv要素は全部margin-topがついてしまい、p要素は赤くなってしまいます。このあとのスタイリングで不要な打ち消しを余儀なくされるでしょう。
Shadow DOMが良い感じに扱えるようになるとこれらも解消出来るはずなんですが……まだしばらくはタイプセレクターでスタイルを宣言するのはやめた方が良さそうです。
最後にマークアップとの関わり方。
これは一言で言えば「CSS in JSを導入したからってマークアップが適当で良くなることは無い」に集約されます。
spanを使えば良い場所を全部divで書いてdisplay: inline;を書くのは手間ですし、変な階層構造のマークアップをするとpositionとかz-indexで苦しめられがちです。
マークアップはマークアップでちゃんと書けた上で、CSS in JSはプラスアルファ便利になるツールでしかありません。
かなり詰め込んでしまいましたが、変わること変わらないことそれぞれ3つご紹介しました。
変わることは
- スタイルの競合と命名規則
- ロジックによるスタイル分岐のしやすさ
- ライブラリを理解する必要性
変わらないことは
- CSS設計の必要性
- タイプセレクターの扱い
- マークアップとの関わり方
自分のLTは以上です。ご清聴ありがとうございました。