next js 12 tanstack/react-query v5 적용기

사용 이유

데이터를 관리하고 통신 과정 , stats를 사용해서 loading상태를 알아서 유저의 경험을 더 좋게 하기 위해서 SWR에 대해서 고려하게 되었다. 이전에 개인 프로젝트 내에서 React-query를 사용해 보기도 하였고 이미 커다란 프로젝트 내에서 _app.ts 파일을 감싸야 하는 것에 부담을 느끼고 라이브러리 용량 차이도 있어서 SWR을 고려하게 되었다.

SWR은 사용해본적이 없기도 하고 쉽고 간략하게 사용할수 있다 라는 점에서 사용해보려고 했는데

SWR vs React-query 를 검색해보며 내용들을 살펴봤는데 결국 React-query로 선정하게 되었다.

SWR vs React-query중 선정이유

이유
1. SWR 은 간편하게 사용할수 있다고 한다. < - SWR도 결국 에는 라이브러리를 설치하고 _app에 감싸서 사용해야 한다. (라이브러리 아니고 리액트 내장 훅인줄 알았다. ) (동점 이지만 SWR에 실망(?))

2. SWR vs React-Query 라이브러리 용량 차이 <- 용량은 SWR은 4.3KB사이즈로 가볍고 reactQuery는 13KB로 상대적으로 무겁다. (SWR 승)
3. SWR은 빠르게 렌더링하는 데에 필요한 데이터를 제공하는 것에 초점을 맞추고 있고 React Query는 API 호출로 받아온 데이터를 관리하는 것에 초점을 맞추고 있다.

캐싱 부분에서 SWR은 캐싱하면서 데이터 호출에 빠르게 관여할수 있지만 React Query는 캐싱+ 데이터 관리 에도 초점을 맞추고 있다.

캐싱을 가지고 있는것은 비슷하지만 React Query는 다른 사람들에 의해 값이 변경될수 있는 캐싱된 값에도 초점을 맞추고 있어서 캐싱된 데이터도 잘 관리하는 옵션을 가지고 있다.

결과적으로 캐싱 과 State 값으로 로딩중인지 아닌지 알기위해서 이 라이브러리가 필요했는데. 추후의 데이터들도 생각하고 있다는점(캐싱)에서 React-Query를 선택하게 되었다. 특히 가볍다고 해서 SWR이 더 간편하게 사용할수 있을것 같긴하지만 사용 방식에는 비슷하게 사용하는것 같아서 조금 실망했다.

이전에 사용해본적있는 React Query를 다시 적용하면서 배워 가기로 하였다.

ReactQuery 사용의 이점

1. useEffect로 mount 될때 처음 데이터를 가져오는 로직이 필요가 없어졌다.
   useEffect로 처음 사이트에 접속했을때 data를 fetch받는 로직을 매번 작성했는데
   react-query를 사용하면서 이 로직 구문 이 필요 없어졌다.

• 추가로 상세를 열고 닫을때 url파라메터로 0, 1 값을 줘서 useEffect의 두번째 인자로 감시하는 구문을 줘서 열릴때마다 호출하게 감시하도록 했는데 react-query내부의 enable 을 이용해서 enabled값이 있을때만 호출하기 때문에 이 구문도 삭제할수 있었다. 계속 감시하는 것도 성능적인 측면에 약간의 불편함이 있었는데 개선할수 있었던것 같다.

2. 기존 호출 관리를 위해서 데이터를 모아두는 setState구문 삭제,
   예시로 카드 리스트를 가지고 있었고 카드 상세 버튼을 누를때마다 카드 No에 맞는 detail정보를 호출해야해서 매번 호출 할때마다 서버 비용이 드는 것을 감안해서 useState를 사용해서 데이터를 담아두었다.

예시로 들면 [detailData,setDetailData] = useState() 로 detailData에 호출시마다 setDetailData 로 No값을 가진 데이터가 있으면 넘어가고 없으면 추가해주는 방식으로 나름 캐시 형태로 사용하였는데
reactQuery에서 자동으로 캐싱형태로 이전에 호출했던 값을 가지고 있어서 구문을 삭제할수 있었다.

다만 stale 시간을 체크하는데 일단 넉넉하게 5분정도로 설정해두었다. 5분정도 지나면 다시 refetch 가 일어난다.

데이터를 캐싱해서 가지고 있는것도 좋지만 만약 다른 컴퓨터에서 데이터를 바꿨는데 나는 state 로 캐싱해두어서 캐싱된 데이터를 감시하지 못한다. 하지만 이점으로서 좋은점이 react-query는 캐싱 데이터를 감시하고 있다는 점이다.

구문과 성능측면에서 효과적일것이라 생각이 된다.

3. 데이터 분리 이점 .select
   데이터를 가공하기 위해서 fetch를 받은 이후에 사용하고 싶은데이터를 가공해서 사용했는데 react-query의 option값인 select를 활용해서 데이터를 바로바로 가공해서 사용할수 있어서 좋았다.
   따로 훅으로 관리했는데 유지보수를 위해서 데이터를 가공하는 함수가 따로 떨어져 있어서 스크롤을 이동하면서 데이터를 추적해야 하는점이 불편했지만 이를 통해서 유지보수와 코드 파악이 한결 더 효과적으로 변한것 같다.

4. isLoading, isError 상태 관리
   원래 이것때문에 사용하려고 했는데 이것 또한 효과적이다. isLoading일때 Loading 중임을 알릴수 있어서 UX측면에서 효과적이다.