JSConf JP 2022 introduce React Query

Transcript

1. React Query 導入と 実装ルールについて考える 2022.11.26 JSConf JP 2022 | 株式会社カオナビ Yuuki Minami © kaonavi, inc.
2. © kaonavi, inc. 2 • Yuuki Minami • CTO 室 フロントエンド支援チーム • 🍜🍺❤
3. React Query の導入時に得られた知見や 実装について考えたこと 話すこと © kaonavi, inc. 3
4. INDEX 1 .React Query について 2 .React Query 導入と選定 3 .実装ルール・実装例 4 .React Query の近時 © kaonavi, inc. 4 5 .まとめ
5. React Query について © kaonavi, inc. 5
6. React Query (TanStack Query) © kaonavi, inc. 6 • 非同期状態管理ライブラリ ◦ データ取得 ◦ サーバーデータ (API レスポンス) のキャッシュ • v4 から TanStack Query へ名称変更 ◦ React, Solid, Vue に対応 (2022年11月時点)
7. React Query の特徴 © kaonavi, inc. 7 • stale-while-revalidate キャッシュ戦略 • 同一データ取得リクエストの重複削除 • garbage collection の設定 • structural sharing による Query 結果のメモ化 • バックグラウンドでのデータ更新 • Suspense モード
8. useQuery Component がレンダリングされるとキャッシュが有効であれ ばキャッシュされたデータを返し、キャッシュが存在しない場 合やキャッシュの状態が Stale の時はデータをフェッチする。 • queryKey: キャッシュ管理のための 一意なキー • queryFn: データ取得のための Promise を返す関数 基本的な使い方 © kaonavi, inc. 8
9. React Query 導入と選定 © kaonavi, inc. 9
10. • 一部のページで MPA -> SPA へ移行 • 歴史的背景 ◦ Redux Store がページ毎に存在 (Not single store) • SPA で Redux 以外の Global State 共有のアプローチが必要 • SPA 化によりキャッシュ活用の機運が高まる • Redux 実装が肥大化しがちでつらい 導入のモチベーション © kaonavi, inc. 10
11. • React Query ◦ 自動 garbage collection 👍 ◦ 公式 Devtools 👍 ◦ 開発の勢いとリリースサイクルの早さ 👍 • SWR ◦ シンプル・必要最低限の機能はある ◦ サイズが小さい • RTK Query ◦ 歴史的背景から Redux (RTK) がシングルストアではない ◦ Redux にロックイン 他の候補との比較と導入の決め手 © kaonavi, inc. 11
12. Stale Time • Query を fresh から stale へ移行す るまでの時間 • fresh の間はデータは常にキャッシュ から取得され、リクエストが走ることは ない • stale の場合、キャッシュを返しつつ バックグラウンドで再取得とデータ更 新が可能 React Query Concepts © kaonavi, inc. 12 • 非アクティブな Query のキャッシュを 削除 (GC) するまでの時間 • Observer (その Query を利用するコ ンポーネント) が全て unmount される と Query は非アクティブに移行 Cache Time © kaonavi, inc. 12
13. React Query Devtools • Query 毎にキャッシュされているデータが確 認可能 • Query の状態が把握でき、ボタンからデータ の再取得やキャッシュの破棄も可能 • オプトインなので利用する際は本体と別にイ ンストール • development build でのみ有効化される
14. TanStack/query 開発とリリース © kaonavi, inc. 14 https://github.com/TanStack/query/pulse/monthly © kaonavi, inc. 14
15. TanStack/query 開発とリリース https://www.npmjs.com/package/@tanstack/react-query?activeTab=versions © kaonavi, inc. • Opened issues: 18 (資料作成時点) • Feature Requests & Questions は Discussions • Issue の修正が早い • リリース頻度が高い ので修正がマージされたらす ぐに取り込める 15
16. Comparison Matrix © kaonavi, inc. 16 https://tanstack.com/query/v4/docs/comparison
17. Redux は不要になるか？ © kaonavi, inc. 17 • API レスポンス以外の Global State を React Context 等に寄せることで場合によっては不要 ◦ Context でレンダリングを最適化するには Context を適宜分割し、複数の Provider を用意 する必要がある • 複雑な要件に対応させるために API レスポンス以外にも様々な Global State を管理 • レンダリング最適化や可読性の観点から、 Redux は引き続き有用と考える
18. 実装ルール・実装例 © kaonavi, inc. 18
19. Custom Hooks © kaonavi, inc. 19 • Query 毎に Custom Hooks で抽象化し、可搬性・ 保守性の向上 • Component から直接 useQuery を呼ばない • コアメンテナ Dominik 氏のブログでも推奨 ◦ https://tkdodo.eu/blog/practical-react-query ※v5では useQuery の引数は単一のオブジェクトのみ許容に
20. Query Keys © kaonavi, inc. 20 • 一意性を担保するためにルールを設定 • common or features ◦ common: 省略 ◦ features: feature 名を含める • Hooks name ◦ useFoo の foo を含める • Custom Hooks ファイル内で定義 ◦ 利用する Query Keys を間違えない ◦ コンフリクトしない
21. useQuery options type • useQuery に options を渡すことが可能 • Custom Hooks の引数で options を受け取る • select option による取得データの加工 ◦ select で取得されるデータに変更があっ た場合のみ再レンダリング ◦ 型推論させるために工夫が必要 ◦ 最適解求む！ © kaonavi, inc. 21
22. React Query の近時 © kaonavi, inc. 22
23. ESLint Plugin © kaonavi, inc. 23 • v4.14.0で追加 • @tanstack/query/exhaustive-deps ◦ queryFn 内で利用するパラメータは queryKey に指 定する • @tanstack/query/prefer-query-object-syntax ◦ useQuery の引数は単一のオブジェクトのみ許容
24. suspense for useQueries © kaonavi, inc. 24 • v4.15.0で useQueries が suspense モードに対 応 (experimental とのこと) • 全ての Query の取得が完了するまでコンポー ネントツリーはマウントせずに fallback • Issue が報告されてから約 2年越しに解決 🎉 • 通常の useQuery の suspense モードでは ウォーターフォール的にしか実行できない
25. • useQuery の引数は単一のオブジェクトのみ許容 • require React >=18.2.0 • require TypeScript >=4.7 • rename cacheTime to gcTime • rename useErrorBoundary to throwError • Optional chaining のトランスパイル廃止によるバンドルサイズ改善 v5 Roadmap © kaonavi, inc. 25 現在ドラフト https://github.com/TanStack/query/discussions/4252
26. まとめ © kaonavi, inc. 26
27. まとめ © kaonavi, inc. 27 • React Query はプロダクトで活躍できるポテンシャルがある ◦ 痒いところに手が届く API や Options ◦ Devtools や ESLint Plugin による開発者体験 ◦ 開発の勢い • 実装のルールはしっかり考えないと破綻する可能性あり (特に Query Keys) • Stale Time と Cache Time の概念だけ最初は少々戸惑いがち ◦ 実際に手元で動かして理解するのが一番 • 開発が早く、検索した情報が古くなっている可能性があるので公式ドキュメントと照らし合 わせる