Next.js
- Vercel에서 만든 풀스택 웹 애플리케이션을 구축하기 위한 리액트 기반 프레임워크
- 리액트 서버 사이드 렌더링의 대명사
- create-next-app으로 프로젝트 생성 가능
package.json
- 프로젝트 구동에 필요한 모든 명령어 및 의존성이 포함
- next : Next.js의 기반이 되는 패키지
- eslint-config-next
- Next.js 기반 프로젝트에서 사용하도록 만들어진 ESLint 설정
- 구글과 협업해 만든 핵심 웹 지표에 도움이 되는 규칙들이 내장됨
next.config.js
- Next.js 프로젝트의 환경 설정 담당
- reactStrictMode
- 리액트의 엄격 모드와 관련된 옵션
- 리액트 애플리케이션 내부에서 잠재적인 문제를 개발자에게 알리기 위한 도구
- swcMinify
- vercel에서 SWC라고 불리는 오픈소스 개발 <- 번들링과 컴파일을 더욱 빠르게 수행하기 위함
- SWC 기반으로 코드 최소화 작업을 할 것인지 여부를 설정하는 속성
- basePath : 일종의 URL을 위한 접두사
- poweredByHeader : 응답 헤더에 X-Power-by를 추가할 건지 여부. false하는 것이 좋음
- redirects : 특정 주소를 다른 주소로 보내고 싶을 때 사용
- assetPrefix : 만약 next에서 빌드된 결과물을 동일한 호스트가 아닌 다른 CDN 등에 업로드하고자 한다면 이 옵션에 해당 CDN 주소를 명시하면 됨
pages/_app.tsx
- 애플리케이션의 전체 페이지의 시작점
- 웹 애플리케이션에서 공통으로 설정해야 하는 것들을 여기에서 실행할 수 있음
- 에러 바운더리를 사용해 애플리케이션 전역에서 발생하는 에러 처리
- reset.css 같은 전역 CSS 선언
- 모든 페이지에 공통으로 사용 또는 제공해야 하는 데이터 제공 등
_app.tsx의 render 함수 내부에서 console.log()를 추가해서 실행하면 해당 로그가 브라우저가 아닌 Next.js를 실행한 터미널에 기록됨
이후 페이지를 전환하면 더 이상 서버에서 로깅되지 않고 브라우저에 로깅 되는 것을 확인할 수 있음
=> 최초에는 서버 사이드 렌더링을, 이후에는 클라이언트에서 _app.tsx의 렌더링이 실행된다는 점을 짐작할 수 있음
pages/_document.tsx
- 애플리케이션의 HTML을 초기화하는 곳
- <html>이나 <body>에 DOM 속성을 추가하고 싶다면 _document.tsx를 사용함
- _app.tsx는 렌더링이나 라우팅에 따라 서버나 클라이언트에서 실행될 수 있지만 _document는 무조건 서버에서 실행됨 => 이벤트 핸들러 추가하는 것은 불가능
_app.tsx vs _document.tsx
- _app.tsx
- Next.js를 초기화하는 파일
- Next.js 설정과 관련된 코드를 모아두는 곳
- 경우에 따라 서버와 클라이언트 모두에서 렌더링 될 수 있음
- _document.tsx
- Next.js로 만드는 웹사이트의 뼈대가 되는 HTML 설정과 관련된 코드를 추가하는 곳
- 반드시 서버에서만 렌더링됨
pages/_error.tsx
- 클라이언트에서 발생하는 에러 또는 서버에서 발생하는 500 에러를 처리할 목적으로 만들어짐
- Next.js 프로젝트 전역에서 발생하는 에러를 적절하게 처리하고 싶다면 이 페이지를 활용할 것
pages/404.tsx
- 404 페이지를 정의할 수 있는 파일
pages/500.tsx
- 서버에서 발생하는 에러를 핸들링하는 페이지
- _error.tsx와 500.tsx가 모두 있다면 500.tsx가 우선적으로 실행됨
pages/index.tsx
- 웹 사이트의 루트
서버 라우팅, 클라이언트 라우팅
- Next.js는 서버 사이드 렌더링의 장점, 즉 사용자가 빠르게 볼 수 있는 최초 페이지를 제공한다는 점과 싱글 페이지 애플리케이션의 장점인 자연스러운 라우팅이라는 두 가지 장점을 모두 살리는 방식으로 동작
- <a> 대신 <Link> 태그 사용
- window.location.push 대신 router.push 사용하기
getStaticPaths와 getStaticProps
- 어떠한 페이지를 사용자와 관계없이 정적으로 결정된 페이지를 보여주고자 할 때 사용되는 함수
- getStaticPaths
- 접근 가능한 주소를 정의하는 함수
- fallback
- 미리 빌드해야 할 페이지가 너무 많은 경우 사용 가능
- paths에 미리 빌드해 둘 몇개의 페이지만 리스트로 반환하고, true나 "blocking"으로 값을 선언할 수 있음
- true : 사용자가 미리 빌드하지 않은 페이지에 접근할 경우, 빌드되기 전까지는 fallback 컴포넌트를 보여주고, 빌드가 완료된 이후에 해당 페이지를 보여주는 옵션
- "blocking" : 별도의 로딩과 같은 처리를 하지 않고, 단순히 빌드가 완료될 때까지 사용자를 기다리게 하는 옵션, 서버 사이드에서 렌더링할 때까지 대기한 다음, 렌더링이 완료되면 해당 페이지를 제공함
- getStaticProps
- 정의한 페이지를 기준으로 해당 페이지로 요청이 왔을 때 제공할 props를 반환하는 함수
- 가능한 모든 조합을 빌드 시점에 불러와 페이지로 렌더링함
- 사용자가 접근할 수 있는 페이지를 모조리 빌드해 두고 배포하면 사용자는 굳이 페이지가 렌더링되는 것을 기다릴 필요 없이 이미 완성돼 있는 페이지를 받기만 하면 되므로 굉장히 빠르게 해당 페이지를 확인할 수 있음
getServerSideProps
- 서버에서 실행되는 함수이며 해당 함수가 있다면 무조건 페이지 진입 전에 이 함수를 실행함
- 응답값에 따라 페이지의 루트 컴포넌트에 props를 반환할 수도, 혹은 다른 페이지로 리다이렉트시킬 수도 있음
- 이 함수가 있다면 Next.js는 꼭 서버에서 실행해야 하는 페이지로 분류해 빌드 시에도 서버용 자바스크립트 파일을 별도로 만듦
- Next.js의 서버 사이드 렌더링은 getServerSideProps의 실행과 함께 이뤄짐
- getServerSideProps의 props로 내려줄 수 있는 값은 JSON 값으로 제한됨
- window, document와 같이 브라우저에서만 접근할 수 있는 객체에는 접근할 수 없음
- API 호출 시 protocol과 domain 없이 fetch 요청을 할 수 없음 => 반드시 완전한 주소를 제공해야 함
- 여기서 에러가 발생하면 500.tsx와 같이 미리 정의해 둔 에러 페이지로 리다이렉트됨
getInitialProps
- getStaticProps나 getServerSideProps가 나오기 전에 사용할 수 있었던 유일한 페이지 데이터를 불러오기 위한 수단
- 라우팅에 따라서 서버와 클라이언트 모두에서 실행 가능한 메서드
context 객체
- pathname : 현재 경로명. 페이지상 경로
- asPath : 브라우저에 표시되는 실제 경로. 사용자에게 표시되는 주소
- query : URL에 존해나느 쿼리
- req : Node.js에서 제공하는 HTTP request 객체
- res : Node.js에서 제공하는 HTTP response 객체
글로벌 스타일 적용
- _app.tsx에서 필요한 스타일을 직접 import로 불러옴
컴포넌트 레벨 CSS
- [name].module.css와 같은 명명 규칙 준수해야 함
'FE > 리뷰' 카테고리의 다른 글
| [모던 리액트 딥다이브] 5.2장 리액트 훅으로 시작하는 상태 관리 (0) | 2024.08.11 |
|---|---|
| [모던 리액트 딥다이브] 5.1장 상태 관리 (0) | 2024.08.11 |
| [모던 리액트 딥다이브] 4.2장 SSR을 위한 리액트 API (0) | 2024.08.03 |
| [모던 리액트 딥다이브] 4.1장 서버 사이드 렌더링 (0) | 2024.07.21 |
| [모던 리액트 딥다이브] 3.2장 사용자 정의 훅과 고차 컴포넌트 (0) | 2024.07.21 |
