Next.js getStaticPaths
토이프로젝트에서 동적 라우팅을 적용하며 Next.js의 기초인
getStaticPath와 getStaticProps에 대해 복습하며 정리를 해보았다.
getStaticPath와 getStaticProps
getStaticPaths는 페이지의 경로를 정적으로 생성한다.
Yarn build로 next project를 빌드할 때 getStaticProps 내부의
API로 받은 또는 json으로 받은 데이터를 확인한 후
필요한 모든 경로에 대해 페이지를 프리 렌더링 해둘 수 있도록 해주는 역할을 한다.
또한 getStaticProps도 빌드 타임에 동작하므로 모든 경로에 대한 페이지가
미리 만들어져있게 된다.
하지만 빌드가 끝난 뒤 DB에 새로운 교회가 추가될 수 있는데,
그럴 때마다 next 전체를 빌드해서 새로운 경로를 매번 만들어 주는 건 무리다.
이럴 땐 getStaticPaths에서 return에 fallback 속성을 이용해주면 된다.
fallback 속성이란
fallback은 boolean 이나 ‘blocking’이라는 문자 타입으로 되어있다.
fallback이 false일 경우, 확인되지 않는 경로에 대해서 바로 404 page로 이동시키지만
Fallback이 true일 경우, 확인되지 않는 경로에 대해서 바로 404 page로 이동시키는 것이 아닌
getStaticProps를 호출한다.
빌드타임이 아니라 새로운 경로에 접근을 했을 때도 getStaticProps를 호출해
getStaticProps 내부에 있는 내용을 실행한다.
만약 getStaticProps 내부에 데이터가 없을 때 404로 라우팅 되도록
설정한 코드가 존재한다면 404 page로 이동한다.
그러면서 getStaticProps가 실행이 되는 동안에는 router의 isFallback이 실행되어
구성을 해놓은 fallback UI가 존재한다면 해당 UI를 보여주게 된다.
그렇다면 fallback은 언제 사용하는 것일까?
토이 프로젝트를 진행할 때 처럼 적은 데이터를 컨트롤 하는 것이 아닌
최소 몇만 단위의 데이터를 컨트롤 할 때 사용하는 것이 좋다고 생각된다.
매번 수만, 수십만 개의 데이터를 빌드 타임에 프리 렌더링 하는 것은 서버에 부담이 된다.
만약 데이터가 너무 많다고 여겨진다면 최소한의 경로만 생성해놓고
fallback: true를 주어서 유저가 접근할 때 경로를 생성하는 것이 효율적이다.
Fallback:true를 통해 새로 만들어진 HTML 파일도 Next.js에서는
프리 렌더링된 페이지로 인식하고 그것을 정적으로 저장한다.
사용자가 처음 들어왔을 때 최초의 경로가 생성이 된다면
그 다음 사람부터는 getStaticProps를 호출하는 것이 아니라
이미 프리 렌더링된 HTML을 받아볼 수 있다는 것이다.
fallback의 blocking 속성
Fallback: ‘blocking’
Fallback :true와 달리 isFallback이라는 fallback UI가 보이지 않고 바로 404 page로 넘어간다.
새롭게 접근한 URL에 대해 HTML이 생성될 때까지,
즉 getStaticProps가 완료될 때까지 대기한다.
그리고 fallback : true와 같이 처음 접근한 사람에 대해서만 getStaticProps를 호출하고
그 다음부터는 프리 렌더링된 페이지를 바로 제공한다.
나의 프로젝트에서는 어떻게 적용해야 할까
1) 대규모의 데이터를 사용하는 서비스가 아니고
2) json 데이터 위에 새로운 교회가 추가될 일이 없기 때문에
isFallback은 false로 설정해줬고, 또한 fallback UI도 없어도 된다.
마찬가지로 getStasticProps 내부의 404 page로 redirect하는 코드도 필요가 없기에 삭제를 해줬다.
Reference
[Next.js 공식 문서] https://nextjs.org/docs/basic-features/data-fetching/get-static-paths