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

これまでの流れ

FLOCSSの運用振り返りシリーズ最後は、運用編です。
ルールを制定して、プロジェクトに導入した後は運用のフェーズになりますが、ここでもやはり実践からの気づきがいくつかあったので残しておきます。

Projectレイヤーが理解しにくい

FLOCSSのObjectレイヤーに位置するProjectレイヤーですが、実際に運用してみるとこいつがよく分からないという意見が多数出ました。
改めてFLOCSS本家のドキュメントから参照すると…

プロジェクト固有のパターンであり、いくつかのComponentと、それに該当しない要素によって構成されるものを定義します。
例えば、記事一覧や、ユーザープロフィール、画像ギャラリーなどコンテンツを構成する要素などが該当します。

https://github.com/hiloki/flocss

つまり、Component化された要素や、Component化されていない要素たちによって構成される集合体をProjectレイヤーとして定義するようです。
本家であまり具体的な説明がなされていないこともありますが、FLOCSSを触ったことがある方なら一度は悩むポイントかなと思います。

Componentレイヤーとの違いですが、ComponentレイヤーはUIを構成する上で最小単位のものですが、Projectレイヤーは複数の最小単位の要素によって構成されている再利用性のある集合体という点です。

改めて公式のドキュメントの説明を見ると、記事一覧やユーザープロフィールや画像ギャラリーがProjectレイヤーとして挙げられています。
これらの集合体は複数のページで使い回しされることがある要素なので、Projectレイヤーとして定義して再利用性を担保するという理解です。

Component/Projectレイヤーとして定義するか否か問題

というわけで、ComponentレイヤーもProjectレイヤーも基本的には再利用性があるという前提です。
すでに複数の箇所で使い回されている要素はいずれかのレイヤーに振り分けていけますが、初めて登場してきたものはどうでしょうか。

『他のページでも使うかもだからとりあえずComponentにしておくか…』という判断でも良いと思うのですが、自分の場合はRule of threeの考えに則りました。
3回も出てくる要素であるならば再利用性を担保すべきなのでコンポーネント化をしましょうというルールです。

また、初めて登場する要素はデザイナーもまだ試行錯誤の段階ということが多く、フェーズが進むにつれて変化していくことも珍しくないです。
そうした状態で初めからコンポーネント化を頑張りすぎてもひっくり返る可能性があるので、初めはコンポーネント化しなくて良いと思います

ではどのFLOCSSのどのレイヤーに書くのだという話になりますが、そのためのPageレイヤーでもあります(Pageレイヤーについてはこちらの記事をどうぞ)。
まずはPageレイヤーにベタベタっとスタイルを書いてリリースし、3度使い回されるようであればComponentかProjectレイヤーとしてリファクタリングするという流れです。

Sassの変数で管理すべき

これはFLOCSSに限った話ではないのですが、せっかくSassを使っているのであればあらゆるスタイルの設定値は変数で管理するべきです。

これは自分がFLOCSS移行のスケジュールを間にあわせるために優先度を落として対応しなかった部分なのですが、後になってからめちゃくちゃ後悔しました…
color・opacity・margin・padding・width・height・shadow…などなど、これらのスタイルの設定値は変数として持っておくとデザインルールが破綻しにくい状況を作れるので品質担保にも繋がりますね。

また、デザインルールが全面的に変わるとしても、変数で徹底的に管理できていればデザインアップデート実装の工数も大幅に削減できるというメリットもありますので、今後はどんなに忙しくても後回しにしないようにしたいと思います。

既存スタイルとの共存問題

すでに運用中のプロジェクトにFLOCSSを導入する場合、既存スタイルとFLOCSSの共存については慎重に進める必要があります。

まずFLOCSSに移行する際の進め方としては以下のようなパターンが考えられます。

  1. 既存のスタイルを全て削除して0からFLOCSSで組み直す
  2. 既存のスタイルを削除して部分的にFLOCSSに移行する
  3. 既存のスタイルを残して部分的にFLOCSSに移行する

