[react-query] Observer와 Query의 개념 및 동작 과정(staleTime, cacheTime, 캐시, fetching과 loading) 과 refetch 조건 및 옵션 완벽 정리

📖 react query의 staleTime과 cacheTime에 refetch 조건에 대한 이해가 필요하다고 생각하여 공식 문서 참고 및 여러 실험 후 기록해둡니다.

 

 

0. 옵저버(Observer)와 쿼리(Query)

가장 먼저 react-query의 핵심 개념 중 하나인 옵저버와 쿼리에 대해서 알아보겠습니다.

옵저버(Observer)

 옵저버는 비동기 데이터 요청을 추적하고 업데이트를 처리하는 객체입니다. 쿼리의 상태 변화를 감지하고 변화 과정과 결과에 따라서 UI를 업데이트 시킬 수 있습니다. useQuery 훅을 사용하여 옵저버를 생성할 수 있습니다.

옵저버는 다음과 같은 속성을 가질 수 있습니다.

• isLoading : 캐시에 없는 비동기 데이터 요청이 진행 중인지 여부
• isFetching: 비동기 데이터 요청이 진행 중인지 여부(isLoading보다 범위가 큰 상위 개념이라고 생각하면 됩니다.)
• isError : 요청이 실패했는지 여부
• data, error, refetch 등등...
• 명령형 코드로 처리를 할 때 isLoading || isFetching 은 isLoading만 처리를 하거나 이렇게 논리합 연산자로 조건문을 줘서 처리하는 경우가 많습니다.
• 하나의 쿼리를 여러 옵저버가 관찰할 수 있습니다.

쿼리(Query)

쿼리는 비동기 데이터 요청을 나타내는 객체입니다. 좀 더 정확히 얘기하자면, unique key에 바인딩되어 있는 비동기적인 데이터 source 객체를 의미합니다. prefetch, useQuery, fetchQuery 등을 사용하여 쿼리를 생성하고 서버로부터 데이터를 가져오는 등의 작업을 수행하며 같은 쿼리에 대해 각자 다른 설정도 할 수 있습니다. 쿼리는 옵저버의 업데이트를 트리거하고 서버로부터 데이터를 요청하고 데이터를 받아옵니다. 옵저버와 함께 사용하여 비동기 데이터 요청을 처리하고 UI를 업데이트 할 수 있습니다. 일반적으로 각 컴포넌트나 커스텀 훅에서는 useQuery hook을 사용하여 쿼리와 옵저버를 생성하여 query 를 구독할 수 있습니다.

쿼리는 다음과 같은 속성을 가질 수 있습니다.

• queryKey : 쿼리를 식별하는 키
• queryFn : 비동기 데이터 요청 함수
• onSuccess, onError, onMutaion 등의 콜백함수 등등...
• 하나의 쿼리를 여러 옵저버가 관찰할 수 있습니다.

 

 

1. staleTime

• 데이터가 fresh 상태에서 stale 상태로 변경되는 데 걸리는 시간이다.
• 즉, 신선한 데이터로 교체(fetch) 후에 썩지 않는 시간을 의미한다.
• default 값은 0
• ms 단위이다. 3000ms = 3초

staleTime: 3000,

데이터가 한 번 fetch 되고나서 staleTime이 지나지 않았다면 unmount 후에 다시 mount 되어도 fetch가 일어나지 않는다.

위 코드의 경우에는 3초동안 아주 빠르게 100만 번 해당 페이지를 재진입 해도 api 요청을 통한 background-refetching 없이 이전의 쿼리 캐싱 데이터를 가져와 보여줄 것이다.

 

🚀 staleTIme 은 데이터 구조가 자주자주 변하는 어플리케이션이라면 지정하지 않는 편이 좋고 해당 브라우저에 표현되는 내용의 데이터들이 정적이라면 staleTime을 지정해주고 요청하는 것이 서버의 부담을 경감시킬 수 있는 설정이다.

 

