[발표]22.12.22 react-query 도입시 예상되는 장단점

Joseph·2023년 6월 1일

(이전에 남겼던 기록과 마찬가지로, 해당 내용은 발표한지는 오래되었지만 발표했던 내용을 기록해본다.)

당시 입사한지 한달 좀 넘었을 시기였는데, api 관련된 작업은 하나도 진행하지 않고 정적인 페이지만 빠르게 작업하고 있었다. (about, membership 과 같은 페이지들)

그리고 12월 중순이 되면서 api 연결이 필요한 로그인 페이지 작업에 들어가야 했는데...

react-query로 선택

이전에 데이터 패칭 라이브러리를 발표한 내용을 바탕으로 어떤 라이브러리를 사용할지 고민해본 결과, react-query를 사용하기로 결정했다.

사실 SWR, react-query, rtk-query 등 대부분이 캐싱 등 비슷한 기능들을 제공했기에 어느 라이브러리가 특별하게 우리한테 알맞을지 판단하기 어려웠다.

하지만

1) 유력한 후보였던 SWR이 isLoading과 같은 상태를 제공해주지 않는다는 것과(22년 11월 당시에는 그랬다)과
2) 데이터 패칭 라이브러리 비교표(react-query에서 만든거지만)에서 react-query가 더 많은 기능을 제공하고
3) react-query docs가 자세하게 나와있는 등의 이유로
react-query 라이브러리를 선택하였다.

그럼 react-query를 도입했을 때 예상되는 장단점은?

실제 react-query를 프로젝트에 도입해보진 않았지만, 예상되는 장단점을 간단하게 정리해서 발표하기로 했다.

예상되는 장점

1. 로딩, 에러 등 다양한 내용이 포함된 return 값 제공

useQuery의 return 객체에 useQuery 실행의 성공/실패/완료에 대한 정보가 들어있어 각 상황에 따른 처리가 편리하다

예시로

isLoading : query가 처음 fetching 중이라 아예 data가 없을 때 (서버에 데이터 처음 요청)
isError : query 결과가 error를 마주쳤을 때
isFetching: query가 fetching 중일때 (이전에 받은 캐시 데이터는 존재할수도, 안할수도 있음)

등과 같은 내용을 제공해주어 사용자가 핵심 로직에만 집중할 수 있도록 한다.

2. fetching 데이터를 캐싱하여 중복 요청을 줄인다.

특정 페이지에서 동일한 데이터를 가져오는데도 불구하고, 매번 api호출이 일어나면 서버 부하가 커진다.
react-query는 캐싱된 데이터를 가져와 사용할 수 있다.
또한, fetching하여 캐싱된 데이터는 전역 상태처럼 관리되어 어디서든 필요한 곳에서 사용할 수 있다.

3. 데이터가 오래(stale)되었다면 일정시간 후 refetching / 또는 일정시간마다 polling

api 호출 후 받아온 데이터가 너무 오래되어 서버의 데이터와 차이가 나는 것이 우려될 경우, 일정 시간마다 fetching 요청을 하는 방식으로 최신화를 시킬 수 있다.
각 useQuery 마다 설정을 달리 해서, 원하는 refetching 설정이 가능하다.

예상되는 단점

1. (SSR에서 사용 설정시) 보일러플레이트 코드

react-query를 SSR에서 사용할 경우 두가지 방식을 지원한다.

데이터를 prefetch하고 이걸 initialData 형태로 넘겨주기
- SSR에서 데이터 패칭을 완료하고, props로 패칭한 데이터를 넘겨서 initialData에 전달한다.
서버에서 데이터를 prefetch하고 캐시를 refresh한 다음에 이걸 client에 전달하기
- 미리 서버에서 여러 query를 prefetching 한다. 그리고 dehydrate를 한 뒤, 해당 페이지에서 hydrate하는 방식이다.
```
/ pages/posts.jsx
import { dehydrate, QueryClient, useQuery } from '@tanstack/react-query'

export async function getStaticProps() {
  const queryClient = new QueryClient()

  await queryClient.prefetchQuery(['posts'], getPosts)

  return {
    props: {
      dehydratedState: dehydrate(queryClient),
    },
  }
}
```
위와 같이 매 페이지마다 prefetchQuery 메서드를 작업해주고 해당 페이지에서도 useQuery를 작성하는 방식이라 다소 세팅해야하는 코드량이 많은 편이다.

2. Next js rewrite 기능과 쓸시 SSR에서 사용불가능…(Caveat for Next.js rewrites)

참조 사이트 : https://react-query-v2.tanstack.com/guides/ssr#using-hydration
만일 Next.js의 rewrites 기능과 함께 Automatic Static Optimization이나 getStaticProps를 쓸 경우
React Query에 의한 두번째 hydration을 발생시킬 수 있다.
우리는 rewrites를 사용하고 있었기에 react-query는 CSR에서만 사용하는 걸 고려해야 한다.

3. 학습 시간 or 추후 에러 발생시 시간 지연

실제 프로젝트에서는 처음 도입하는 라이브러리이므로 학습시간이 필요하다. 또한, 초기 환경 설정중 어떤 에러 마주할지 몰라 프로젝트 진행이 지연될 수 있다.

결론

Nextjs rewrite 이슈가 있기 때문에 react-query는 우선적으로 CSR에서 사용하기로 했다.
사실 react-query의 단점에 대한 내용은 찾기 어려워서 간단하게만 짚었었다.

Joseph

안녕하세요 프론트와 백 둘다 관심있는 웹개발자 이창무입니다.