리액트 쿼리 하이드레이션에서 fetchQuery를 사용하지 않는 이유

 

 

프로젝트에서 React Query의 Hydration과 prefetchQuery를 활용하여 SSR(Server-Side Rendering)을 구현했다.

https://new-development.tistory.com/13

React Query와 SSR: 서버 사이드 데이터 관리와 Hydration 활용

 

 

이 과정에서 팀원들과 다양한 의견을 나눴는데, 그중 fetchQuery에 대한 논의가 있었다.

의견 1.
"부모 컴포넌트에서 SSR을 통해 데이터를 패칭한 뒤, 이를 자식 컴포넌트에 props로 전달하면 자식 컴포넌트가 서버 컴포넌트로 동작할 수 있지 않을까요? SEO 관점에서 더 유리할 것 같습니다."

의견 2.
"fetchQuery로 데이터를 가져와 props로 넘겨주는 방식은 어떨까요? 속도면에서 장점이 있을 것 같습니다."

 

이 논의에서 나는 리액트쿼리 공식 문서가 prefetchQuery와 useQuery를 함께 사용하는 이유에 의문이 들어 관련 내용을 조사하고 정리했다.

 

 

---

 

 

 

fetchQuery의 문제점

예제 코드

// fetchQuery 사용 예시
const ParentComponent = async () => {
  const data = await fetchQuery(queryClient, ['posts'], fetchPosts);
  return <ChildComponent posts={data} />;
};

 

문제 1: 캐시 지속성 부족
fetchQuery는 데이터를 가져와 즉시 사용하는 일회성 작업에 적합하다. 하지만 React Query의 캐시와 완벽히 통합되지 않아 다음과 같은 문제가 발생할 수 있다.

• 데이터가 캐시되더라도 다른 컴포넌트에서 이를 활용하지 못함.
• 새로고침, 페이지 이동 시 캐시된 데이터를 잃어버림.

 

문제 2: 리패칭 문제
fetchQuery를 통해 데이터를 가져온 후, 자식 컴포넌트에서 useQuery를 사용하면 동일한 쿼리 키에도 불구하고 중복 요청이 발생할 수 있다.

const ChildComponent = ({ posts }) => {
  // 불필요한 네트워크 요청 발생 가능
  const { data } = useQuery(['posts'], fetchPosts);
  return <div>{/* ... */}</div>;
};

 

문제 3: React Query의 고급 기능 활용 제한
React Query의 고급 기능들을 사용할 수 없다.

• 데이터 신선도 관리
• 자동 백그라운드 리패칭
• 에러 처리 및 재시도
• 낙관적 업데이트 Optimistic UI

 

---

prefetchQuery와 useQuery의 조합

prefetchQuery는 SSR에서 데이터를 미리 가져와 React Query 캐시에 저장하고, 클라이언트에서 이를 활용해 Hydration을 수행한다. 이 방식은 fetchQuery의 문제를 해결하며, 다음과 같은 이점을 제공한다.

• 데이터 신선도 관리: staleTime과 cacheTime 설정 가능
• 캐시 활용: 여러 컴포넌트에서 동일한 데이터를 공유
• 성능 최적화: 불필요한 네트워크 요청 방지
• 유지보수 용이성: React Query의 상태 관리 기능을 적극 활용

 

---

실제 프로젝트 적용

1. 메인 페이지

• 실시간성이 중요한 인기 여행/리뷰 컴포넌트에서 prefetchQuery와 useQuery 조합을 사용해 데이터를 관리
• 이유: 데이터 신선도 관리가 중요하며, React Query의 자동 리패칭 기능을 활용할 수 있기 때문

2. 상세 페이지

• 여행 상세 페이지처럼 정적 데이터 위주의 화면에서는 fetchQuery를 사용해도 무방하지만, 동적 요소(예: 북마크, 동행 신청 버튼)에서는 데이터 불일치 문제가 발생할 가능성이 있어 마찬가지로 prefetchQuery 사용

 

---

fetchQuery vs prefetchQuery: 정리

선택기준	fetchQuery	prefetchQuery
데이터 성격	정적 데이터	동적 데이터, 신선도 관리 필요
SEO	필요	필요
캐시 활용	제한적	효과적
React Query 기능 활용	불가능	가능

 

 

 

---

prefetchQuery와 SSR/CSR에 대한 의문점

prefetchQuery를 사용하면 자식 컴포넌트가 useQuery를 사용해야 하므로, 자식 컴포넌트가 클라이언트 컴포넌트가 되어 SSR이 제대로 동작하지 않는 것이 아닌가?

 

SSR이 동작하는 이유

1. 서버 역할

• 서버는 클라이언트가 필요로 하는 데이터를 미리 가져와 React Query의 캐시에 저장한다.
• 저장된 캐시는 dehydrate를 통해 JSON 형태로 직렬화된다. 이 직렬화된 데이터는 HTML에 삽입되어 클라이언트로 전달된다.

2. 서버에서 완전한 HTML 제공

• 서버에서 데이터를 미리 패칭했기 때문에, 브라우저는 이 데이터를 포함한 완전한 HTML을 받아 검색엔진이 이를 바로 읽을 수 있게 된다.

3. 초기 렌더링

• 자식 컴포넌트가 useQuery를 사용하더라도, 클라이언트는 이미 Hydration을 통해 데이터를 보유하고 있다. 즉, 클라이언트 컴포넌트는 Hydration된 데이터를 기반으로 즉시 렌더링하므로 추가 네트워크 요청이 발생하지 않는다.

 

 

---

 

정리하다보니 무조건 prefetchQuery를 사용해야 하는 것 처럼 말했지만, 프로젝트의 적합성에 따라 고려해야 할 점이 많은 것 같다.

 

 

 

참고자료

fetchQuery vs prefetchQuery

fetchQuery vs prefetchQuery

 

고급 서버 렌더링

고급 서버 렌더링