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
150
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
4.3k
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
500
Other Decks in Technology
See All in Technology
クマ×共生 HACKATHON - 熊対策を『特別な行動」から「生活の一部」に -
pharaohkj
0
180
ML Pipelineの開発と運用を OpenTelemetryで繋ぐ @ OpenTelemetry Meetup 2025-07
getty708
0
320
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷
ojima_h
4
520
隙間時間で爆速開発! Claude Code × Vibe Coding で作るマニュアル自動生成サービス
akitomonam
2
200
[TechNight #91] Oracle Database 最新パフォーマンス分析手法
oracle4engineer
PRO
3
150
Expertise as a Service via MCP
yodakeisuke
1
160
With Devin -AIの自律とメンバーの自立
kotanin0
2
790
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
1.3k
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
280
AIエージェントを支える設計
tkikuchi1002
11
2.3k
alecthomas/kong はいいぞ
fujiwara3
6
1.1k
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
620
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
The Cult of Friendly URLs
andyhume
79
6.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Practical Orchestrator
shlominoach
189
11k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
GraphQLとの向き合い方2022年版
quramy
49
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Being A Developer After 40
akosma
90
590k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
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