https://velog.io/@mskwon/next-js-static-generation-fallback
https://steadily-worked.tistory.com/604
사전렌더링 SSR
공식문서에서는 데이터가 있든 없든, 가능하다면 Static Generation을 사용할 것을 추천한다. 왜냐면 build time에 한 번 만들어지고나서 CDN에 의해 served 되는데, 이 경우는 매 요청시마다 페이지를 렌더링하는 SSR보다 더 빠르기 때문.. 예를 들면
Marketing pages (판매 페이지)
Blog posts (블로그 글)
E-commerce product listings (온라인 커머스 및 상품 나열)
스스로에게 물어봤을 때, 유저의 요청 이전에 이 페이지를 띄워야되는지? 가 맞다면 Static Generation을 쓰면 되고, 그게 아니라면 SSR을 쓰면 된다.
예를 들면, 지속적으로 업데이트되는 페이지의 경우 유저의 요청이 있기 전에 사전 렌더링을 할 수 없으므로 이 경우에 Static Generation은 좋은 아이디어가 아니다. 이 경우 두 가지 방법 중 하나를 사용해야 한다.
페이지의 일부 부분에 대해 사전 렌더링을 스킵하고 클라이언트 사이드의 JavaScript 또는 TypeScript를 사용할 수 있다.2) SSR을 사용하기
-> 2. Server Side Rendering(바로아래)에서
1) Static Generation과 Clien Side Rendering(CSR)을 사용하기
2. Server Side Rendering(SSR)
서버 사이드 렌더링을 사용할 경우, 각 요청시 마다 페이지를 사전 렌더링한다. 페이지가 CDN에 의해 캐싱될 수 없으므로 Static Generation에 비해서는 더 느릴 것이다.
그렇지만, 사전에 렌더링된 페이지들은 항상 최신 상태를 유지한다.
For example, suppose that your page needs to pre-render frequently updated data (fetched from an external API). You can writegetServerSidePropswhich fetches this data and passes it toPagelike below:
만약 페이지가 (외부 API로부터 fetch해 오는) 업데이트되는 데이터를 항상 사전 렌더링해야 할 경우, 이 데이터를 받아와서 Page로 넘기는 getServerSideProps를 사용해야한다.
getStaticPaths 반환 객체
이 때, 어떤 path들에 대해서 정적 페이지 생성을 할지 정하는 getStaticPaths 함수는 반환 객체로 paths 키와 fallback 키를 반드시 포함시켜야한다.
pages/users/[id].js에서 getStaticPaths 함수가 아래와 같은 객체를 반환하면,
// getStaticPaths
return {
paths: [
{ params: { id: '1' } },
{ params: { id: '2' } }
],
fallback: ...
}
Next JS는 users/1, users/2 페이지를 빌드타임에 생성하게 된다.
paths
어떤 path의 페이지들을 빌드 타임에 생성할지 정하는 배열이다.
paths 배열에서 각각의 params 값은 페이지 이름에 있는 파라미터와 일치해야한다.
여기서 주의할 점들은 다음과 같다.
만약 파일명이 pages/users/[userId].js 였다면, params 객체도 userId 키값을 가지고 있어야한다.
파일명이 pages/[...slug]와 같이 catch-all 라우트를 이용중인 경우, params 객체는 slug 배열을 가지고 있어야한다.
파일명이 pages/[[..slug]]와 같이 optional catch-all 라우트를 이용중인 경우, null / [] / undefined / false 값을 넣어주면 루트 라우트를 렌더링하게 된다.
fallback
빌드 타임에 생성해놓지 않은 path로 요청이 들어온 경우 어떻게 할지 정하는 boolean 또는 'blocking' 값이다.
false인 경우
getStaticPaths가 반환하지 않은 모든 path에 대해서 404 페이지를 반환한다.
아래와 같은 경우에 사용할 수 있다
적은 숫자의 path만 프리렌더링 해야하는 경우
새로운 페이지가 추가 될 일이 많지 않은 경우
→ 새로운 페이지가 자주 추가 된다면, 추가될때마다 다시 빌드해줘야한다
true인 경우
getStaticProps의 동작이 바뀌게 된다.
getStaticPaths가 반환한 path들은 빌드 타임에 HTML로 렌더링된다
이외의 path들에 대한 요청이 들어온 경우, 404 페이지를 반환하지 않고, 페이지의 "fallback" 버전을 먼저 보여준다
백그라운드에서 Next js가 요청된 path에 대해서 getStaticProps 함수를 이용하여 HTML 파일과 JSON 파일을 만들어낸다
백그라운드 작업이 끝나면, 요청된 path에 해당하는 JSON 파일을 받아서 새롭게 페이지를 렌더링한다. 사용자 입장에서는 [ fallback → 풀 페이지 ]와 같은 순서로 화면이 변하게된다.
새롭게 생성된 페이지를 기존의 빌드시 프리렌더링 된 페이지 리스트에 추가한다. 같은 path로 온 이후 요청들에 대해서는 이때 생성한 페이지를 반환하게된다.
"fallback" 상태일 때 보여줄 화면은 next/router의 router.isFallback 값 체크를 통해서 조건 분기하면 된다. 이때 페이지 컴포넌트는 props로 빈값을 받게된다.
// pages/posts/[id].js
import { useRouter } from 'next/router'
function Post({ post }) {
const router = useRouter()
// If the page is not yet generated, this will be displayed
// initially until getStaticProps() finishes running
if (router.isFallback) {
return
}
// Render post...
}
아래와 같은 경우에 사용할 수 있다
데이터에 의존하는 정적 페이지를 많이 가지고 있으나, 빌드 시에 모든 페이지를 생성하는건 너무나 큰 작업일 때
몇몇 페이지들만 정적으로 생성하게 하고, fallback 옵션을 true로 설정해주면 이후 요청이 오는 것에 따라서 정적 페이지들을 추가하게 된다
→ 빌드 시간도 단축하고, 대부분 사용자들의 응답 속도도 단축할 수 있다
'blocking'일 경우
true일 경우와 비슷하게 동작하지만, 최초 만들어놓지않은 path에 대한 요청이 들어온 경우 fallback 상태를 보여주지 않고 SSR처럼 동작한다. 이후 true 옵션과 같이 기존의 정적 페이지 리스트에 새로 생성한 페이지를 추가한다.
