Closed3

Muiを薄く使うかスクラッチか

OpionOpion

動機

セレクトボックスやモーダルダイアログなど自前でアクセシビリティとデザインを両立させるのがしんどいコンポーネントを楽に実装したい。自前で実装をして「iOSだけXXXが動作しない、表示されない」などのバグを踏み抜きたくない。

利用方法の草案

デザインシステムではなく一部のコンポーネントの実装/保守工数の削減が目的。
そのためすぐ捨てられるように実装する。

  • コンポーネントごとにMuiを閉ざす
    • _app.tsxではなくコンポーネントに対しThemeProviderを生やす
    • I/FはMuiの利用有無に拘らない形式で出す
  • Mui利用コンポーネントと他のコンポーネントは疎にする
    • [Problem] 線引きが難しい
      • select > button, modal, input > accordion > card, listのイメージだけど明文化したい

保守時の弊害

長く放置されてあとから追加開発が始まった、とかのケースで

  • Muiの当時のバージョンのドキュメントやStackOverflowが探しづらいので高度にカスタマイズされたコンポーネントを扱いづらい
    • 避けるにはこまめにバージョンアップする必要がある
      • 破壊的変更があった場合に保守工数が嵩む
  • Reactから新規の何かに移行するとき、tsx + css-modulesに比べて移行工数が嵩む
  • Reactのメジャーアップデート時に、React自体は破壊的な変更がなくてもMui側が壊れる恐れがある
OpionOpion

https://mui.com/joy-ui/customization/using-css-variables/
CSS変数も組み込めるみたいだから

_app.tsxではなくコンポーネントに対しThemeProviderを生やす

ではなく、普通に_app.tsxに入れてやる、でよさそう。
MUIコンポーネントをwrapして利用する方針はそのままで
あとはどこまで利用するか、になるかも。

現状の候補は

  • Feedback
  • Navigation
  • Inputs

の3カテゴリ。ここら辺はコンポーネント単体で充足するからマイグレーション等も容易そう。

OpionOpion

結局素のHTMLがまあまあ優秀なのと対象環境が最近のものだったのでフルスクラッチしてしまった。うーん(?)

このスクラップは2023/05/25にクローズされました