목표
모든 Path에 대응하여 동적으로 header content를 랜더링 해 줘야 함
이 때 nextjs layout system을 사용하여 랜더링 해 줘야지 최적화를 가져갈 수 있음
1번
MasterLayout 컴포넌트를 만듦
이 컴포넌트는 prop으로 headerContents: Array 를 받아 정해진 순서대로 랜더링을 해줌
하지만 모든 페이지마다 HeaderContent 배열을 선언해야 하는 문제가 있고, 복잡성이 증가함
- 랜더링 되는 컨텐츠들에 대해 파라미터를 각 페이지에서 재선언 해줘야 하는 문제 등..
2번: Parallel routes 적용
path별 slot을 만들어서, 각 layout에서 path별 @header를 만들어 대처가 가능하겠다 해서 도입함
그리고 nested layout 구조에서 현재 path가 아니면 그 layout은 랜더링 하지 않도록 처리하려고 했음
그런데 생기는 문제.
- layout은 보통 server component로 만들기 때문에 server component에서는 url path를 받아 올 수가 없음. 따라서 각 path 구분 불가. 그냥 nested된 채로 랜더링 됨
- 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를 적용하면 모든 경우에 부하가 생김으로 해당 방법을 제외하고 생각하였음
'Front-End' 카테고리의 다른 글
Web 3.0 (0) | 2022.01.05 |
---|---|
[JS] event.stopPropagation을 웬만해서 사용하지 않아야 하는 이유 (0) | 2021.10.08 |
React 의미론적 컴포넌트화, 최적화에 대해서 (0) | 2021.10.08 |
Infinity scroll, Lazy loading 🥱 | Intersection observer (0) | 2021.08.17 |
[JS] Optional chaining, Nullish coalescing operator 🛒 (0) | 2021.08.04 |