MUIをベースにしたデザインシステムの構築CTOA若手エンジニアコミュニティ 勉強会#1
View Slide
自己紹介早瀬和輝◦ 2021年4月 BuySell Technologies入社◦ フロントエンドエンジニア◦ React / TypeScript / Go / GraphQL / Hasura◦ Zenn: kazu777◦ 趣味:マンガ、アニメ、開発、旅行2
アジェンダ◦ 背景◦ MUIとは◦ デザインシステムを導入する目的◦ 具体的な取り組み◦ おわりに3
背景14
背景リユースプラットフォームを開発中5
背景◦ 各サービスごとに開発チームが存在◦ サービス間でUI・UXを統一する必要がある◦ プラットフォーム全体のデザインシステムはない作りたい気持ちはあるが開発コストが大きい全体のデザインシステムの構築はもう少し未来の話6
背景チーム間で共通のコンポーネントライブラリを使用することで、UI・UXの統一を図るその他のルールや開発は基本的に各チームに委ねる7※今回紹介するのは自分が所属するチーム内のデザインシステムについてであり、プラットフォーム全体のデザインシステムについてではないです
MUIとは28
MUIとは◦ React用のコンポーネントライブラリ◦ Github stars 84.1k(2023/01/21時点)◦ かなり多い種類のコンポーネントを提供9
MUIとは10https://mui.com
MUIを選択した理由◦ コンポーネントが豊富◦ デザインがカスタマイズしやすい◦ Figmaが提供されている11
デザインシステムを導入する目的312
デザインと実装の同期◦ 変更の反映をしやすくする◦ 運用コストは極力抑える属人性の排除◦ 特定の実装者に依存しない◦ 実装者による差異を減らす◦ レビューコストの削減デザインシステムを導入する目的13
具体的な取り組み414
具体的な取り組み◦ カラーコードの集約◦ デフォルトスタイルのオーバーライド◦ Typographyの定義◦ Atomic Designの不採用15
具体的な取り組み◦ カラーコードの集約◦ デフォルトスタイルのオーバーライド◦ Typographyの定義◦ Atomic Designの不採用16
カラーコードの集約カラーコードをピックアップして名前を付け、定数として定義17Figma src/styles/theme.ts
カラーコードの集約コンポーネント側で指定する際は定数を使用カラーコードが氾濫せず、型安全に実装できる18
具体的な取り組み◦ カラーコードの集約◦ デフォルトスタイルのオーバーライド◦ Typographyの定義◦ Atomic Designの不採用19
デフォルトスタイルのオーバーライドオーバーライドしたい場合はトップレベルで指定20
具体的な取り組み◦ カラーコードの集約◦ デフォルトスタイルのオーバーライド◦ Typographyの定義◦ Atomic Designの不採用21
Typographyの定義fontSizeやfontWeightは使用するものを厳選22
Typographyの定義sizeとweightをconst assertionで定義して、それらをPropsで受け取るコンポーネントを作成23
Typographyの定義MUIのTypographyのimportをeslintで禁止して、独自定義のTypographyのみ使用する予期しないsize, weightが使用されることがなくなる24
具体的な取り組み◦ カラーコードの集約◦ デフォルトスタイルのオーバーライド◦ Typographyの定義◦ Atomic Designの不採用25
Atomic Designに感じていた課題から不採用◦ Organismsの肥大化◦ コンポーネント設計の難しさAtomic Designの不採用26
ざっくりとしたディレクトリ構成コンポーネントの分類はシンプルにするAtomic Designの不採用27
コンポーネントの設計に悩む場面が少なくなるAtomic Designの不採用28アプリケーション共通で使用するsrc/components src/features/*/componentsYes No
おわりに529
おわりに◦ MUIをベースにすることで、低コストでデザインシステムを構築できた◦ デザインシステムの導入目的も達成できているデザインとの同期には、ほぼコストがかかってないチーム全員でフロントエンドの開発に取り組めている30