Mirai TranslatorのReactリプレイスでMUI(Material-UI)を採用した理由

Mirai Translatorのフロントエンド刷新プロジェクト

テキスト翻訳やファイル翻訳機能を提供する、みらい翻訳のプロダクト「Mirai Translator®」は、2017年にリリースされ、今日まで機能追加・改善が行われてきました。

リリースから数年が経ち、当時の技術スタックで構成されたMirai Translatorのフロントエンドでは、引き続き優れたセキュリティ性や、UI/UXを持つサービスを提供することが困難であると判断し、モダンな技術によるリプレイスプロジェクトが進行中です。

採用した技術スタック

今回リプレイスにあたって採用した代表的な技術を紹介します。

上の4つに関しては、2022年のフロントエンドプロジェクトで広く採用されおり、その優位性が既に多くの場所で議論されているため、あえてこの記事でMirai Translator開発で採用した理由を語る必要はないでしょう。

今回は、UIコンポーネントライブラリであるMUIを採用した理由を語りたいと思います。

UIコンポーネントライブラリの必要性

モーダルやツールチップ等、落とし穴の多いコンポーネントの再実装を避けたい

ユーザビリティ性の高いモーダルをイチから実装するのは、フォーカストラップ、role属性、キーバインドの実装…かなり難易度が高いです。

同じように、ツールチップに関してもフォーカス時の動作、portalの使用など、考えるだけでも面倒な実装が待っています。

もちろん、react-modal, Popperのようなライブラリを導入しても良いですが、都度適切なライブラリを選定をする必要があります。一方で、それらはMUIのようにすぐに使える、全体的な調和の取れたReactコンポーネントを提供しているわけではなく、実際にプロダクトに使うには多くの調整が必要です。

色の管理、スペーシング、ブレークポイントなどの定数を決まったルールに従って管理したい

MUIは独自のthemeを定義することで、プロダクトに使われるべき色やブレークポイントを限定することができます。

MUIのtheme定義は細かくカスタムできる拡張性を持ちつつ、きちんとした型が定義されていて、堅牢性も兼ね備えています。グローバルCSSで好き勝手に上書きできてしまうような悪夢は起こりにくくなっています。

Theming - MUI

Stack, Gridといったflex-box糖衣コンポーネントを使いたい

単純に言えばdiv + flex-boxではあるものの、あえてコンポーネントとして切り出して名前をつけたStackコンポーネントがMUIにはあります。

コンポーネントとして <Stack> という名前を持つことで、コードリーディングの際にどのような画面が出力されるのか予想しやすくなります。

FlutterやSwift UIでも似たような方法でUIを構築できますが、最近の流行りなのでしょうか。

sxプロパティによるスタイル定義をしたい

The sx prop - MUI

ほぼ全ての(Container的コンポーネントを除く)MUIのコンポーネントは、sxプロパティが生えています。sxプロパティによって、TailwindCSSライクな、ユーティリティファーストな方法でスタイル定義ができます。

他の技術との比較

Chakra-UI

同じくUIコンポーネントライブラリで、sxプロパティやStackコンポーネントがあり、MUIと非常によく似た設計となっています。

MUIと比較すると、管理画面でよく使うTable関係のコンポーネントにやや機能不足を感じました。

また、themeを拡張する際の型定義がMUIほど厳密ではなく、先述のメリットを享受しにくいのもポイントでした。

MUIと比べて後発のライブラリであるため、コンポーネントの数や機能で劣るのは仕方ないでしょう。一方でシンプルなAPIでとっつきやすく、複雑なコンポーネントが必要でないアプリケーションでは活用できそうです。(みらい翻訳の他のプロダクトで採用事例があります)。今後のさらなる発展に期待しています。

MUIをプロダクトでうまく使うコツ

MUIをプロダクトで採用し、うまく運用するコツは、MUI Wayを外れないことです。

公式ドキュメントをよく読む

MUIの各コンポーネントに関するページは、実装例があるページと、コンポーネントのAPI仕様が書かれたページに分けられています。

例えば、Buttonであれば

React Button component - MUI

Button API - MUI

のように。

実装例のページだけを見て、サンプルコードをコピペして使うのではなく、APIのページの方も一読することを強くおすすめします。

カスタマイズするために苦労してロジックを書いたり、sxプロパティを駆使したりして作ったその機能・デザイン、実はプロパティ一つ変えるだけで実現できたる、ということがあります。

MUIに付属している機能をなるべく使うことで、より可読性・保守性の高いアプリケーションになります。

themeを活用する

場当たり的なsxプロパティによるスタイリングの乱発は、全体で調和の取れたデザインに整えるのを難しくします。

sxプロパティを使う場合、まずthemeに書けないか検討しましょう。

MUIを採用することに関してのデメリット

UIのコードが特定のライブラリとべったりになる

Stack, Boxを駆使してフレームを作り、便利なユーティリティ系コンポーネントを使って作り上げたアプリケーションから、MUIを剥がしたり別のUIライブラリに乗り換えるのは大変な工数がかかるでしょう。開発効率を得た結果の犠牲ですが、UIのコードはある程度このようになるのは仕方ないと考えています。一方で、UIよりも生存期間が長いであろうビジネスロジックのコードの保守性を高める努力はするべきです。