styled-componentsへの最近の感想
今の職場で既に組まれたシステムが既にstyled-componentsにべったり依存していて、別に積極的に入れ替える理由もないので普通に使っているけれども、やっぱりこれ微妙だなと思った話。
そもそもとして、ビルドシステムへの介入が多くて不必要にロックインになったり、提示されてる手法がだいたいイマイチで普通にCSSとかSCSSを書く以上の意義が見出せないので、僕は基本的に「JS中にCSSを書いたり、ES Moduleのimportを使ってCSSを読み込むタイプのアプローチ（以下CSS-in-JS）」がそんなに好きではない・大人しくCSS書く方が好きではあるんだけど。色々あった理由はこちら:
- https://saneyukis.hatenablog.com/entry/2019/02/28/022750
- https://saneyukis.hatenablog.com/entry/2019/03/14/023446
感想
上のリンク先にも色々書いてる微妙に感じる点を全部見なかった事にしても、やっぱり微妙だと思う。
- 何を作るにもstyled-componentsで包まれた（ファクトリ）コンポーネントを作る事になるので、ラムダ（匿名関数）を書いて済ませたい箇所で、古のJavaのCallbackクラスを書くのを強制される気持ちになる
- 具体的には調整用のdivやspanをぺろっと置きたいだけなのに、わざわざ書く事になる
- 結果、包まれた（ファクトリ）コンポーネントは変数定義順の問題があり、function宣言のhoistingなどに頼ることができないので、 BEMのelement定義してからBlock書く感じになる。なので、抽象化されたコンポーネントを定義したいのに、まず具象化された細部から書いていく必要があるし、既存のコードもそのように書かれる
- ここら辺、人によって書き方変わるし、lintなどのしばり方次第で如何様にも書けるだろうけど、temporal dead zoneを考えると宣言してない変数を使うのはありえないのは共通認識とする
- 末節・BEMでいうelement側の定義をファイルを分けてimportすれば解決する問題だが、繰り返すようにラムダ（匿名関数）を書いて済ませたい箇所でCallbackクラスを定義するような事になる
- そもそもテンプレートリテラルで文字列として記述しているのが、非常に中途半端に見える
- JSX記法がDSLとしてセマンティクスを持つ事による教訓が活かされていないのは釈然としない
イマイチだと思ったのはここら辺。他にも色々あるけれども。
かつてのCoffeeScriptを持て囃す論説への拒否感と似ているものの、そんなことをいうとCoffeeScriptに失礼だな。
それとstyled-componentsに限った話題ではないけれども、いわゆる「GUIのTheme実現が可能」みたいな売り文句は実際には十中八九使わないタイプの機能だと思っていて、なぜかというと
- 現実にはダークモード+alphaくらいしかテーマを作らない
- そもそもテーマ機能を真面目に用意してるプロダクトを見た数の方が少ない
- ダークモード対応なら
prefers-color-schemeで解決する
- ダークモード対応なら
- そもそもテーマ機能を真面目に用意してるプロダクトを見た数の方が少ない
- 仮に実装するとしても、起こり得るテーマの変更はCSS custom propertiesで使って色やサイズや
background-imageなどの変数定義で解決するのが大半なので、標準化された方法に依存した方が良い - もっと複雑なことをやりたい場合は、大抵はGUIの実装部分が別になるので「一つのファイル・コードで複数のテーマを実現可能」にお世話になることは（あんまり）ない
- ユーザー定義スタイルを許容する場合、尚更public interfaceとしてclass属性などは必須だし.
から。 ちなみに自分の好きなアプローチは上の方に貼ったリンク先に全部書いてあって、それを超えるものではなかったかな。
Facebookのリデザインに見る、CSS-in-JSの良さそうな方向
色々ぐだぐだ書いているけれども、 https://engineering.fb.com/web/facebook-redesign/ に載っているサンプルコードの方向性は、良さそうに見える。実際にこの通りに書かれてるかはわからないけどね。
なぜかというと、
