enechain フロントエンドのアーキテクチャ構成/デザインシステムの統合

2024/03/13 リンケージ×enechain toBシステム開発勉強会 ~ PostgreSQLからReactまで の登壇資料です。

Transcript

1. フロントエンド アーキテクチャ構成と
 デザインシステムの統合
 Shunya078 (2024年3月13日) 

2. 自己紹介
 • 大坪 隼也 - (Otsubo Shunya)
 ◦ ただ お酒のんでる えんじにあ やってます 
 ◦ https://twitter.com/_Shunya078 
 • 専ら JSON に色を塗っています
 ◦ 経験上だと、React, Vue, Angular, jQuery… 
 ◦ 諸々 チョットダケ🤏 掻い摘んできました 
 • デザインシステム
 ◦ 社内でのプロダクトオーナー的なポジションを 
 やっているので宣伝しに来ました 
 2
3. 目次
 • ディレクトリ構成と各レイヤーの振る舞い
 • コンポーネント設計
 • デザインシステムとの統合
 3
4. 目次
 • ディレクトリ構成と各レイヤーの振る舞い
 • コンポーネント設計
 • デザインシステムとの統合
 4
5. 使用ライブラリのおさらい
 社内では
 ◦ React (Non Next) ベース の SPA App
 ◦ Chakra UI を UI ライブラリ
 ◦ Recoil でグローバル状態管理
 ◦ react-router(-dom) でルーター周りの制御
 ◦ Tanstack Query を API Client に
 使用しています
 (最近の Web App を作る大枠はこの辺りで大体良いでしょうか... 👀)
 5
6. ディレクトリ構成と各レイヤーの振る舞い
 前提： リポジトリの大枠構成
 • 1つのサービスとして、ユーザー向け App と 社内向け App の 2つを
 開発チームとして立ち上げることが多いので、最近は monorepo が多め
 • また、ユーザー向けと社内向け の App 同士の依存が大きい
 ◦ 見た目等々もかなり近い UI を組むことが多い 
 
 そのため、今回は monorepo としてよく使用されているパターンを紹介します
 ※ 非 monorepo の場合でも apps/ 配下は同じように分けています 
 6
7. ディレクトリ構成と各レイヤーの振る舞い
 monorepo と言いつつ
 比較的大枠はシンプル
 • app 同士で
 共通利用するか否かが
 まず前提
 • packages 配下も
 ui / utils の使い分けは
 .ts ファイルか
 .tsx ファイルか程度
 
 7
8. ディレクトリ構成と各レイヤーの振る舞い
 app の中もシンプルに
 思想は常に
 横断使用されるか否か
 routes や globalStates も
 全体で利用される
 = 全ページで横断使用される
 8
9. ディレクトリ構成と各レイヤーの振る舞い
 pages を最小単位とする
 • index.tsx は
 components, hooks...
 を呼び出す Container 的な 立ち位置
 
 ※ Container-Presentational Component Pattern
 9
10. ディレクトリ構成と各レイヤーの振る舞い
 ⭕ 本構成で良かったこと
 • 新規実装時にファイルの置き場に困らない
 ◦ 新規機能開発が多く進んでいく 弊社のようなフェーズで有効 
 
 • Apps 配下での階層が深くなりすぎない
 • ディレクトリ内で異なる概念が生まれない
 ◦ レイヤーごとの命名で統一されるので、URL ファーストの設計で見られる 
 pages > A > [_id] のような場合に「components」と「_id」が共存しない 
 
 • スコープが広がりすぎない
 ◦ A 機能が B 機能, C 機能... に依存しているような場合でも、 
 「どこを直せばいいんだ」が起こりにくい 
 10
