RSCSSを使用した感想と課題

#概要
RSCSSは合理的なCSS設計のためのアイデア集です。
スッキリしていて良さそうな印象だったので、サイト制作に取り入れてみました。
その時の感想と課題を書きます。

#RSCSSについて
簡単に以下のような特徴があります。

• Components で組み立てる。Components は - で区切った２ワード。（例： .like-button）
• Components の内部要素は Elements。Elements は１ワード。（例： .field）
• Components も Elements も variants を持てる。variantsは - ではじめる。（例： .-large）
• Components はネストできる。
• Layout に関するスタイルは親 Components で指定する。

詳細は公式サイトで確認してください。
https://rscss.io/index.html
https://qiita.com/kk6/items/760efba180ec526903db

#感想
良いところ

• 組み立てるのがかんたん。Elementsに簡単なワードを使えるのが良い。
• Componentsごとにscssファイルを分けるの良い。ただし、globは必須。
• Componentsの命名規則は２ワード、Elementsは１ワードって分け方がよい。
• Variantsの命名が気に入った。（.-large）

残念なところ

• キーセレクタが汎用的なワードになるのでパフォーマンス的にすこし心配。
• scssでの過剰なネストを避けるのは賛成だが、結果、子セレクタ（>）が連なって分かりにくくなる。それを防ぐためには、細かくComponentsを分ける必要がある。
• レイアウトに関するスタイルを親のComponentsからの指定に徹底するのが大変。
• ネストしたComponentsの複雑さをsassのextendで解決するのは反対。後から情報を追うのが面倒になる。
• Componentsの命名規則とファイルのフォルダ構成に課題あり。（プロジェクト内でルール化が必要）

#設計のアイデア
RSCSSの改善案ではなく、RSCSSを取り入れ、これからどんなCSS設計を採用するかについてのアイデアです。

##子セレクタ問題
デザインの複雑性に対応するためにはネストを深くするか子セレクタ（>）を連ねることになり、パフォーマンス的にも読解的にも良いとは言えません。細かくComponentsを分けると管理が煩雑になることがあるので、ElementsをComponentsの子クラスではなく、BEM的に書いた方がよいと思いました。
個々のComponentsごとに１つのscssファイルにまとめる管理方法は賛成です。

/* ✗ Avoid: 3 levels of nesting */
.image-frame {
  > .description {
    /* ... */
    > .icon {
      /* ... */
    }
  }
}

/* ✓ Better: 2 levels */
.image-frame {
  > .description { /* ... */ }
  > .description > .icon { /* ... */ }
}

/* My Best */
.image-frame_description { /* ... */ }
.image-frame_icon { /* ... */ }

##状態変化
RSCSSのVariantsはそのままつかうが、Helpersは使用しません。便利かもしれないけど、複雑化するためです。

// Variants
.component-name {
  &.-large {...}
}
// Helpers
._center { text-align: center !important; }　//NG

##レイアウト
レイアウト関連のスタイルは親からの指定を「推奨」にします。画面上部に固定するコンポーネントなどを考慮するためです。
記述の場合は、親ではなく子の中で指定するようにします。依存関係がまとまり、コンポーネントを削除しやすくなります。これは、ECSSから得たアイデアです。

.child-component {
  .parent-component > & {
    position: absolute;
    left: 1em;
    top: 1em;
  }
}

#まとめ
課題が残るが、良いアイデアを得ることができました。
結局のところ、どこまで変化を許容して設計するかだと思います。
いろんな場所で便利に使えるclassは変化に弱く、個々のUIパーツごとに完結させると、変化に強いがコードが多くなります。

中規模以上だったり、運用期間がある場合は、個々のUIパーツごとに完結させる方が良いというのが、今現在の結論です。その上で、開発しやすい設計を考えていこうと思います。

#更新履歴
（2019/07/23）子孫セレクタをたくさんつかっても対してパフォーマンスが落ちないそうなので、記事内容を更新しました。
https://twitter.com/clockmaker/status/1153314178754420738