FLOCSSを2年間ほど運用した振り返り~ルール編~

CSSをゴリゴリと書いてはLPを仕上げることに楽しみを感じていた時期もあったなぁと突然前触れもなくエモくなったので、今回はそれに絡む話でも。
(今となってはなるべくCSSを書かずに済む方向に努力をしますが…)

タイトルの通り、先日まで担当してたプロジェクトでFLOCSSを2年くらい運用していました。
当時の自分なりの解釈で初期構築したりルールを一部カスタマイズしていたのですがとても良い経験になったので、整理も含めて振り返っていきたいと思います。

今回はルール編までいきたいと思います!

FLOCSSとは

「フロックス」と読みます。
公式にも書いてある通りなのですが、OOCSS,SMACSS,BEM,SuitCSS,MCSS等の思想をベースにして作成された比較的新しいCSS構成案です。
ちなみに作者は日本人の方です。

スタイルフレームワークと違ってCSS構成案なので、BootstrapとかBulmaみたいにすでに構築されたCSSを読み込んで使用するのではなく、あくまで概念とルールの部分を提供してくれています。

詳しくは上記の公式を読んでもらえればと思いますが、最大の特徴はレイヤーという概念を用いて各スタイルの役割・ファイル構成に規則性を持たせている点かなと思います。
基本的には上記のベースになっているCSS構成案の優れいている点を継承しています。

導入前の状態

そのプロジェクトはBootstrapでUIが構築された後、デザイン改修に伴って独自のスタイルが追記されていったという歴史的背景がありました。

自分もジョインしてからは新規ページの作成をしたり、既存のUIを改修していたのですが、徐々にスタイルの実装がしんどくなっていきました…

  • 同じようなUIがあちこちにあるのになぜかclassが違う
  • カスケーディングが考慮されておらず、適用したいスタイルが過去のスタイルに上書きされてしまう
  • ディレクトリ構成や命名規則にルールが無いので目的のスタイルの記述を探すのに時間がかかる

主にここら辺が原因でフロントエンドの開発コストが高まっていたように思えます。

理想の状態

そうした状態を打破したいと思って準備を進めたのですが、スタイル周りの理想的な状態としては以下のようにしたいなと思ってました。

  • 徹底的にコンポーネント化が行われている
  • HTMLにclassを付与していくだけでUIの構築ができてしまう
  • どこに何が書いてあるか開発者が管理しやすいソースになっている

2つめに関してはエンジニアの努力次第ですが、その他についてはFLOCSSという概念を取り入れることで解決できそうだと当時思いまして、導入を決定しました。

独自ルール

そんなわけで導入前にFLOCSSの公式サイトを読んでみたり参考サイトを漁っては下調べをしましたが、プロジェクトの状況に即した形にするため、そして、自分なりの解釈を反映するために独自のルールを追加しました。

Pageレイヤーの追加

そのプロジェクトは某サービスの管理画面開発だったのですが、ページ数がそこそこありました。
FLOCSSを導入するのであれば基本的には再利用性を考慮したスタイルを書くべきですが、特定のページでしか使用されないUIがあるのは間違いなく事実です

絶対に他のページでは使わないと分かっているスタイルをどのようにコンポーネント化するかについて考える時間は無駄だと思いますし、Objectレイヤー以下に再利用しないスタイルを書いて肥大化させるのも嫌でした。

そんなわけで、Pageレイヤーという特定のページでしか使わないスタイルを格納するためのレイヤーを追加しました。
ちなみに接頭辞は「pg-」にしました。

他のページを汚染するリスクを潰すために、そのページ固有のidでカプセル化しておきました。
こんな感じですね。

#contactPage
  .pg-contactForm
    color: $black

このPageレイヤーの追加は基本的には成功したと思っています。
イレギュラーなスタイルがそちらに集約されるので、Component,Objectレイヤーがより綺麗に保てるというメリットがありました。
ただ、『それはコンポーネント化しようよ…』みたいなスタイルもPageレイヤーに書かれてしまうデメリットもあるので、開発メンバーとの意識のすり合わせは重要かと思います!

class名のハイフンとアンダースコアは1つに変更

FLOCSSはMindBEMdingを踏襲しているので以下の命名規則が適用されます。

  • Elementはアンダースコア2つで表現
  • Modifireはハイフン2つで表現

ElementだのModifireだのというのはMindBEMdingの考え方です。
ここで詳しくは触れませんが、ようはコンポーネント化を行う際はBlockというルート要素があり、その下にElementという子要素がいて、それぞれのバージョン違いはModifireとして表現するというものです。
こんな感じです。

.box // これがBlock
  .box__button // これがElement
  .box__button--small // これがModifire

これを1つにした理由は以下です。

  • そもそも気持ち悪い
  • アンダースコアとハイフンを二回打つのが面倒
  • Vue.jsのtemplate内の可読性を担保したいのでclass名は極力短くしたい
  • キャメルケースでclass名を表現するルールを取り入れていたので競合することも無さそう

こうして冷静に振り返ることで半分は自分のわがままだったという事がよく分かりました。
しかし、これに関しても運用において特別大きな後悔や副作用はありませんでした。

ただ、上記にも書いた通り1つで行く場合は必ずキャメルケースでclassを表現しましょう(状態を表現する接頭辞は例外)。

むしろシングルクラスを推奨する

公式にも書いてあるのですが、FLOCSSは一つのモジュールを表現するのにマルチクラスを基本的に推奨しています。
extendを使ってシングルクラスにすることも可能です、と補足されていますが、むしろシングルクラスを推奨するようにしました。

理由はハイフンとアンダースコアを1つにしたのとほぼ同じで、記述量を減らしたいというのが大きかったです。

シングルクラスを推奨するに伴い、ベースとなるスタイルはclassではなくPlaceholderにしました。
公式からソースを拝借しますが…

.button {
  display: inline-block;
  padding: 0.5em 1em;
  cursor: pointer;
}
.button--primary {
  @extend .button
  background-color: #CCAA00;
  color: #FFFFFF;
}
.button--secondary {
  @extend .button
  background-color: #FFCC00;
}

この.buttonというクラスは単体で使用してもボタンというUIを表現することができないのでPlaceholderにしてしまっても良いのではないかという判断です。
(もちろんマルチクラスでいくなら必要ですが)
Placeholderにしておくことでコンパイル後のソース量を少し減らせるというメリットもあります。

この判断については少し反省点があって、開発メンバーにシングルクラスを推奨ということをしっかりと共有できなかったばかりに、シングルクラスで構築されるUIとマルチクラスで構築されるUIが混在してしまったのです。
規則性を生み出して整理整頓するためのFLOCSSなのに、ルールが破綻してしまったは元も子もないですね…
この項目に限った話ではないですが、導入時はルールのすり合わせを徹底しましょう。

おわり

他にも細かい独自ルールはあるのですが、大きな変更点は以上です!
これでルール周りは落ち着いたので、次回は導入編です。

ではでは