改めて自分の記事を読み返してみたら、なんだか説明書みたいで硬いなと思ったので、今日からちょっとトーンを変えてみます。もっと自分がしゃべってるときの感じに近づけたいので、これからはこのくらいゆるっとした感じで書いていくつもりです。というわけで、今回はFLOCSSの話です。
このブログの子テーマも含めて、案件のSCSSはFLOCSSというディレクトリ設計をベースに組んでいます。有名な設計手法なので目新しさはないんですが、実際に運用してみると「教科書通りにいかない部分」がいくつかあったので、自分なりに調整しているポイントをまとめてみます。
基本のディレクトリ構成
採用しているのは、こんな構成です。
foundation: 変数・リセットCSS・ベーススタイルlayout: ヘッダー・フッターなど大枠のレイアウトcomponent: ボタン・カードなど使い回すパーツproject: 特定のページ・機能に紐づくスタイルutility: 汎用的な微調整用クラス
ここまでは教科書通りです。悩ましいのは、実際に手を動かし始めてからの「これはcomponentかprojectか」っていう判断なんですよね。
componentとprojectの線引き
一番よく迷うのがここです。自分の中では「2ページ以上で使い回すかどうか」を基準にしています。ボタンやタイトル、カードみたいな汎用パーツはcomponentに、特定のページの特定セクションにしか出てこない見た目は、たとえ見た目上コンポーネントっぽく見えてもprojectに置く、というルールです。
このブログでいうと、記事内の広告CTAや関連記事ブロックは、どの記事にも登場しうる汎用パーツなのでcomponentに置いています。一方でトップページのヒーローセクションみたいにトップページにしか出てこないものはproject/_page.scssにまとめています。「見た目が独立したブロックに見えるかどうか」じゃなくて「複数箇所で再利用されるかどうか」で判断する、っていうのがポイントです。
判断に迷ったときの実例
実際にこのブログを作ってるときも、何度か判断に迷った場面がありました。例えば記事末尾の「関連記事」ブロックを最初に作ったとき、一瞬「これは記事ページ専用だからprojectかな」と思いかけたんです。でもよく考えると、固定ページにも将来使う可能性があるし、そもそも「記事」という特定の文脈に依存してるわけじゃなくて、あくまで「関連コンテンツへの導線」という汎用的な役割を持つパーツなんですよね。文脈(どのページで使うか)じゃなくて役割(何をするパーツか)で判断する、という基準に立ち返ることで、component側に置く判断ができました。迷ったときほど「このパーツ自体の役割は何か」に立ち返るようにしています。
同じ見た目のパーツを複製しない
案件を重ねる中で気をつけているのが、同じビジュアル・構造のコンポーネントが別のページにも登場したときに、ページ名を接頭辞にして別クラスとして複製しないことです。例えば「トップページ用のカード」「一覧ページ用のカード」みたいな似た見た目のパーツが増えていくと、修正のたびに複数箇所を触る羽目になって、気づけば見た目がじわじわとズレていきます。既存のクラスをそのまま再利用する、という判断を早めにできるかどうかで、後々の保守コストがかなり変わってきます。
クラス命名のプレフィックス
クラス名には役割ごとにプレフィックスを付けています。
l-: レイアウトc-: コンポーネントu-: ユーティリティis-: 状態(開閉・選択中など)
このブログでもl-header、c-button、u-hidden、is-activeみたいに統一しています。プレフィックスを見ただけで「これはレイアウトの話か、パーツの話か、状態の話か」が判断できるので、他人のコードはもちろん、数ヶ月前の自分が書いたコードを読み返すときにも助かります。
BEMのネストは浅く保つ
Block内のElementは__、Modifierは--で表現するBEMを使っていますが、ネストの深さは2〜3階層までに意識的に抑えています。深くネストしたBlock構造は、一見厳密に見えても、実際に修正が必要になったときにどのクラスがどの要素を指しているのか追いにくくなりがちです。Blockの独立性を保って、__は同一Block内でのみ使う、というルールを徹底するだけでも、後から見返したときの分かりやすさがかなり違ってきます。
margin-bottom統一というシンプルなルール
細かい話ですが、縦方向の余白は基本的にmargin-bottomで統一しています。margin-topを使うのは、意図的な負のマージンでの重なり演出や、WYSIWYGエディタで書かれた本文コンテンツなど、明確に理由がある場合だけに限定しています。余白の付け方がページによってバラバラだと、コンポーネントを別の場所に移動しただけで余白が崩れる、みたいな事故が起きやすくなります。ルールを1つに絞っておくと、こういう事故を未然に防げます。
まとめ
FLOCSSは「型」自体は有名で情報も多いんですが、実際にうまく回すコツは、component/projectの線引きや命名ルールの徹底みたいな、地味な運用ルールの積み重ねだと感じています。このブログ自体も、まさにこのルールに沿って日々スタイルを追加しているので、今後新しいコンポーネントを作るたびに、この記事のルールに立ち返って判断していくつもりです。
設計ルールって一度決めたら終わりじゃなくて、実際に手を動かしながら「これは本当に守るべきルールか」を都度確認していくものだとも感じています。ルールのためのルールにならないように、迷ったときは「なぜこのルールがあるのか」まで立ち返って考える癖をつけていきたいです。
