04
27

0부터 1까지만 알아보자

1. 개요

react query를 왜 사용하는가? 에 대한 질문은 너무 쉽게 할 수 있다. 왜냐고? 캐싱, 최적화, 언제 어디서든 서버에서 최신의 상태를 가져다가 전역으로 사용할 수 있는 매우 편한 라이브러리가 아닐수 없다! 하지만 세상에 완벽한게 어디있나, 분명 그에도 단점은 존제 할 것이다. 그래서 단점을 찾기 전에 가장 근본적인 질문부터 하나하나 알아 보려고 한다.

2. Query

- 많은 프론트 개발자들은 query와 친하지 않다.(사실 뭔지도 잘 모르겠다. 하지만 직접 쿼리를 써보라고 하면 또 쓴다...!? 어째서..)

- query : 질의

- DB와 통신에 필요한 요청을 질의하는 것을 말한다.

- 이를 위해 만들어지는 질문을 SQL이라고 부른다.

3. react-qurey

- 서버 상태관리를 위한 라이브러리

- fetching, caching, synchronizing, updating을 간단하게 hook으로 할 수 있다.

- 기존의 미들웨어는 복잡한 로직으로 만드는 과정이 쉽지않고, 이를 위해 보일러 플레이트를 만들어 여러 프로젝트에 적용한다고 해도, 코드의 양도 많아진다. 이를 react query는 대체할 수 있다.
(하지만 여기서 단점, 이렇게 내부 로직을 잘 알고 쓴다면 상관없지만, 다양한 hook들이 어떠한 방식을 통해 데이터를 다루고 있으며 데이터의 흐름을 직접 제어할 수 없다는 점에서 단점이 있다!)

- QueryClientProvider가 React Context API를 사용해 가장 최상단에 존제하기 때문에, 전역으로 사용할 수 있는 서버의 상태가 된다.

4. react-qurey의 기본 동작 순서

  1. 상태 확인
    • 데이터의 상태를 확인한다.
    • 데이터 상태의 종류
      • fresh : 최신화 된 데이터. 혹은, 아직 staleTime이 지나지 않아서 개발자가 보장하는 최신화된 데이터
            -> 이미 최신화된 데이터라면, 중복으로 네트워크 요청을 막음
      • fetching : 서버와 데이터를 통신하는 중
      • stale : 최신화 되지 않은 옛날 데이터 -> react qurey는 이 경우 다시 fetching -> fresh한 데이터로 상태를 바꾸려 한다.
      • delete : 삭제된 데이터. 혹은, cacheTime이 지나 케시에도 없는 데이터
  2. 상태에 따라 서버와 통신

5.간단한 원리

- 서버와 통신하여 데이터가 최신인지를 확인한다.

- 이때, 최초의 통신이 발생한다. 그래서 데이터가 최신인지를 확인하게 된다. 그리고 이는 state로 관리된다. (useQurey)

- 최신이라면, 캐싱하고 알맞는 queryKey에 바인딩 된다.

- 만일 데이터가 stale하여 다시 서버와 통신이 일어나 데이터가 최신화 되면, state도 바뀐 것이므로 리렌더된다.

- 더 자세한 내용은 아래 글 참고

 

React Query의 구조와 useQuery 실행 흐름 살펴보기 | 카카오엔터테인먼트 FE 기술블로그

함성준(kevin) 개발에는 인생(喜怒哀樂)이 담겨있습니다. 커피 좋아합니다.

fe-developers.kakaoent.com

6. state와의 접점

- react query는 데이터 패칭 라이브러리가 아니다.

 

Thinking in React Query

In this talk, we will learn how a different mindset can help us understand React Query and work with it efficiently.

tkdodo.eu

 

[번역] React Query 적으로 사고하기

React Query Maintainer인 Tkdodo가 알려주는 리액트 쿼리적으로 사고할 수 있는 3가지 요소들을 다루어봅니다.

velog.io

- 비동기 상태 관리자 (Async State Manager) 라고 한다.

- 클라이언트 단에서는 네트워크를 통신해서 불러온 데이터도 '상태'로 관리하고 UI에 필요한 데이터도 '상태'로 관리하게 된다. 필요에 따라 스코프를 넓혀 '전역 상태'로도 관리하게 된다.

- 프로젝트의 사이즈에 따라 전역상태가 관리가 힘들정도로 많아 진다면 혹은, 필요없는 상태들까지 전역으로 관리하거나 하는 행동은 코드 가독성과 유지보수에 치명적이다. (진짜 고통스럽다. 기능 추가 혹은 수정에 시간을 오래 쓰기보다 상태들을 따라가 찾는데 오랜 시간을 쓰게 된다.)

- 그래서 일단, 서버 상태와 클라이언트 상태를 분리시키는데 의의가 있다.

- 그리고 서버 상태는 효율적으로 관리될 필요가 더욱 크다. 필요할때 데이터를 불러 상태를 변경해 최신화 하고, 이미 최신의 데이터를 유지하고 있다면 상태를 업데이트 할 필요가 없어진다.

- 이때, 데이터의 최신화 여부가 상태의 업데이트를 함께 다뤄준다는 점이  react query의 최고 장점 되시겠다.

COMMENT