page router 단점
- 페이지별 레이아웃 설정이 번거롭다
- 데이터 페칭이 페이지 컴포넌트에 집중된다
- 불필요한 컴포넌트들도 JS번들에 포함된다
페이지별 레이아웃 설정이 번거롭다
매번 레이아웃이 필요한 페이지에 Page.getLayout 이라는 것을 만들어 호출해야하기 때문이다. app router 방식에서는 layout.tsx 파일 하나만으로 손쉽게 페이지별 레이아웃 설정이 가능하다.
데이터 페칭이 페이지 컴포넌트에 집중된다
SSR, SSG, ISR 등의 기법을 사용하여 모든 데이터들을 백엔드 서버에 호출해서 데이터를 받아오고 페이지 컴포넌트에 props로 데이터 전달하는 방식인데 이는 page컴포넌트에게 props를 전달하는 방식이기 때문에 이 페이지 컴포넌트의 a, b, c 등 여러 하위 컴포넌트에서 받은걸 계속 자식 컴포넌트로 전달해야하는 props drilling이 일어나게 된다.
전역상태관리로 커버할 수 있지만 애초에 이런 구조가 번거롭다는 것이다.
불필요한 컴포넌트들도 JS번들에 포함된다
우리가 작성한 모든 컴포넌트를 page기반으로 전부 보내주는데, 불필요한 컴포넌트란 상호작용이 없는 컴포넌트를 의미한다.
상호작용이 없는건 단순히 UI만 렌더링하는 JS코드가 동작하지 않는 컴포넌트 같은 것들을 의미한다.
JS 번들파일에 상호작용이 필요없는 코드까지(즉, 하이드레이션을 할 필요가 없는 부분까지)받게 된다는 문제가 있다. 서버에서 한번만 렌더링되면 그만인 컴포넌트인 것이다.
이러한 단점들을 개선하기 위해 Next.js에서 app router 방식으로 바꾸고, 서버 컴포넌트라는 개념을 도입하여 클라이언트, 서버단에서 두번 일어나는 렌더링을 서버측에서만 렌더링하여 중복되는 현상을 없애 성능을 개선한 것이다.
Next.js는 총 2번의 렌더링이 일어나는데, 처음은 서버쪽에서 JS실행하여 렌더링이 일어나고(HTML), 두번째는 브라우저에서 하이드레이션을 실행할때이다. (하이드레이션이란 상호작용이 불가능한 페이지를 가능하게 하도록 하는 과정이므로 여기서 렌더링이 다시 일어나게 된다)
