~11 min · tanstack-query, state-management, ecosystem
Level 0React 입문자
0 XP0/54 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
한 번의 fetch를 넘어 공유 캐시와 재시도, 재검증이 필요해지면 TanStack Query가 서버 데이터의 수명을 맡아 줘.
Query key가 데이터의 주소야
useQuery에 query key와 함수를 넘기면 같은 key를 사용하는 컴포넌트가 캐시와 진행 중 요청을 공유해. Sidebar와 본문이 같은 사용자 데이터를 읽어도 요청을 중복해서 보낼 필요가 없어.
서버 데이터의 운영 규칙을 한곳에 모아
재시도, stale 시간, 창에 다시 focus했을 때 재요청, pagination, 낙관적 업데이트 같은 규칙을 각 useEffect에 반복하지 않아도 돼. Mutation이 끝난 뒤 관련 query를 무효화하면 화면들이 같은 최신 데이터를 읽어.
Suspense와도 결합할 수 있어
Suspense 모드를 사용하면 컴포넌트는 성공한 데이터만 받고 로딩은 Suspense가, 오류는 오류 경계가 맡아. TanStack Query의 캐시 관리와 선언적인 화면 경계를 함께 사용할 수 있어.
단순한 요청에는 필수가 아니야
한 화면에서 한 번 읽고 공유·재검증이 필요 없는 데이터라면 fetch와 use()만으로 충분할 수 있어. WebSocket이나 SSE로 계속 들어오는 상태는 스트림 전용 훅이 더 자연스러울 수 있어.
캐시 운영이 실제 문제로 떠올랐을 때 라이브러리를 써. Map에 무효화와 재시도, 중복 제거를 직접 붙이기 시작했다면 이미 전용 도구가 필요한 단계야.
QueryClient가 캐시의 소유자야
앱 root에 QueryClientProvider를 두고 useQuery가 같은 client를 사용하게 해. Query key는 배열로 만들 수 있어. 예를 들어 ['user', userId]는 사용자마다 별도 캐시를 만들고 같은 userId 요청은 합쳐.
Freshness와 수명을 설정해
staleTime은 데이터를 얼마 동안 최신으로 볼지 정하고, cache가 사용되지 않은 뒤 언제 버릴지도 설정할 수 있어. 창에 다시 focus했을 때 재요청할지, 실패한 요청을 몇 번 재시도할지도 query별 또는 client 기본값으로 정해.
Mutation 뒤에는 관련 query를 갱신해
저장이나 삭제가 성공하면 invalidateQueries로 영향을 받은 key를 오래된 상태로 표시해. 낙관적 업데이트를 사용한다면 이전 캐시를 보관하고 실패했을 때 되돌린 뒤 최종 서버 값으로 재검증해.
목록과 상세 화면이 캐시를 공유할 수 있어
목록에서 이미 받은 항목을 상세 화면의 initial data로 사용하면 화면 이동 직후 빈 상태를 줄일 수 있어. 백그라운드 재요청이 최종 값을 맞춰 줘. Infinite query와 polling처럼 운영 규칙이 복잡해질수록 직접 만든 Map보다 전용 cache의 이점이 커져.
앱 root에 QueryClientProvider를 연결하고 useEffect와 useState로 읽던 사용자 화면을 useSuspenseQuery로 바꿔. 같은 query key를 쓰는 컴포넌트 두 개를 동시에 렌더링해 네트워크 요청이 하나뿐인지 확인하고, 화면을 떠났다가 staleTime 안에 돌아왔을 때 cache를 재사용하는지도 봐. 마지막으로 이름 변경 mutation을 성공시킨 뒤 관련 query를 무효화해 두 화면이 같은 최신 값을 읽게 해.
Hint
Network 패널의 요청 수, Query Devtools의 cache 상태, mutation 전후 화면 값을 함께 기록해. 실패 mutation에서는 이전 cache가 유지되거나 명시적으로 되돌아와야 해.
Progress
Progress is local-only — sign in to sync across devices.