こんにちは、id:cw-nishiguchi です。 最近、SCSSファイルを、該当のUIコンポーネントファイルと同じディレクトリに置いたらよかったので共有したいと思います。
このエントリーは @kyo_ago の「UnitTestと対象コードを同じディレクトリに置いたらよかった話」のオマージュです。 creators-note.chatwork.com
具体的には
各チームでプロジェクトのディレクトリ構造はそれぞれだと思いますが、CSSファイルに関してよく見るのは、css/ や styles/ というディレクトリにまとめていく形だと思います。
チャットワークでもこういった感じの構造をしていました。
こうした場合、対象となる各UIコンポーネントのファイルと遠くなり、ファイルの行き来が大変なため、次のようにUIコンポーネントとSCSSを同じディレクトリに置くことにしました。
.
└── source
└── ui
└── RoomList
└── RoomList.tsx
└── RoomList.scss
※ファイル名などはサンプルです
共通で使うSCSSは、styles/ ディレクトリに置いています。
利点
この形式にして次のようなメリットがありました。
UIコンポーネントとSCSSファイルとの行き来が楽
コンポーネント編集時、スタイルの修正が必要な場合でも、同じディレクトリにあるので、すぐにSCSSにたどり着けます。 ファイル検索や、IDEで飛ぶこともできますが、ファイル一覧からすぐに開けるのは便利です。
SCSSが適切な単位で分割できる
コンポーネント単位でSCSSファイルを機械的に分割できるため、そのファイルに定義するルールセットもそのコンポーネントに関するものだけになります。
人によって分割する単位が違ってくる、ということもなくなります。
そのため、どこに記述していいか迷うことなく、コーディングができます。また、関係のない要素のルールセットが追加されることもありません。
css/ ディレクトリ以下でまとめて管理する形でも、ファイルを分割することはできますが、分割する単位を検討したり、分割したファイルの名前をどうするか考えたり、分割することに多少意識的になる必要があります。
ファイルが探しやすい
css/ ディレクトリ以下にズラッとファイルが並んでいるより、各コンポーネントディレクトリ単位で必要ファイルがまとまっている方が、探しやすいです。
これもIDEの機能で補完できますが、クラスは何かを調べて、検索して、というより、触っているコンポーネントのディレクトリを見て、そこにあるSCSSを開くという方が幾分便利なように思います。
欠点
この形式で感じている欠点は以下です。
共通mixinや変数の命名に工夫が必要
コンポーネントをまたいで使用するようなmixinや変数は、どうしても、広範囲に参照できる場所にあるファイルに書かないといけません。 そうした場合、その影響範囲を限定的にするには、名前で使用場所や、役割を明確にするため、名前が長くなりがちです。
さいごに
ファイル管理は、各チームそれぞれのやり方があるので、ここで紹介した方法が正解とは思いません。 ただ、私達のチームでは、この管理方法が今のところいい感じなので、参考にしていただけると幸いです。
