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
プロダクト横断を見据えた刷新プロジェクトのフロントエンド開発 / front-end development in revamp project
Search
Daiki Narushima
November 18, 2021
Programming
0
1.5k
プロダクト横断を見据えた刷新プロジェクトのフロントエンド開発 / front-end development in revamp project
GeekGig 『スタディサプリ x Showcase Gig』 〜フロントエンドを楽しむ〜
Daiki Narushima
November 18, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
オブジェクト指向のリ・オリエンテーション~歴史を振り返り、AI時代に向きなおる~
hanyudaeiiti
9
5.5k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
5
2k
[SF Ruby, March 2024] Rails on Wasm
palkan
0
360
SpringBoot+MyBatisで例外が出たときどこを見るか
syukai
0
110
せっかくモデル図描くのなら、嬉しいことが多い方がいいよね!
kuboaki
1
3k
受託開発でGitLab CI を活用していく
xiombatsg
1
260
Prepare for Jakarta EE 11 - Performance and Developer Productivity
ivargrimstad
0
350
どうしてこうなった命名集 ~🔥編~ / OOC 2024 LT
pictiny
5
3.9k
try! Swift Tokyo 2024 参加報告 / try! Swift Tokyo 2024 Report
hironytic
0
160
単体テストを書かない技術 #phpcon_odawara
o0h
PRO
24
7.6k
9年開発を牽引して見えてきた、共通化すべきものと個別でつくるもの ~プログラム言語~
shinout
1
640
OpenAPI を守るのは難しい
ohmori_yusuke
2
760
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
123
8.5k
Faster Mobile Websites
deanohume
296
30k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
355
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
185
16k
Making Projects Easy
brettharned
106
5.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
645
57k
Atom: Resistance is Futile
akmur
258
25k
Testing 201, or: Great Expectations
jmmastey
27
6.3k
The Brand Is Dead. Long Live the Brand.
mthomps
48
27k
The Invisible Customer
myddelton
114
12k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
153
14k
Designing the Hi-DPI Web
ddemaree
275
33k
Transcript
プロダクト横断を見据えた 刷新プロジェクトのフロントエンド開発 2021/11/18@GeekGig
自己紹介 • 成嶋大樹(なるしまだいき) • 次世代店舗創出プラットフォーム「O:derプラットフォーム」の開 発において、O:der ToGoを担当 • ReactとTypeScriptが好き 2
株式会社Showcase Gig フロントエンドエンジニア dnrsm
今日話すこと プロダクト横断を見据えた 刷新プロジェクトのフロントエンド開発 3
アジェンダ • 刷新プロジェクトについて • プロダクト横断のコンポーネントについて • コンポーネントの設計で気をつけたこと • プロダクトの実装・技術スタック •
振り返りと学び 4
1. 刷新プロジェクトについて 5
Product Backend やろうとしてること 6
何を刷新するのか • Platformからフロントエンドまで技術刷新を行う ◦ 今回話すのはフロントエンドについて • Vue→Reactベースの技術スタックに置き換える • デザインも全く新しいものに置き換わる ◦
それに伴いデザインシステムも構築する • UI/UXを統一するためのコンポーネント基盤を作る 7
以前まではどうやっていたか • テイクアウトもテーブルオーダーも全く別のデザイン • 担当するチームがそれぞれ別のリポジトリで作業をしていた 8
O:der Backend Shared Components 9 何を刷新するのか
どうやって進めるのか • Yarn Workspaceでmonorepo構成に ◦ ひとつのリポジトリで複数の packageを管理 する • 各packageを担当するチームが独立して
作業をする ◦ 影響範囲を明確にする 10
どうやって進めるのか • eslint, tsconfig, prettierの設定を共通化 ◦ monorepoなのでルートに置いて各 package でextendsする形で利用 11
2. プロダクト横断のコンポーネントについて 12
O:der Backend Shared Components 13
Shared Componentsとは • 現状はOSSにはせず社内だけで使うコンポーネントライブラリ • toCプロダクトのデザインシステム • これをもとにテイクアウトアプリやイートインアプリを作る 14
なぜ作るのか • ユーザー体験や振る舞いを統一したい • 一貫したデザインによりユーザー体験を向上させる • 価値提供のスピードを向上させる • コンポーネントの作り方に一貫したルールができる 15
何を作ったのか 大きく分けると以下の3つ • 基礎的なUIパーツ • Brandingのためのパーツ • headlessなUIパーツ 16
基礎的なUIパーツ 17 • 外観を持つ抽象的な基礎コンポーネント • ButtonやTextFieldなど
Brandingのためのコンポーネント • 色・フォント・アイコンなどBrandingのためのコンポーネント • Typography, Iconなど 18
HeadlessなUIパーツ • 外観は持たず振る舞いとしての機能のみを持つ • ModalやTransitionなど • 細かいインタラクションなどもプロダクト間で統一できるように共通化 19
コンポーネントの責務について • 共通コンポーネント ◦ Atomic Designでいうところの、Atoms, Moleculesを主に実装する ◦ ローカルステート(useState)とロジックはなるべく持たないように •
プロダクト側のコンポーネント ◦ Atomic DesignでいうところのOrganims, Templatesを主に実装する ◦ データの取得・更新やロジックを含めて良い 20
どう作ったのか 主な技術スタック • React • TypeScript • CSS Modules プロダクト側のアーキテクチャで使いやすいように、純粋なReactコンポーネントとして提
供する 21
コンポーネントカタログの提供 22
コンポーネントカタログの提供 • ChromaticというUIテストやホスティングをしてくれるサービスを使って Storybookを公開してい る • どんなコンポーネントがあるのか一覧化することができる • コンポーネントの表示パターンや挙動や型情報を確認できる ◦
オンボーディングコストが下がる 23
3. コンポーネント設計で気をつけたこと 24
コンポーネント設計で気をつけたこと 1. プロダクトのコンテクストに引っ張られないように 2. 早まった共通化・抽象化をしないように 25
プロダクトのコンテクストに引っ張られないように 26
どう作ったのか(再掲) 主な技術スタック • React • TypeScript • CSS Modules プロダクト側のアーキテクチャで使いやすいように、純粋なReactコンポーネントとして提
供する 27
プロダクト側のコンテキストに引っ張られないように • Tagコンポーネントを例にすると、下の2つで共通なのは色がオレンジということだけ • 「注文済み」というコンテキストにつられて、オレンジの状態にしたいときにtype="orderComplete" のようにするのはNG • colorScheme="orange"のような色の情報だけを持つ汎用的なPropsにする 28
O:der Backend Shared Components 29 プロダクト側のコンテキストに引っ張られないように
• 共通コンポーネントは親からどのように利用されるかを知らない • 各Propsにどのような値を渡すかは親の責務 • 共通コンポーネントのPropsはプロダクト側のコンテキストに合わせず抽象的にする プロダクト側のコンテキストに引っ張られないように 30
早まった共通化・抽象化をしないように 31
やってしまったこと • プロダクト側のコンポーネントも頑張って抽象化しようとしてしまう ◦ 再利用を目的としてしまう • 安易にDRYにしようとしてしまう ◦ 同じようなことをしているから共通化して論理的凝集することが多かった ◦
プロダクト間でのユースケースを知る前に共通化しようとしてしまう 32
再利用化を目的とするあまり、副作用が多く脆弱な コンポーネントが出来上がってしまった 33
App Component A Page A Page B Component B Component
C 34
モジュールはたったひとつのアクターに対して責務を負うべきである 『Clean Architecture』SRP: 単一責任の原則 より 35
• 要するに、変更理由が一つであれば疎結合で依存性が少なくて済む • コンポーネントに名前をつけるときにしっくりくる名前が思いつかない場合、「複数の 責務を持っている」ことが多い ◦ 1つだけであればやっていることを命名すれば良いので楽 36
App Component A Page A Page B Component C Component
D Component B 37
どうすれば良かったのか • プロダクト側のコンポーネントはAtomic DesignでいうところのOrganismsと Templatesを主に実装する。ビジネスロジックとドメイン知識が入り込みやすいコン ポーネントなので、共通化するときは慎重に見極めることが大事。 • 共通化できる場合もあるだろうけど、いずれにせよ慎重に • アクターが異なる場合、最初から分離しておく
38
どうすれば良かったのか • はじめの段階では限定的なコンポーネントとして実装する • 共通化できそうなタイミングでリファクタリングをすれば良い 39
4. プロダクトの実装・技術スタック 40
プロダクトの実装・技術スタックについて 1. Next.jsの採用について 2. スキーマファースト開発 41
Next.jsの採用について 42
Next.jsの採用について • SSR/SSG/ハイブリッドなど要件に合わせやすい • ファイルベースルーティング ◦ pages/配下にファイルを置けばルーティングされるので、 react-router使って頑張って書 かなくて良いので楽 •
ゼロコンフィグ ◦ Webpackまわりなどの足回りが揃った状態から開発を始められる ◦ すぐにReact書き始められるので効率的 43
スキーマファースト開発 44
以前までは • OpenAPIを使ってはいたが放置されがちだった • openapi-generatorとか使ってないのでAPI通信まわりは自前実装 • APIまわりの型も書いたり書いてなかったり • APIの変更に追従しづらいので開発効率が悪かった 45
スキーマファースト開発 • OpenAPIを使ってAPIドキュメントを記述しています • スキーマからモックサーバーを使って開発を始められるので、バックエンドの実装 が終わるのを待たずにAPIと結合した開発が進められる • openapi-generatorでAPIクライアントと型を生成しているので、APIの変更に追従し やすく、クライアントとサーバー間で齟齬も起こりにくい 46
振り返りと学び • チームで独立して作業できる状態にはなった • コンポーネント実装の基本的なルールはできた • 共通コンポーネントは抽象的に作ることを常に意識する • コンポーネントについては最初は分離した状態で限定的なコンポーネントとして実 装した方が良さそう
• 設計に銀の弾丸というものはないので、サービスの成長とともにリファクタリングは 継続していく 47
ご清聴ありがとうございました 48