티스토리 뷰

프로그래밍/React

요즘 핫한 React Query

수박수박좋다 2022. 9. 14. 20:29
반응형

React Query

Fetching, caching, synchronizing and updating server state 라이브러리

React Query Star : 8.4K

SWR Start : 5.6K

 

왜 등장했지 ?

전통적인 상태관리 라이브러리는 client 상태를 다루는데는 좋았지만 async 또는 server 상태관리에는 좋지 않았다.

Server 상태는 Client와는 매우 다르기 때문이다.

  • client에서 제어할 수 없음
  • 비동기 요청이 필요함
  • 나도모르게 변경될 수 있음
  • 최신결과를 가져오지 않으면 "오래된"상태로 남아있음

이러한 특징 때문에 하나의 store에서 둘의 상태를 관리하는 것은 쉽지 않았다.

또한 아래와 같은 것들을 해결해내기위해 엄청난 리소스가 투입이 되어야했다.

  • 캐싱 - 구현하기 많이 어려움
  • 동일 응답에 대한 다중 요청을 단일 요청으로 중복제거
  • "오래된"데이터를 백그라운드에서 업데이팅
  • "오래된"이라는 시점을 알기
  • 최신 데이터를 반영하기
  • 페이지네이션, lazy loading data 퍼포먼스 향상
  • server 상태에 대한 메모리관리
  • 쿼리 결과 메모이징

위의 사항을 해결했다면 React query를 도입하지 않아도 될 것 같다..

React Query를 위의 문제를 우리가 해결할 필요없이 위임이 가능하다.

또한 이를 사용하면 이전보다 메모리성능을 높일 수 있고, 복잡하고 잘못된 코드들을 해당 코드 로직으로 교체할 수 있다고 한다.

 

React Query - 왜 써야할까?? 남들이 쓰니까 ?

개발하면서 체감이 많이되었던 부분이고 다른 개발자분들의 고민에 공감이 되었던 부분이라 써보려고 합니다.

현재 상태관리하는 방법중 하나는 Redux와 같이 store에서 모든 state를 관리하는 것이다.

store에는 버튼의 비활성화여부, 체크박스의 체크여부 등을 가지는 View관련 state도 있고 또한

서버의 데이터를 가져오는 비동기 요청에 대한 응답결과 state도 같이 들어가있다.

서버 데이터를 브라우저에서 조작하며 수정도 발생할 것이고 삭제도 발생할 것이다. 그렇다면 이 데이터는 서버상태일까 클라이언트 상태일까? 전혀 구분되고 있지 않다.

한마디로 client에서 갖는 것과 server에서 오는 state가 합쳐진 혼종 store가 만들어지고 있는 것이다.

이 두개가 합쳐지다보니 점점 store가 비대해지고 관리하기도 어려워진다.

RTK의 경우 ducks 패턴으로 한 파일에 몰아서 작성하고 있는 경우가 많은데, 비대해지면 비대해질수록 라인수가 늘어나 유지보수하거나 디버깅하기 어려워진다.

 

RTK를 사용한 비동기 처리과정은 다음과 같다.

  • 컴포넌트에서 dispatch를 통해 비동기처리 액션을 생성함
  • thunk와 같은 미들웨어가 액션을 받아 비동기요청을 수행함
  • extraReducers가 해당 비동기요청의 결과를 받아 전역 state에 업데이트함

한가지 비동기요청을 처리하는데 작성해야하는 코드는 3군데나 된다.

 

React Query를 사용한다면 컴포넌트 내에서 요청들을 처리하고 또 필요하다면 데이터를 업데이트 할 수 있기에 코드가 적어진다.

 

이것도 되나?

이런 비동기요청에 대한 응답데이터를 React Query가 관리해주고 전역처럼 꺼내어쓸 수 있고 수정도 가능한 것인가 ?

useQuery라는 hook으로 가능하다. 다만, 한번 응답받은 데이터로 존재하는 것이 아니라 staleTime을 조절하여 n초가 지나고 해당 hook을 호출했다면 새로 요청을 보내 데이터를 최신화시킬수 있거나 또는 설정에 따라 불러오지 않을 수 있음을 유의하자.
Access data already fetched with react query in other component

 

 

무조건 장점만 갖고있지는 않다.

내가 들어가있는 오픈톡방에 거의 매일 ReactQuery에 대한 질문이 올라온다. 그만큼 유의해야할 점이 많다고도 생각이 든다.

보일러플레이트코드가 적어지지만 비동기 관련코드들이 컴포넌트로 들어오기에 이전보다 컴포넌트가 비대해질 수는 있다.

 

 

 

일단은 써보자

나 역시 서버데이터를 가져오고 관리하는 보일러플레이트코드가 너무 과하다고 생각이된다. 리덕스사가를 사용했을 때보다 RTK가 훨씬 몇배는 더 적어지긴 했지만 여전히 반복되는 코드들이 존재한다. 앱의 규모가 커지고있는데 이를 해결해야할 필요가 있다.

React query는 내 상황에 필요한 라이브러리라고 생각이 된다. 기록도 좋지만 써보면서 체감하는게 우선인 것 같다.

반응형
댓글
반응형
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
농담곰의 고군분투 개발기