Dev/React.js

[React] React Query

隣席の開発者群 2023. 5. 24. 16:28
반응형

기본적인 상태관리에 이어서 상태관리 라이브러리에 대해서 이야기를 시작해보고자 한다. 

상태관리 라이브러리라고 하면 React Query를 제외하고라도 상당히 종류가 많은데, 

굳이 React Query로 상태관리 라이브러리에 대한 이야기를 시작하는 이유는 그냥 내가 가장 최근에 썼기 때문이다. 

나는 다른 분들이 써둔 글처럼 공식 Doc에 근거하기 보다는 일단 내가 이해한 방식대로 정리를 할 예정인데

아마 무조건 틀릴거긴하다. 그래도 일단 기록은 남겨야지 이런 삽질을 했다~ 라는 느낌으로 다가.

 

1. React Query란?

캐싱 기반의 상태관리를 해주는 라이브러리다. (캐싱 이해 잘해야한다.)

useQuery라는 hook을 통해서 querykey라는 고유값의 이름을 가진 글로벌 상태를 만들어두고, 

querykey를 통해서 이 상태를 컨트롤한다. 

가장 심플하게 구성하는 방법을 예제 코드로 살펴보자. 

 

//app.js
//Redux에 비유하면 Store에 해당하는 글로벌 State저장소를 만들어줘야한다. 


const queryClient = new QueryClient({})// 여기 {} 안에서 defaultOption들 설정가능하다.

return (
	<QueryclientProvider client={queryClient} >
    		<router/>
	</QueryclientProvider>
);

 

이렇게 App.js 안에서 전체 컴포넌트들을 감싸는 QueryClient를 만들어 주고나면 useQuery를 사용할 준비가 끝났다.

이 이후엔 그냥 컴포넌트 내부에서 마음껏 useQuery로 상태를 만들어주면 되는데, 대부분 서버에서 데이터를 가져와서 사용할거라고 가정을 하고, 한번 예를 들어보자.

 

const SampleComponet = (props) => {
	const queryKey = 'sampleQuery'; // queryKey는 string, string[] 타입이 가능하다.
	const { data, refetch } = useQuery({
    	// 여기가 관련옵션 작성하는 곳, 아무것도 설정하지 않고 default로 쓴다고 가정하겠다.
        queryKey,
        queryFn: async () => {
        	const res = axios.get(
            	'대충 API 주소'
            )
            return res;
        }
    })

	return (
    	<div>{res.data}</div>
    )
}

이런 느낌이다. 이런 식으로 쿼리를 선언하면, queryClient에 querykey를 고유값으로 해서 관리된다. 

기본 사용법은 뭐 이정도면 될 것 같고, 이제 부터는 React Query의 특징에 대해서 알아보자. 

 

2. 좀 특이한 React-Query 

React-Query를 사용하면서 진짜 많은 문제를 겪었다. 애초에 용도가 다른 상태관리 라이브러리들이랑 다르다는 느낌?

물론 다양한 옵션을 제공하고 있기 때문에, 옵션을 바꾸면 다른 라이브러리들이랑 거의 동일하게 사용이 가능하다만, 근데 괜히 마음이 그렇다. default는 다른 라이브러리들이랑 다르니까.

 

React-Query는 Data를 fresh한 상태와, stale한 상태로 구분하는데, stale로 바뀌는 시점이 되면 알아서 다시 Request를 날린다는 특징이 있다. 일단 Default로 정해져있는 staleTime (받아온 데이터가 Stale하다고 여겨질때까지 걸리는 시간) 은 0이다. (그러니까 데이터 받아오면 바로 낡았다고 생각하고 계속 Request 날려버림.)

이거 들으면 바로 생각할 수 있을 것 같은데, 실시간 업데이트가 필요한 프로그램들에 진짜 딱 좋아보인다. 물론 enable이라는 옵션으로 못하게 할 수 있다. 

 

<React Query의 Caching에 대한 이해>

React query하면 이 caching기능을 빼놓고 얘기하기가 뭐한데, 대부분 이해를 좀 잘못하고 있더라.

(나도 이해 잘못하고 있었음ㅋ)

캐싱을 제대로 사용하기 위해서는 StaleTime과 상당히 연관성을 가지고 있기 때문에 상황에 따라 StaleTime을 설정해주어야한다.

왜냐면 data를 받아온 뒤에 이 data는 react query의 캐시에 저장이 되게 되는데, 이 data가 어느 정도 시간 후에 stale한지 판단하는 기준이 StaleTime이기 때문이다. 즉, data가 자주 변경될 일이 없는데 StaleTime을 설정해주지 않아서 계속 서버에 Request를 날리게 된다면, 이는 서버에 부담을 안겨주는 요인이 된다는 의미다. 

또한, CacheTime이라는 옵션은 이 캐시 안에 저장되어있는 데이터가 지정한 시간이 지나면 메모리에서 사라진다는 이야기이니, StaleTime과 CacheTime에 대한 차이를 제대로 구분하고 사용하는게 필요하다고 생각한다. 

 

3. 어디에 쓰면 좋을까?

개인적인 생각으로는 앞에서도 언급했지만 상당히 데이터의 업데이트가 잦은 케이스일 때 적용하면 빛을 발할 것 같다. default 옵션으로 사용한다면 계속 자동으로 쿼리를 날리기 때문에 사용자가 잘못된 데이터를 확인할 가능성을 최대한 줄여줄 수 있다고 보인다. 

LIST

'Dev > React.js' 카테고리의 다른 글

[React] useMemo, useCallBack  (0) 2023.06.01
[React] MobX  (0) 2023.05.30
[상태관리] 상태관리(State)  (0) 2023.05.18
[React] .js & .jsx  (0) 2023.05.02
[React] 함수형 프로그래밍과 hooks  (0) 2023.05.02