요즘 프로젝트를 하느라 정말 정신이 없다. 시간이 정말 빨리간다.
바쁘게 사는 것 같아 뿌듯하다.

이번 프로젝트에서 새롭게 도전해보는 기술에는 react-query와 소켓 통신을 위한 sockJS, stompJS가 있는데, 아직 실시간 채팅 기능은 구현하기 전이라 공부만 살짝 했는데 어느 정도 감이 잡혔다. 근데 백엔드와 같이 함께 구현해야하는데 나도 잘 몰라서 조금 걱정이긴 하다.😂

react-query를 공부하면서 알게 된 지식들은 따로 블로그에 정리를 하고 있는데, react-query의 장점, 왜 쓰는지에 대해서는 블로그에 정리한 적이 없어서 이번에 정리해보려 한다.

server state와 client state

server state는 서버로 부터 불러와 사용되는 데이터를 말한다. API 요청을 통해 서버에서 전달 받는 형식이라 클라이언트에서 제어가 불가능하다.

client state는 클라이언트에서 제어가 가능한 데이터를 말한다. 예를 들면 사용자로부터 입력 받는 input 데이터, 야간모드 주간모드를 위한 데이터 등이 있다. 서버를 전혀 거치지 않는다.

react-query를 사용하는 이유

✔ 우선 server state를 쉽게 관리하기 위해 사용된다.
redux, recoil, mobx 등의 전역 상태 관리 라이브러리들이 존재하지만, 언급한 라이브러리들은 모두 client state관리에 적합한 라이브러리로서 server state를 제어하고 관리하기에는 조금 어려움이 있다.

예를 들어, redux-thunk를 사용하여 비동기 API 통신을 구현해보면, 보일러 플레이트도 많지만 이건 둘째 치고, 서버의 데이터를 변경하고 나서 그 데이터를 가져오는 액션을 dispatch 해야 최신의 데이터를 가져올 수 있었다.
나는 이 부분이 너무 불편했다.

react-query에서는 개발자가 하나하나 dispatch 해주는 것이 아니라 react가 알아서 최신의 데이터를 가져올 수 있도록 하게 해준다. 이 부분이 정말 좋았다.

그리고 react-query의 장점을 알아보자.

1. 캐싱

서버에서 가져온 데이터를 캐시에 저장하여 캐시에 데이터가 남아있으면 그 데이터를 가져와서 사용할 수 있어 불필요한 반복적인 API 요청을 막을 수 있다.

2. 최신 server state

최대한 빨리 최신의 server state로 업데이트가 가능하다.
react-query는 가지고 있는 데이터가 stale한 상태라고 판단이 되면 다시 데이터를 가져올 수 있다.

3. 동일한 데이터 요청 제거

동일한 데이터가 여러 번 요청되면 한 번만 요청한다. 옵션으로 중복 호출 가능 시간을 조절할 수 있다.

4. 에러핸들링, 로딩

에러핸들링과 로딩을 정말 쉽게 처리할 수 있다. isError, isLoading, isFetching 등을 react-query에서 제공하기 때문에 이를 위한 loading, error state를 따로 선언하여 사용하지 않아도 된다.

5. 가비지 컬렉션

캐시에 남아있는 데이터가 오래 사용되지 않으면(cacheTime이 지나면) 가비지 컬렉션이 작동하여 데이터를 삭제한다. react-query가 알아서 메모리를 관리해준다.