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
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
340
Other Decks in Technology
See All in Technology
失敗しないOpenJDKの非互換調査
tabatad
0
270
Nix入門パラダイム編
asa1984
2
200
APIテスト自動化の勘所
yokawasa
7
4.1k
ネット広告に未来はあるか?「3rd Party Cookie廃止とPrivacy Sandboxの効果検証の裏側」 / third-party-cookie-privacy
cyberagentdevelopers
PRO
1
120
Automated Promptingを目指すその前に / Before we can aim for Automated Prompting
rkaga
0
110
【若手エンジニア応援LT会】AWSで繋がり、共に成長! ~コミュニティ活動と新人教育への挑戦~
kazushi_ohata
0
170
プロダクトチームへのSystem Risk Records導入・運用事例の紹介/Introduction and Case Studies on Implementing and Operating System Risk Records for Product Teams
taddy_919
1
160
Vueで Webコンポーネントを作って Reactで使う / 20241030-cloudsign-vuefes_after_night
bengo4com
4
2.5k
AIを駆使したゲーム開発戦略: 新設AI組織の取り組み / sge-ai-strategy
cyberagentdevelopers
PRO
1
130
【技術書典17】OpenFOAM(自宅で極める流体解析)2次元円柱まわりの流れ
kamakiri1225
0
210
visionOSでの空間表現実装とImmersive Video表示について / ai-immersive-visionos
cyberagentdevelopers
PRO
1
100
Jr. Championsになって、強く連携しながらAWSをもっと使いたい!~AWSに対する期待と行動~
amixedcolor
0
180
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Visualization
eitanlees
144
15k
Embracing the Ebb and Flow
colly
84
4.4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
Writing Fast Ruby
sferik
626
61k
Designing the Hi-DPI Web
ddemaree
280
34k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
4 Signs Your Business is Dying
shpigford
180
21k
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