6. 장점
기존에 Redux-thunk를 활용한 데이터 fetching은
하나의 api당 100줄의 코드를 작성해야 했음.
(Redux thunk-action + reducer + 컴포넌트)
React-query를 활용하면 동일 로직을 20줄 이내로 축소 가능 (생산성 ↑)
7. 단점
1. 새로운 라이브러리 도입을 위한 팀원들의 학습이 필요
-반론 : Redux, Redux-thunk에 비해 5배 쉬움(hook이랑 비슷)
2. Redux는 코드를 중앙에 모아서 작성하나, React-query의 경우
컴포넌트 훅처럼 각각의 컴포넌트에서 api 호출
- 한눈에 모든 api를 확인하기 어려움
-반론 : Redux를 활용해도 코드가 많아지면 한눈에 보기 힘들어짐.
10. 현재 방식
1. 모든 api호출 함수를 Redux에 작성
2. 각각의 컴포넌트에서는 dispatch를
통해 실행
단점
1. 전역 상태로 관리할 필요가 없으나
어쩔 수 없이 전역으로 관리하게 됨
2. 하나의 api마다 작성해야 하는 코드 多
11. 개선 방안
Api는 컴포넌트 내에서 query hook을 통해 호출
- 작성할 코드가 적기에 생산성↑
Client 전역 상태 ex) 로그인, 팝업, UI 상태
등은 Zustand로 관리 (2022/03/30)
단점
1. 기존의 Redux 코드 수정 필요(레거시)
2. 러닝 커브
12. 질문
굳이 Redux로 잘 동작하는데?
- 로그인 새로고침 적용 문제를 해결하기 위해서는
어차피 지금 Redux 코드를 변경해야함.
- 앞으로의 기능 개발을 react-query로 한다면
과거의 코드도 미래와 통일성 있게 만들 필요 有
- 다른 회사들도 Redux > react-query 변경중
참고자료
https://techblog.woowahan.com/6339/
16. 커스텀 훅 불러오기
만들었던 커스텀 훅을 사용할 컴포넌트에서 import하여 사용한다.
17. Props를 사용하지 않는다.
React-query는 키 값마다 데이터를
fetch 후에 캐싱한다.
다른 컴포넌트에서는 캐시된 데이터를
사용하게된다.
따라서 하위 컴포넌트에게 props로
데이터를 전할 필요 없이, 같은 키 값의
훅을 한번 더 호출하면 된다.
캐시 값 불러오는 명령어
queryClient.getQueryData(키값)
18. 캐시 시간 설정
1. 모든 query에 대한 공통 캐쉬 시간
설정이 가능하다.
staleTime : 밀리세컨
20. 캐시 비우기
직접 캐시를 비우고 싶을 때
invalidateQueryies( ) 를 사용한다.
( ) 안에 원하는 훅의 key 값을 넣으면 된다.
21. 예외 처리
필요에 따라 예외 조건을 걸 수 있다.
Enabled: 부분에 Boolean 값을 넣는다.
- true일 때만 발동된다.
(모달창을 띄울 때)
22. 데이터 변경
받은 데이터를 한번 가공하여
내보낼 수 있다. (select 옵션 사용)
23. Redux, React-query 구분
Redux와 React-query를 용도에 맞게 구분하여 사용한다.
Redux : 클라이언트 상태관리 라이브러리
query : Server 상태관리 라이브러리
- 서버에서 가져온 데이터는 react-query를 사용한다.
- 클라이언트에서만 사용하는 데이터(UI, 모달, 팝업 등)는 Redux를 활용한다.