11. ディレクトリ構成と各レイヤーの振る舞い
 ❌ 本構成で改善したいこと
 • 抽象化がやや難しい
 ◦ 扱うドメインの Entity や 機能に 1:1 で作っていくことになるので、 
 プリミティブに扱っていくことを意識しないと、似たロジックが散見する 
 • 依存機能の開発に弱い
 ◦ A ページの機能が B のページに依存しているような場合、 
 URL ファーストで分割されていると、A と B は独立していることが多い 
 ◦ 紹介した分け方だと、B を改修する際に A が壊れてしまうリスクがある 
 ▪ そのため 分割粒度 を意識する、ページ間の参照はどの程度まで許容するか、 
 チーム内で合意が必要 
 11
12. 目次
 • ディレクトリ構成と各レイヤーの振る舞い
 • コンポーネント設計
 • デザインシステムとの統合
 12
13. コンポーネント設計
 • packages/ui と apps/components の
 棲み分けは apps の再利用性
 • p6 前述の通り、apps 同士での独立度合いが弱いので
 共通コンポーネントを packages/ui に置くことで
 速度面でのメリットを取るようにしている
 
 13
14. コンポーネント設計
 • コンポーネントの最小単位は
 Chakra と 社内の Design System を
 使用している
 • Feature は API 等々の依存も
 許可するような形
 • components, pages/components の
 棲み分けは pages での再利用性
 14
15. 🤔 common が肥大化するのでは？
 15
16. 目次
 • ディレクトリ構成と各レイヤーの振る舞い
 • コンポーネント設計
 • デザインシステムとの統合
 16
17. Common が肥大化する原因
 common の役割：外部依存がない振る舞いを持つコンポーネント群
 
 「見た目やスタイルなどの UI ロジックをサービス内で共通化したい」
 
 がそもそものモチベーションのはず
 17
18. サービス内で共通化...🤔 
 18
19. common に置かれる
 ベースのようなモノを
 社内で共通化すれば良い🤗
 19
20. ということで
 弊社では デザインシステムを
 運用しています
 20
21. Chakra ＋ デザインシステム
 • UI ライブラリとして、コンポーネントも提供する Chakra に
 デザイントークンを与えた上で配布するデザインシステムを使用
 • 内部パッケージとして Google Artifact Registry で配布
 詳細はこちら：https://techblog.enechain.com/entry/google-artifact-registry-package 
 
 21
22. Chakra ＋ デザインシステム
 デザインシステム自体のメリット
 • サービスだけでなく、会社としての UI/UX の一貫性を保つことができる
 • デザイナーとの共通言語として、コンポーネントを扱える
 • 再利用可能なコンポーネントの配布によって、
 開発効率を上げることができる
 ◦ B 向けのプロダクトを大量に作るようなフェーズでは特に有効 
 etc...
 22
23. Chakra ＋ デザインシステム
 Chakra を使用した デザインシステムとしてのメリット
 • 1 から 最小単位のコンポーネントをフルスクラッチで作るよりも、 
 styled props を制約していく方に舵を切ることで、機能開発にリソースが割ける 
 • toB サービスの初期 開発フェーズでも待ちが発生しにくい 
 ◦ 「A さんが 一旦大量のコンポーネントを入れてくれるまで...」 
 「これはデザインシステムにないから...」といった 
 色塗りの達人 による実装を待たなくても、直接 Chakra を使ってスピード感持って作れる 
 23
24. Chakra ＋ デザインシステム
 • 社内での共通化の仕組みにより、 
 新規立ち上げのプロジェクトでも 2ヶ月強でリリースに 
 ◦ 直近のべ 2サービス
 しかし
 • まだまだ 提供しきれていないコンポーネントも、 
 運用レベルで決まってないこともたくさんある 
 → 完成した状態で提供しなくても、「とりあえず使ってもらえる」状態が大事 
 24 https://techblog.enechain.com/entry/design-system-2023 

25. まとめ
 - ディレクトリ構成 は認知負荷を下げるための 境界線が重要
 - 「とりあえず使ってもらえる」デザインシステムは良いぞ
 - まだまだ発展途中、常に進化を遂げる
 25