• CREATIVE

March 04.2020

FLOCSSのComponentとProjectの違いを身の回りのもので考える(お寿司編)

FLOCSSのComponentとProjectの違い

こんにちは、Webデザイナー兼フロントエンドエンジニアの薮口です。

複数人でWebサイトを構築していく上で欠かせないのが、コーディングルールを定めるためのCSS設計です。

現在ではOOCSSやSMACSS、FLOCSSなど様々なCSS設計法がありますが、今回はFLOCSSを使用する上で分類に悩みがちなComponentとProjectの違いについてお話ししたいと思います。

1. そもそもFLOCSSとは?

FLOCSSは株式会社サイバーエージェントのフロントエンジニアである谷拓樹氏(飼っておられる黒柴が非常に可愛い!)が提唱されたCSS設計法です。

以前からあったOOCSSやSMACSS、BEMのいいとこ取りとも言える設計法で、作者が日本人でFLOCSS公式ドキュメントが日本語ということもあり、近年日本で注目されている設計法の1つです。

1.1 FLOCSSの構成

FLOCSSの構成は大きく「Foundation」「Layout」「Object」の3つに分類され、「Object」内ではさらに「Component」「Project」「Utility」の3つに分類されます。それぞれの分類は以下のルールに則って行います。

・Foundation…ブラウザごとのデフォルトのスタイルをリセットするためのCSSや、サイトの基礎となるスタイルを記述
・Layout…ヘッダーやメインコンテンツ、サイドバー、フッターなどのレイアウト分け
・Component…サイト内で再利用できる最小単位のモジュール
・Project…複数のComponentやその他の要素で構成されるモジュール
・Utility…ComponentやProjectのModifierで解決できないわずかなスタイルの調整(marginなど)

1.2 命名規則

FLOCSSではBEMを発展させたMindBEMdingが採用されています(最近ではMindBEMdingが主流になっているので、BEMと言った場合、MindBEMdingを指すことも多くなってきました)。

MindBEMdingはコンポーネントをBlockという大きな塊で考え、その中の子要素をElementとして扱います。また、元となるBlockやElementから変化した状態(他のバリエーション)をModifierとして扱います。

Blockに対してのElementはアンダースコア2つ(__)、Modifierはハイフン2つ(–)で表します。それぞれ2つずつとなっているのはクラス名を「スネークケース(単語間をアンダースコアで繋ぐ)」「ケバブケース(単語間をハイフンで繋ぐ)」で表している場合に混同を避けるためです。

※スネークケースという名前はアンダースコアで繋いだクラス名がヘビのように見えるため、ケバブケースはハイフンで繋いだクラス名が肉を串刺しにしたケバブのように見えるからだそうです。お腹が空いてきますね。

例えば.btnというボタンのコンポーネントがあった場合、.btnをBlockとして考え、中に入っているテキストやアイコンは.btn__txt、.btn__iconと命名します。

色違いなどバリエーションを増やしたい場合は、.btnに.btn–redなどModifierのクラスをつけて作成します。

このようにコンポーネント内の階層やバリエーション違いをクラス名で表すことで、コンポーネントの構造が分かりやすくなります。

また、FLOCSSではObject内のモジュールはそれぞれの分類ごとにクラス名の頭にプレフィックス(接頭辞)をつけることが推奨されています。

・Component…c-*
・Project…p-*
・Utility…u-*

プレフィックスをつけることでそれぞれのクラスがどういった役割を持つのかが明確になり、誰が見ても容易に構造を把握することができます。

2. ComponentとProjectの分類が難しい!

FLOCSSは複数人でWebサイトを構築する場合に、コードを見るだけで他メンバーとの意思疎通ができるので非常に便利なのですが、導入して最初に当たる壁があります。

そう、ComponentとProjectの分類が難しいのです。

先ほどの.btnのコードにプレフィックスをつけると以下のようになります。

