티스토리 뷰
redux에서 react query로의 전환 이유
redux에서 비동기처리를 해주기 위해서는 redux-saga 같은 미들웨어를
사용하여 상태에 저장시켜야 한다.
saga에서 api의 응답을 받고 redux에 저장하는 과정 속에서 api 상태에 따라 렌더링을 해야되는 상황이 발생한다.
이 때 isLoading, isSucess, isError 같이 상태를 별도로 지정해주고 이에 따라 렌더링을 해줄 수 있다.
(이처럼 Redux에서 비동기 처리를 할때 api 응답상태를 별도로 만들어 주어야한다.)
반면 react-query에서는 이를 기본 옵션으로 제공하고 있다.
이외에도 Redux를 사용시 다른 saga에 dependency를 두는 saga가 무수히 늘어나게 된다면,
중간 api 에 문제가 생겨도 에러 원인을 찾기 어려워지고 나도 모르게 sideEffect를 발생시킬 수 있다는 단점이 있다.
반면 react query에서는 필요로하는 dependency나 query 키를 enabled 값을 통하여 직관적으로 관리가 가능하다.
데이터 구분
Redux만 사용시 client side data (모달, 페이지 이름, loadStatus..)와 server side data(사용자 정보, 결제 정보, 구독 정보...)를 구분하기 어려움
React query 도입 시, client side data는 redux로 관리하고 server side data는 react-query로 분리가 가능했다.
(추가적으로 react-query에서는 loadstatus의 정보까지 제공한다!)
에러 처리
하나의 API가 여러 컴포넌트에서 사용되게 된다면, 각 컴포넌트의 상황에 맞춰서 에러 핸들링을 해야하기 때문에 위와 같은 로직을 가지게 된다.
React query를 사용하면, onError 함수를 이용해서 컴포넌트가 리렌더링이 되지 않더라도 에러핸들링이 필요없어져서 더 간단한 로직이 된다.
React query를 사용하는 이유?
- Redux에서는 api 상태에 따라 화면 구현시 별도의 도구나 상태 필요
- Redux saga는 의존성이 깊은 구조를 만들 수 있음
- Redux는 장황한 보일러 플레이트가 필요
- Redux 에러 핸들링 과정에서 다소 불필요한 작업(리렌더링) 발생
'프로젝트 > 실물(silmul)' 카테고리의 다른 글
OAuth 로그인 구현 (0) | 2023.05.24 |
---|---|
react quill - image size 조절 (0) | 2023.05.15 |
Quill editor 내부의 사진 서버로 보내기 (0) | 2023.05.14 |
login 전역상태관리 (0) | 2023.05.12 |
Redux toolkit (0) | 2023.05.10 |
- Total
- Today
- Yesterday
- 개인 프로젝트
- SEB43기
- 기술면접
- 회고
- 감정일기장
- Python
- seb
- 프론트엔드
- 브루드포스
- BFS
- SEB 43
- 감정 일기장
- SEB 43기
- 프리프로젝트
- 코테
- 코드스테이츠
- dfs
- dictionary
- 스택오버플로우
- React quill
- til
- 인적성
- SEB43
- useContext
- 프로젝트
- 백준
- 그리디 알고리즘
- 프로그래머스
- Redux
- 다이나믹 프로그래밍
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |