[React Query] React Query와 상태관리

어제 세미나를 진행한 우아한형제들 주문 프론트팀 배민근 님의 라이브 프론트엔드 세미나를 보면서 기록해 보겠습니다.

우아한형제들 Rel팀에서 전달하는 세미나를 들어보고 있습니다.

저 또한 잠시 써보았지만 정확하게 알면서 상태관리에 대해 더 알아가보자 작성하도록 하겠습니다.

FE 상태관리 대해

State?

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

UIUX 중요성과 함께 프로덕트 규모가 많이 커지고 FE에서 수행하는 역할이 늘어나 관리하는 상태가 많아졌다.

 

상태관리 라이브러리

Redux, MobX, Recoil 등..

 

상태관리는?

상태를 관리하는 방법에 대한 것 => 상태들은 시간에 따라 변화함. React에선 단방향 바인딩이므로 Props Drilling 이슈도 존재하며, Redux, MobX 라이브러리를 활용해 해결하기도 함.

 

상태관리에 관한 고민

API 통신 관련 코드가 모두 Store에 관리하는게 맞는지?

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

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

 

경험했듯, 반복되는 코드와 API까지 스토어에 관리하는게 맞는가 라고 생각을 해봤을 때 맞는 말이다.

절대 그렇지 않아도 되고, 상태만 관리하고 API

 

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

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

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

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

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

 

state들은 일종의 캐시 라는 생각이 들었다고 합니다.

 

Server State / Client State

Client State

- Client에서 소유하며 온전히 제어가능함.

- 초기값 설정이나 조작에 제약사항 없음.

- 다른 사람들과 공유되지 않으며 Client 내에서 UI/UX흐름이나 사용자 인터렉션에 따라 변할 수 있음.

- 항상 Client 내에서 최신 상태로 관리됨.

 

Server State

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

- Fetching/Updating에 비동기 API가 필요함

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

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

 

React Query

React Query는 Server State를

- 데이터 가져오기

- 캐시

- 동기화

- 데이터 업데이트

 

세 가지 core 컨셉 살펴보기

- Queries

- Mutations

- Query invalidation

 

Query는 데이터 Fetching용이다.

Query Function

promise를 반환하는 함수