[24] React Query에 대해서 설명해주세요.

hyeyoonS commented 2 months ago

📎 질문

React Query에 대해서 설명해주세요.

✏ 답변 키워드

한 줄 요약: 서버 상태를 쉽게 가져오고, 캐싱하고, 동기화 및 업데이트하게 해주는 서버 상태 관리 라이브러리
서버 상태 관리의 단순화
자동 데이터 갱신(데이터 동기화)
캐싱 및 성능 최적화

✏ 서술 답변

[24] ReactQuery에 대해서 설명해주세요.

1. 리액트 쿼리가 뭐지?

비동기 상태를 관리하는 강력한 툴!
서버(api서버)에서 가져온 데이터를 웹 브라우저 앱에서 사용하기 쉽게 도와주는 기술입니다. (서버: 클라이언트(리액트) 에게 데이터베이스에 있는 정보를 전달해주는 역할)

⇒데이터베이스에서 가져온 데이터를 클라이언트에서 보여주기 위해 ajax를 이용하는데요, 이 때 서버에서 가져오는 데이터를 서버의 상태 라고 이야기 합니다.

2. 상태(State)

주어진 시간에 대한 시스템을 표현한 것
문자열, 배열, 객체 등 다양한 형태로 Application에 저장된 데이터

⇒ 프론트: 페이지가 로드되거나 렌더링 된 이후 사용자가 수행한 모든 결과

⇒ 백: 특정 시점에 클라이언트의 요청에 대해 데이터 베이스에서 유저 정보를 가져와 서버의 상태 값을 관리하고, 데이터 베이스에 있는 값을 그대로 전달 or 가공을 해서 메모리에 저장

사용자의 Action ⇒ State 변경 ⇒ View 변화! ⇒ 사용자가 또다른 Action ⇒ State 변경 ….

3. 🧐 왜 리액트쿼리?

기존 상태 관리 라이브러리는 비동기 및 서버 상태 관리엔 적합하지 않다!

👀 만약 리액트쿼리를 사용하지 않는다면?

server state ⇒ client state로 가져오는 데 너무 불편하다 ㅠ ㅠ
컴포넌트의 생명 주기를 파악한 후 적절한 시점에 ajax 호출을 하고 서버에서 데이터를 받아옵니다. 그리고 useState를 사용할 경우 데이터를 불러와 setState호출을 통해 응답 당시의 server state를 component state로 wrapping 해야 합니다.

useEffect(() => {
 customFetch("...").then(setState)
},[]);

이렇게 클라이언트 앱은 server state와 client state에 대한 로직을 나누어 선언해주어야 합니다.

🤔앗 ajax가 뭐였지…? 자바스크립트를 사용해서 비동기적으로 리퀘스트를 보내고 리스폰스를 받는데 기반이 되는 기술들의 집합

👀 앗 이제는 이해할 수 있다! Next.js의 fetch가 왜 불편한지…!!

공식적으로 Next14는 캐시된 값을 버리는(invalidate) 기술을 두 가지 지원합니다.

