MUI入門
はじめに
実務でMUIを本格的に使用することになりそうなので、MUIに入門していきたいと思います。
なお、筆者はMUIの前身のMaterial UIは少し使用したことがあり、Material Designについてはエアプです。それらを踏まえて対戦よろしくお願いします。
本記事で触れること
- パッケージ構成からみるMUIの概要
- MUIのカスタマイズ
- MUIで何ができるのか
- その他のUIコンポーネントライブラリと比較した場合のMUIの立ち位置
本記事で触れないこと
- MUIの導入手順
- MUIの具体的な使用方法
パッケージ構成からみるMUIの概要
※この章は基本的には以下のページを和訳したものとなります。
まずMUIには以下の2種類のプロジェクトが存在します。
- MUI Core
- MUI X
みなさんがMUIと聞いて思い浮かべるのはMUI Coreの方だと思います。
MUI Xは複雑なユースケースに対応した高度なReact UIコンポーネント集ということなので、本記事の対象外とします。
そしてMUI Coreには以下の5種類のパッケージが存在します。
@mui/material@mui/base@mui/system-
styled engines@mui/styled-engine@mui/styled-engine-sc
※正確には@mui/stylesというパッケージも存在しますが、こちらはMaterial UIで使用されていたもので現在非推奨となっており将来的に削除される予定のため、本記事の対象外とします。
@mui/material
GoogleのMaterial Designを実装した、包括的なコンポーネントライブラリです。
デフォルトでMaterial Design準拠のスタイルが施されています。
また後述する@mui/systemがdependencyとして含まれているため、別途@mui/systemをインストールする必要はなく、@mui/material経由でインポートすることができます。
@mui/base
スタイルなしのReact UIコンポーネントと低レベルのフックのライブラリです。
簡単に言うと@mui/materialからMaterial Design準拠のスタイルを取り除いたもので、イメージとしてはRadix UIのようなHeadless UIコンポーネントライブラリに近いと思います。
基本的なユースケースとしては、@mui/materialを使用しているが一部のコンポーネントでMaterial Design準拠のスタイルとは全く異なるデザインにしたい場合に@mui/materialの該当のコンポーネントの全てのスタイルをオーバーライドする代わりに使用することが想定されています。
ただしこのパッケージは本記事執筆時点ではアルファ版となっています。
MUIの将来のバージョン（v6以降）では@mui/baseのコンポーネントとフックを基礎構造として使用する予定のようです。
@mui/system
MUIのコンポーネントライブラリ（@mui/materialや@mui/base）のデザインをカスタマイズするためのCSSユーティリティ集です。
themeオブジェクトによるグローバルなカスタマイズやsxによるその場限りのカスタマイズを可能にします。
CSSユーティリティを作成するためのエンジンとして後述するstyled enginesに依存しています。
styled engines
CSSユーティリティを作成するためのエンジンです。
以下の2種類のパッケージが存在します。
@mui/styled-engine@mui/styled-engine-sc
@mui/styled-engineは@emotion/reactと@emotion/styledに、@mui/styled-engine-scはstyled-componentsに依存しています。
デフォルトでは@mui/styled-engineが使用されます。
この場合は@mui/styled-engineを別途インストールする必要はありません（ただし@emotion/reactと@emotion/styledについては別途インストールする必要があります）。
styled-componentsを使用したい場合は@mui/styled-engine-scとstyled-componentsを別途インストールする必要があります。
MUIのカスタマイズ
themeのカスタマイズ
MUIのthemeでカスタマイズできる設定変数は以下の7種類です。
.palette.typography.spacing.breakpoints.zIndex.transitions.components
.componentsを除く6種類の設定変数はいわゆるデザイントークンです。
MUIではこれらのデザイントークンをカスタマイズすることでプロダクトの世界観を表現することになると思います。
コンポーネントのカスタマイズ
MUIのコンポーネントにはデフォルトでMaterial Design準拠のスタイルが施されていますが、それをカスタマイズする方法が以下のページで紹介されています。
4種類のカスタマイズ方法が紹介されていますが、1. One-off customizationではその場限りのカスタマイズについて紹介されています。
その場限りのカスタマイズについてはsxの汎用性が高く、使いやすそうでよく使うことになりそうです。
それ以外の3種類ではグローバルなカスタマイズについて紹介されています（2. Reusable componentは少し違いますが）。
グローバルなカスタマイズについてはカスタマイズ対象のコンポーネントの数が増えれば増えるほど、スタイルのカスタマイズ度合いが増せば増すほどMUIを使用するメリットが薄くなってしまいそうです（Headless UIコンポーネントライブラリにスタイルを付与するのと大差がなくなってしまうため）。
MUIで何ができるのか
公式ドキュメントを読んでみて、MUIで何ができるのかを一言で表すと、「工数を抑えつつMaterial Designベースのデザインシステムを構築すること」だと思います。
MUIのthemeをカスタマイズしてデザイントークンを定義するだけでコンポーネントライブラリが完成し、後はそれらを組み合わせてパターンライブラリを作成していけば、短期間でMaterial Designベースのデザインシステムを構築できると思います。
ただしMUIを使用したパターンライブラリの作成にはMaterial Designの知識が必須なので、MUIを正しく使用してMaterial Designベースのデザインシステムを構築するのは思っている以上にハードルは低くなさそうです。
その他のUIコンポーネントライブラリと比較した場合の立ち位置
MUIで最も特徴的なのは「デフォルトでMaterial Design準拠のスタイルが施されている」点です。
MUIのコンポーネントにはMaterial Designというデザインシステムの思想が色濃く反映されています。
そういった意味ではRadix UIのようなHeadless UIコンポーネントライブラリの対極に位置していると言えるでしょう。
また筆者もよく使用しているChakra UIについてはこれら2つの中間に位置するUIコンポーネントライブラリと言えそうです。
おわりに
今回はMUIの公式ドキュメントを読んで、MUIの概要やMUIで何ができるのかなどをまとめてみました。
個人的には以下の2点を満たす場合にMUIを選定すればよさそうだなと思いました。
- コンポーネントライブラリ作成の工数を抑えたい
- Material Designに沿ってデザインを進めることを許容できる（Material Designのメリット・デメリットを許容できる）
以上何かの参考になれば幸いです。
Discussion