React Query 실무 도입
React Query와 전역 상태 관리
전역 상태 관리 라이브러리인 리덕스로 대부분의 프로젝트를 진행을 했었는데, 사용하면서 느낌 문제점은 다음과 같습니다. - 대부분의 전역 상태는 비동기 통신을 위해서 쓰이고 있다. - Store의
hong-jh.tistory.com
위 글에서 작성한 내용을 실제로 사용하려면 개념적으로 아직 무리가 있다고 생각해서 좀 더 실무적인 방법으로 정리한 글이다.
FE에서 상태관리란 무엇인가?
상태 : 언제든지 변경될 수 있는 저장된 데이터 (관리해야 하는 데이터들)
- 애플리케이션이 커짐으로써 관리해야 하는 상태가 많아졌다.
- 상태들은 시간에 따라 변화함.
- React에서는 Props Drillings현상
- 위 문제는 라이브러리로 해결
상태 관리에 API통신 코드가 너무 방대해지는 문제가 발생함.
https://techblog.woowahan.com/6339/
Store에서 비동기 통신 분리하기 (feat. React Query) | 우아한형제들 기술블로그
오늘은 주문에서 사용하는 FE 프로덕트의 구조 개편을 준비하며 FE에서 사용하는 Store에 대해 개인적인 고민 및 팀원들과 검토하고 논의했던 내용을 소개합니다. 이 과정에서 생긴 여러 가지 의
techblog.woowahan.com
서버 상태의 특징
- Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지된다.
- 비동기 API가 필요
- out of date의 가능성이 있음.
=> 일종의 캐시?
거기서 나온 아이디어 다른 관리방법
Client State와 Server State (관리하는 주체가 누구인가?)
React Query는 Server State를 관리하는 Fetching 라이브러리
Fetch, Cache, Update 해준다. 즉, Server State의 out of date에 대한 단점이 어느 정도 보안이 된다.
사용법
QueryClient를 선언하고 QueryClientProvider에 client props에 넘겨주어야 한다.
주요 개념은 다음과 같다.
Queries, Mutations, Query Invalidation
Queries => 데이터를 Fetching하는 용도. CRUD 중 Reading. useQuery(키, 쿼리 함수);
Query Key에 따라서 query caching을 관리한다.
Query Function은 Promise를 반환하는 함수가 들어간다. resolve, reject
useQuery Hook이 반환하는 값은 다양함. (data, error, loading, refetch, remove 등)
※ remove는 query cache를 지운다, refetch는 다시 요청을 보냄.
커스텀 option도 설정해 줄 수 있는데 대표적으로 (onSuccess, onError, onSettled등의 Side Effect)
※ select 함수는 성공 시 가져온 data를 가공해서 전달해준다.
예를 들어서 select가 없다면 data.data.payload등의 작업을 해주어야 하지만, select로 가공을 하면 좀 더 깔끔하게 사용할 수 있다.
Muations => 데이터 생성/수정/삭제하는 용도. CRUD중 Create/Update/Delete를 담당.
const mutation = useMutation(newTodo => {
return axios.post('/todos', newTodo);
})Promise를 반환하는 함수를 Callback으로 전달해준다. key는 선택인데, 넣으면 디버깅이 가능하다.
Mutation은 자동으로 실행되지 않는다. mutate함수를 실행해야 한다. <= useMutation 함수에서 리턴함.
설정값에는 다양한 값들이 있지만 onMutate가 중요하다.
onMutate는 mutate전에 실행되는 함수를 명시하게 된다. (Optimistic Update UI 적용 시 유용)
Optimistic UI란?
True lies of Optimistic UI - 옵티미스틱 UI의 계산된 거짓말
이 글은 Denys Mishunov가 2016년 11월 SMASHING MAGAZINE에 게재한 글입니다. 피엑스디에서 저자의 서면 허락을 받고 번역, 게재하였으며, 저자의 허락없이 복사하여 사용하는 것은 절대 안됩니다. 원문 링
story.pxd.co.kr
Q. 왜 굳이 mutation으로 요청을 보내야 하는가?
A. Server State의 값을 변화시키기 위해서 사용된다. 그냥 ajax 요청으로 보내게 된다면 Server State는 React-Query에 의해 제어되지 않을 것이다.
Query Invalidation => 쿼리를 invalidate한다.
Papago의 꿀팁 : invalidate는 "무효화하다" 라는 뜻이다.
Q. React Query에서 Caching과 Synchronization은 어떤 식으로 동작하는가?
A. HTTP의 Cache Control에 대한 명시를 보면 좋다. 그중 stale-while-revalidate는 개념은 백그라운드에서 stale response를 revalidate 하는 동안 캐시가 가진 stale response를 반환한다는 개념이다.
max-age의 값이 만료되면 다시 서버에서 새로운 데이터를 받아오게 되는데, stale-while-revalidate를 명시해놓으면 선언한 시간만큼
stale(낡은) 데이터를 사용하면서 fetching을 해오겠다는 의미다. (지연 시간을 줄일 수 있음.)
"새 물건 올 때까지 예전 물건 보여준다" <- 사용자의 시간을 끄는 행위.
react-query는 메모리 캐싱을 구현한 구현체다.
캐싱은 효율적인 측면에서는 정말 유용한 기술이지만, 실시간 정보가 유효하게 취급되는 서비스면 stale-while-revalidate의 유효기간을 조금 생각해 볼 필요가 있다.
- Queries는 기본적으로 캐싱된 데이터는 stale 취급한다.
- 각 시점에서 data가 stale 하다면 항상 refetch가 발생한다.
- inAction Query는 5분 뒤에 GC가 처리한다.
- Query가 실패하면 참을 인 3번 한다. (3번 retry를 한다.)
여기서 기본적이라는 말은 Zero Config에 의해의 명시된 설정을 의미한다.
Q. 마치 전역 상태로 관리하는 것처럼 보이는데, React Query는 값들을 어디서 관리하는가?
A. 내부적으로 react-query는 Context API를 사용한다. 그것이 왜 QueryClientProvider가 필요한 이유다.
Q. Fetching 라이브러리를 도입하면서 기존의 전역 상태 관리 라이브러리로 Server State를 관리하던 방식과 비교해서 어떤 점이 좋아졌는가?
A. 각 state는 목적에 맞게 관리를 할 수 있게 되었다.
Client State => 클라이언트 내부적으로 사용되는 상태들만 남아 심플하게 관리 (redux, context api 등)
Server State => React Query로 캐싱을 하면서 간단하고 효율적으로 Server State관리
이런 분들이 사용하기 좋다.
- 전역 상태와 API가 엮여있어서 Store가 엄청 커지게 되는 문제를 직면하신 10대 직장인 홍 모 씨
- API 통신 관련 코드를 간단하고 효율적으로 구현하고 싶은 고등학생 홍 모 씨
- Caching 전략을 FE에 도입해보고 싶은 일반인 홍 모 씨
위 내용들은 https://www.youtube.com/watch?v=MArE6Hy371c 에서 수강을 하면서 정리한 내용이다.
시간 날 때 한 번씩 꼭 들어보면 좋은 강좌인 것 같다.