본문 바로가기
Front-End

Nextjs layout 고민

by 박성은3 2025. 7. 3.

목표

모든 Path에 대응하여 동적으로 header content를 랜더링 해 줘야 함
이 때 nextjs layout system을 사용하여 랜더링 해 줘야지 최적화를 가져갈 수 있음

1번

MasterLayout 컴포넌트를 만듦
이 컴포넌트는 prop으로 headerContents: Array 를 받아 정해진 순서대로 랜더링을 해줌
하지만 모든 페이지마다 HeaderContent 배열을 선언해야 하는 문제가 있고, 복잡성이 증가함

  • 랜더링 되는 컨텐츠들에 대해 파라미터를 각 페이지에서 재선언 해줘야 하는 문제 등..

2번: Parallel routes 적용

path별 slot을 만들어서, 각 layout에서 path별 @header를 만들어 대처가 가능하겠다 해서 도입함
그리고 nested layout 구조에서 현재 path가 아니면 그 layout은 랜더링 하지 않도록 처리하려고 했음
그런데 생기는 문제.

  1. layout은 보통 server component로 만들기 때문에 server component에서는 url path를 받아 올 수가 없음. 따라서 각 path 구분 불가. 그냥 nested된 채로 랜더링 됨
  2. dynamic path 와의 좋지 않은 호환성: /app/item/@header, /app/item/[id], /app/item/[id]/@header 이와 같이 구성했을 때, nextjs 내부 작동 방식에서의 문제로 인해 URL /item/2 직접 접근 시 context의 부재로 인해 /app/item/[id]/@header/default.tsx 를 찾음. 따라서 404가 보여짐. default.tsx를 똑같이 복붙 해서 해결 한다 해도 매 번 복붙해야하는 문제가 발생

3번: 각 1-depth layout에서 모든 path를 관리.

RootLayout은 server component로 가져가고, 기존 MasterLayout을 리펙토링 하여 client component로 사용하며 config driven 방식으로 구현 함

사전에 각 요소에 대응하는 set을 선언해 놓고, 개발자가 그 요소 set들을 조합하여 동적으로 구성할 수 있게끔 구성 하였음.
이는 RootLayout에서 한 번의 MasterLayout 랜더링을 시행하기 때문에 nextjs layout 시스템의 최적화도 가져갈 수 있으며 목표를 달성함

기타

middleware를 구성하여 path를 server side로 가져오는 방법도 있었지만, layout 레벨에서 middleware를 적용하면 모든 경우에 부하가 생김으로 해당 방법을 제외하고 생각하였음