Layout Nesting

layout 중첩 균형

layout을 중첩하면 UI는 재사용되지만 데이터와 provider 범위도 함께 넓어진다. 보존할 것과 새로 계산할 것을 분리해야 한다.

01

반복 UI 탐색

여러 page에 복사된 header나 sidebar는 공통 layout으로 올리는 후보다.

02

데이터 신선도 비교

layout 데이터가 자식 page보다 덜 자주 바뀌는지 확인하지 않으면 낡은 정보가 오래 남을 수 있다.

03

provider를 필요한 곳까지 내린다

전역 상태가 모든 route에 필요하지 않다면 가장 가까운 공통 layout에 둔다.

static shell
안정적인 공통 UI 문서 목차, 대시보드 frame처럼 자주 바뀌지 않는 영역에 적합하다.
layout 유지 이점을 얻는다.
dynamic data
하위 page 우선 필터나 상세 데이터처럼 leaf마다 달라지는 값은 page에 두는 편이 단순하다.
상위 fetch 남용을 피한다.
provider depth
리렌더 범위 provider가 높을수록 영향 범위가 커진다.
필요한 소비자까지만 감싼다.
오류 범위
복구 범위 error 파일 위치가 어느 UI까지 대체할지 결정한다.
관련 없는 영역을 살려 둔다.

반복 제거 · 데이터 위치 · 상태 범위 점검

반복 제거 page마다 같은 shell을 복사하지 않는가.
데이터 위치 상위 layout fetch가 leaf별 캐시 정책과 충돌하지 않는가.
상태 범위 provider가 불필요하게 앱 전체를 client component로 만들지 않는가.

중첩 판단

// stable across children -> layout
// varies by route/search params -> page
// only interactive island -> client child