FLOCSS で自社サービスの CSS 設計をやり直した話

この記事は TECHSCORE Advent Calendar 2016 の 9 日目の記事です。

弊社サービス Synergy! では、新機能「リターゲティングメール」搭載のタイミングで UI の刷新が行われました。
無事リリースできたのは良かったものの、特に CSS 設計は手探りな部分が多かったので、その後いろいろと課題が見えてきました。
今後の UI のベースとするには、あまりにも心もとない……ということで、FLOCSS を導入して CSS 設計のリファクタリングに取り組んだお話です。

元々の設計

Bootstrap
FlatLab (Bootstrap ベースのテンプレート)
自社の style.css

HTML/CSS 周りは、ざっくりこんな感じの構成です。
独自のスタイルは style.css に集約していました。

あと、クラスの命名規則は特に設けていませんでした。
Bootstrap & FlatLab でそれなりの種類のコンポーネントが用意されているので、そこまで独自のスタイルを定義することはないだろうという甘い見積もりのせいです。

抱えていた課題

画面やコンポーネントが増えていくにしたがって、style.css がどんどん肥大化。それに連れて以下のような問題に苦しめられるようになりました。

一枚の CSS にまとめられていたので、見通しが悪い
コンポーネントの粒度を決める基準が曖昧なので、再利用しにくい
命名ルールがないので、クラス名やコンポーネント設計の際、毎回悩む
同じようなコンポーネントを定義するスタイルが複数できてしまっていた
変更が及ぼす影響範囲がわかりにくくて、修正が怖い
フレームワークのスタイル上書きによる !important 地獄

この CSS をベースに今後の新機能 UI も作成していく構想だったので、設計の見直しは急務でした。
何か良い設計方法はないのかと調べるうちに、FLOCSS を導入すれば問題の多くを解決できるのではと思うようになりました。

hiloki/flocss: CSS organization methodology.

なぜ FLOCSS を採用したか

OOCSS、 MCSS、SMACSS、FLOCSS など様々な設計手法がある中、なぜ FLOCSS 採用に至ったのかというと、

後発なので、各手法のいいとこ取りである
BEM の採用がルールとして盛り込まれている
SMACSS より Object（コンポーネント）の分け方が細かい

といったところが主な理由です。
特に、「どんな粒度でコンポーネントを分けるのがいいんだろう？」という疑問に対しての答えが示されている点が魅力的に感じました。この点について少し掘り下げます。

Object の分け方について

FLOCSS のレイヤー構成は下記の通りです。

Foundation
Layout
Object
1. Component
2. Project
3. Utility

繰り返し利用されるようなパーツは Object として定義します。

Object はさらに、

Component → ボタン、パネルなど小さな単位のパーツ
Project → 記事一覧、ユーザープロフィールなどまとまったパーツ
Utility → margin の調整などのヘルパークラス

といった具合に分けるようになっています。

この分類に沿って、コンポーネント化していけばいいので、style.css からの切り出しは割とスムーズでした。

どう FLOCSS 化したか

実際の FLOCSS 導入作業は、

Foundation や Layout に当たるスタイルの切り出し
Object に当たるスタイルの切り出し
HTML 側のクラスや構造の修正
パターンライブラリにコンポーネントを追加していく

という流れで行いました。

スタイルを各レイヤーに切り出していく際、適宜クラス名の変更を行いました（レイヤーの接頭辞付与や、BEM の形式に揃えていくなど）

また、(2) と並行して、同じようなスタイルの統廃合も行っています。
完全にスタイルがダブっているケースはそれほどなかったのですが、Utility で定義したヘルパークラスをうまく使うことで、結構な量のスタイルを削ることができました。
かなり骨の折れる作業ではありましたが、減っていく style.css の行数を励みにコツコツ頑張りました。

(4) については、FLOCSS 化自体とは直接関係ないのですが、パターンを整理するついでにコードスニペット付きのパターンライブラリ（こういうやつ）を作っていきました。
ちなみにスタイルガイドやパターンライブラリ作成のツールとして「Frontify」を利用していますが、お勧めです。

FLOCSS 化してみて

まず結論として、FLOCSS を導入してよかったなと思っています。

よくなったなと実感している点はこんな感じです。

レイヤー構造が明確になったおかげで、コンポーネント設計に悩むことが少なくなった
再利用性が高まったので、画面を作る時に新たにコンポーネントを作るケースが減った
BEM のルールに従えばいいので、クラス名の決定が簡単になった
スタイルが適応される範囲がわかりやすくなったので、修正が気楽になった
新しいマークアップエンジニアがジョインしてきても、ちゃんと構造を説明できる気がする
新機能のモックアップ作成速度がかなり上がった
なんかモダンな設計を取り入れられていることの嬉しさ

メリットはたくさんありますが、なんといっても「多少壊れてもすぐに直してやるぜ！」と思えるようになったことが大きいです。
肥大化した CSS の壊れやすさといったらないですから。（参考：なんでCSSすぐ死んでしまうん）

逆にこれ微妙だなという点も挙げておきます。

BEM のクラス名の冗長さ（メリットは重々承知ですが）
Component にするか Project にするかで迷う
Bootstrap は BEM じゃないので、命名規則が混在することに

Bootstrap x BEM で作られているプロダクトって珍しくないと思うのですが、みんな命名規則の問題にどうやって折り合いをつけているのか気になるところです。

今後の課題

コンポーネントの粒度をさらに細分化したい

FLOCSS 化していくときに「このパーツって、Component か Project どっちだろう？」と迷うことが結構ありました。なので、もうちょっと細かくコンポーネントを分けられた方が捗りそうな気がしています。

分け方の候補としては、Atomic Design が今のところ有力です。
FLOCSS だと Component、Project の2つに分けていく感じですが、Atomic Design だと Atoms、Molecules、Organism の3段階で分けられるので、より再利用性が高まりそうです。

Web Components を意識しておきたい

FLOCSS 導入によって、比較的規模の大きい CSS でもそれなりに管理できる手応えは得られました。
ただ、グローバルにスタイルが適用される設計の辛さが完全に払拭されたわけではありません。

Angular、React をはじめとする各種フレームワークの動向を見ても、Web Components 的なアプローチが今後の主流になりそうな気配ですので、そこは見据えておきたいです。
実際、 Riot.js を触ってみたときに感じたのですが、一つのコンポーネントに対する HTML、CSS、JS が一つのファイルに定義されているのは安心感がありました。
また、スタイルのスコープが限定されることによって、クラス名が短く済んだり、そもそもクラスを振らなくて済むのもいいですね。

実装とパターンライブラリを一元化したい

現状、実装とパターンライブラリは完全に別物になっているので、同期がちょっと手間です。

Riot.js と Atomic Design ではじめるテクニカルクリエイター

上記の記事で紹介されているような、コンポーネントを直接利用してスタイルガイドを作る方法を是非取り入れていきたいなと考えています。