실전에서 바로 쓰는 Next.js

Next.js를 사용하면 SSR 페이지든 정적 페이지든 다 Node.js에서 실행되기 때문에 fetch, window, document 같은 웹 브라우저의 객체나 HTML 요소에는 접근할 수 없다.

ts를 나중에 사용하기로 했다면, tsconfig.json 파일을 생성하고 서버를 실행한다.

next.env.d.ts 파일은 삭제하면 안 됨!

hydration: 서버에서 만든 HTML에 클라이언트에서 실행하는 JS를 추가해서 앱 상태를 관리하고 렌더링하는 기법, 웹 페이지를 동적으로 처리한다.

SSR의 장점: 페이지를 서버에서 렌더링하기 때문에 쿠키, API, 데이터 검증에 대한 부분에서 안전하다. 호환성이 좋다. SEO

정적 페이지는 vercel이나 netlify를 사용하여 배포할 수 있지만 SSR은 서버가 필요하기 때문에 자원이 많이 들어가고 부하가 크며 유지보수 비용이 높고 요청을 처리하는 시간이 더 오래 걸린다.

SSR 방식으로 페이지를 렌더링 할 때 데이터 통신이나 API 호출이 있다면 서버에서 호출해 클라이언트로 그 데이터를 전송하게 된다. 그 때 사용하는 함수가 getServerSideProps 함수인데 next.js는 이 함수를 다 찾아서 실행하고 props라는 객체를 반환한다. 그러면 페이지에서 그 함수의 인자로 props를 받아 화면에 표시해준다.

리액트는 서버에서 클라이언트로 번들을 전송한 후에 렌더링을 시작한다. (CSR) 그에 대한 장점으로는 브라우저에 모든 페이지가 다운되기 때문에 페이지를 새로 고칠 필요가 없고, 페이지 전환이 자연스럽다. 지연로딩이 가능하고 서버 부하가 감소된다.

만약 반드시 클라이언트 측에서 실행해야 하는 것이 있다면 useEffect 훅을 사용한다. 예를 들어 DOM을 조작하거나 데이터 불러오기 같은 것들이 있다. 아니면 process.browser를 통해서 true이면 클라이언트, false면 서버에서 실행하는 것이라고 하고 로직을 짠다. 근데 이 기능은 곧 중단될 예정이라서 typeof window ? server : client 를 사용하면 된다. 저 값이 false면 서버사이드라고 생각하면 된다. 그것도 아니면 dynamic 모듈을 사용해서 {ssr: false} 구문을 추가하여 사용하면 된다.

SSG 정적 사이트 생성 : 일부 또는 전체를 빌드 시점에 미리 렌더링한다. 내용이 많이 바뀌지 않는다면 정적 형태로 렌더링 하는 것이 더 좋다. 장점으로는 쉬운 확장, 더 좋은 성능, 안전한 API요청이 있다. 그러나 다음 배포 전까지 내용이 변하지 않는다는 단점이 있다.

위의 단점을 해결하기 위해 ISR (증분 정적 재생성) 렌더링 방식이 있다. 정해진 주기마다 정적 페이지를 렌더링한다. getStaticProps 함수를 사용한다. 반환 객체에 revalidate 속성을 추가해주면 주기를 설정할 수 있다. revalidate 시간마다 렌더링 하는 것은 아니고 그 시간이 지난 후에 새로 요청이 들어오면 함수를 다시 호출하여 화면을 렌더링한다.

만약 서버 사이드 렌더링을 했다면 getServerSideProps({ param }) 에서 param으로 URL에서 값을 가져올 수 있다. 그리고 그 값을 페이지에서 props 속성값을 통해서 가져올 수 있다. 아니면 useRouter 사용해서 query 매개변수를 가져올 수 있다.

내비게이션 처리는 Link를 통해서 사용이 가능한데 그렇게 연결 된 페이지를 모두 미리 읽어오게 된다. 만약 미리 읽지 않으려면 preload = {false} 속성을 전달하면 된다.

이미지의 경우에는 웹사이트 성능이나 SEO 점수에 큰 영향을 미친다. 그리고 저런 경우에 누적 레이아웃 이동 (CLS) 이라는 문제가 있을 수 있는데 next.js에서는 이걸 해결할 수 있다.

그리고 Image 컴포넌트를 통해서 이미지를 자동으로 최적화 해준다. next.config.js 파일에 어떤 파일을 최적화 할지 설정이 가능하다. 여기에 적어준 것들은 이미지를 WebP 포맷으로 변경해주고 화면 크기에 따라 여러 이미지를 생성하게 된다. 근데 계속 이렇게 하면 서버에 부하가 오기 때문에 loader 속성을 지정해서 다른 서비스로 최적화 할 수도 있다. 만약 vercel 로 배포를 한다면 지정할 필요가 없다.

app.js: 페이지 이동시 서로 다른 페이지 간 상태를 유지하고자 할 때 사용한다. 예를 들어 장바구니나 테마 등. 전역 스타일이나 페이지의 레이아웃을 관리한다.

document.js : HTML 태그를 커스터마이징 하게 된다. HTML(HTML의 html 태그에 해당됨), Head(공통 태그를 정의한다), Main(페이지 컴포넌트, 공통 컴포넌트를 넣어준다), NextScript(페이지 렌더링 후 커스텀 스크립트를 넣는 자리이다) 네 가지의 컴포넌트가 무조건 필요하다.

두 파일 모두 SSR, SSG는 적용할 수 없고, ISR은 사용이 가능하다. 하지만 최적화가 되지는 않는다.