디자인과 서버 개발을 기다리는동안 이것저것 많이 찾아봤다.
그 중 클라이언트와 서버 데이터를 따로 관리하는 recoil과 react query 조합도 있었는데, 지금 만들고 있는 서비스에선 서버 데이터를 그다지 많이 사용하지는 않기 때문에 새로운 기술을 굳이 두개나 도입할 필요가 있을까?싶어 RTK Query를 도입해보기로 결정했다.
Recoil 정리글 바로가기
react-query 정리글 바로가기
RTK Query vs react-query
RTK Query는 react-query와 비슷한데, 공식문서에 따르면 "Redux Toolkit 패키지에 포함된 선택적인 추가기능"이며 "Redux Toolkit에 있는 다른 API와 같이 제공"된다.
작업중인 프로젝트에서 소켓 통신 관련 데이터를 Redux Toolkit으로 하고 있기 때문에, RTK Query를 사용해보면 좋겠다고 생각했다.
Redux-Toolkit ThunkAPI vs RTK Query
기존에 Redux Toolkit으로 axios 통신을 하려면, 다음과 같은 절차를 거쳐왔다.
1) axios interceptor 파일을 만들어 interceptor를 관리한다.
2) api 파일을 만들어 관련 api들을 관리한다.
3) redux module에서 thunkAPI를 만든다.
4) 컴포넌트에서 thunkAPI를 dispatch 한다.
5) slice에서 extrareducer로 상태 관리를 한다.
6) 데이터가 필요한 곳에서 useSelector를 사용해 데이터를 호출한다.
뭔가 좀 많지 않은가? 이해하고 나면 그렇게 어려운 개념은 아니지만, thunk는 boilerplate 코드도 많고, 이 절차가 복잡하다는 의견이 많다. 그래서 다들 react-query를 쓴다고 한다.
react-query와 비슷한 RTK Query는 통신을 위해 다음과 같은 절차를 거친다.
1) query를 만든다.
2) useQuery로 필요한 데이터를 호출한다.
와우. 이렇게 쓰니까 엄청 간단해보인다 ㄷㄷ
RTK Query에 내장된 속성들을 잘 이용하면 따로 instance를 만들어 인증 요청 시 헤더를 넣어주지 않아도 되고, 에러 핸들링도 미들웨어를 사용해 한번에 할 수 있다. 그리고 에러 처리도 그냥 error 불러와서 쓰면 된다!
사용해보니 좋았던 점
- react-query처럼 굳이 새로 설치하지 않아도 됨
- tag를 걸어서 알아서 api를 재호출하게 할 수 있음
- 알아서 캐싱도 관리해줌
- 같은 데이터에 대한 여러번의 요청이 있을 시 중복을 제거함(이게 정말 좋은것 같다.. 굳이 신경쓰지 않아도 되잖아 !! 히히)
- 에러 핸들링이 쉽다(전체적인 에러 핸들링도 할 수 있고, 세부적인 에러 핸들링도 컴포넌트에서 바로 할 수 있다)
- 데이터 조작이 편리하다(굳이 instance를 안써도, transformResponse, transformErrorResponse 등을 활용해 응답 데이터를 내 입맛대로 조작할 수 있다)
- 상태 관리를 안해도 된다(refetching이 너무나도 깔끔하게 된다 ㄷㄷㄷ 난 내가 나도 몰래 상태 관리 하고 있는줄 알았3)
- 요청과 응답을 한 큐에 해결할 수 있다(dispatch, selector 쓰면 벌써 두 줄이야~~)
- 이번 프로젝트에 rest api를 사용하는 부분이 많지 않아서 많은 기능을 사용하진 않았지만, 굉장히 편리한 내장 기능들이 많은 것 같다.
사용해보니 불편했던 점
- 참고할만한 레퍼런스가 매우 적다.. 한국어로 된 글은 거의 없다보니(심지어 공식문서도 번역하다 말았던데,,) 공식 문서를 직접 읽어야했다. 근데,, 공식 문서 읽는거 되게 좋은 것 같다는걸 깨달아서 사실 그렇게 불편하지 않았음 ㅎ 정말 기능이 많고나!!!!
그래서 또 쓰고 싶음?!
- 물논이다~! 좀 더 rest api 활용을 많이 하는 프로젝트를 기획해 한번 제대로 써보고 싶다! 정말 편리해보이는 기능들이 많다 ㅎㅎㅎㅎ
그래서 어느 프로젝트에서 썼냐구 ?! 가치마인드 프론트 깃헙 바로가기