staleTime은 query의 설정마다 다르게 작동한다.

    이는 react query에서 이해하고 있어야 할 아주 아주 아주 중요한 개념이다. 예를 들어서 설명하면 이해가 쉽다.

예를 들어 같은 쿼리 키 데이터(키 완전 동일)로 fetch를 해서 사용하는 A, B 컴포넌트가 있다. 그런데 A 컴포넌트에는 staleTime이 0으로 지정되어 있고, B 컴포넌트에는 staleTime이 1000 * 10(10초)로 지정되어 있다. 이 때 이 두 컴포넌트는 같은 쿼리 키 데이터를 이용하더라도 A의 query에서는 A컴포넌트가 마운트 될 때마다 stale 상태이므로 매번 계속해서 background-refetching이 일어난다. 같은 쿼리를 바라보고 있는 B 컴포넌트는 (B)컴포넌트의 마운트와는 상관없이 이 staleTime이 다 지나야지만 background-refetching이 발생한다. 이게 무슨 뜻인지는 바로 밑에서 얘기한다. (참고로 컴포넌트의 마운트와 상관있게 fetch를 하도록 만들 수 있는 refetchOnMount라는 query 옵션이 있다. 이는 맨 밑에서 다룬다.)

 

🌟 만약 A 컴포넌트로 갔다가 B컴포넌트로 이동하면 staleTime은 어떻게 계산이 될까? (바로 위랑 이어지는 내용)

  B컴포넌트(staleTime 10초)가 마운트 될 때는 A 컴포넌트(staleTime0초)에서 같은 쿼리키 쿼리에 데이터를 새로 채운 시점을 기준으로 staleTime이 계산된다. A 컴포넌트는 staleTime이 0초여서 매번 refetch가 일어나는데,  A 컴포넌트에서 refetch 후에 5초 머무른 후에 B 컴포넌트로 이동하면 B 컴포넌트의 쿼리 설정은 staleTime 10초임에도 불구하고 A컴포넌트에서 최신 쿼리로 업데이트 후 머무른 시간까지 계산하여 5초 후에 stale 한 상태가 된다(5 + 5 = 10). 가장 최근에 같은 키로 데이터가 업데이트된 시점을 추적하여 그 때부터 시작하여 staleTime을 계산하는 것이다. 이것을 이해했다면 컴포넌트의 생명주기에 마냥 종속되어 있지만은 않은 staleTIme이라는 개념을 완벽히 이해한 것이다.

 

📝 정리하자면

  키가 같은 경우 staleTime은 가장 최근에 관측한 쿼리 설정의 staleTime으로 덮어질 수 있되, 시간계산은 가장 최근에 쿼리 캐시 데이터가 업데이트 된 것을 관찰한 시점을 기준으로 계산이 되는 것이고, cacheTime(밑에서 다룸)은 active 상태 진입 때마다 지나간 시간은 매번 초기화 및 inactive 상태 진입 때 새로운 시작으로 새로 계산하되, 최초로 생성한 쿼리 인스턴스의 cacheTime 설정을 계속 따라간다.즉, cacheTime은 쿼리 캐시 데이터가 업데이트 되어도 새로운 쿼리 cacheTime 설정으로 덮어지지 않는다. inactive 상태에서 시간이 지나 캐시에서 삭제되어 쿼리가 삭제되어야 직후 생성되는 쿼리의 cacheTime 설정으로 새롭게 변경 될 수 있다. UX개선을 위해서 같은 키로 미리 fetch를 하는 prerefetch 할 때 참고하면 좋다. 캐시 타임은 밑에서 더 자세하게 다룬다. )

 

 

---

2. cacheTime

