#section5
1. 풀 라우트 캐시 1
- Next 서버 측에서 빌드타임에 특정 페이지의 렌더링 결과를 캐싱하는 기능
- 풀 라우트 캐시는 Static Page 에서만 적용 된다
(SSG와 유사)
빌드타임에서 /a 페이지의 렌더링 결과를 캐싱하여 풀 라우트 캐시에 SET
이후 /a 페이지 접속 요청시 풀 라우트 캐시에서 HIT
Dynamic Page 로 설정되는 기준
특정 페이지가 접속 요청을 받을 때마다 매번 변화가 생기거나 데이터가 달라질 경우
-
캐시되지 않는 Data Fetching을 사용할 경우
ex){ cache : 'no-store' } -
동적 함수(쿠키, 헤더, 쿼리스트링)를 사용하는 컴포넌트가 있는 경우
→ 풀라우터 캐시 적용 X
Static Page 로 설정되는 기준
Dynamic Page가 아닌 경우 (Default : Static Page)
→ 풀라우터 캐시 적용 O
revalidate 옵션을 사용해도 풀 라우트 캐시가 적용된다 (ISR과 유사)
정리
2. 풀 라우트 캐시 2
Dynamic Page → Static Page로 변경하기
1. 캐시되지 않는 Data Fetching을 사용할 경우
Data Fetching의 옵션을 {cache : 'force-cache'}로 변경
2. 동적 함수(쿠키, 헤더, 쿼리스트링)를 사용하는 컴포넌트가 있는 경우
리액트 내장 컴포넌트인 <Suspense> 사용하기
동적 함수를 사용하는 페이지를 사전렌더링 하면 오류가 생긴다
(ex. 아직 유저가 입력한 쿼리스트링이 없는 Searchbar 컴포넌트)
그래서 클라이언트 측에서만 실행하도록 변경해야하는데 이때
① <Suspense> 라는 리액트의 내장 컴포넌트로 해당 페이지를 감싸주고
② fallback 을 통해 대체 UI를 설정해준다
<Suspense fallback={<div>Loading ...</div>}>
<Searchbar />
</Suspense>→ <Suspense> 에 감싸진 Searchbar 컴포넌트는
①사전 렌더링에서 제외되고 ②클라이언트 측에서만 렌더링 된다
대신 fallback에 설정되어있는 대체 UI가 먼저 실행되고
Searchbar 컴포넌트의 비동기 작업이 완료되면 렌더링된다
3. 풀 라우트 캐시 3 동적 경로에 적용하기
동적인 값을 사용하는 페이지
searchParams 같은 동적인 값은
사용자의 검색어를 기반으로 백엔드 서버와 실시간으로 통신하여 렌더링 해야한다
그래서 이런 페이지들은 Static Page로 설정이 불가능하고 풀 라우터 캐시를 포기해야한다
대신 페이지가 실시간으로 생성되는 속도를 조금이라도 빠르게 최적화 하기 위해서
데이터 캐시만 따로 적용할 수 있다
⇒ fetch 메서드의 두번째 옵션에 {cache : 'force-cache'} 작성
(한 번 검색이 된 데이터에 대해서 조금이라도 더 빠르게 응답 가능)
동적 경로를 갖는 페이지
⇒ generateStaticParams 라는 약속된 이름의 함수 사용하기
return 값에는 빌드타임에 어떤 url 파라미터가 이 페이지에 존재할 수 있는지 작성한다
(Page Router의 getStaticPaths 와 동일한 역할)
export function generateStaticParams(){
return [{id:'1'}, {id:'2'}, {id:'3'}]
}빌드결과
이렇게 정적인 url 파라미터를 담은 배열을 작성해주면
빌드타임에 Next 서버가 자동으로 정적 파라미터들을 읽고
파라미터에 해당하는 페이지들을 정적으로 만들게 된다
만약 설정한 파라미터 이외의 다른 경로 접속을 막고 싶다면
아래의 코드를 추가해준다
export const dynamicParams = false 
위에서 설정한 /book/1 /book/2 /book/3 페이지 이외의 경로로 접속시
페이지가 렌더링 되지 않는 것을 확인할 수 있다
주의점
- url 파라미터 값을 명시할 때 문자열 데이터로만 사용
generateStaticParams함수 작성시 해당 페이지는 강제로 Static Page로 설정 됨
