인프런 커뮤니티 질문&답변

깊이있는 좋은 질문 주셔서 감사합니다. Next.js에서 필터가 많은 페이지를 구현할 때 서버 Fetch를 사용하는 것이 권장되는 이유는 서버 컴포넌트(RSC)의 장점인 초기 로드 시 빠른 응답과 낮은 클라이언트 번들 사이즈 때문입니다.

그러나 질문하신 케이스처럼 필터가 많아 사용자가 빈번하게 데이터를 변경해야 할 경우에는 몇 가지 트레이드오프가 존재합니다.

1. 서버 Fetch (RSC + route.push/replace)

서버 컴포넌트와 서버 Fetch를 사용할 경우 다음과 같은 장단점이 존재합니다:

장점

• 초기 페이지 로딩이 매우 빠르고, SEO에 유리합니다.

• 클라이언트 JS 번들 사이즈가 줄어들어 성능이 좋습니다.

• 상태 관리 복잡도가 현저히 낮아집니다. (상태 관리를 서버가 대신합니다)

단점

• 필터 옵션을 변경할 때마다 매번 서버로 요청을 보내야 합니다.

• 상태가 URL로 표현되기 때문에 router.push 또는 router.replace로 페이지가 다시 렌더링됩니다. 이는 페이지가 계속 새로 그려지는 느낌을 줍니다. (UX가 약간 투박할 수 있음)

서버 Fetch 방식이 가장 적합한 경우는 필터가 상대적으로 자주 바뀌지 않고, URL 공유나 SEO가 중요한 상황입니다.
예: 이커머스 상품 페이지, 검색 결과 페이지 등

(또한 revalidatePath 등으로 캐시를 무효화하는 방법도 있습니다 :))

2. 클라이언트 Fetch (React Query 등 클라이언트 상태 관리)

필터 변경이 빈번한 경우 React Query와 같은 클라이언트 상태 관리 라이브러리를 사용하면 다음과 같은 특징이 있습니다.

장점

• 필터 변경 시 UI가 부드럽고 자연스럽습니다. UX가 더 뛰어납니다.

• 클라이언트에서 데이터를 캐싱해두고 빠르게 응답을 제공합니다.

• 페이지 전체가 아닌 필요한 부분만 리렌더링하므로 UX가 비교적 뛰어납니다.

단점

• 초기 JS 번들 사이즈가 늘어나고, 초기 로딩 속도는 서버 Fetch 대비 느려질 수 있습니다.

• 데이터가 클라이언트 상태와 서버 상태로 나뉘게 되므로 관리가 복잡해질 수 있습니다.

• SEO 친화적이지 않을 수 있습니다. (데이터가 클라이언트에서 Fetch되므로)

이 방식이 적합한 경우는 필터 변경이 매우 빈번하고, 실시간으로 부드럽게 변경되는 경험이 중요한 경우입니다.
예: 관리자 페이지, 대시보드, 인터랙티브 데이터 분석 페이지 등

상황을 고려하셔서 적절한 기술을 사용하는게 가장 좋은 해결책인것 같습니다..!

리액트 쿼리 동작은 혹시 searchParams 가 키값에 포함되어 있나요??

만약 그렇다면 아래와 같은 과정을 생각해볼 수 있을것 같아요.
기본적으로 리액트 쿼리는 Query Key가 변경될 때 자동으로 다시 fetch를 수행합니다.

• 사용자가 직접 URL을 replaceState를 이용해 변경해도, Next.js Router나 React Router와 같은 라우터에서 제공하는 훅들이 URL 상태를 계속 관찰하고 있으며, URL 상태가 변경되면 라우터 상태가 변경됩니다.

• 이로 인해 React Query 훅이 사용하는 queryKey(searchParams 등)가 변경되며, React Query가 변경을 감지하여 자동으로 fetch를 다시 요청합니다.

• React Query는 기본적으로 Query Key가 달라지면 새로운 요청을 자동으로 수행합니다.

결론적으로 React Query가 사용하는 상태가 URL 상태와 연결되어 있다면, URL만 변경해도 자동으로 fetch 요청이 발생하는 것으로 추측할 수 있어요 :)

안녕하세요, 인프런 AI 인턴입니다. 변재정님.

필터 옵션이 많은 페이지에서 서버 fetch를 사용할지, 리액트 쿼리를 사용할지는 상황에 따라 다를 수 있습니다. 두 방법에는 각각의 장단점이 있으므로, 이를 잘 이해하고 상황에 맞게 사용하는 것이 중요합니다.

서버 fetch vs 리액트 쿼리

1. 서버 fetch:

   • 서버 fetch는 페이지가 초기 로드될 때 데이터를 받을 수 있어, 초기 렌더링 성능을 높일 수 있습니다. 서버에서 데이터를 이미 준비했기 때문에 필요한 경우 사용자에게 즉시 제공할 수 있습니다.
     
   • 하지만, 필터 변경 시마다 데이터를 서버에서 다시 가져오도록 하려면, 페이지 내비게이션이 필요할 수 있습니다. 이는 사용자가 페이지 이동마다 새로고침되는 느낌을 받을 수 있어 사용자 경험에 영향을 미칠 수 있습니다.
     

2. 리액트 쿼리:

   • 리액트 쿼리는 클라이언트 측에서 데이터를 캐싱하고 관리할 수 있게 해주며, 특정하게 최적화된 방법으로 데이터를 업데이트하고 유지할 수 있습니다.
     
   • 필터 변경 시 데이터를 즉시 반영할 수 있기 때문에 보다 부드러운 사용자 경험을 제공할 수 있습니다.
     
   • 클라이언트에서 URL을 업데이트하고 싶다면 window.history.replaceState() 등을 활용할 수 있으며, 리액트 쿼리는 URL의 변화와 데이터의 최신 상태를 반영할 수 있도록 훅 등을 통해 리렌더링을 트리거할 수 있습니다.
     

URL 변경과 리렌더링

• 리액트 쿼리와 같은 상태 관리 라이브러리는 URL이 바뀌면, 예를 들어 useQuery 훅을 통해 URL의 상태가 변할 때마다 데이터를 다시 가져오는 로직을 포함할 수 있습니다. 이렇게 하면 URL이 바뀌어도 사용자가 새로운 데이터를 즉시 확인할 수 있게 해줍니다.
  
• window.history.replaceState는 브라우저 히스토리에 URL을 추가하지 않기 때문에 URL만 변경되고 페이지가 리로드되지 않습니다. 그러나 리액트 쿼리가 감지할 수 있는 상태 변화를 초래할 수 있습니다.
  

더 많은 정보와 관련 논의는 지식공유자님의 쉽게 리액트 쿼리 처리하기를 참고해 보세요. 해당 게시물에서는 리액트 쿼리를 활용한 예제 코드와 사용자 경험 개선에 대한 힌트도 제공합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.