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
120
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
140
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
360
Other Decks in Technology
See All in Technology
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
160
Chasing the White Whale of Open Source - ROI
mrbobbytables
0
110
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
150
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
470
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
3
360
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
430
Storybook との上手な向き合い方を考える
re_taro
5
1.8k
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
4
250
型チェック 速度改善 奮闘記⌛
tocomi
1
140
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.4k
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.9k
心が動くエンジニアリング ── 私が夢中になる理由
16bitidol
0
110
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Gamification - CAS2011
davidbonilla
80
5k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
GitHub's CSS Performance
jonrohan
1030
460k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Navigating Team Friction
lara
183
14k
Statistics for Hackers
jakevdp
796
220k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
How STYLIGHT went responsive
nonsquared
95
5.2k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
120
Designing the Hi-DPI Web
ddemaree
280
34k
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