해결된 질문
작성
·
37
0
페이지 라우터(Page Router) 방식에서는 링크가 뷰에 등장하면 해당 링크의 JS 번들이 자동으로 프리패칭되는 것으로 알고 있습니다.
그런데 앱 라우터의 동작 구조를 설명한 도식(2번 사진)에서는, 사용자가 실제로 페이지 이동을 요청한 이후에 JS 번들과 RSC Payload를 받는 것으로 표현되어 있습니다.
페이지 라이팅과 달라진 점이 RSC payload를 보내주는 것이라 하셨는데 도식에서는 언제 JS 번들을 보내주는지에 차이가 있어보여서 질문드립니다.
초기 접속 시 서버에서 서버컴포넌트를 RSC 페이로드로 해석하고 완성된 HTML을 보내준다.
초기 접속 시 브라우저는 해당 페이지의 클라이언트 컴포넌트 JS Bundle만 받는다.
이후, JS Bundle과 HTML을 하이드레이션 한다.
페이지 전환 시, 새로 이동하는 페이지의 JS Bundle과 함께 서버 컴포넌트에 대한 RSC Payload도 함께 받아 브라우저에서 조합된다.
즉, 페이지 전환 전에 프리패칭이 없다.
이렇게 이해하는게 맞을까요?
답변 2
0
안녕하세요 이정환입니다.
우선 앱 라우터에서도 페이지 라우터와 동일하게 링크가 페이지에 보여질 경우, 해당 링크에 대한 JS Bundle과 RSC Payload를 프리페칭 하게 됩니다. 위 그림은 프리페칭이 동작하지 않는다는 가정 하에 페이지 이동을 위해서 전달되어야 하는 파일을 도식화 한 것 입니다.
이에 대해서는 수강하고 계신 챕터 3.6 의 15분 45초에서 다루고 있으니 참고 부탁드립니다!
두번째 질문에 대해서는 우리 강의의 3.6) 네비게이팅 15분 45초 이후에 프리페칭에 대해 설명드리는 내용을 수강하신 다음 다시 정리해보시면 좋을 것 같습니다. 앱 라우터 역시 프리페칭이 진행됩니다.
0
안녕하세요, 인프런 AI 인턴입니다. kos7662님께서 Next.js의 앱 라우터 방식에 대해 궁금해하시는 부분에 대해 답변 드리겠습니다.
Next.js의 페이지 라우터에서 링크가 뷰 안에 나타나면 JS 번들이 자동으로 프리패칭되는 것은 맞습니다. 이는 사용자 경험을 향상시키기 위한 메커니즘입니다. 하지만 앱 라우터의 경우, 도식에서 보셨듯이 페이지 이동 요청 후 JS 번들과 RSC Payload를 받는 과정이 이전 페이지 라우터의 프리패칭과는 다르게 설명됩니다.
질문 주신 내용에 대해 설명드리면:
초기 접속 시: 서버는 서버 컴포넌트를 RSC Payload로 해석하여 HTML을 렌더링한 후 클라이언트에 전달하게 됩니다. 이때 브라우저는 초기 페이지의 클라이언트 컴포넌트에 대한 JS 번들만 받습니다.
하이드레이션: 받은 HTML은 클라이언트 측에서 상호작용이 가능하도록 JS 번들과 함께 하이드레이션(초기화)됩니다.
페이지 전환 시: 페이지 이동이 이루어질 때 새로운 페이지의 JS 번들과 RSC Payload가 함께 전송되어 이를 기반으로 브라우저에서 페이지가 렌더링됩니다.
프리패칭 여부: 앱 라우터에서 프리패칭이 없는 경우도 있다고 보이지만, 이는 특정 케이스에 의한 것으로 사용 중인 설정이나 버전에 따라 다를 수 있습니다.
이를 더 잘 이해하기 위해 다른 유사 질문과 답변들을 참고해 보시면 도움이 될 것입니다:
이해가 되셨길 바라며, 추가 질문이 있다면 언제든지 말씀해 주세요. 질문자님의 이해를 돕고자 기존 답변을 참고하여 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.