• 데이터가 inactive 상태일 때 캐싱된 상태로 남아있는 시간이다. 
  *inactive 상태:  쿼리 인스턴스가 unmount[관찰 중단] 되면 데이터는 inactive 상태로 변경된다. 해당 데이터가 현재 화면에 표시되는 컴포넌트에 의해 사용되지 않거나 해당 데이터에 대한 요청이 없는 상태를 말한다. 웬만하면 쿼리데이터가 활용되고 있다면 해당 쿼리 인스턴스는 observing 상태인 경우가 많다. observing(관찰) 상태 때는 캐시 시간이 아예 흐르지 않고 새로 refresh 된다. 캐시의 지난 시간이 초기화 된다는 뜻이다.
• cacheTime은 같은 키의 쿼리 인스턴스가 다시 관찰될 때(active)마다 남아있는 캐시 시간이 초기화된다.(처음 설정한 캐시 시간이 다시 채워진다는 뜻이다.)
• 즉, cacheTime은 쿼리가 inactive 상태가 돼야 설정한 시간이 흐르기 시작한다.  stale 시간과는 무관하게 캐싱 시간이 지나면 react query devtools로 해당 쿼리가 삭제되는 것을 확인할 수 있다. =>  쿼리가 삭제되면 fetching & loading 과정을 다시 거쳐야 하기 때문에 staleTime은 CacheTime보다 적게 지정하는 것이 좋다.
• default cacheTime : 5분 (마찬가지로 ms단위로 변환한 5 * 60 * 1000 으로 적어줘야 한다. 0이 아닌 5분임에 유의하자.)
• cache processing:
  1. useQuery의 첫 번째, 새로운 쿼리 인스턴스 생성(observer mount) => 만약에 런타임간 최초로 fresh한 해당 쿼리가 호출되었다면, 캐싱하고, 패칭이 끝나면 (staleTime : 0 =기본값 이라면 )해당 쿼리를 stale로 바꿈.
  2. 앱 어딘가에서 useQuery 같은 키의 두 번째 쿼리 인스턴스 생성(observer mount) => 이미 쿼리가 stale이므로 최근 요청 때 만들어 놨었던 캐시를 반환하고 리패칭을 함. 이 때 캐시도 업데이트된다. 헷갈리지 않게 정확히 말하자면 캐시 데이터가 업데이트 되고 cacheTime은 최초 쿼리 인스턴스의 cacheTime 설정을 상속한다.
  3. 옵저버가 언마운트되고 쿼리 데이터를 더 이상 사용하지 않을 때 => 마지막 옵저버가 언마운트되어 inactive 상태가 되었을 때 5분(cacheTime의 기본값)이 지나면 해당 캐싱 쿼리 데이터는 자동으로 삭제된다.

 

아니 그럼 staleTime을 cacheTime보다 더 길게 설정해놓는 것은 말이 안되겠네요?

TkDodo는 react query의 버전 관리자다

 원한다면, 말이 될 수도 있다. 예를 들어 극단적으로 `staleTime: Infinify`로 설정하고, `cacheTime: 0`으로 설정한다면, 이것은 데이터를 한 번 캐싱완료했으면 절대 data를 refetch하지 말고 내가 그 데이터를 더 이상 사용하지 않게 되자마자 cache에서 바로 삭제하라는 뜻이다. 즉, 볼 수 있는 기회가 단 한 번 뿐인 쿼리를 만들어 버리는 것이다. 활용할 수 있는 것들을 잘 찾아보자. 한 번만 보고 말 것들에 활용하면 되겠다.

---

3. Browser Cache
브라우저 캐시에는 메모리 캐시와 디스크 캐시가 존재한다.

memory cache

memory cache는 더 빨리 캐시를 가져오기 위해서 캐시 메모리에서 가져온다. 캐시 메모리에는 L1, L2, L3가 있고 보통 CPU에 내장되어 있다. CPU에 내장되어 있기에 캐시를 더 빨리 가져올 수 있는 것이다. 그러나 캐시 메모리는 브라우저를 닫으면 캐시가 지워진다. 

 

