概要

FLOCSSでLPを作ったので、自分なりの作法とその感想について記述します。
(サンプルサイトあり)

FLOCSSについて

詳細は下記のリポジトリをご覧ください。
https://github.com/hiloki/flocss

提唱者

より詳しい使い方などはこちらの記事を参考にしてください。

導入前後の開発ディレクトリ

現行の私の開発環境

build.txt

base
    _reset.scss
    _setting.scss
component
    ここにコンポーネント系scssファイルを追加していく。
fonts
    フォント系のファイル
helper
    mixinなど
inc
    パーツをディレクトリごとにimportする。
    _component.scss
    _layout.scss
    _page.scss
layout
    ここにレイアウト系scssファイルを追加していく。
page
    ページ単位のscssファイル
style.scss
    全体のファイルをimport
vendor
    外部APIなど専用ディレクトリ

新しくFLOCSS用に作成したレイアウト

build_new.txt

base
    変更なし
fonts
    変更なし
helper
    変更なし
inc
    変更なし
object
    layout　 l-プレフィックスのscssファイル
    component　c-プレフィックスのscssファイル
    project p-プレフィックスのscssファイル
    utility u-プレフィックスのscssファイル
page
style.scss
vendor

導入経緯

HTML,CSSは容易に破綻することがしばしば問題になっていました。
その破綻を完全に防ぐことはできないが、設計ルールをもたらすことで少しでも防いで行こうという試みが,BEMやSMACSS、そして今回導入したFLOCSSなどのCSS設計ルールです。
私自身も短いエンジニア経験ではありますが、すでに設計ルールの重要性を痛感しております。

「現行の私の開発環境」　を見て頂ければお分かりかと思いますが、
基本CSSパーツを増やす時は、[component]ディレクトリに追加していきます。
プレフィックスなども無く、リードエンジニアが自由に記述していきます。
現在の職場では多くても二人、常に近くにエンジニアが居る状態ですので、このような設計方法でも特に問題ありません、むしろ細かな設計ルールを決めすぎないことで、誰でも構築に参加しやすいようにしています。

ではなぜ、私がFLOCSSを導入したかと言いますと、上記のcomponentにファイルを増やし続けるとおおよそcomponentディレクトリにファイルが70~100ファイルになります。
これくらいの数ですと、まだファイルを追うことも難しく無いですが、今後もっと大規模なサイトになった場合、秩序も無いままファイルが増え続けてしまうことへの懸念があり、
また、コンポーネント同士の上書きが発生した場合、コンポーネントファイルの中にコンポーネントファイルを上書きする必要がありクラス名の追跡が難しくなるなどの問題がありました。

提唱者のReadmeを見て頂くと、FLOCSSは基本ルールを持ちつつもある程度開発現場によって可用性を認めています。
私の場合常に
layout
project
component
の記述順をルールとしています。

index.html

基本パターン

<div class="l-layout">
    <div class="p-project">
        <span class="c-component"></span>
    </div>
</div>


c-componentを上書きする場合

<div class="l-layout">
    <div class="p-project">
        <span class="p-project_component c-component"></span>
    </div>
</div>

c-componentにモディファイアをつける場合

<div class="l-layout">
    <div class="p-project">
        <span class="c-component -is-red"></span>
    </div>
</div>

メリット　デメリット

メリット
Layout
Project
Component
の階層を守るのでコンポーネントの中のコンポーネントなど複雑になりにくい。
思い切ってprojectのパーツにすることでカンプ合わせが結果的に楽になった。
ファイルの検索が楽
軽い縛りがあることでCSSを書くことが楽になった。

デメリット
複数人で開発する場合、後から開発に参加してくる人にはある程度の説明が必要
ルールがある以上共通認識がないと破綻する。
結局のところComponent、Projectの切り分けは最後は個人の裁量になってしまう。
(これはどの設計思想でも避けられない気がします。)

サンプルサイト

ここまでは簡単な自己開発環境の説明でしたが、いざ初めて導入した時は、
これがはproject?component?となり結構迷ってしまいました。
今は導入実績が数件になり、ある程度自分の中でルール化ができますが、最初は中々戸惑うことも多いかと思います。
ですのでこちらのURLに私がLP想定したテストサイトを公開します。

caution!!!
実際に公開されているサイトの流用になるため、本来存在した要素の削除、不必要なプロパティが適用されています。
デザインそのものよりも、class名の付け方や、projectとcomponentの粒度の参考にして頂ければと思います。
FLOCSS使ってみようという方へ少しでも足しになればと思います。

FLOCSSでCSS設計に秩序を持たせる(サンプルサイトあり)

概要