[React] React Query - 기존 상태 관리 라이브러리의 단점

React를 사용하다보면 자연스럽게 마주하는 부분이 상태 관리일 것이다. 

 

Hooks를 사용하는 useState만으로는 프로젝트의 크기가 커진다면 불편함을 느낄 것이고,

그러면 자연스럽게 전역 상태 관리에 눈이 가게 될 것이다. 

 

React는 Redux, MobX, Recoil 과 같은 전역 상태 관리가 있다.

그런데 어느날 React Query 라는 것을 알게 되었는데, 이것도 상태 관리를 도와주는

라이브러리라고 한다. 

 

hmm... 솔직히 들어보지 못했다. 이런 것이 있는줄은.... 

그래서 한번 찾아보니 일반적으로 상태 관리는 Client의 상태와 Server의 상태가 있다. 

그동안의 나는 당연하다듯이 Redux를 사용해서 두가지 상태를 모두 관리하게 되었다. 

 

Redux를 사용해서 서버와 통신을 하기 위해서는 React-Thunk와 같은 미들웨어를 사용해야한다. 

 

근데 나는 React-Query를 알기 전까지만 해도 솔직히 이게 불편하다? 이상하다? 라는 

생각을 하지 못했다. 

 

아니 불편하다까지는 공감한다. 하지만 React-Thunk를 사용하는 것이 이상하다는 

느낌을 받지 못했다. 

 

한마디로 내가 느끼기엔 React Query는 불편한 부분을 도와주는 라이브러리라고 생각했다. 

 

Redux, 불편한 점 

카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유

아래 링크를 남기겠지만 React Query에 대해서 더 공부하는 중 카카오 페이에서 

React Query에 대한 좋은 글이 있어 해당 내용을 보았다. 

 

1. Boilerplate 코드 

내가 생각한 Redux의 단점을 이야기 한다. 

 

Redux로 개발을 하다보면 비동기 작업을 위해서 생각보다 많은 처리가 필요하다. 

(Thunk를 사용한다면 어느정도? 줄지만 일반적으로 Saga를 사용하기에... )

 

Client의 상태만 관리한다면 Redux가 크다고 생각하는 느낌을 받지 못하겠지만, 

비동기 작업을 Redux를 사용해서 구현한다면 확실히 코드가 많고 복잡해진다. 

 

2. API 요청 수행을 위한 규격화된 방식 부재 

이 부분부터는 내가 생각하지 못한 부분이다. 

 

Redux는 API 통신 및 비동기 상태 관리를 위한 라이브러리가 아니다.

Redux는 API 통신 및 비동기 상태 관리를 위한 라이브러리가 아니다. Redux를 사용해서
비동기 데이터를 관리하기 위해서는 하나부터 열까지 관련된 코드를 구현해야한다.

이건 내가 당연하다고 생각한 부분에 대한 의문이라 충격을 받았다. 

 

생각없이 Redux는 상태 관리 라이브러리니깐 이렇게 구현해야겠다.

라는 마인드로 솔직히 사용했었는데, 이 글을 보니 놀라게 되었다. 

 

확실히 개발자에 따라 데이터를 관리하는 방식과 방법이 달라지기 때문에 인원이 적다면 문제없지만 

많은 인원과 협업을 한다면 이것을 맞춰나가는 일도 많은 노력이 들 것이다. 

 

자 여기까지가 불편함을 느끼는 부분에 대한 내용이다. 

내가 찾아본 글에는 실제 사용기도 나와 있었지만 이부분은 내가 직접 경험해보고 

이후 다시 작성하려고 한다. 

 

문제점은 솔직히 내가 생각하기엔 아직 불편함을 느끼지 못해서 참고를 위해서 작성했지만 

이게 React Query를 사용함으로 어떻게 해결 가능한지는 추후에 다시 작성하겠다. 

 

참고 

https://tech.kakaopay.com/post/react-query-1/

카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유 | 카카오페이 기술 블로그