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

브라우저 뒤로가기할 때 필터의 스테이트를 하나씩 이전 상태로 되돌리실거면 서버 페치로 해서 히스토리 관리하시는 게 낫고, 그게 아니라면 리액트 쿼리로 하시면 될 것 같습니다.

리액트쿼리는 브라우저주소 바뀔 때 이벤트 탐지가 붙어있는게 아닌가 싶습니다.

안녕하세요, 인프런 AI 인턴입니다.

변재정님께서 질문하신 내용은 Next.js와 React Query의 구조 및 데이터 페칭 전략 관련된 것입니다. 필터 옵션이 많은 페이지에서 서버 fetch와 클라이언트 fetch 중 어떤 것을 사용하는 것이 좋을지 고민이시네요. 아래에 관련된 설명을 드리겠습니다.

1. 서버 Fetch vs 클라이언트 Fetch:

   • 서버 Fetch는 주로 페이지 로드 시, SEO가 필요하거나 초기 데이터 로딩이 중요한 경우에 유리합니다.
     
   • 클라이언트 Fetch는 필터링이나 인터랙티브한 데이터 변경에 적합합니다. 이 경우 React Query 같은 툴을 사용해 UI 상에서 빠르고 쉽게 데이터 상태를 관리할 수 있습니다.
     

필터 옵션을 자주 변경해야 하는 경우, 클라이언트에서 데이터를 가져오고, 필요한 경우에만 데이터를 갱신하는 것이 더 효율적일 수 있습니다. 서버 request를 줄여 클라이언트 측에서 작업을 처리함으로써 사용자 경험을 향상시킬 수 있습니다.

2. window.history.replaceState 동작 원리:
   

window.history.replaceState는 브라우저의 URL을 변경하되, 페이지를 새로고침하거나 컴포넌트를 다시 렌더링하지는 않습니다. 이는 브라우저의 네비게이션 히스토리에만 URL 상태를 변경할 뿐, React 컴포넌트나 애플리케이션 상태에는 영향을 주지 않습니다.

그러나, React Query의 경우 커스텀 훅이나 특정 상태가 URL에 반응하도록 설정되어 있을 수 있습니다. 이때 URL 변경 이벤트에 따라 트리거가 발생하면서 데이터 페칭이 일어날 수 있습니다. 이는 React Query의 watchQuery나 학습된 URL 파라미터 핸들링 로직에 의해 유발되는 경우가 많습니다.

이 주제와 관련된 추가 학습을 위해, 비슷한 질문과 답변이 있는 글을 참고하시면 도움이 될 수 있습니다:
- “React Query와 URL 변경”: 해당 글에서는 React Query가 URL 변경 시 어떻게 동작하는지, 각 엔드포인트에서 상태 변화를 관리하는 방법에 대해 설명하고 있습니다.
- “Next.js에서 데이터 페칭 전략”: 이 문서는 Next.js에서 서버 및 클라이언트 데이터 페칭 시 고려해야 할 사항과 전략을 다룹니다.

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