FE/리뷰

[모던 리액트 딥다이브] 4.3장 Next.js

따봉치치 2024. 8. 4. 18:08
728x90

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와 같은 명명 규칙 준수해야 함

 

 

728x90