Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
enechain フロントエンドのアーキテクチャ構成/デザインシステムの統合
Search
Shunya078
March 15, 2024
Technology
0
130
enechain フロントエンドのアーキテクチャ構成/デザインシステムの統合
2024/03/13 リンケージ×enechain toBシステム開発勉強会 ~ PostgreSQLからReactまで の登壇資料です。
Shunya078
March 15, 2024
Tweet
Share
More Decks by Shunya078
See All by Shunya078
我々のデザインシステムは Chakra v3 にアップデートします
shunya078
2
3.6k
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
420
Other Decks in Technology
See All in Technology
例外処理を理解して、設計段階からエラーを「見つけやすく」「起こりにくく」する
kajitack
12
3.7k
ソフトウェア開発現代史:製造業とソフトウェアは本当に共存できていたのか?品質とスピードを問い直す
takabow
15
5.3k
CNAPPから考えるAWSガバナンスの実践と最適化
yuobayashi
5
680
[2024年10月版] Notebook 2.0のご紹介 / Notebook2.0
databricksjapan
0
1.6k
Tokyo RubyKaigi 12 - Scaling Ruby at GitHub
jhawthorn
2
210
panicを深ぼってみる
kworkdev
PRO
2
150
Oracle Cloud Infrastructure:2025年1月度サービス・アップデート
oracle4engineer
PRO
0
200
ObservabilityCON on the Road Tokyoの見どころ
hamadakoji
0
210
業務ツールをAIエージェントとつなぐ - Composio
knishioka
0
110
Enhancing SRE Using AI
yoshiiryo1
1
270
EDRからERM: PFN-SIRTが関わるセキュリティとリスクへの取り組み
pfn
PRO
0
110
Japan AWS Jr. Championsがお届けするre:Invent2024のハイライト ~ラスベガスで見てきた景色~
fukuchiiinu
0
1.1k
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.2k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Automating Front-end Workflow
addyosmani
1367
200k
Scaling GitHub
holman
459
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
20
2.4k
Fireside Chat
paigeccino
34
3.2k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
19k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
Building an army of robots
kneath
302
45k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
Transcript
フロントエンド アーキテクチャ構成と デザインシステムの統合 Shunya078 (2024年3月13日)
自己紹介 • 大坪 隼也 - (Otsubo Shunya) ◦ ただ お酒のんでる
えんじにあ やってます ◦ https://twitter.com/_Shunya078 • 専ら JSON に色を塗っています ◦ 経験上だと、React, Vue, Angular, jQuery… ◦ 諸々 チョットダケ🤏 掻い摘んできました • デザインシステム ◦ 社内でのプロダクトオーナー的なポジションを やっているので宣伝しに来ました 2
目次 • ディレクトリ構成と各レイヤーの振る舞い • コンポーネント設計 • デザインシステムとの統合 3
目次 • ディレクトリ構成と各レイヤーの振る舞い • コンポーネント設計 • デザインシステムとの統合 4
使用ライブラリのおさらい 社内では ◦ React (Non Next) ベース の SPA App
◦ Chakra UI を UI ライブラリ ◦ Recoil でグローバル状態管理 ◦ react-router(-dom) でルーター周りの制御 ◦ Tanstack Query を API Client に 使用しています (最近の Web App を作る大枠はこの辺りで大体良いでしょうか... 👀) 5
ディレクトリ構成と各レイヤーの振る舞い 前提: リポジトリの大枠構成 • 1つのサービスとして、ユーザー向け App と 社内向け App の
2つを 開発チームとして立ち上げることが多いので、最近は monorepo が多め • また、ユーザー向けと社内向け の App 同士の依存が大きい ◦ 見た目等々もかなり近い UI を組むことが多い そのため、今回は monorepo としてよく使用されているパターンを紹介します ※ 非 monorepo の場合でも apps/ 配下は同じように分けています 6
ディレクトリ構成と各レイヤーの振る舞い monorepo と言いつつ 比較的大枠はシンプル • app 同士で 共通利用するか否かが まず前提 •
packages 配下も ui / utils の使い分けは .ts ファイルか .tsx ファイルか程度 7
ディレクトリ構成と各レイヤーの振る舞い app の中もシンプルに 思想は常に 横断使用されるか否か routes や globalStates も 全体で利用される
= 全ページで横断使用される 8
ディレクトリ構成と各レイヤーの振る舞い pages を最小単位とする • index.tsx は components, hooks... を呼び出す Container
的な 立ち位置 ※ Container-Presentational Component Pattern 9
ディレクトリ構成と各レイヤーの振る舞い ⭕ 本構成で良かったこと • 新規実装時にファイルの置き場に困らない ◦ 新規機能開発が多く進んでいく 弊社のようなフェーズで有効
• Apps 配下での階層が深くなりすぎない • ディレクトリ内で異なる概念が生まれない ◦ レイヤーごとの命名で統一されるので、URL ファーストの設計で見られる pages > A > [_id] のような場合に「components」と「_id」が共存しない • スコープが広がりすぎない ◦ A 機能が B 機能, C 機能... に依存しているような場合でも、 「どこを直せばいいんだ」が起こりにくい 10
ディレクトリ構成と各レイヤーの振る舞い ❌ 本構成で改善したいこと • 抽象化がやや難しい ◦ 扱うドメインの Entity や 機能に
1:1 で作っていくことになるので、 プリミティブに扱っていくことを意識しないと、似たロジックが散見する • 依存機能の開発に弱い ◦ A ページの機能が B のページに依存しているような場合、 URL ファーストで分割されていると、A と B は独立していることが多い ◦ 紹介した分け方だと、B を改修する際に A が壊れてしまうリスクがある ▪ そのため 分割粒度 を意識する、ページ間の参照はどの程度まで許容するか、 チーム内で合意が必要 11
目次 • ディレクトリ構成と各レイヤーの振る舞い • コンポーネント設計 • デザインシステムとの統合 12
コンポーネント設計 • packages/ui と apps/components の 棲み分けは apps の再利用性 •
p6 前述の通り、apps 同士での独立度合いが弱いので 共通コンポーネントを packages/ui に置くことで 速度面でのメリットを取るようにしている 13
コンポーネント設計 • コンポーネントの最小単位は Chakra と 社内の Design System を 使用している
• Feature は API 等々の依存も 許可するような形 • components, pages/components の 棲み分けは pages での再利用性 14
🤔 common が肥大化するのでは? 15
目次 • ディレクトリ構成と各レイヤーの振る舞い • コンポーネント設計 • デザインシステムとの統合 16
Common が肥大化する原因 common の役割:外部依存がない振る舞いを持つコンポーネント群 「見た目やスタイルなどの UI ロジックをサービス内で共通化したい」 がそもそものモチベーションのはず
17
サービス内で共通化...🤔 18
common に置かれる ベースのようなモノを 社内で共通化すれば良い🤗 19
ということで 弊社では デザインシステムを 運用しています 20
Chakra + デザインシステム • UI ライブラリとして、コンポーネントも提供する Chakra に デザイントークンを与えた上で配布するデザインシステムを使用 •
内部パッケージとして Google Artifact Registry で配布 詳細はこちら:https://techblog.enechain.com/entry/google-artifact-registry-package 21
Chakra + デザインシステム デザインシステム自体のメリット • サービスだけでなく、会社としての UI/UX の一貫性を保つことができる • デザイナーとの共通言語として、コンポーネントを扱える
• 再利用可能なコンポーネントの配布によって、 開発効率を上げることができる ◦ B 向けのプロダクトを大量に作るようなフェーズでは特に有効 etc... 22
Chakra + デザインシステム Chakra を使用した デザインシステムとしてのメリット • 1 から 最小単位のコンポーネントをフルスクラッチで作るよりも、
styled props を制約していく方に舵を切ることで、機能開発にリソースが割ける • toB サービスの初期 開発フェーズでも待ちが発生しにくい ◦ 「A さんが 一旦大量のコンポーネントを入れてくれるまで...」 「これはデザインシステムにないから...」といった 色塗りの達人 による実装を待たなくても、直接 Chakra を使ってスピード感持って作れる 23
Chakra + デザインシステム • 社内での共通化の仕組みにより、 新規立ち上げのプロジェクトでも 2ヶ月強でリリースに ◦
直近のべ 2サービス しかし • まだまだ 提供しきれていないコンポーネントも、 運用レベルで決まってないこともたくさんある → 完成した状態で提供しなくても、「とりあえず使ってもらえる」状態が大事 24 https://techblog.enechain.com/entry/design-system-2023
まとめ - ディレクトリ構成 は認知負荷を下げるための 境界線が重要 - 「とりあえず使ってもらえる」デザインシステムは良いぞ - まだまだ発展途中、常に進化を遂げる 25
26