react-query를 기존에도 사용하고 있었는데 프로젝트 특성 상 캐시되지 않도록 구현해야 했기 때문에 서버요청을 병렬적으로 처리하거나 데이터 패칭기능을 위주로 사용하고 있었다.
그러나 내부 상황 상 유저를 트래킹할 필요가 없게되어 캐싱 기능을 도입하게 되었다. 생각보다 관련 옵션이나 기능이 많아서 정리해두는게 좋겠다고 생각했다.
react-query 장점
- 패칭
- 캐싱
- 동기화
- 서버쪽 데이터 업데이트
기존에 알고 있던 상태관리 라이브러리는 클라이언트 데이터 관리에 적합함.
예를들어 관리자화면에서 동시에 두 관리자가 같은 페이지를 보고 있는 상황에서, 한 명이 데이터를 변경하면 다른 사람에게도 변경된 데이터가 보여야 한다. => 서버 데이터 관리에 적합
- stale : 낡은 데이터 -> 패칭
- staletime : 받아온 데이터를 신선상태로 유지시켜줄 지 옵션 (default 0)
- cachetime: 쿼리가 unmount된 후 캐시메모리에 저장 된 데이터 유지시간 옵션 (default 5min)
캐싱이 안된다?
staletime을 지정해주지 않으면 항상 캐싱되어있는 데이터는 stale하다고 여기기 때문에 refetching하게되어 서버에 계속 요청됨 => 따라서 staletime을 지정해준다.
cachetime이 지나기 전에 쿼리인스턴스가 다시 마운트되면, 데이터를 패칭하는동안 캐시데이터를 보여준다.
invalidateQueries?
staletime과 cachetime이 만료되지 않아도useQuery가 가지고 있던 queryKey의 유효성을 제거해서 캐싱데이터를 화면에 보여주지 않고 서버에 새롭게 데이터 요청.
즉, 원하는 구간에만 invalidateQueries를 설정해주면 된다.
mutation 시에만 사용되는 건가..? → 데이터 변경 시 사용
일반적으로 get을 제외한 post, update.delete시에 사용하는데, 변경된 데이터를 패칭시간 전에 다시 받아오기 위한 방법으로 사용한다.
같은 페이지를 보는 다른 유저가 데이터를 변경한 경우? staletime만큼 새로고침 안돼...
react-query를 사용하며 이해가 안됐던 부분이 invalidateQueries와 관련된 부분이었다. 유저 입장에서 데이터 업데이트와 관련된 이벤트를 발생했을 때 staletime이 경과되지 않더라도 invalidateQueries에 queryKey를 등록하면 해당 쿼리를 refetch할 수 있다.
이 점을 이용해서 원하는 상황에서 fetching을 컨트롤하고 싶을 때 사용할 수 있을거라고 생각했다. 하지만 서버의 데이터가 변경되었는지 감지하는건 불가능하며 (socket통신하는거 아니면) invalidateQueries는 Mutation시에 삽입해서 사용해야하는 것인 걸 알게되었다.
(getData시 사용하면 해당 queryKey를 무시하고 계속 get해옴..ㅜ)
결국, react-query는 기존의 서버데이터 핸들링을 편리하게 해주는 것이지 만능은 아니었다.
refatching 제어?
- refetchOnWindowFocus
기본값 true. 단순 페이지 전환만으로 refetch
false로 변경 시 다른 화면으로 이동했다가 현재화면으로 되돌아 올 시 staleTime이 지났을 때 refetch
- refetchOnMount
데이터가 stale 상태일 경우 마운트 시 마다 refetch를 실행
always설정 시 마운트 마다 refetch
- refetchOnReconnect
stale 상태인 데이터를 Refetching
기타 제어 ?
enabled false로 설정 시 코드 실행 안됨 (Dependent Query or 조건문처럼 사용)
success / error 시 공통 핸들링도 가능 -> QueryClient-> defaultOptions
현재 진행중인 프로젝트에서는 read 위주의 기능을 사용하기 때문에 react-query의 기능들을 온전히 사용하지 않았다.
진행예정인 개인 프로젝트에서 더 공부한 후 접목시켜봐야겠다.
