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
大規模Reactアプリのリアーキテクチャ~8万行のTanStack Query移行の軌跡~
Search
Ibuki Kaji
April 18, 2024
Programming
4
2k
大規模Reactアプリのリアーキテクチャ~8万行のTanStack Query移行の軌跡~
株式会社WinTicketにおけるReduxからTanStack Queryへのリアーキテクチャ事例の紹介です。
Ibuki Kaji
April 18, 2024
Tweet
Share
More Decks by Ibuki Kaji
See All by Ibuki Kaji
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
190
WINTICKET QA における Autify 活用
kj455
2
710
Other Decks in Programming
See All in Programming
ATDDで素早く安定した デリバリを実現しよう!
tonnsama
1
1k
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
970
バグを見つけた?それAppleに直してもらおう!
uetyo
0
210
ある日突然あなたが管理しているサーバーにDDoSが来たらどうなるでしょう?知ってるようで何も知らなかったDDoS攻撃と対策 #phpcon.2024
akase244
2
7.7k
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
320
PHPで作るWebSocketサーバー ~リアクティブなアプリケーションを知るために~ / WebSocket Server in PHP - To know reactive applications
seike460
PRO
2
720
Запуск 1С:УХ в крупном энтерпрайзе: мечта и реальность ПМа
lamodatech
0
870
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
8
1.8k
為你自己學 Python
eddie
0
500
週次リリースを実現するための グローバルアプリ開発
tera_ny
1
690
命名をリントする
chiroruxx
1
560
競技プログラミングへのお誘い@阪大BOOSTセミナー
kotamanegi
0
390
Featured
See All Featured
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Embracing the Ebb and Flow
colly
84
4.5k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.7k
GraphQLとの向き合い方2022年版
quramy
44
13k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
340
Fireside Chat
paigeccino
34
3.1k
Documentation Writing (for coders)
carmenintech
67
4.5k
Writing Fast Ruby
sferik
628
61k
Agile that works and the tools we love
rasmusluckow
328
21k
Side Projects
sachag
452
42k
The Cost Of JavaScript in 2023
addyosmani
46
7.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
550
Transcript
大規模Reactアプリのリアーキテクチャ 8万行のTanStack Query移行の軌跡 株式会社WinTicket 鍛冶 維吹 2024/04/18 Muddy Web #8
鍛 冶 維 吹 - k a j i ,
i b u k i e 2022年 株式会社サイバーエージェント新卒入B e 株式会社 WinTicket 所a e ~2024/03:web フロンW e 2024/04~:バックエンF e 「筋トレは歯磨き」 自己紹介 @kj4555 @kj455
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
WINTICKET について E 公営競技ネット投票サービ' E 競輪/オートレー' E 2019年4月リリー' E 市場シェアNo.1
#React #Fastly #Go #Kubernetes #Flutter #Cloud Run #Google Cloud #TypeScript #TanStack Query
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
TanStack Query への移行背景 WINTICKET Web の旧状態管理アーキテクチャ 3種類[1]のうち2種類の管理を Redux が担っていた [1]
Zenn. “「3種類」で管理するReactのState戦略”. https://zenn.dev/knowledgework/articles/607ec0c9b0408d 2024/04/14 サーバーレスポンスのキャッシュ 管理場所 ステート種類 Redux Redux コンポーネント グローバルステート管理 ローカルステート ローカルステート
TanStack Query への移行背景 Redux の辛み 「サーバーデータのキャッシュ」用途では面倒なポイントが多p g 非同期処理を扱うにはプラグインが必W g Redux
Thunk (or Redux Saga6 g サーバーからのデータ取得に特化したものではない → 自前で色々と書く必要がある
Redux での処理の一例
Redux での処理の一例
Redux での処理の一例
Redux での処理の一例
これに加え データの正規É クエリ引数ごとのデータ保À ... Redux での処理の一例
これに加え データの正規É クエリ引数ごとのデータ保À ... Redux での処理の一例
TanStack Query への移行背景 TanStack Query の導入 サーバーレスポンスのキャッシュ Before ステート種類 Redux
Redux TanStack Query Redux コンポーネント コンポーネント After グローバルステート管理 ローカルステート ローカルステート
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
移行結果 定量比較:状態管理周りのコード量
移行結果 定量比較:状態管理周りのコード量 Before 77438 (行)
移行結果 定量比較:状態管理周りのコード量 Before After 77438 (行) (行) 50215 -27223(35%)
移行結果 移行を経て得られた定性的なメリット 10 データフローが簡潔に 70 レポジトリオーナーシップ向上[2] m クエリの呼び出しだけでデータを取得可 m データの正規化を廃
m 将来 TanStack Query を剥がすことになっても 比較的楽にマイグレーション可能 m アプリケーション基盤への理 m 様々なドメインのコードの読み書v m レビューによる知見の共有 [2]. Speaker Deck. 「リアーキテクトと開発生産性について」. https://speakerdeck.com/yosuke_furukawa/riakitekutotokai-fa-sheng-chan-xing-nituite. 2024-04-14
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
アーキテクチャ紹介 実際の使用例:Query 定義
アーキテクチャ紹介 実際の使用例:Query 定義 独自のクエリファクトリ関数 による Query 定義 Query 定義
アーキテクチャ紹介 実際の使用例:Query 利用 Query 定義
アーキテクチャ紹介 実際の使用例:Query 利用 useQuery Query 定義 fetchQuery
アーキテクチャ紹介 実際の使用例:Query 利用 useQuery Query 定義 fetchQuery ①
アーキテクチャ紹介 実際の使用例:Query 利用 useQuery Query 定義 fetchQuery ① ②
アーキテクチャ紹介 実際の使用例:Query 利用 useQuery Query 定義 fetchQuery ① ②
アーキテクチャ紹介 1. Query ファクトリ関数 useQuery 実行時の流れを追ってみる
アーキテクチャ紹介 1. Query ファクトリ関数 useQuery 実行時の流れを追ってみる
アーキテクチャ紹介 1. Query ファクトリ関数 useQuery 実行時の流れを追ってみる
アーキテクチャ紹介 1. Query ファクトリ関数 useQuery 実行時の流れを追ってみる
アーキテクチャ紹介 1. Query ファクトリ関数 useQuery 実行時の流れを追ってみる
アーキテクチャ紹介 1. Query ファクトリ関数 useQuery 実行時の流れを追ってみる
アーキテクチャ紹介 1. Query ファクトリ関数 ① ② .options():クエリオプションの生B 8h クエリ引数の queryKey
への自動反T 9h queryKey, queryFn の一括管理
アーキテクチャ紹介 1. Query ファクトリ関数 ① ② TanStack Query V5 で導入された
queryOptions API と同じ思想 .options():クエリオプションの生 ym クエリ引数の queryKey への自動反 m queryKey, queryFn の一括管理
アーキテクチャ紹介 1. Query ファクトリ関数 ① ② TanStack Query V5 で導入された
queryOptions API と同じ思想 実は一点危ないポイントが...! .options():クエリオプションの生 { クエリ引数の queryKey への自動反m { queryKey, queryFn の一括管理
余剰プロパティを含むオブジェクトを引数に渡す例:
余剰プロパティを含むオブジェクトを引数に渡す例: 型エラー
余剰プロパティを含むオブジェクトを引数に渡す例: 型エラー 型エラーなし 関数引数に余剰プロパティが含まれていても 型エラーにならない場合がある
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 TypeScript は余剰プロパティチェックを オブジェクトリテラルに対してのみ行う (実用性観点) QueryOptions 生成関数においては この挙動が問題になりうる
型エラーにならない 余剰プロパティを含むオブジェクトを引数に渡す例:
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 S オプション生成時の引数は そのまま queryKey に格納されQ S TanStack
Query は queryKey が異なると別クエリとして扱う
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 S オプション生成時の引数は そのまま queryKey に格納されQ S TanStack
Query は queryKey が異なると別クエリとして扱う 引数オブジェクトが余剰プロパティを含む = クエリが別物として扱われる
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 Todo 更新処理(UpdateTodo) 1 2 3 以下のようなケースで問題になb da
Todo取i Ta Todo更v Ya 最新の Todo 取得
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 Todo 更新処理(UpdateTodo) QueryKey 1 2 3 ≠
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 Todo 更新処理(UpdateTodo) QueryKey 1 2 3 ≠
→最新のTodoが再取得されない...!! ×
アーキテクチャ紹介 QueryOptions 生成関数引数の型の厳格化 常に余剰プロパティを含まないような型制約(`Exact`)をかけることで防ぐ type-fest の `Exact` 型を利
簡単なものであれば自作可能 型エラーになる
アーキテクチャ紹介 (再掲)実際の使用例:Query 利用 useQuery Query 定義 fetchQuery ① ②
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext 実現したいこと: Query をテスタブルにする → を外部から注入する
依存
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext 実現したいこと: Query をテスタブルにする → を外部から注入する
依存 QueryFunctionContext
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext QueryFunctionContextG B metc B queryKeV
B signa5 B pageParam ←任意の値を入れられる Query の defaultOptions で meta に依存を注入可能
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext t QueryClient 生成時の defaultOptions で
meta に依存を注h t テスト時はモックに差し替える
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext t QueryClient 生成時の defaultOptions で
meta に依存を注h t テスト時はモックに差し替える →この方針には一点だけ問題がある...
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext WINTICKET では他の要件のために meta を活用している... あくまでデフォルト値なので
meta に他の値を指定すると上書きされて依存が 消えてしまう
アーキテクチャ紹介 2. DI 層としての QueryFunctionContext useQuery をラップし meta のマージ処理を行うことで解決 (時間の都合上話せないが)
他の要件で既に useQuery を独自にラップする 必要があった
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
移行を通じての学び メンバー全員の理解/同意を得る リアーキテクチャは将来の開発スタイルに関わる大きな意思決定なので メンバー全員の理解/同意が必要 アーキテクチャ自体への納得y q 移行リードへの信頼感
移行を通じての学び メンバー全員の理解/同意を得る t アーキテクチャ自体への納得感 「 良い設計をする e Docsを読み漁q e ベストプラクティスを知q
e 作者の X をフォローすq e 作者のブログを読4 e アプリケーション要件に応じてカスタマイズする 移行リードへの信頼感 「 徹底的なコミット e メンバーからどんな質問が来ても自分の意見で答 えられる状態にすq e 何か起きても自責でどうにかする
移行を通じての学び 「最適な設計」にこだわりすぎない 手戻りを恐れて、手を動かす前に机上で考えてしまいがち ただ、結局手を動かさないとわからないことが多くある 何かあったら気合いでリファクタする覚悟さえあれば前に進んで良い 進み始めて後悔したことは一回もない インクリメンタルに進む方が早く良いものが出来上がる
移行を通じての学び 移行戦略の重要性 移行に取り組む順番への戦略S W 足元の進捗だけで見ると、影響少ないかつ剥がしやすい箇所ばかり進めてしま4 W 結局複雑なコアロジックが最後まで残ってしまいがち 影響/依存の小さい箇所 既存アーキテクチャとの共存 書き心地
コアロジック 複雑な要件へ耐えうる アーキテクチャかどうかの確認 残り 設計の妥当性は確認済み あとは移行するだけ 初期 中期 後期
01 WINTICKET について 02 TanStack Query への移行背景 03 移行結果 04
アーキテクチャ紹介 05 移行を通じての学び 06 終わりに 目次
終わりに 思い残していること V TanStack Query V5 にアップデートできていなd V そもそも React
18 にあげないと..# V Server Component 全盛時代が来たら TanStack Query も要らなくなる?
終わりに 最後に p 8万行を半年で、かつ、手作業で書き直すのは途方の見えない戦いだっ6 p チームメンバーの皆さん本当にお疲れ様でし6 p 大規模リアーキテクチャには技術力に加えて気合いも必要
終わりに We are HIRING !!! WINTICKET Web で働いてくれる人を募集していますW
圧倒的若手チーム(全員20代3 Web っぽいことだけに閉じずに CI/CD やインフラ周りを触る機会もアリ
Thank you for listening!!!