はじめに

FLOCSSというすんばらしいCSS設計をやっていく上で、唯一の悩みどころにcomponentprojectの判別があります。私のチームでも悩み、チームメンバーがモヤモヤし、あとあとCSSも崩壊しそうだったので、一つの判別基準をつくることにしました。

スクリーンショット 2018-04-16 9.18.54.png

FLOCSS とは

数あるCSS設計手法のひとつで、OOCSSやSMACSS、BEM、SuitCSSなどのメジャーな設計手法のいいとこどりをした国産の設計手法です。
https://github.com/hiloki/flocss

CSSはデザイン通りの見た目を実現するために様々な書き方ができてしまうため、あるルールに則って記述していかないと、一つの変更が予期せぬところのレイアウト崩れを発生させてしまいます。そのルールというのも、かなり練りこんだものでないとあとあと破綻してしまいます。

FLOCSSはそういった要点を抑えたうえで、UIパーツを以下のようなレイヤーに分類するという特徴をもちます。

  1. Foundation - reset/normalize/base...など
  2. Layout - header/main/sidebar/footer...など
  3. Object
    • Component - grid/button/form/media...など
    • Project - articles/ranking/promo...など
    • Utility - clearfix/display/margin...など

FLOCSS設計の悩みどころ

開発していると、ここの中の2つのレイヤーcomponentprojectの判別に悩みます。

ComponentとProjectの定義
1. Component
再利用できるパターンとして、小さな単位のモジュール。 例えばBootstrapのComponentカテゴリなどに見られるbuttonなどが該当。 出来る限り、最低限の機能を持ったものとして定義されるべき。
2. Project
プロジェクト固有のパターンであり、いくつかのComponentと、それに該当しない要素によって構成されるものを定義する。 例えば、記事一覧や、ユーザープロフィール、画像ギャラリーなどコンテンツを構成する要素などが該当する。
https://github.com/hiloki/flocss より抜粋

人間で言えば、裸んぼの人間が最小単位のモジュールcomponentで、他にネクタイや靴下、スーツといったcomponentがあり、組み合わせてビジネスマンprojectになると考えられますが、

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f35303738332f62366162623038392d386463322d336134372d313138612d6266623538333239326430332e706e67.png

人によってはhumanはさらに細かくできるのでは?と思うかもしれません。
この考え方の違いによってhumanがcomponentなのかprojectなのかが違ってきます。

スクリーンショット 2018-04-13 1.32.40.png

具体的なUIパーツを例にあげると以下のようなcardの場合です。

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f35303738332f33356439313366332d623635632d316566382d613566632d3430656466623763386631352e706e67.png

この最小単位の判別が実装者によってバラバラだと、あとあとcss設計が破綻してしまいます。

この問題に対して、他の方々は独自ルールで仕分けしているようです。

プロダクトの中で4回以上同じ Object が登場したらそれは Component に分類
FLOCSSを使ってCSSファイルを20,000行から9,000行にした話

Atomic Designでいう、AtomsをComponent、Molecules等Atoms以外をProjectとしました。
再利用性の高い粒度の小さいコンポーネントがComponentのイメージです。

脱・CSS無法地帯。FLOCSSで指針のある設計を。

とても参考になりましたが、私がいる開発現場では以下のような問題がありました。

  • ABテストを繰り返して開発を続けているため、UIパーツの出てくる回数を最初には決められない
  • Atomic Designの考え方だと、今度は何がAtomsになるのか?と悩むことに

我々にはチーム全員が機械的に共通した仕分けができる方法が必要でした。

考えついた仕分け方

チーム全員が「これは最小単位のモジュールだ」と機械的に判別できるものを探しました。

そこで辿りついたのがPowerPointの図形です。

download.png

スクリーンショット 2018-04-13 18.04.53.png

このPowerPointの図形を使って以下のようにcomponentprojectを定義しました。

  • component:パワポの図形1つの単位
  • project:グループ化して動かす単位

この考えでいくと、例えば次のように仕分けすることができます。

スクリーンショット 2018-04-13 18.48.55.png

上の例ではprojectにもbuttonがあります、これをつくることでボタンの中にアイコンをいれたボタンをつくりたい場合に、最小単位のアイコンを、最小単位であるはずのボタンが制御しなければはならないというジレンマを解消します。

これによりc-buttonを最小構成に保つということを守りつつ
アイコンや他のUIパーツを組み合わせたボタンを作成することができます。

以下は実装例です。
c-のついたUIパーツはcomponentを表しており、それ自体に位置などは指定せず、色などの見た目だけを指定しています。 そして、p-のついたprojectはそれらcomponentの位置を指定します。

See the Pen FLOCSS Sample - button by UGA (@uga) on CodePen.


c-thumbnailは画像である場合が多いので、見た目を変更することがなく、場合によっては不要かもしれません。つまり、かならずprojectの中にcomponentがあるというわけではありません。

c-thumbnailが必要になる場合は、たとえば必ずborder-radius: 4pxを指定する場合が考えられますが、これはデザイナーと相談して決めることになります。

まとめ

FLOCSScomponentprojectの判別を迷わないために、PowerPointの図形を使って以下のように決めました。

  • component:パワポの図形1つの単位
  • project:グループ化して動かす単位

とりあえずこれでチーム全員が「これは最小単位のモジュールだ」と判別できる基準をもつことができました。

余談ですが

当初、IllustratorやPhotoshopでの判別を考えていましたが、図形とテキストが別なのでうまくいきませんでした。
PowerPoint以外では、もちろんKeynote、ExcelやWord、Draw.ioでも大丈夫です。

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.