2021.05.17

SASS使うメリット、ディレクトリ構成についてまとめました

スポンサーリンク

SASSは覚えるべき

 

今はDartSassが主流なのでこの記事と合わせて読んでね!!!!!

Dart Sassの移行や使い方についてまとめました


SASSのディレクトリ構成をまちがった方法で運用していたので、備忘録として記しておきます。
またSASSを学び始めてディレクトリ構成がよくわからない方は、足掛かりとしてこの記事を参考にしてみてください。

ディレクトリ構成について

/assets

├── /css
│   ├── app.css
│   └── app.css.map

└── /sass
      ├── _base.scss
      ├── _components.scss
      ├── _reset.scss
      ├── _style.scss
      ├── _var.scss
      └──app.scss

パーシャル化してファイルを分割

sassディレクトリ内にあるsassファイルの接頭辞に_(アンダーバー)がついていますがこれはパーシャルといってファイル分割するとき付けます。

ファイル分割する理由としてはリファクタする際、対象箇所を特定することが容易になる点です。

ただかなりボリュームの少ないLPなんかだとSASSを使用する恩恵は薄れる場合もありますが、今後増築、改修することを考えればSASSで構築してもいいのかなと思っています。
ここはクライアントとの折り合いも兼ねてよしなにやってください。

コンパイル用のファイルを用意

上のツリー構造を確認していただくとわかりますが、app.sassだけ接頭辞_(アンダーバー)が付与されていないことがわかります。
このパーシャルされていないファイル内には各パーシャル化したファイルのパスをインポートしています。

このファイルに各ファイルのパスをインポートすることでコンパイルするファイルを一個にまとめることができます。
なぜこのような形にするのかというと、コンパイルするコマンド実行が一回で済むようになるからです。


app.scss

@charset "UTF-8";
@import "./reset";
@import "./var";
@import "./components";
@import "./base";
@import "./style";

 

ファイル分割の粒度について

ここら辺の話は本題と少しずれてCSS設計の話になってしまうのですが、一応補足として書いておきます。

パーシャル化するファイルの粒度としては作成するサイト規模によりますが、LP等の小規模だとこの程度の切り分けで十分かなと個人的には思いますがそこはお任せ。
ファイル名は適宜変更してください。

ファイル構成(簡略版)
app.scss ~ パーシャルを一括で読み込むためのファイル(コンパイルするファイル)
reset.scss ~ 初期化ファイル
var.scss ~ 変数、mixinをまとめたファイル
components.scss ~ コンポーネントとして切り分けたもの
base.scss ~ 全体を通して共通してあてているスタイルをまとめたもの
style.scss ~ ヘッダー、メイン、フッター等を記述するファイル(サイトの規模によりこのファイルを更に分割します)

コンパイルしてcssファイルとして吐き出す

scssファイルはコンパイルしないとブラウザには反映されません。
なので、ターミナルからコマンドを実行してコンパイルしましょう。

$ sass app.scss:../css/app.css --style expanded --watch

コマンドの内容はコンパイル対象のファイルを左側に、:(コロン)を挟んで、任意のcssファイル名として吐き出す先を指定している形になります。

ファイル更新するごとに上記コマンドをたたくのは非効率的なので--watchオプションをつけておくと楽です。
--watchオプションをつけることにより永続的に更新し続けてくれます。抜ける場合はCtrl+CでOK。

以上、SASSのディレクトリ構成と運用方法についてでした。

 

CSS設計について

余談ですが、CSS設計について少し。。
SASSを使うにあたって親和性のある設計を紹介しておきます。
LP、コーポレートサイト、ブログサイト、大規模Webサイト等々様々な規模の案件がありますが、どの規模にも通用するCSS設計はやはりFROCSSだと感じます。

Qiitaの参考記事
https://qiita.com/super-mana-chan/items/644c6827be954c8db2c0

理由① 命名のバッティングが起こらない

やはり普通の設計だと命名のネタ切れが起こります。
例えばボリュームの多いセクション内で、共通パーツでないクラスに"description"という命名をつけたとします。

後半同セクションでdescriptionという同じ命名を使ってしまい、同じ命名をされたクラスにいらないスタイルが当たってしまい、レイアウトが崩壊する事態につながります。

セレクタを切ることが上記の対策ではありますが、セクション内のボリュームが多い場合、セレクタをいちいち管理していくのがとてもとても面倒です。

そのセクション内に共通パーツとして切り分けていない同じ命名のものが存在するだけでお互い干渉する可能性があるため、命名は一意にするべきというのがFLOCSSを使う理由の一つ。

理由② どこに使われているクラスなのか把握しやすい

クラス名に接頭辞を付与することで大枠の切り分けを簡単に把握可能になる。
ここら辺の命名規則は上記に貼ったQiitaの記事がわかりやすいので見を通しておくと良いかも。

例えば、FLOCSSではコンポーネントとなるクラスには接頭辞にcを付与します。

隣接セレクタで簡単につけ外し可能となり、ぱっと見でコンポーネントとわかるので可読性が良くなるといったメリットがあります。

他スタイルに干渉しないため、リファクタリングも容易になりみんなハッピーになります。

デメリットとしては、命名が長くなりがちなので記述がダルいということだけかなと。

まとめ

SASS+FLOCSSを正しく使えるようになると、効率的かつカオスな状態にならないので使わない手はありません。
最初のステップであるOOCSSの概念を理解できたら次はSASS+FLOCSSの学習がおすすめ。

HTML,CSSはWeb上に情報が腐る程ありますので本とか買わなくても良いと思っています。
買って満足より即行動でググりながらコードを書いてみると良いでしょう。