[React] 이번 프로젝트에서 React-query를 선택한 이유

안치영·2022년 12월 21일
0

React

목록 보기
13/15

이번 프로젝트에서 React-Query를 선택하게 된 이유에서 얘기해볼까 한다.

React-Query는 서버의 상태를 다루는 라이브러리이고
mobx와 redux 등은 클라이언트의 상태를 다루는 라이브러리이다.

💥 redux를 사용하지 않았던 이유

먼저 SPA(Single Page Application)의 문제점에 대해 얘기해 볼 필요가 있다.
리액트와 같은 SPA의 장점은 웹앱 개발에 많은 변화를 주었고, FE코드에서 BE코드를 분리하는 것은 관심사를 분리하고 전문화 하게 해주었고, 상태와 같은 복잡성도 생겨나게 되었습니다.
이제 FE개발의 큰 부분은 상태관련버그, 데이터 비졍규화, 오래된 데이터에 방해받지 않고 전역 저장소를 관리하는 방법으로 인해 부담을 겪고 있었습니다.

나아가 리덕스는 캐시가 아닙니다.
리덕스나 유사한 라이브러리를 사용할 때 가장 큰 문제는, 우리가 그것을 BE상태의 캐시로 취급한다는 것입니다. 우리는 리덕스가 너무 많은 일을 하도록 만들며, 만능 솔루션으로 취급하는데 FE상태와 BE상태는 실제로 동기화 되지 않는다는 것 입니다. 이것은 클라이언트-서버 모델의 단점이며 FE에 캐시를 둬야하는 이유입니다. 하지만 상태를 캐싱하고 동기화 하는 것은 엄청나게 복잡하므로, 리덕스가 권장하는 것 처럼 BE상태를 처음부터 재작성하는 짓은 하지 말아야 합니다.

실제로 redux를 통해 데이터 요청코드, pending, success, error 등 모든 처리를 해주려면 별거 아닌 요청에도 비대한 코드를 작성해야하는 단점이 있고, 이러한 점 때문에 불필요한 보일러플레이트 코드가 많아지기 때문에 사용하지 않았습니다.

💥 react-query를 사용함에 있어서 다른 상태관리 라이브러리보다 뛰어난 점

  • 로딩,에러처리,무한스크롤 등 많은 기능이 탑재되어 있다.
  • 서버와 클라이언트 간의 비동기 작업을 쉽게해주는 라이브러리 이기 때문에 개발자가 전역적으로 관리해야하는 데이터가 매우 적다.
  • 서버에서 데이터를 받아오는 작업이 매우 간편하고 데이터 캐싱을 아주 쉽게 해결할 수 있다.
  • 데이터가 오래되었다고 판단하면 다시 데이터를 가져오고, redux-thunk를 사용할 시 불필요한 보일러플레이트 코드가 반복되는 것에 비해 코드량이 매우 줄어든다.
  • 자체 내장되어있는 devtools를 개발 환경에서 사용할 수 있기 때문에 데이터를 보기 간편하다.

이러한 장점 때문에 사용하게 되었다.

카카오페이 프론트엔드 개발자들이 react-query를 왜 쓰는건지에 대한 아티클을 봤는데 아주 인상깊었고 위와 같은 이유 때문에 react-query를 사용하게 되었다.

궁금하시면 아래에 링크에서 보면 됩니다.
카카오 아티클

또한, react-query는 전역 상태관리 라이브러리가 아니기 때문에 recoil이나 jotai 같은 간소한 상태관리 라이브러리와 함께 많이 사용되는데 제일 추천되는 조합은
react-query + recoil 입니다.

0개의 댓글