しかし、このコードではComponent(最小単位)を.btnとして記述しておりますが、中のテキストやアイコンを他の場所で使い回したい場合は

.c-btn__txtを.c-txt
.c-btn__iconを.c-icon

として命名しなければなりません。

これで一件落着のようですが、このコードには大きなルール違反があります。

最小単位であるべきComponent内にComponentが入ってしまっているのです。

この場合は.c-btnをProject(集合体)として扱わなければならないので、.c-btnはp-btnとなり、テキストやアイコンのクラス名にもProjectとしての階層を表すクラス名を付与することが推奨されます。

考えすぎて熱が出てしまいそうですね。

業務効率を上げるために導入したFLOCSSで体調を崩してしまっては元も子もありません。そこで、楽しくComponentとProjectを分類するための、おすすめの方法があります。

3. 身の回りのものでComponentとProjectの分類を考える!

モニター画面とにらめっこしているばかりでは気が滅入ってしまいますし、視力も悪くなります。一度、気分転換がてら身の回りにあるもので分類を考えてみましょう。

3.1 お寿司にFLOCSSを導入してみる

日本人ならば誰でも構造も把握しているお寿司を例にして考えてみましょう。

ComponentとProject

このマグロのお寿司そのものをComponentとして考えると、以下の通りとなります。

ComponentとProject

コードで表すと以下のようになります。

※サビ抜きの場合は3行目をコメントアウト、もしくは削除してください。

無事お寿司にFLOCSSが導入できました。

しかし、マグロのお寿司の他にエビのお寿司があった場合はどうでしょう。

3.2 お寿司が複数ある場合

ComponentとProject

ワサビとシャリは同じだ!

マグロのお寿司とエビのお寿司はネタが異なるだけで、ワサビとシャリは全く同じものを使用しています。この場合はお寿司そのものをProjectとして考えることで、ワサビとシャリを使いまわすことができます。

まず、マグロのお寿司のクラス名を以下のように命名し直します。

ComponentとProject

コードは以下のようになります。

このようにネタやワサビ、シャリをComponentとして扱うことで

ComponentとProject

ネタをマグロからエビに変更するだけで、ワサビとシャリを使いまわすことができます!

コードは以下のようになります。

クラス名を1つ変更するだけなので、修正作業も簡単です。

では、ワサビ多めのお寿司が食べたい場合はどうでしょうか。

3.3 ワサビを多くしたい場合

この場合は2通りの考え方をすることができます。

・.p-osushiのModifierとして.p-osushi__wasabiを多くする
・.c-wasabiのModifierとして.c-wasabiを多くする

.p-osushiのModifierとして.p-osushi__wasabiを多くする場合はこのようになります。

ComponentとProject

コードは以下のようになります。

.c-wasabiのModifierとして.c-wasabiを多くする場合はこのようになります。

ComponentとProject

コードは以下のようになります。

どちらも見た目は同じですが、.p-osushiのModifierとして.p-osushi__wasabiを多くしている場合は.p-osushiにスタイルが依存しているため多めのワサビを単体として使い回すことはできません。

ワサビ多めのお寿司を作ることは出来ても、多めのワサビそのものを作ることは出来ないのです。

ComponentとProject

ですが、.c-wasabiのModifierとして.c-wasabiを多くした場合の.c-wasabi–largeは.c-wasabiのバリエーション違いなので単体で使い回すことができます。

お寿司とは別にお皿に多めのワサビを盛りたいワサビ好きの方のことを考えると、.c-wasabi–largeとして定義しておくのがベストです。

ComponentとProject

4. モニター画面の中だけが勉強の場ではない

以上のように、エンジニアとしての勉強の場は日常生活内に多く存在しています! 日頃から身の回りに目を向けることで、柔軟な思考を持つことができるようになりますね。

今日からぜひ、あらゆる機会にFLOCSSを導入してみることをおすすめします。

それではよいFLOCSSライフを!