7.2 API 상태 관리하기
실제 API를 요청하는 코드는 컴포넌트 내에서 비동기 함수를 직접 호출하지 않음.
비동기 API를 호출하기 위해서는 API의 성공. 실패에 따른 상태가 관리 되어야 함.
-> 상태 관리 라이브러리의 액션이나 훅과 같이 재정의된 형태를 사용해야 함.
.
.
.
1. 상태 관리 라이브러리에서 호출하기
상태 관리 라이브러리의 비동기 함수들은 서비스 코드를 사용 -> 비동기 상태를 변화 시킬 수 있는 함수를 제공.
-> 컴포넌트는 이러한 한수를 사용하여 상태를 구독
-> 상태가 변경될 때 컴포넌트를 다시 렌더링하는 방식으로 동작.
-
Redux는 비동기 상태가 아닌 전역 상태를 위해 만들어진 라이브러리
-> 미들웨어라고 불리는 여러 도구를 도입하여 비동기 상태를 관리.
( 간편하게 비동기 상태를 관리하기 어려운 상황도 발생 )
-
반면! : MobX 라이브러리
-> 비동기 콜백함수를 분리하여 액션으로 만들거나 runinAction과 같은 메서드를 사용하여 상태 변경을 처리
-> async / await 나 flow 같은 비동기 상태 관리를 위한 기능도 있어 더욱 간편하게 사용 가능. -
모든 상태 관리 라이브러리는 비동기 처리 함수를 호출하기 위해 액션이 추가될 때마다 관련된 스토어나 상태가 계속 늘어남.
-> 이때 생기는 문제 : 전역 상태 관리자가 모든 비동기 상태에 접근하고 변경할 수 있음. 만약 2개 이상의 컴포넌트가 구독하고 있는 비동기 상태가 있다면 쓸데없는 비동기 통신이 발생하거나 의도치 않은 상태 변경이 발생 가능.
2. 훅으로 호출하기
react-qeury나 useSwr 같은 훅 사용 -> 상태 변경 라이브러리를 사용한 방식보다 훨씬 간단.
-
캐시 cache 사용 -> 비동기 함수 호출, 상태 관리 라이브러리에서 발생했던 의도치 않은 상태 변경을 방지하는 데 도움이 됨.
-
Redux, MobX -> react-query 변경하는 시도가 많이 이루어짐.
- why? 상태 관리 라이브러리에서는 비동기로 상태를 변경하는 코드가 점점 추가되면 전역 상태 관리 스토어가 비대해지기 때문.- 단순히 상태를 변경하는 액션이 증가하는 것뿐만 아니라 전역 상태 자체도 복잡해짐.
-
에러 발생, 로딩 중 등과 같은 상태 : 전역으로 관리할 필요가 거의 없다.
- 고민 : 다른 컴포넌트가 에러인지 성공인지 등을 구독하는 경우 컴포넌트의 결합도와 복잡도가 높아져 유지보수가 어려워짐- 해결 : 비동기 통신을 react-query를 사용해서 처리.
도서참조 : 우아한 타입스크립트 with 리액트