自分の場合はFLOCSSへの移行作業は段階的にリリースするという判断をしていたので3のパターンになりましたが、これは良い判断ではなかったと後悔が残っています。
何故かというと、部分的に移行していく中で既存のスタイルありきの前提でFLOCSS内のスタイルが構築されてしまったことが最大の要因です。


例えば既存のスタイルでbuttonタグ自体にスタイルが設定されている場合、FLOCSSのComponentレイヤーで定義されたbuttonコンポーネントは既存スタイルを上書きする形で定義されます。
(本来であればbuttonタグ自体に設定されているスタイルを削除したいところですが、他のページのボタンにまで影響してしまうので自分の場合はできませんでした)

そして他のページにもComponentレイヤーで定義したbuttonコンポーネントを適用していきます。
ついに全ページに適用が済んだので既存のスタイルを削除してみると、全ページのボタンが表示崩れを起こしてしまう…みたいな状況があり得ます。

もちろん、ボタン程度のシンプルな要素であれば既存のスタイルをFLOCSSの方に移し替えるだけで良いのですが、これがProjectレイヤーだったらどうでしょう。
複数の要素・Componentで構成されている上に従来のスタイルも絡んできているとなると途端にややこしい話になります。
実際それが原因で自分の場合は従来のスタイルを消すことができなくなってしまい、少し歪なFLOCSS構成になってしまいました。

それらの反省を踏まえて、このような場合には以下のように進めるべきかなと思います。

  • まずは既存のスタイルを全て削除してからFLOCSSで再構成する選択肢の可能性を模索する
  • 部分的に移行するとしても、FLOCSSに置き換えた部分の従来のスタイルは削除しながら進められるように移行スケジュールを組む
  • 上記のいずれも実施できない場合、従来のスタイルをコピペした上でFLOCSS内で新しいスタイルを構築していく

FLOCSS化した結果むしろ管理できない問題

一見すると散らかっている部屋も散らかしている本人にとっては規則性があって、逆に整理整頓されると管理できなくなってキレる…的な話じゃないですが、FLOCSSに忠実に整理していくと結構な数のファイル数になって管理がしんどくなってきます

buttonが一つのComponentになるのであれば、それは例えば_button.sassみたいなファイルが一つ出来ることになります。
規模の大きいプロジェクトになるとCopmonentだけで相当な数になりますし、Projectレイヤーも加わるといよいよ管理できなくなってきます。

そこで、実際に行った工夫やこうしたら管理しやすいかなーという点がいくつかあったのでまとめておきます。

  • ファイル名は中身が想起しやすいよう配慮する
    • ファイル名を見ただけで何のスタイルが格納されているか理解できることが理想
    • 開発者の中で共通認識をもっているワーディングにする
  • ProjectレイヤーはComponentレイヤーほど細分化してファイルを作らないorディレクトリで括る
    • 例えばFormに関連するProjectが複数作られ場合、それらに対して一つずつファイルを作るのではなく_form.sassのようにして一つのファイルに格納するか、project/以下でさらにform/ディレクトリを作って整理する
  • ファイルの先頭にコメントアウトで何のためのモジュールなのか説明を入れておく
    • ファイル名から中身が予測できずにファイルを開いた際、初見の人でも内容を把握できるようにしておくと親切
    • 具体的に定義しておくことで誤ったスタイルを追加されなくなる利点もある
  • FLOCSSに沿ったスタイルガイドを作る
    • FLOCSSの構成に対応したスタイルガイドがあると視覚的に管理できるので目的のコンポーネントを探す手助けになる
  • デザインデータとFLOCSSをリンクさせる
    • FLOCSSで定義したコンポーネント名とデザインデータのレイヤー名がリンクさせる

最後のは自分も実践していないのでただの妄想ですが、デザインデータの時点で使用するコンポーネントやclass名が分かると最高かと思います。

おわり

パッと思いついた点を書き上げてみましたが、これからFLOCSSを導入される方orすでに運用中の方の参考になれば幸いです!

ではでは