우아한 테크 세미나 React Query

상태란?

주어진 시간에 대해 시스템을 나타내는 것으로 언제든지 변경될 수 있음, 즉 문자열, 배열, 객체등의 형태로 응용 프로그램에 저장된 데이터
=> 개발자 입장에서 관리해야하는 데이터들 !

UI/UX의 중요성과 함께 프로덕트 규모가 많이 커지고 FE에서 수행하는 역할이 늘어남 => 관리하는 상태가 많아짐!

상태 관리란? (Feat. FE)

• 상태를 관리하는 방법에 대한 것 -> 프로덕트가 커짐에 따라 어려움도 커짐

• 상태들은 시간에 따라 변화함

• React에선 단방향 바인딩이므로 Props Drilling 이슈도 존재

• Redux와 MobX 같은 라이브러리를 활용해 해결하기도 함

주문 FE 프로덕트

어플에서 쓰이는 화면은 웹뷰를 통해 관리하는 페이지가 많기 때문에 상태관리가 중요하다. 그 중 상태관리에 대한 고민. . . . Store는 전역 상태가 저장되고 관리되는 공간인데.. 상태관리보단 API 통신코드 ..?
상태관리 영역이 서버값을 저장하는데까지 확장

• API 통신 관련 코드가 모두 Store에 ?

• 또, 반복되는 isFetching, isError 등 API 관련 상태

• 또또, 반복되는 비슷한 구조의 API 통신 코드

서버에서 받아야하는 상태들의 특성

• Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지됨

• Fetching이나 Updating에 비동기 API가 필요함

• 다른 사람들과 공유되는 것으로 사용자가 모르는 사이에 변경될 수 있음

• 신경 쓰지 않는다면 잠재적으로 "out of date"가 될 가능성을 지님

=> FE에서 이 값들이 저장되어있는 state들은 일종의 캐시

Client State vs Server State의 Key Point는 Ownership이 있는곳 . .

이러한 상태관리에 대한 고민에서의 해답은 React Query ! ! !

React Query 세 가지 core 컨셉 살펴보기

• Queries: Data Fetching
  Query Key: React Query는 Query Key에 따라 query catching을 관리합니다.
  Query Function: Promise를 반환하는 함수!

useQuery가 반환하는 함수는 ?

• data: 마지막으로 성공한 resolved된 데이터
• error: 에러가 발생했을 때 반환되는 객체
• isFetching: Request가 in-flight 중일 때 true
• status, isLoading, isSuccess 등등: 모두 현재 query의 상태
• refetch: 해당 query refetch하는 함수 제공
• remove: 해당 query cache에서 지우는 함수 제공

useQuery Option

• onSuccess, onError, onSettled: query fetching 성공 / 실패 완료 시 실행할 Side Effect 정의

• enabled: 자동으로 query를 실행시킬지 말지 여부

• retry: query 동작 실패 시, 자동으로 retry 할지 결정하는 옵션

• select: 성공 시 가져온 data를 가공해서 전달

• keepPreviousData: 새로운 fetching시 이전 데이터 유지 여부

• refetchInterval: 주기적으로 refetch 할지 결정하는 옵션

• Mutation: 데이터 생성/수정/삭제 용

useMutation

• mutate: mutation을 실행하는 함수
• mutateAsync: mutate와 비슷 But Promise 반환
• reset: mutation 내부 상태 clean

useMutation Option

• onMutate: 본격적인 Mutation 동작 전에 먼저 동작하는 함수, Optimistic update 적용할 때 유용

Query Invalidation

• 간단히 queryClient를 통해 invalidate 메소드를 호출하면 끝!

RFC 5861

• state-while-revalidate
  -> 백그라운드에서 stale response를 revalidate 하는 동안 캐시가 가진 stale response를 반환

Cache-Control: max-age=600, stale-while-revalidate=30

• 이렇게 동작하면 Latency가 숨겨지겠죠?

• (stale-if-error도 이 명세에 있어요)

이 컨셉을 메모리 캐시에도 적용해보자 !

이러고 나온것이 react-query, swr, etc

• cacheTime: 메모리에 얼마만큼 있을건지(해당 시간 이후 GC에 의해 처리, default 5분)

• staleTime: 얼마의 시간이 흐른 후에 데이터를 stale 취급할 것인지(default 0)

• refetchOnMount, refetchOnWindowFocus, refetchOnReconnect -> true이면 Mount, window focus, reconnect 시점에 data가 stale이라고 판단되면 모두 refetch(모두 default true)

Query 상태흐름

zero-config에서도 이런 역할을

• Queries에서 cached data는 언제나 stale 취급

• 각 시점에서 data가 stale이라면 항상 refetch 발생

• inactive Query들은 5분 뒤 GC에 의해 처리

• Query 실패 시 3번까지 retry 발생

React Query는 어디에서 값들을 관리할까요?

어떻게 Server State들을 전역상태처럼 관리할까요?

• QueryClient 내부적으로 Context 사용

React Query etc

• useInfiniteQuery
• Prefetching
• TypeScript
• GrahQL
• SSR & Next.js
• devtools
• etc

React Query 이후 프로덕트 변화

• Store는 Client State들만 남아 목적에 맞고 심플하게

• Server State들은 React Query와 함께 간단하고 파워풀

• Component는 조금 길어졌지만 Container 컴포넌트 같기도. . .

장점

• 서버상태 관리 용이하며 직관적인 API 호출
• API 처리에 관한 각종 인터페이스 및 옵션제공
• Client Store가 FE에서 정말로 필요한 전역상태만 남아 Store답게 사용됨
• devtool 제공으로 원활한 디버깅
• Cache 전략 필요할 때 아주 좋음

React Query를 써야 하나요?

• 최근 React Query는 1년 전보다 4배 많은 npm 다운로드 수

추천하는 분

• 수많은 전역상태가 API 통신과 엮여있어 비대해진 Store를 고민하는 분
• API 통신 관련 코드를 보다 간단히 구현하고 싶으신 분
• FE에서 데이터 Caching 전략에 대해 고민하시는분
• (공부가 목적이라면) 모든 FE 개발자!