Apollo Client의 mutation 이후 refetch 간단 정리

Updated:
2 minute read

본 글은 apollo-client 를 기준으로 작성했습니다.

개발하다보면, mutataion을 수행한 이후, 변경 사항을 보여주고자 다시 query를 요청하는 경우를 자주 보게 됩니다.

이럴 때 apollo client는 두 가지의 대표적인 refetching 방식을 소개하고 있습니다.

  1. refetch 함수
  2. refetchQueries 옵션

이번 글에선 이에 대해 간단히 살펴보겠습니다.

refetch

refetchuseQuery의 리턴 값인 QueryResult의 property 중 하나 이며 이름 그대로 데이터를 다시 한 번 fetch 하는 함수입니다.

variables를 optional하게 받을 수는 있지만 기본값은 처음 전달한 variables 그대로 입니다. 동일한 variables를 사용했을 시 fetchPolicy에 따라 cache를 resolve 하는 것을 방지하기 위해 refetchnetwork-only를 기본 fetchPolicy로 삼습니다.

refetchQueries

useMutation은 mutation 이후 바로 실행할 query 를 refetchQueries 옵션으로 받고 있습니다. 덕분에 onCompleted에 할당된 콜백함수에서 refetch()를 호출하지 않더라도 mutation 이후 자동으로 리소스를 재요청할 수 있습니다.

refetchQueries 옵션은 queryvariable의 배열을 값으로 갖는데, 자세한 타입 정보는 공식 문서에서 확인할 수 있습니다.

추가로 awaitRefetchQueries 옵션을 통해 refetchQueries에 입력한 query의 동기/비동기 여부를 설정할 수도 있습니다.

networkStatus

재요청을 하다보면 최초 요청과 재요청의 loading을 구분해야할 상황이 발생하기도 합니다.

이 때는 QueryResultloading property 대신 networkStatus를 통해 현재 네트워크 상태를 자세히 확인할 수 있습니다.

networkStatus를 조회하기 전에 우선, notifyOnNetworkStatusChange 옵션을 true로 바꿔 networkStatus를 활성화해줍니다. networkStatus는 네트워크 상태에 따라 1에서 8까지의 값을 가지며, 값의 의미는 다음과 같습니다.

value status
1 loading
2 setVariables
3 fetchMore
4 refetch
5 -
6 poll
7 ready
8 error

이 중 최초 query는 1(loading), refetch는 4(refetch)의 값을 요청이 in flight 인 동안 갖게 되고 이를 통해 요청에 따라 loading을 구분할 수 있는 것입니다.

여기서, 한 가지 주의해야할 점이 있는데, refetchQueries로 재요청한 경우엔 networkStatus 값이 4가 아닌 1이 온다는 것입니다. (개인적으론 버그 보단 스펙 같습니다.) 만약 재요청 여부에 따라 loading 중 다른 동작을 부여하고자 할 땐 refetchQueries 옵션 보다는 refetch 함수를 직접 호출해야겠습니다.

References

refetch: Queries - Client (React) - Apollo GraphQL Docs

refetchQueries: Advanced topics on caching - Client (React) - Apollo GraphQL Docs

networkStatus: apollo-client/networkStatus.ts

Apollo Client Hooks API: Hooks - Client (React) - Apollo GraphQL Docs

Apollo Client HOC API: apollo-client/hoc.mdx at main · apollographql/apollo-client

Back to top ↑

Leave a comment