CSS in JSの基礎

原点はこちらのスライドがよく挙げられる。
いわゆる「CSSのあらゆる問題をJSで解決する」という感じのもの。
先行の記事としてはこのような感じ
- CSS in JS(Elm)したら想像以上に良かった
- Free-Style のススメ ~ CSS Modules は解決策ではない
とりあえず今回はReactと一緒に使う前提のことを考える

CSS in JS ライブラリの実装系統

CSS in JSライブラリもかなり色々あるが、だいたい下記の観点で分類できそうだった。

スタイルの再現に関する実装

<style>タグを生成して、<head>にinsertする実装パターン
- 昨今のスタンダードなライブラリの使っている手法
- CSSの疑似要素や@media queryもだいたい使える
InlineにCSSを展開する実装パターン
- わりと絶滅危惧種っぽい（開発止まっていたり）
- そもそも素のreactがこの機能を提供しているので、あんまりライブラリの旨味はない

スタイルの記法に関する実装

JSに記載
- JSのObjectとして記載
- template StringなどでCSSを記載
- transpileを前提にした独自記法
別ファイルに記載
- CSSに記載

Library比較

今回は、下記を前提として比較した。

:hoverなど疑似要素利用可能
@media、@fontface、@keyframes利用可能
クラス名の衝突回避をしてくれるもの
template stringとしてCSSを書くものは除外
- パースエラーの検出など考えると頭痛いため
Reactへの依存性が少ないならなお良し
参考資料はこのへん。ただし、割りと既に古かったりするので、網羅性だけを見たほうが良さそう
- https://github.com/MicheleBertoli/css-in-js
- https://github.com/FormidableLabs/radium/tree/master/docs/comparison

Aphrodite

classNameに記載してるクラスは、ハッシュ化されたsuffixがつけられ、名前空間が重複しないようになる (参考：Aphrodite Output tool )

import { StyleSheet, css } from 'aphrodite';
const style = StyleSheet.create({
  red: {
    color: 'red',
    ':hover': {
      opacity: 0.8
    }
  },
})
const Label = ({children}) => {
  <span className={css(styles.red)}>
    {children}
  </span>
}

利点

<style>の生成関連が、一番気使っている感じがする
animation周りが一番書きやすい
Star数が多く、人気高め
!importantをつけて、他のCSSの影響を殺す事も出来る
- aphroidte/no-importantを利用すれば、これを無効化することも出来る
autopreifxerを内部で自動的につけてくれる
開発が個人でなく組織なのでちょっとだけ安心度高い
hypertermなどで実績あり

欠点

className以外へのCSS適応を許さない姿勢なので、resetなどは別途考えないといけない
子要素のCSSを指定する方法も限定されているので、わりと厳格にCSS in JSに書いていく必要がある

Free-style

const FreeStyle import 'free-style'

// Create a container instance.
const Style = FreeStyle.create()

const LABEL_STYLE = Style.registerStyle({
  color: 'red',
  '&:hover': {
    opacity: 0.8
  }
})
const Label = ({children}) => {
  <span className={LABEL_STYLE}>
    {children}
  </span>
}

利点

React非依存
selectorの指定は、それなりの柔軟さがある

欠点

aphroditeに比べると、手数の多さが気になる

glamor

styleやhoverなどを関数定義して展開させるという独自の記法。なかなか悪くないと感じた。
aphroditeからの乗り換えは楽に出来るように作られているので、必要になったら乗り換えようかな、という感覚。

import { style, hover } from 'glamor'
const Label = ({children}) => {
  <span   
    {...style({ color: 'red' })} 
    {...hover({ opacity: 0.8 })}>
    {children}
  </span>
}

利点

StyleSeet.create的な記法が無いので、手数が少ない
glamor/reset、glamor/aphrodite、glamor/jsxstyleなど、他のライブラリに記法を近づけるようなものも提供している
select("ul li")のような関数を使うと、子要素へstyleを適用出来る
- このあたりの使い勝手は良さそうだが、注意深く使わないと、CSSの厄介な部分を引き出しそう

欠点

べったりstyleに記載
内部的な実装として、[data-hogehoge]というCSSセレクタに変換するため、パフォーマンス大丈夫だろうか？と心配になる。

その他の実装や手法（見送り）

ライブラリ無し(素react)

@mediaなどは我慢できるが、hoverまでonHoverなどで実装しなきゃいけないのは辛すぎるのでボツ

Radium

Star数はかなり多い
Reactに強依存。React以外で使う事は想定されてなさそう。
decoratorを利用しているが、decoratorの仕様策定がまだ不安定な情勢なので、かなり怖い
decoratorを利用しない場合の動作がどうにも不安定（Stateless Functional Componentと相性悪い？）