disk cache

disk cache는 큰 용량을 저장하기 위해서 하드디스크, SSD에서 가져온다. 디스크 캐시는 브라우저를 닫더라도 캐시는 지워지지 않는다.

 

캐시 메모리와 디스크 캐시에 저장되는 기준은 리소스 용량으로 추정된다.

캐시 메모리는 8kb에서 8MB로 작은 용량이므로 그 이상의 리소스인 경우에는 디스크 캐시에 저장된다.

---

4. fetching 과정

데이터 페칭이 다시 일어나는 상태는 Stale 상태부터 이다. 근데 이때의 페칭은 처음 데이터를 요청할 때와는 다른 페칭이다. 이때 일어나는 페칭을 Background re-fetching(stale + cache O인 상태에서 실행) 이라고 한다. 과정은 다음과 같다.

1.  먼저 캐싱된 데이터를 가져와 브라우저에 보여준다.
2.  데이터가 구식일 수 있기 때문에 암묵적으로 다시 서버에 재요청을해서 데이터를 Fresh하게 바꾼다.
3. 데이터의 변화가 있었다면 캐시를 업데이트하고 UI도 변경된다. (아니라면 그대로 유지된다.)

  Stale 상태에는 캐시된 데이터도 불러오고, 데이터 페칭도 일어난다고 보면 된다. 데이터가 Stale 상태라고 판단할 시간을  QueryClient를 생성하면서 또는 각 컴포넌트 내부의 useQuery 인스턴스를 마운트 하면서 설정할 수 있는데 staletime의 값을 변경하면 된다. 기본값은 0이다. 그러니까 지금까지 변경을 안하고 사용했다면, 데이터를 요청해서 불러오자마자 stale 상태가 되었을 것이다. 그러면 매번 background-refetch를 했을 것이다.

 

 

---

5. isFetching, isLoading

• isFetching: 데이터가 fetch 될 때 true, 캐싱 데이터가 있어서 백그라운드에서 fetch 되더라도 true
• isLoading: 캐싱된 데이터가 없을 때(초기 진입) 혹은 inactive + cacheTimeout (+ stale)일 때 fetch 중에 true

inactive + cacheTimeout (+ stale) 상태에는 평범한 데이터 페칭이 일어난다. Background re-fetching과 차이는 isLoading 값의 차이이다. 전자는 true 후자는 false이다. Background re-fetching 때는 따로 로딩이 일어나지 않는다는 것이다.  예를 들어 isLoaindg으로 spinner를 보여주도록 해놨을 때 초기 진입 때만 로딩이 걸리고 이후 재진입 때는 spinner를 볼 수 없는 이유가 바로 이것 때문인 것이다.

 

6. refetch 조건 정리

컴포넌트단에서 단순 "리"렌더링만으로는 react-query는 다시 fetch 하지 않는다. query의 기타 다른 함수를 사용하지 않고 state 변경으로 인한 리렌더링과 관련해서 직접적으로 fetch를 유발시키려면, state를 react-query의 enabled나query key에 react state를 포함시키면 된다. 단순히 queryFn에 사용되는 parameter가 바뀌는 것만으로는 다시 fetch를 하지 않는다. 그렇기 때문에 parameter에 사용되는 state라면 보통 query key에도 같이 적어주는 것이 반 강제적으로 필수이다. 더 자세한 fetch 조건을 정리하자면 아래와 같다.

1. query key에 react state를 포함시키고, state가 변경되면 refetch (기본적으로 이것만 잘 지켜도 refetch를 기대할 수 있다.)
2. refetchOnWindowFocus >> 데이터가 stale 상태일 경우 윈도우에 포커즈가 이동될 때 마다 refetch
3. refetchOnMount >> 마운트 될 때마다 refetch
4. refetchOnReconnect >> 연결이 끊어졌다가 재 연결 되었을 때 refetch
5. clientQuery.invalidateQueries() >> 고의로 쿼리 무효화를 했을 때 refetch, 서버 데이터를 변경한 후 새로운 데이터를 받아오기 위해 고의로 쿼리를 무효화 >> 데이터가 바로 stale 상태로 변경됨과 동시에 refetch 실행
6. 명시적으로 refetch 함수를 호출 할 때
7. enabled 변경할 때

