はじめに
SCSS の Mixin めちゃくちゃ便利なんですよね。
個人的には作ると便利だけど、運用となると難しくなることがあるなぁと思ってきましたので、そうした事例を紹介しながらお話していこうと思います。
※説明上記載しているところもありますが Mixin の詳しい利用方法はこの記事では説明しませんので、他の記事を参考にしてください。
Mixinって便利ですよね
何と言ってもこれがないと生きていけないレベルにみなさん依存していると思います。
例えば以下のようにリンクテキストで利用することを想定して text-link という Mixin を用意しておくと、サイトのフッターに表示する固定ページのリンクや、ニュース・ブログサイトの関連記事のリンクなどでとても役立つでしょう。
@mixin text-link {
text-decoration: none;
&:hover,
&:focus {
text-decoration: underline;
}
}
- アプリケーション全体で統一感を作れる
- ソースコードの可読性が上がる
Mixinを使うルール
まずは Mixin を使うならという自分なりのルールを考えてみましたので、列挙してみます。
- 自己ドキュメント化できること
このコード自身がある意味仕様になれること - コーディングが苦手な人にも理解できるように入れ子は使わない（ 擬似クラス（
:hoverなど) は例外として）。 - それ自身にアプリケーションのコンテキストを含まないこと
Mixin を使うべき箇所
Media Query
昨今のWeb開発では一番 Mixin の恩恵を受けるところかなと思っています。
レスポンシブの Breakpoint を毎度一つ一つ書くのはもちろん大変なことですし、Mixin の実装に含まれる内容がそのままアプリケーションの仕様になってくるので、チーム開発でも大いに役に立つと思っています。
Button, Link (リンクインタラクション)
ボタンやリンクに関する Mixin です。こちらは Variables の恩恵のほうが大きいかもしれません。
特に業務ツール系のアプリケーションなどでは、ボタンやリンクなど状態によって UI を出し分けるケースが多いので、こちらも Mixin 化しておくと良いと思います。
Form UI
フォームもボタンと同様、アプリケーション全体で統一感を持たせたいです
とはいえ、アプリ全体のデザインのなかでもサイズ感などは変わらない
バリデーションで発火する
Mixinの運用が難しいポイント
- 初期に作った Mixin でアプリケーション全体で多用されていると影響範囲が大きくなってしまい、用意に変更できない
- それぞれの機能に合わせたニーズに対応していくうちに、Mixin である意味がなくなってくる
こんなものは全くもって作るべきじゃない
内容が予想しにくいもの
内容が想像しにくいものは、Mixin に限らず開発するすべてにおいて該当するものですが、作成するときはわかりやすい名前をつけましょう。
@mixin hoge {
br {
display: none;
}
}
Mixin in Mixin （例外: ボタン系のMixin）
役割は小さくまとめましょう。Mixinが別のMixinに影響を与えだすとメンテナンスが大変になる一方です。
@mixin text-title {
font-size: 12px;
text-decoration: underline;
color: white;
}
@mixin head-section {
.title {
@include text-title;
padding-bottom: 2px;
border-bottom: 2px solid white;
background-gray: black;
font-size: 14px;
}
}
さいごに
誰も「あしたのことはわからない」ので、将来を見据えた実装などではなく、足元で効率の良い実装を心がけていきましょう。
Discussion