풀 라우트 캐시 관련 Dynamic Page 조건에 대해 궁금한 점 있습니다.

Question

풀 라우트 캐시 조건에 http 요청에서 쿠키나, 헤더값등을 얻어오는 동적함수를 사용하거나

props에서 searchParams를 꺼내오는 등의 조건들이 동적 페이지로 선정되는 기준이라고 하셨는데요.

components/searchbar.tsx에서 useSearchParams() 훅 사용도 같은 맥락인것 같은데, 이친구는 왜 빌드시에 체크된걸까요?

빌드 과정 중 정적 코드 분석을 통한 경고성 오류일까요?
(with-searchbar)/page.tsx가 static page로 선정되어, 그 내부에 포함되어 있는 컴포넌트이기 때문에 components/searchbar.tsx까지 빌드하려다가 발생한 오류일까요?
useSearchParams() 훅은 dynamic page 선정조건에 포함되지 않은걸까요?

궁금합니다! 만약 수업 내용 중 있었는데, 제가 놓친거라면 죄송합니다~

이정환 Winterlood · Answer

안녕하세요 이정환입니다.

우선 페이지의 유형(다이나믹, 스태틱)을 결정할 때 클라이언트 컴포넌트는 고려되지 않습니다. 오직 서버 컴포넌트에서 동적 함수를 사용했는지, 캐시되지 않는 데이터 페칭을 사용했는지 유무만 판단한다고 이해하시면 됩니다.

추가로 빌드 과정 중 searchbar 컴포넌트의 useSearchParams 까지 호출이 되는 이유는, 정적으로 페이지를 생성하려다 보니 클라이언트 컴포넌트들도 한번은 실행해야 할 필요가 있기 때문입니다.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. dlsrksrhk님께서 풀 라우트 캐시와 관련하여 질문을 주셨군요.

Next.js에서의 useSearchParams() 훅 사용과 관련된 빌드 시 체크 사항에 대해 궁금해하셨습니다. useSearchParams() 훅이 동적 페이지로 판단될 수 있는 이유와 빌드 시 오류가 발생하는 이유를 순서대로 설명 드리겠습니다.

빌드 과정 중 정적 코드 분석을 통한 경고성 오류일 가능성:
- Next.js는 빌드 시점에 정적 코드 분석을 통해 동적 페이지로 판단될 수 있는 코드를 찾아냅니다. useSearchParams()는 클라이언트 측에서 실행되는 클라이언트 훅으로, 이러한 특성을 가진 코드는 동적 페이지로 설정하는 것이 일반적입니다. 따라서, 해당 훅을 사용 시 빌드 타임에 경고를 내는 경우가 있습니다.
(with-searchbar)/page.tsx가 Static Page로 선정된 경우:
- 특정 페이지가 정적 페이지로 선정되면, 내부의 모든 컴포넌트도 정적이라는 가정이 수반됩니다. 그러나 useSearchParams()가 포함된 컴포넌트는 클라이언트 측에서 실행되어야 하는 로직이기 때문에 사전 렌더링 시점에 이 부분이 문제를 일으킬 수 있습니다. 그로 인해 빌드 중 오류로 체크될 수 있습니다.
useSearchParams()의 Dynamic Page 조건 포함 여부:
- useSearchParams()는 URL의 쿼리 스트링을 포함해 동작하므로, 클라이언트 측에서 실행되어야 합니다. 이로 인해 동적 페이지로 분류될 수 있는 조건을 만족하게 됩니다. 그러나 이러한 경우에도 빌드 타임에 경고로 체크될 수 있으니, Suspense와 같이 클라이언트 렌더링에 특화된 방법을 사용할 수 있습니다.

Suspense를 이용하여 해당 부분을 감싼 후 클라이언트에서 처리되도록 하거나, loading.tsx 파일을 생성하여 이를 최종적으로 해결할 수 있습니다. 이는 빌드 오류 없이 클라이언트에서 마무리되게 만드는 방법입니다.

유사한 주제에 대해 다른 학습자가 남긴 유익한 질문과 답변을 참고할 수 있습니다:

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏

추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

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