Automatic Static Optimization
next.js에서 ssr을 사용하지 않고 데이터를 받아오는 경우
즉, getServerSideProps 와 getInitialProps를 사용하지 않는 경우 자동으로 정적 페이지라고 페이지를 인식한다. 이러한 next.js의 특징은 next.js가 하이브리드로 동작할 수 있도록 해주는데, 이는 유저가 빠른 로딩 경험을 할 수 있도록 도와준다.
빌드 돌리면 해당 각각의 페이지들이 어떤 방식으로 렌더링 되고 있는지 확인 할 수 있다.
ssr보다 정적 데이터로 데이터를 받아오는게 더 빠르다는 건가?
✅ Next.js는 기본 페이지가 정적 페이지 즉, 빌드 상에서 이미 만들어지는 페이지기 때문에 ssr보다 더 빠르다.
만약 getServerSideProps 와 getInitialProps가 있다면 next.js는 필요시에, 요청할 때 마다 페이지를 렌더링하게 된다.(==SSR) 만약 이게 없다면 정적 HTML문서를 자동으로 미리 렌더링 해두는데 미리 렌더링하는 과정에서 router의 query는 데이터를 가지고 있지 않다.
쿼리 데이터는 클라이언트 사이드 자바스크립트가 정적 HTML을 변환한 이후(hydration) 데이터가 업데이트 된다. hydration이란, test.js라는 파일이 있는 경우 test.html 파일로 먼저 생성 후 test.js로 변환되는 과정을 의미한다.
- getServerSideProps를 사용한 경우에는 바로 js 파일로 해석된다.
그래서 다음과 같은 상황에서는 쿼리에 값이 업데이트 되었는지 확인해야한다.
- 동적 라우팅 - 동적 라우팅 내에서 getServerProps를 사용하는 경우는 해당 없음
- URL에 쿼리가 포함되어있는 경우
- next.js에서 제공하는 rewrite 기능을 사용시 쿼리가 필요한 경우
Rewrite 기능
페이지를 별도로 만들 필요 없이 유저가 특정 라우팅으로 접근 시, 이를 리다이렉트 해주는 기능이다. 처음 알게되었는데, 회사 페이지를 이관하면서 기존 페이지와 충돌되는 페이지 라우팅을 이를 이용해 수정해보아야겠다.
isReady
isReady라는 next.js에서 제공하는 라우터 기능을 이용해 이를 체크할 수 있다.
useEffect 내부에서 사용하는 것을 권장한다.
const router = useRouter();
useEffect(()=>{
if(!router.isReady) return;
...
}, [router.isReady]);주의사항
만약 app.js에서 getInitialProps 을 사용하는 경우
app은 모든 페이지에 적용되는 파일이므로, 해당 페이지에서 getInitialProps을 사용하지 않아도 이미 app에서 사용된 getInitialProps에 의해 서버에서 렌더링되기 때문에 opitimizing이 발생하지 않는다.
만약 document.js에서 getInitialProps 을 사용하는 경우
클라이언트에서 쿼리와 마찬가지로 서버에서 ctx.req가 미리 렌더링되는 과정에서 생성되지 않으므로, 렌더링 되었다고 가정되기 전에 해당 데이터가 있는지 확인 후 사용해야한다!
router.asPath 사용시
isReady 값이 true가 아니면 asPath를 사용하는 것을 주의해야한다. 정적 페이지에서 asPath는 클라이언트에서만 알 수 있기 때문에, 의도와 다르게 동작할 수 있다.