이외의 경우는 더 없다.

 

 

 

7. 유용한 옵션

7-1. refetchOnWindowFocus

  refetchOnWindowFocus 는 stale 상태일 경우 window focus 때마다 refetch를 실행하는 옵션이다.

• (🌟추천 stale 상관O) 기본값은 `true` 이다. stale 상태면 refetch를 실행한다.
• (stale 상관X) `always` 로 설정하면 window focus 때마다 매번 refetch 를 실행한다.
• (stale 상관X) `false` 로 설정하면 window focus 되어도 refetch 하지 않는다.

  /**
   * TIL: refetchOnWindowFocus 는 stale 상태일 경우 window focus 때마다 refetch를 실행하는 옵션이다.
   * *(🌟추천 stale 상관O) 기본값은 `true` 이다. stale 상태면 refetch를 실행한다.
   * !(stale 상관X) `always` 로 설정하면 window focus 때마다 매번 refetch 를 실행한다.
   * !(stale 상관X) `false` 로 설정하면 window focus 되어도 refetch 하지 않는다.
   */
  refetchOnWindowFocus: false,

 

7-2. refetchOnMount 

refetchOnMount 는 stale 상태일 경우 컴포넌트 mount 때마다 refetch를 실행하는 옵션이다.

• (🌟추천 stale 상관O) 기본값은 `true` 이다. 마운트 때마다 stale 상태면 refetch를 실행한다.
• (stale 상관X) `always` 로 설정하면 마운트 시마다 매번 refetch 를 실행한다.
• (stale 상관X) `false` 로 설정하면 최초 fetch 이후에는 refetch 하지 않는다.

  /**
   * TIL: refetchOnMount 는 stale 상태일 경우 컴포넌트 mount 때마다 refetch를 실행하는 옵션이다.
   * *(🌟추천 stale 상관O) 기본값은 `true` 이다. 마운트 때 stale 상태면 refetch를 실행한다.
   * !(stale 상관X) `always` 로 설정하면 마운트 시마다 매번 refetch 를 실행한다.
   * !(stale 상관X) `false` 로 설정하면 최초 fetch 이후에는 refetch 하지 않는다.
   */
  refetchOnMount: false,

 

7-3. refetchInterval 

 `refetchInterval` 는 stale 상태일 경우 일정 시간마다 refetch를 실행하는 옵션이다.(단위 ms)

`refetchIntervalInBackground` 은 창에서 벗어나 있는 상태여도 refetch를 실행해주는 옵션이다.

• 중요한 점은 브라우저에 focus 되어 있어야만 일정 시간마다 자동으로 refetch가 실행된다.
• 기본값은 `false` 이다.
• 하지만 focus 안 되어 있을 때도 작동하게 하는 방법이 있다.
• `refetchIntervalInBackground` 에 true 로 값을 주면 된다.
•  기본값은 `false` 이다.

  /**
   * TIL: refetchInterval 는 stale 상태일 경우 일정 시간마다 refetch를 실행하는 옵션이다.(단위 ms)
   * ! 중요한 점은 브라우저에 focus 되어 있어야만 일정 시간마다 자동으로 refetch가 실행된다.
   * * 기본값은 `false` 이다.
   * * 하지만 focus 안 되어 있을 때도 작동하게 하는 방법이 있다.
   * ! `refetchIntervalInBackground` 에 true 로 값을 주면 된다.
   * * 기본값은 `false` 이다.
   */
  refetchInterval: 2000,
  refetchIntervalInBackground: true,