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 Queryは非同期の状態管理ライブラリだ
Search
ytaisei
July 13, 2023
Technology
3
2k
React Queryは非同期の状態管理ライブラリだ
HRBrain Fly High #4 -Frontend-にて使用した資料
ytaisei
July 13, 2023
Tweet
Share
More Decks by ytaisei
See All by ytaisei
TanStack Routerを新規プロダクトで1年間運用してみた結果
ytaisei
1
170
Reactを段階的に覗いてみる
ytaisei
3
1.7k
Reactのトランジションを覗いてみる
ytaisei
1
2.4k
Deep Dive Into React 〜React Fiber Architectureについて〜
ytaisei
2
340
React19で状態管理はどう変わるか
ytaisei
2
180
TanStackで効率的なルーティングとデータ取得を実現
ytaisei
10
2.2k
TanStack Routerで型安全かつ効率的なルーティングを実現
ytaisei
4
2.3k
BunがCommonJSをサポートする理由
ytaisei
2
410
TanStack Router SPA開発の選択肢になるか(+TanStack Query)
ytaisei
2
1.5k
Other Decks in Technology
See All in Technology
CDKの魔法を少し解いてみる ― synth・build・diffで覗くIaCの裏側 ―
takahumi27
1
150
「データ無い! 腹立つ! 推論する!」から 「データ無い! 腹立つ! データを作る」へ チームでデータを作り、育てられるようにするまで / How can we create, use, and maintain data ourselves?
moznion
7
4.1k
【M3】攻めのセキュリティの実践!プロアクティブなセキュリティ対策の実践事例
axelmizu
0
130
明日から真似してOk!NOT A HOTELで実践している入社手続きの自動化
nkajihara
1
500
エンジニアに定年なし! AI時代にキャリアをReboot — 学び続けて未来を創る
junjikoide
0
180
大規模プロダクトで実践するAI活用の仕組みづくり
k1tikurisu
4
780
バクラクの AI-BPO を支える AI エージェント 〜とそれを支える Bet AI Guild〜
tomoaki25
2
750
『HOWはWHY WHATで判断せよ』 〜『ドメイン駆動設計をはじめよう』の読了報告と、本質への探求〜
panda728
PRO
5
1.7k
内部品質・フロー効率・コミュニケーションコストを悪化させ現場を苦しめかねない16の組織設計アンチパターン[超簡易版] / 16 Organization Design Anti-Patterns for Software Development
mtx2s
2
260
Javaコミュニティの歩き方 ~参加から貢献まで、すべて教えます~
tabatad
0
110
嗚呼、当時の本番環境の状態で AI Agentを再評価したいなぁ...
po3rin
0
410
QAを"自動化する"ことの本質
kshino
1
110
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
Navigating Team Friction
lara
190
15k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Typedesign – Prime Four
hannesfritz
42
2.9k
Become a Pro
speakerdeck
PRO
29
5.6k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Why Our Code Smells
bkeepers
PRO
340
57k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
It's Worth the Effort
3n
187
28k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Writing Fast Ruby
sferik
630
62k
Transcript
React Queryは非同期の 状態管理ライブラリだ HRBrain 長期インターン 安井大晟
自己紹介 01. 02. 03. 04. 05. 状態管理の種類 Client State vs
Server State 非同期の状態を 管理する キャッシュを 管理する Table of contents
自己紹介 01.
経歴 2019年 早稲田大学教育学部入学 2021年 42Tokyo入学 プログラミングを始める 2022年 技育展優秀賞 2022年 HRBrain長期インターン開始 2023年 春のJavaScript祭りLT登壇 2023年 社内Qiita Engineer Festa運営中
02. 状態管理の種類
Reactの状態には 何種類ある? Redux Context API Recoil jotai useState React Query
SWR
A. 3種類
株式会社ナレッジワークよしこさんの 記事をお借りします
Client State Global State Server State Reactの状態には3種類ある 各Component内で 管理される状態 ページをまたいで
保持し続ける 必要のある状態 サーバーデータ のキャッシュ
Client State Global State Server State Reactの状態には3種類ある UIの状態 トースト表示 APIレスポンス
Client State Global State Server State Reactの状態には3種類ある UIの状態 トースト表示 APIレスポンス
クライアントの状態 サーバーの状態
本来、サーバーの状態は クライアントの状態と 分けて管理されるべきである
Client State Global State Server State Reactの状態には3種類ある UIの状態 トースト表示 APIレスポンス
クライアントの状態 サーバーの状態
Client State Global State Server Stateが存在しない UIの状態 トースト表示 APIレスポンス
Redux
Client State Global State Server Stateが存在しない UIの状態 トースト表示 APIレスポンス Reduxでは、
Server Stateを Global State として管理している
03. Client State vs Server State
Client StateとServer State の違いは? 以後、Client State = Client State +
Global State
Client State vs Server State Client State Server State 所有者
クライアントが完全に所有している リモートに操作されうる 同期性 同期的に使用することができる 非同期的に使用する必要がある 最新性 常に最新の状態である 状態が古くなる可能性がある
Client State vs Server State Client State Server State 所有者
クライアントが完全に所有している リモートに操作されうる 同期性 同期的に使用することができる 非同期的に使用する必要がある 最新性 常に最新の状態である 状態が古くなる可能性がある
04. 非同期の状態を管 理する
ReduxとReact Queryでの 非同期な状態の実装を比較 loadingで検証
Reduxの場合
React Queryの場合
React Queryの場合
React Queryは非同期の 状態管理ライブラリだ
05. キャッシュを 管理する
Client State vs Server State Client State Server State 所有者
クライアントが完全に所有している リモートに操作されうる 同期性 同期的に使用することができる 非同期的に使用する必要がある 最新性 常に最新の状態である 状態が古くなる可能性がある
状態をなるべく 最新に保ちたい
useQueryを使用した データフェッチの流れ 1. useQueryがコンポーネントで呼ばれ、データフェッチを開始 2. queryKeyを参考にキャッシュを確認する - キャッシュヒットした場合、キャッシュされたデータをコンポーネントに返却 - キャッシュヒットしなかった場合、または、キャッシュヒットしたがキャッシュが
stale状態の場 合は3に進む 3. バックグラウンドで新しいデータを fetchしてアップデートする 4. 新しいデータをキャッシュに保存して再レンダリングする
なるべくキャッシュを 返してfetchを減らしたい
StaleTimeとcacheTime • staleTime ◦ キャッシュをstale(古くなったとみなす) 状態にするまでの期間 ◦ デフォルト:0 • cacheTime
◦ キャッシュをガベージコレクション(メモリ領域の開放)するまでの 時間 ◦ デフォルト:5分
StaleTimeを使用する • staleTime:0 ◦ 常に最新のデータを取得する • staleTime:Infinity ◦ キャッシュが常にfreshなのでネットワークのリクエストが走らず、 キャッシュからデータを取得する
◦ 自分しか変更できないデータに有効
StaleTimeを使用する • staleTime:0 ◦ 基本はこの設定で良い • staleTime:Infinity ◦ データが更新されるタイミングがわかっていれば Infinityにして、更新時に明示的にinvalidateする
最新性を優先する
Client State vs Server State Client State Server State 所有者
クライアントが完全に所有している リモートに操作されうる 同期性 同期的に使用することができる 非同期的に使用する必要がある 最新性 常に最新の状態である 状態が古くなる可能性がある
Thanks!!!
Thanks!!! • Twitter ◦ https://twitter.com/ytaisei_ • Qiita ◦ https://qiita.com/taisei-13046 •
Zenn ◦ https://zenn.dev/taisei_13046