React Query

React 애플리케이션에서 서버 상태를 가져오고, 캐싱하고, 동기화하고, 업데이트 하는 작업을 쉽게 만든다.

// ✅ : react-query를 사용하면 하나의 훅으로 모든 페칭에 연관된 상태를 한번에 제어할 수 있다.
const { status, data, error, isFetching } = useQuery(() => fetch(URL));

핵심개념 : Server-state와 client-state -- global state ㄴㄴ

• 비동기 관련된 로직 처리 -> 동기적으로 업데이트 되는 데이터와 액션만 남길 수 있다.
• Redux를 더 취지에 맞게 사용할 수 있음 : Redux는 전역관리를 useQuery는 서버에서 받아온 데이터 관리를

// TODO : 우리 프로젝트에 react-query를 쓰려는 이유가 뭐지? 상태관리를 리덕스없이 진챠 할 수 있는 것?

만들어진 동기

• react 자체가 데이터를 패칭해오거나 업데이트 하는 옵셔을 제공하지 앟ㄴ기 때문에 원래 React 개발자들은 각자의 방식으로 http 통신 로직을 짜야했다.
• Redux 같은 전역 상태관리 라이브러리들이 클라이언트 상태값에 대해서는 잘 작동하지만, 서버 상태에 대해서는 그렇게 잘 작동하지 않는다.Server State는 Client State와 완ㄴ전 다르기 때문
  • 서버 데이터는 항상 최신 상태임을 보장하지 않는다. fetching을 수행해야만 최신 데이터로 전환됨
  • 네트워크 통신은 최소한으로 줄이는게 좋은데, 복수의 컴포넌트에서 최신 데이터를 받아오기 위해 fetching을 여러번 수행하는 낭비가 발생할 수 있다.

사용법

• App.js에서 Context Provider로 컴포넌트를 감싸고 queryClient를 내려보내줌
  // TODO : Context가 뭐임??/

컨셉

• Query들은 4개의 상태를 가지며, useQuery가 반환하는 객체의 프로퍼티로 어떤 상태인지 확인이 가능하다
  • fresh : 새롭게 추가된 쿼리 인스턴스
  • fetching : 요청을 수행 중인 쿼리
  • stale : 인스턴스가 존재하지만 이미 패칭이 완료된 쿼리. 특정 쿼리가 stale된 상태에서 같은 쿼리를 useQuery로 또 호출해 마운트를 시도하면 캐싱된 데이터 반환
  • inactive : active 인스턴스가 하나도 없는 쿼리. 렌더링시에 다시 호출되지 않은 쿼리들은 inactive됨
• refetching이 일어나는 경우?
  • 렌더링 간 쿼리 인스턴스가 다시 만들어졌을 때
  • window가 다시 포커스 되었을 때
  • 네트워크가 다시 연결되었을 때
  • refetch interval이 있을 때 : 요청 실패한 쿼리는 디폴트로 3번 더 백그라운드단에서 요청하며, retry, retryDelay 옵션으로 간격과 횟수를 커스텀 가능하다

// TODO : 쿼리 인스턴스가 뭐임?

useQuery

useMutation

• server state에 side effect를 일으키는 경우에 사용(create, update, delete)
• useQuery를 호출하면 최상위에서 호출해야한다는 훅의 규칙에 위배되기 때문인듯

📑 reference
김맥스 기술 블로그 - React-Query 살펴보기