cssx

トランスパイラー前提として、独自記法で書いていく
さすがに挑戦的すぎたので見送った。
方向性は面白いが、この方向性だと、流石に開発体制の基盤がほしい
facebookがまともにこの方向性のものを作るなら、ちょっと興味があるかもしれない。

jss

cssinjsというそのものズバリな名前で作成されている
pluginなどがあって面白い。
- 短所としては、結構plugin入れないと使い物にならない感じあるかもしれない。
keyframes周りがあまり強くない印象

CSS Modules

知名度高し。導入敷居は低い。
厳密にはCSS in JSとも言いづらい。広義ならCSS in JSと言えそう。
利点
- Webpackとは相性が良い
- 資料が豊富
- 既存のCSSを完全にそのまま使える
欠点
- Webpackへのロックインが現状だとだいぶきつい
  - 一応Browserifyなどがんばればイケるが・・・
- import "foo.css"のような形式だと、testツールで辛みが多い
  - testに関わらず、上記のような記法は避けれるなら避けたい
軽く使ってみるとやっぱりテスト周りが主に辛い＆CSS in JSともずれる、というところで見送った。

jsxstyle

<Flex>や<Block>などのコンポーネントまで提供している。
curryなどの機能は面白そう。
なんとなく自分が使いたいものとはズレるものと見えたので余り調べてない
もしかすると組み合わせて使えるのかも？

ReactShadow

Shadow Domを使う変わり種。
将来性考えると面白いかもしれない

react-look

React Nativeにも対応しているらへんが魅力
今回自分の要件からは外れるので見送った

CSS in JSについての雑感など

結局どれを使いそうか？ → Aphrodite

個人的には、Aphroditeが一番記法的に手数がそれほど多くなく、必要十分な感じだった。

glamorやFreeStyleにあるような子要素へ影響を及ぼすセレクタを書けない事やresetを別途管理しなければならないことは弱点でもあるが、その分CSSで無理な解決をさせず、コンポーネントが適切に分解されることが期待できそうと感じる。

「やっぱりCSS in JS辛い！CSSに戻す！」となったときも、記法の制限が多い分捨てやすいだろうとも感じるし、逆に「制限がきつすぎる！」という場合だったらglamorに乗り換えるのも容易そうだった。

CSS in JSはそもそもやるべきか？

2016年段階で、万人に向けて「是非どうぞ！」と勧めれるような手法ではないだろうと思う。ただ、現実的にトライできるフェーズまでは来ているのかなと感じた。
個人的にもいくつかの動機付けがあった。
このあたりが共感出来るなら、トライする価値があるかもしれない。

小規模なSPA的な感じで、CSS in JSは相性は悪くなかった。
SCSSで分離していたcss部分をJSにまとめれると嬉しい状況があった
- webpackでの結合を避けたかった
デザイナーの理解を得ることが出来た （重要）
デザイン自体は一旦完成して、それをリプレースする状態だったので、そんなに障壁が高くなかった。
CSSに対するベストプラクティスがまだ無いので、チャレンジしたかった
- BEMやSMACSSの命名規約で縛る設計方法に限界を感じていた。
- ここが満足している場合だったら不要なのかも？
CSSとJSが凝縮された世界というのは Angular2や、Shadow Dom 、Riot.jsのscoped css、vue.jsのモジュール化などちょこちょこ見かけるようになっているので、「そろそろやってみても良いかな」という気分があった。

書いてみた所感など

書いてみると、キモさや背徳感と、相反して合理性が同居する複雑な気持ち
- JSXを初めて触った頃の感じによく似ている気がする
CSSに疎いサーバーエンジニアには概ね好評
Atomic Designを意識して、Atom（原子）の部分を明確に区切ってCSS in JSでstyle付けして組み立てるのは相性良さそう
- <Padding>などの調整についてはそれ専用のComponentを作る割り切りが合ったほうが良いかもしれない。
今まで「うーん、このパーツだけで単体ファイル化しても・・・」と思っていた数行のコンポーネントも、styleもまとめると適度な粒度になった。
デザイナが全体感を捉えるのに向いてないのでは？というのはまだぶつかってないが、課題感も感じている
- 多分Atomic Designが抱えている問題の感覚と近そう。うまくStorybookなどを使って解決していきたい。
モーダルなど、外からの影響を遮断したいようなコンポーネントだったらすごい相性良さそう。
React関連のライブラリ提供側で、CSSのimportを要求されるのすごく困るので、そういうライブラリはさっさとCSS in JSに移行してくれたらいいのに、と思った。
houdiniの話とかあるので、将来的にどうなるかはまだまだ未知の世界

Reactと一緒に使う時のCSS in JSのライブラリ選定とか所感とか