React Query와 상태관리 (2)

2월 우아한테크세미나 강의를 듣고 작성한 글입니다.

---

이전의 글에서는 Data fetching, updating을 알아보았는데,
이번 글에서는 Caching , Synchronization에 대하여 알아보자.

---

• cacheTime : 메모리에 얼마만큼 있을 건지 (해당 시간 이후 GC에 의해 처리, default 5분)
• staleTime : 얼마의 시간이 흐른 후에 데이터를 stale 취급할 것인지 (default 0)
• refetchOnMount / refetchOnWindowFocus / refetchOnReconnect
  • true이면 Mount / window focus / reconnect 시점에 data가 stale이라고 판단되면 모두 refetch (모두 default true)

---

Query 상태흐름

1. 화면에 있다가 사라지는 query

2. 화면에 있다가 없다가 좀 더 복잡한 query

---

zero-config 에서도 이런 역할을

알아서 하는 것들이 있어서(기본 세팅이 되어있음) 좋지만 주의도 해야한다

• staleTime : default 값 0
• refetchOnMount / refetchOnWindowFocus / refetchOnReconnect : default 값 true
• cacheTime : default 값 60 5 1000
• retry : default 값 3
• retryDelay : default 값 exponential backoff function

요약

• Quries에서 cached data는 언제나 stale 취급
• 각 시점에서 data가 stale이라면 항상 refetch 발생
• inactive Query들은 5분 후 GC에 의해 처리
• Query 실패 시 3번까지 retry 발생

---

전역상태처럼 관리되는 데이터들

어떻게 Server State들을 전역 상태처럼 관리할까?

해답은 Context

QueryClient 내부적으로 Context를 사용한다.

---

React Query etc.

• useInfiniteQuery
• Prefetching
• TypeScript 지원
• GraphQL 대응
• SSR & Next.js 에서도 사용 가능
• devtools
• etc.

---

어떻게 바뀌었나요

• (Client) Store는 Client State들만 남아 목적에 맞고 심플하게
• Server State 들은 React Query와 함께 간단하고 파워풀

---

이거 좋아요

• 서버상태 관리 용이하며 (Redux, MobX 사용할 때보다) 직관적인 API 호출 코드
• API 처리에 관한 각종 인터페이스 및 옵션 제공
• Client Store가 FE에서 정말로 필요한 전역 상태만 남아 Store 답게 사용됨 (Boilerplate 코드 매우 감소)
• devtool 제공으로 원활한 디버깅
• Cache 전력 필요할 때 아주 좋음

---

이거 좀 더 고민이 필요한 것 같아요

• Component가 상대적으로 비대해지는 문제 (Component 설계/분리에 대한 고민 필요)
• 좀 더 난이도가 높아진 프로젝트 설계 (Component 유착 최소화 및 사용처 파악 필요)
• React Query의 장점을 더 잘 활용할 방법 (단순히 API 통신 이상의 가능성)