server cache invalidate
- fetch('path', { cache: 'no-store' } 로 (DB에서) 항상 새로운 데이터를 받아올 수 있습니다.
- fetch('path', { tags: ['data'] }) 로 캐시를 특정할 수 있는 태그를 붙일 수 있습니다.
- revalidatePath, revalidateTag 함수로 fetch + GET method 의 결과값을 invalidate 할 수 있습니다.
client cache invalidate
- router.refresh() : RQ에서 해당 페이지의 모든 쿼리를 invalidate하는 방식과 비슷합니다.클라이언트 렌더링 결과물만 바뀝니다. 캐시를 무효화하는 것이 아니라 페이지를 완전히 새로 로드하는 것이므로, 서버에서 새로운 HTML 페이지를 받아와서 클라이언트에게 다시 그리는 것과 유사합니다.
⇒따라서 서버의 캐시가 남아있다면, 서버에서 새로운 HTML을 받아오더라도 똑같은 화면이 그려질 것입니다.

이 두 가지 방식을 조합해서 써야 하는데, client cache와 server cache를 생각하면서 잘 써야 하기 때문에 휴먼 에러가 다수 발생할 수 있습니다.

예시로,

사용자가 게시글을 수정하면 → 검색 페이지의 검색 결과에서도 해당 게시글 내용이 수정되어야 하는 경우에,

/search 에서 fetch('/getPost', { tags: [search] }) 로 데이터를 받고 (서버)

/post/edit경로에서 revalidateTag('search') 로 서버의 캐시를 invalidate (서버)

하지만 클라이언트 컴포넌트에서 router.refresh() 를 사용해도 수정 사항이 반영되지 않습니다. 서버의 캐시만을 지웠을 뿐이기 때문입니다.….. 서버의 DB에서 에서 최신 데이터를 서버 상태로 다시 가져온 후 router.refresh()로 화면을 새로 그리거나 or state를 사용하여 데이터를 mutate하여야 합니다.

//state를 사용하여 데이터를 mutate하는 예시코드
import React, { useState } from 'react';

function PostComponent() {
  const [postData, setPostData] = useState(null);

  // 게시글 데이터를 업데이트하는 함수
  const updatePostData = (newData) => {
    setPostData(newData);
  };

  return (
    <div>
      <p>{postData}</p>
    </div>
  );
}

그래서 Client Component에서 데이터 Fetching 을 하는 경우 RQ가 더 간편한 것입니다. ~!!

4. 서버 상태에 대한 자세한 설명 정리

클라이언트에서 제어하지 않거나 소유하지 않은 위치에서 관리
fetching 및 updating을 위해 비동기 API 필요
소유권이 공유되므로 사용자가 모르는 사이에 다른 사용자가 변경할 수도 있음
주의하지 않으면 애플리케이션에서 ‘out of date’상태가 될 수 있음

5. 서버 상태에서 생기는 필연적인 문제들!

캐싱
같은 데이터 요청 중복 제거
언제 ‘out of date’가 되는가? 시점 알아내기
out of date 된 데이터를 백그라운드에서 업데이트 ⇒ 최대한 빠르게 업데이트 반영
pagination, lazy loading 등 성능 최적화
서버 상태의 메모리, garbege collection 관리
structural sharing으로 쿼리 결과 memoizing
등등등~

6. 리액트 쿼리와 캐싱

`Stale - while - revalidate`

HTTP 캐싱에도 사용되는 방식!
React Query에 사용되는 캐싱 메커니즘

⇒ 캐싱된 데이터를 사용자에게 제공하면서, 비동기적으로 콘텐츠를 서버에서 revalidate

⇒ 데이터가 out of date가 되었을 경우, 백그라운드에서 refetch를 보내고 새로 업데이트 하는 전략

⇒ 데이터가 없는 것보다 오래된 데이터를 보여주는 게 낫다!

😎여기부턴 추가,, 좀 더 이해하기 쉬운 설명

리액트쿼리가 해결해주는 문제들

간편한 Server State 수급 방식

앱이 간단하다면 useState와 contextAPI만 사용하더라도 대부분의 client state를 다룰 수 있습니다. 하지만 복잡도가 올라가고 성능 향상에 대한 필요성이 생기는 시점이 예상된다면, 이미 잘 만들어진 바퀴인 상태 관리 도구를 선택하는 게 가장 합리적인 선택일 것입니다.

리액트쿼리가 없었을 때에는 서버 상태 값을 받아오기 위해

redux는 thunk, saga, observable과 같은 개념을 차용했고
mobx는 자체적으로 클래스나 함수를 만들어 async await을 통해 데이터를 가져오고, 이를 미리 선언한 observable한 필드에 초기화하여 사용해야 했습니다.

하지만 높은 러닝커브로 js에 익숙하지 않은 개발자들에게는 큰 부담감이 되었습니다.

⇒ react query는 hook 기반의 로직들로 구성되어 해당 훅을 사용하는 컴포넌트에서 상태 값의 변경을 간편하게 파악하여 리렌더링을 유발하게 해줍니다.

캐시

react query를 사용하기 전까지 state라는 용어는 암묵적으로 client의 state를 가리켰습니다. react query가 server state라는 개념을 만든 것이 아니라

client state만 신경 쓰기에도 프론트엔드 개발자가 해야 할 작업들이 많았던 것인데요

만약 10초 뒤에 앱에서 표현하는 데이터가 더 이상 유효하지 않은 낡은 데이터라고 한다면? (ex. 주식이나 코인 거래소처럼 실시간으로 데이터를 변경해야 하는 경우)
1. 클라이언트에서는 polling방식으로 주기적으로 데이터를 받아오거나 (setInterval)
2. 실시간성이 중요한 데이터라면 웹소켓을 통해 서버의 상태 값이 변경되었을 때 서버에게 통지받아야 합니다 ⇒ 웹 소켓을 사용하려면 api서버에도 추가 작업을 해줘야 합니다.
A 페이지의 특정 컴포넌트에서 불러온 데이터를 페이지 전환하여 B페이지에서 재 사용 해야 한다면? (마이펫로그 동물등록폼 제출 ⇒ 홈에 등록된 동물정보 표시)
1. A, B 페이지에서는 state store에 해당 데이터가 이미 존재하는 지 확인하는 로직이 각 필요하고(재호출 방지)
2. 해당 데이터의 유효성에 대한 로직을 추가로 작성해줘야 합니다. (유저가 탭을 이동했다가 다시 돌아왔을 때, 혹은 최초 접속한 지 몇 초 지난 이후에는 데이터가 만료되었다고 판단하여 리렌더링 하는 로직 추가)

⇒

리액트쿼리는 데이터의 캐시 처리를 간편하게 할 수 있는 인터페이스를 제공합니다.

몇 초 이후에는 데이터가 유효하지 않은 것으로 간주하고 데이터를 다시 불러온다.
데이터에 변경 점이 있는 경우에만 리렌더링을 유발한다.
유저가 탭을 이동했다가 다시 돌아왔을 때 데이터를 다시 불러온다.
데이터를 다시 호출할 때 응답이 오기 전까지는 이전 데이터를 계속 보여준다. 필요에 따라서는 로딩바와 같은 대안 UI를 보여주기 위해 loading state를 기본적으로 제공한다.

💘결론!

fetch api를 사용하여 데이터를 불러올 때 에러 처리를 추가적으로 해줘야 한다는 불편함을 axios가 해결해주듯이,

클라이언트와 서버의 상태 값을 일치시켜야 하는 요구 사항에서 부가적으로 생길 수 있는 로직들을 리액트쿼리의 api와 인터페이스로 간단하게 해결할 수 있도록 도와주는 것입니다.

Nahyun-Kang commented 1 month ago

Next.js와 리액트 쿼리의 캐싱 차이

저번에 나왔던 Next.js의 fetch 함수 캐시 과정에 관련된 자료입니다. 리액트 쿼리의 개념 대신 이 부분을 한 번 조사해보았습니다

[https://velog.io/@nab5m/Next-js의-캐싱](https://velog.io/@nab5m/Next-js%EC%9D%98-%EC%BA%90%EC%8B%B1)

Next.js 캐싱 방법

요청 memoization : 서버 사이드에서 함수의 return 값을 캐싱한다. 한 번의 페이지 요청에 대한 처리 과정에서 사용.
- URL과 옵션이 같은 요청인 경우, 여러 번 요청하는 것이 아니라 memoize 한 결과 반환
- GET 메소드를 사용한 요청에만 적용
Data Cache: 요청 memoization이 없을 때 서버 사이드에서 fetch apu를 호출하게 되고 이에 따라 받는 응답을 캐싱
- Next는 서버로 들어오는 요청의 결과 데이터를 Data Cache에 저장한다.
- 기본적으로 fetch 를 사용하는 데이터 요청은 캐싱된다.
- 캐싱 동작 설정하려면 fetch 옵션으로 cache와 next.revalidate 사
Full Route cache: 서버사이드에서 html과 RSC payload를 저장합니다.
- 빌드 타임에 정적으로 렌더린된 route의 경우 RSC payload와 html을 캐싱
- 무효화: Data Cache가 갱신되면 Router Cache도 갱신하게 되고, 서버 배포를 다시 한 경우에도 초기화된다.
Router Cache: 클라이언트 사이드에서 RSC payload를 캐싱하여 네비게이션으로 인한 라우트 이동 시 서버 요청을 줄일 수 있다.
- 클라이언트 사이드 메모리에 개별 route 세그먼트 단위로 RSC payload 캐싱. Next는 방문했던 route 세그먼트를 캐싱하고 뷰포트 내에 있는 Link 컴포넌트의 route를 Prefetch 한다.
- Router Cache는 정적/동적 렌더링에 상관없이 적용.
- 갱신:
  - 새로고침과 같이 사용자가 완전히 페이지를 초기화한 경우 갱신
  - 동적 렌더링된 route의 경우 30초가 유효, 정적 렌더링된 경우 5분간 유

React-Query 캐싱 방법

리액트 쿼리의 캐싱은 주로 클라이언트 측에서 이루어지며, 내장된 캐시 관리 기능을 통해 데이터를 캐시하고 관리합니다. ( chat-gpt 리액트 쿼리 캐싱 관련 자료는 찾지 못했습니다 ㅠ)

정리하자면 Next.js의 fetch는 브라우저 캐시(클라이언트 캐시), 서버 캐시(서버 캐시)를 따로 동기화해주는 로직이 필요한데

ReactQuery는 자체 캐싱 기능을 지원하여 클라이언트에서 관리를 하므로 동기화 작업이 별도로 필요하지 않은 것 같다는 의미로 이해했습니다.

(확실하지 않습니다 ㅠㅠ)

olseul commented 1 month ago

React Query는 서버 상태 관리를 위해 사용되는 강력한 라이브러리로, 비동기 데이터 페칭, 캐싱, 동기화, 서버와의 데이터 교환을 쉽게 할 수 있도록 도와줍니다. 주로 React 애플리케이션에서 사용되며, 서버 데이터와 관련된 여러 작업을 효율적으로 처리

리액트 쿼리를 사용하는 이유

서버 상태 관리의 단순화 자동 상태 관리: React Query는 isLoading, isError, data 등의 상태를 자동으로 관리해줍니다. 따라서, 서버 상태와 관련된 로딩, 에러 상태를 별도로 관리할 필요가 없습니다.

자동 데이터 갱신 데이터 동기화: 사용자가 애플리케이션에 접속한 후 아무런 행동을 하지 않더라도, React Query는 서버 상태를 자동으로 갱신하여 최신 데이터를 유지할 수 있습니다. 이를 통해 사용자에게 항상 최신의 정확한 데이터를 제공할 수 있습니다.

캐싱 및 성능 최적화 캐싱 기능: React Query는 서버로부터 받은 데이터를 캐시에 저장하여 동일한 요청을 반복적으로 보내는 것을 방지합니다. 이를 통해 불필요한 서버 요청을 줄이고, 성능을 최적화할 수 있습니다.

HaydenDevK commented 1 month ago

React Query란

서버 상태를 쉽게 가져오고, 캐싱하고, 동기화 및 업데이트하게 해주는 서버 상태 관리 라이브러리React Query 사용 의의

React Query 사용 의의

query key를 통해 쿼리를 패칭, 캐싱, 동기화할 수 있다.
status와 fetchStatus를 제공하여 간편하게 로딩, 에러 처리를 할 수 있다.
Infinite Query, Optimistic Update 기능 구현이 간편하다.

Jyophie commented 1 month ago

React Query란?

React Query는 서버 상태를 간편하고 효율적으로 관리하기 위해 설계된 라이브러리입니다. 클라이언트 측 상태 관리와는 달리, 서버 상태는 서버에서 데이터를 가져와야 하고, 이 데이터는 주기적으로 변경될 수 있습니다. React Query는 이러한 서버 상태를 관리하는 데 필요한 기능들을 제공하여 데이터를 fetching, caching, synchronizing, updating 등을 쉽게 할 수 있도록 돕습니다.

주요 기능 및 특징

데이터 패칭(Fetching) 및 캐싱(Caching): React Query는 데이터를 가져오고 캐싱하여 동일한 데이터 요청을 최적화합니다. 캐싱된 데이터는 일정 시간이 지나면 자동으로 만료되며, 필요한 경우 다시 패칭됩니다.
자동 리패치(Automatic Refetching): 데이터가 오래되거나 백그라운드에서 업데이트가 필요한 경우, React Query는 자동으로 데이터를 다시 패칭합니다. 이를 통해 항상 최신 데이터를 유지할 수 있습니다.
쿼리 무효화(Query Invalidation): 특정 이벤트(예: 데이터 업데이트, 사용자의 상호작용 등)가 발생할 때 쿼리를 무효화하여 데이터를 다시 가져오도록 할 수 있습니다.
데이터 동기화(Synchronization): 다양한 컴포넌트 간에 데이터 동기화를 자동으로 관리하여 데이터 일관성을 유지합니다.
배치 업데이트(Batch Updates): 여러 데이터 업데이트를 하나의 배치로 처리하여 성능을 최적화합니다.
로딩 및 오류 상태 관리: 데이터 패칭 중 발생할 수 있는 로딩 상태와 오류 상태를 간편하게 관리할 수 있습니다.

hyeyoonS commented 1 month ago