개요
Nuxt.js를 사용할 때, vuex를 통해서 상태관리를 진행하여 axios로 호출한 api 데이터들을 관리했다. React에서도 axios를 통한 api를 호출을 사용하려고 page에 데이터를 가져왔는데 페이지가 나올때마다 api를 호출해야하고 통신을 위한 코드로 함수가 너무 길어진다는 단점이 있었는데 이를 어떻게 효율적으로 해결해줄까 생각하다보니 react-query를 알게 되었고 공부해보려고 한다.
본문
도입 배경
1) 프론트엔드에서 상태관리란?
상태관리하면 라이브러리가 주로 먼저 떠오른다.
Redux, MobX, Recoil
- 상태는 주어진 시간에 시스템을 나타내는 것으로 언제든지 변경될 수 있음
즉 문자열, 배열, 객체 등의 형태로 응용 프로그램에 저장된 데이터
-> 개발자 입장에선 관리해야하는 데이터들!
2) 모던 웹프론트엔드 개발
UI/UX의 중요성과 함께 프로덕트 규모가 많이 커지고 FE에서 수행하는 역할이 늘어남
-> 관리하는 상태가 많아짐!
3) 상태관리는?
- 상태를 관리하는 방법에 대한 것 -> 프로덕트가 커짐에 따라 어려움도 커짐
- 상태들은 시간에 따라 변화함
- React에서는 단방향 바인딩이므로 Props Drilling 이슈도 존재
- Redux와 MobX 같은 라이브러리를 활용해 해결하기도 함
4) 서버에서 받아야하는 상태들의 특성
- Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지됨
- Fetching이나 Updating에 비동기 API가 필요함.
- 다른 사람들과 공유되는 것으로 사용자가 모르는 사이에 변경될 수 있음.
- 신경 쓰지 않는다면 잠재적으로 "out of date"가 될 가능성을 지님
-> 사실상 FE에서 이 값들이 저장되어있는 state들은 일종의 캐시
5) Client State vs Server State
Client State
- Client에서 소유하며 온전히 제어가능함
- 초기값 설정이나 조작에 제약사항 없음
- 다름 사람들과 공유되지 않으며 Client 내에서 UI/UX 흐름이나 사용자 인터렉션에 따라 변할 수 있음.
- 항상 Client 내에서 최신 상태로 관리됨
Ownership이 Client에 있다.
Server State
- Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지됨
- Fetching/Updating에 비동기 API가 필요함
- 다른 사람들과 공유되는 것으로 사용자가 모르는 사이에 변경될 수 있음
- 신경쓰지 않는다면 잠재적으로 "out of date"가 될 가능성을 지님
Ownership이 Server에 있다.
React Query란?
Fetch, cache and update data in your React and React Native applications all without touching any "global state".
세 가지 core 컨셉 살펴보기
Queries, Mutations, Query Invalidation
1) Queries는 데이터 Fetching용! -> Reading에 사용
string과 array가 있는데 실무에서는 주로 array를 사용.
return 값으로는
- data: 마지막으로 성공한 resolved된 데이터
- error: 에러가 발생했을 때 반환되는 객체
- isFetching: Request가 in-flight 중일 때 true
- status, isLoading, isSuccess, isLoading 등등 : 모두 현재 query 상태
- refetch: 해당 query refetch하는 함수 제공
- remove: 해당 query cache에서 지우는 함수 제공
- etc.
useQuery Option
- onSuccess, OnError, onSettled: query fetching 성공/실패/완료 시 실행할 Side Effect 정의
- enabled: 자동으로 query를 실행시킬지 말지 여부
- retry: query 동작 실패 시, 자동으로 retry 할지 결정하는 옵션
- select: 성공 시 가져온 data를 가공해서 전달
- keepRreviousData: 새롭게 fetching 시 이전 데이터 유지 여부
- refetchInterval: 주기적으로 refetch 할지 결정하는 옵션
- etc.
2) Mutations은 데이터 updating 시 사용하는 아이
return 값으로는
- mutate: mutation을 실행하는 함수
- mutateAsync: mutate와 비슷 But Promise 반환
- reset: mutation 내부 상태 clean
- 나머지는 useQuery랑 비슷
useMutation Option
- onMutate: 본격적인 Mutation 동작 전에 먼저 동작하는 함수, Optimistic update 적용할 때 유용
3) Query Invalidation
간단한 queryClient를 통해 invalidate 메소드를 호출하면 끝! (=reset)
Caching하고 Synchronization은요?
RFC 5861
- stale-while-revalidate -> 백그라운드에서 stale response를 revalidate 하는 동안 캐시가 가진 stale response를 반환
-> stale data: 최신이 아닌 데이터 (=새 물건이 올 때까지 옛날 물건을 보여준다.)
- 이렇게 동작하면 Latency가 숨겨지겠죠?
- (stale-if-error도 이 명세에 있어요.)
이 컨셉을 메모리 캐시에도 적용해보자!
이러고 나온게 react-query, swr, etc.
- cacheTime: 메모리에 얼마만큼 있을건지 (해당시간 이후 GC에 의해 처리, default 5분)
- staleTime: 얼마의 시간이 흐른 후에 데이터를 stale 취급할 것인지 (default 0)
- refetchOnMount / refectchOnWindowFocus / refetchOnReconnect -> true 이면 Mount / window focus / reconnect 시점에 data가 stale이라고 판단되면 모두 refetch (모두 default true)
zero-config에서도 이런 역할을
- Queries에서 cached data는 언제나 stale 취급
- 각 시점에서 data가 stale이라면 항상 refetch 발생
- inActive Query들은 5분 뒤 GC에 의해 처리
- Query 실패 시 3번까지 retry 발생
