invalidateQueries와 refetchQueries를 비교하며 얻은 트레이드 오프 생각하기

[gorjs3540]

평소 정보를 업데이트하는 api 요청 후 그 내용이 반영된 정보를 얻기 위해 여러 가지 방법을 사용한다. 그중 invalidateQueries를 이용하여 cache data를 최신으로 받아오는 작업을 빈번하게 사용한다. 그러던 중 나는 의문이 들었다.

"invalidateQueries는 data refetching의 기능도 하지만 목적은 data의 상태를 stale로 바꿔주는 method잖아? 왜 refetchQueries가 아니라 이걸 사용하고 있었지?"

이 의문을 떠올렸을 땐 뭔가 깨달음을 얻은 사람처럼 논리를 여기저기 펼치고 다녔다. "invalidateQueries는 stale 상태로 변경시켜주는 거잖아요. refetchQueries를 사용하면 그런 변화 필요 없이 바로 가져올 수 있어요." 실제로도 맞는 말이지만 코드 일관성, 여러 컨벤션과 설득 등 여러 곳의 정보를 보다 보니 생각이 점점 달라지기 시작했다.

"그러면 어떤 곳에선 invalidateQueries를 쓰고 어떤 곳은 refetchQueries를 쓴다? active한 상태의 query가 같은 화면에 있으면 refetch..." 이런 구구절절한 기준을 만들다보니 "그렇게까지 신경써야하나?"라는 생각도 들었다. 그러던 중 react-query의 maintainer의 의견을 들으면서 납득하게 되었다. "For queries with active observers, there is no difference as far as I'm aware = 활성화된 query의 경우 아주 근소한 차이다." 라는 것을 보고 너무 logic과 성능에 매몰되어 있었다는 생각이 들었다.

결론은 장인처럼 깎을 수도 있지만 그것에 대한 경제성과 트레이드오프를 생각해야 할 것. 그래서 invalidateQueries를 default 사용으로 결정했다. 실제로 maintainer는 "invalidation is a more smart refetching"라는 의견을 내기도 했다.

관련 PR: https://github.com/TanStack/query/discussions/2468?utm_source=chatgpt.com

---

비교하다가 뜯어본 내부 구현

queryClient.invalidateQueries()

// query의 isInvalidated 상태를 true로 바꿔주는 method. 즉, isStale 상태도 true로 변경시킴.
invalidateQueries<TTaggedQueryKey extends QueryKey = QueryKey>(
    filters?: InvalidateQueryFilters<TTaggedQueryKey>,
    options: InvalidateOptions = {},
  ): Promise<void> {
	  // batch()로 여러 업데이트를 묶어서 한번에 UI 반영
    return notifyManager.batch(() => {
      this.#queryCache.findAll(filters).forEach((query) => {
        query.invalidate() // invalidate를 실행시켜 상태를 stale로 변경시킴
      })

			// refetchType이 'none'이면 무효화만 하고 refetch는 안 함
      if (filters?.refetchType === 'none') {
        return Promise.resolve()
      }

			// refetch type에 우선 순위대로 진행
      return this.refetchQueries(
        {
          ...filters,
          type: filters?.refetchType ?? filters?.type ?? 'active',
        },
        options,
      )
    })
  }

queryClient.refetchQueries()

// refetch는 그냥 진짜 query.fetch를 다시 실행하는 것이였음.
refetchQueries<TTaggedQueryKey extends QueryKey = QueryKey>(
  filters?: RefetchQueryFilters<TTaggedQueryKey>,
  options: RefetchOptions = {},
): Promise<void> {
  const fetchOptions = {
    ...options,
    cancelRefetch: options.cancelRefetch ?? true,
  }
  
  const promises = notifyManager.batch(() =>
    this.#queryCache
      .findAll(filters)
      .filter((query) => !query.isDisabled() && !query.isStatic())
      .map((query) => {
        let promise = query.fetch(undefined, fetchOptions)
        if (!fetchOptions.throwOnError) {
          promise = promise.catch(noop)
        }
        return query.state.fetchStatus === 'paused'
          ? Promise.resolve()
          : promise
      }),
  )

  return Promise.all(promises).then(noop)
}

[al-bur]

"For queries with active observers, there is no difference as far as I'm aware = 활성화된 query의 경우 아주 근소한 차이다."

저도 비슷한 고민해본 적 있었는데, @gorjs3540님과 비슷한 과정으로 납득했던 것 같아요!! 근데, 글이 완전 생생하네요ㅋㅋ 감사합니다

[milooy]

잘읽었습니당
말씀해주신 것처럼 " active한 상태의 query가 같은 화면에 있으면 refetch..." 측면이 저는 '결합도'측면에서 공감이 가는데요,
invalidateQueries 보다 refetchQueries 가 데이터를 update 하는 화면과 fetch하는 화면의 결합도를 높인다는 생각이 들었어요.
그래서 더 낮은 invalidateQueries 가 예측가능성이 높아지는...ㅎㅎ

[gorjs3540]

오 "그런거까지 신경써야하나?" 라는 의문과 불편함을 어떻게 설명할까 고민했었는데 "결합도"를 사용하니 명쾌하게 해결되네요. 감사합니다! TIL에서 TIL을 배우다...