[ 항해99 실전프로젝트 ] 리액트 쿼리 입문하기

 

리액트 쿼리는 서버상태관리라이브러리이다.

리덕스는 클라이언트의 데이터상태를 전역으로 관리하게 해주는 라이브러리이고, 

리액트 쿼리는 클라이어트가 아닌 서버의 상태를 관리하는 라이브러리이다.

 

 

리액트 쿼리를 왜 쓰는데?

 

 

=> 위의 개념과 비슷하다. 기존에 Redux, Mobx, Recoil과 같은 다양하고 훌륭한 상태 관리 라이브러리들이 있긴 하지만, 
클라이언트 쪽의 데이터들을 관리하기에 적합할 순 있어도 서버 쪽의 데이터들을 관리하기에는 적합하지 않은 점들이 있다. 이 점을 해결하기 위해 React-Query가 만들어졌다.

 

 

 

 

리액트 쿼리 다양한 기능들

 

•  React Query는 별도의 설정 없이 즉시 사용 가능하다
•  캐싱을 효율적으로 관리해준다
• 같은 데이터에 대한 여러번의 요청이 있을 시 중복을 제거한다.
• 백그라운드에서 알아서 오래된 데이터를 업데이트해준다.
• 데이터 업데이트 시 최대한 빨리 반영한다.
• 페이징처리, 지연 로딩 데이터와 같은 성능 최적화해준다
•  서버 쪽 데이터를 가비지 컬렉션을 이용하여 자동으로 메모리를 관리해준다.
• 구조적 공유를 통해 쿼리의 결과를 기억해준다.

 

 

 

이렇게만 봐서는 , 그냥 리액트 쿼리가 마냥 굉장한 라이브러리인 것은 알겠으나 어떻게 사용하는 지 정확히 모르겠다.

 

음.. 그래서 정확히 이해하고 싶어서 배달의 민족에서 운영하는 우아한테크세미나에서 리액트쿼리를 다루길래 영상을 보았다.

영상이 두시간짜리라 아직 절반밖에 못보았지만, 이때까지 정리한 내용들을 적어본다.

 

 

 

 

 

---

 

[LIVE] React Query와 상태관리 :: 2월 우아한테크세미나  (절반 정리)

 

 

 

 

 

 

상태관리란?

• 상태를 관리하는 방법에 대한 것 => 프로덕트가 커짐에 따라 어려움도 커짐
• 상태들은 시간에 따라 변화함
• 리액트는 단방향 바인딩이므로 props drilling 이슈도 존재함
• 리덕스나 Mobx와 같은 라이브러리를 활용하여 해결하기도 함.

 

 

 

현업배민개발자가 FE 프로덕트를 보며 가진 고민

 

• 상태관리 영역이 서버값을 저장하는데까지 확장됨. ( api통신 관련 코드조차 Store에서 관리 )
• 반복되는 isFetching, isError 등 API 관련 상태
• 반복되는 비슷한 구조의 API 통신 코드

 

 

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

• 데이터의 소유권이 클라이언트가 아닌, 서버에서 관리되고 유지됨.
• 비동기 API가 필요함
• 다른 사람들과 공유되는 데이터이기 때문에, 사용자가 모르는 사이에 변경될 수 있음. (그렇기때문에, 잠재적으로 "out of date"가 될 가능성 지님)

 

 

 

키포인트는? 오너십이 클라이언트에 있냐 서버에 있냐! 
  클라이언트에서 관리 및 제어를 하는 지, 서버에서 관리 및 제어를 하는 지

 

 

 

 

 

배민 주문 프로덕트에서는 해당 컴포넌트마다 직접 키는 것이 아니라, Query를 선언하는 함수들을 도메인별로 묶어서 관리중. (직접 키면 관리가 어렵다고 함.)