Pages

Written by 심재철

아래 문서는 Next.js 9.3 이상 버전에서 적용됩니다.

Pages

Next.js에서는 pages 폴더 아래에 있는 파일의 이름으로 자동으로 라우팅 된다.

예를들어 pages/about.js에 아래와 같은 리액트 컴포넌트가 있을때

function About() {
  return <div>About</div>;
}

export default About;

우리는 이 컴포넌트에 /about 라우팅으로 진입할 수 있다. 이 About 컴포넌트는 페이지 컴포넌트가 된다.

다이나믹 라우팅 (Pages with Dynamic Routes)

기본적으로 Next.js는 모든 페이지를 pre-renders한다. 이것은 각 페이지에 해당하는 HTML을 미리 생성한다는 말이다. 빈 껍데기 HTML을 내려준 다음 자바스크립트로 그 껍데기 내부를 렌더링하는 방식보다 pre render하는게 초기 페이지가 더 빨리 뜨며 검색엔진봇이 들어왔을때 페이지를 바르게 읽어갈 수 있으므로 SEO에도 적합하다.

페이지 HTML에는 최소한의 자바스크립트 코드만 들어있다. 페이지가 브라우저에 로드된 후에 적은양의 자바스크립트가 호출되고 나면 페이지가 유저와 상호작용이 가능한 상태(interactive)가 된다. 이러한 프로세스를 hydration이라고 부른다.

hydration이란? hydration이라는 뜻은 직역하면 '수화'라는 뜻이다. 프로그래밍스럽게 해석을 해보자면 어떤 정적인 상태였던것이 물을 맞아 동적인 상태로 변경된다고 생각하면 될 것 같다. Next.js나 React.js에서의 hydration은 서버사이드렌더링에 의해 Static하게 렌더링된 HTML에 이벤트 핸들러를 붙여서 동적인 상태로 만드는 과정이라고 생각하면 된다.

Pre-rendering의 두가지 형태

Next.js는 다음 두가지 형태의 Pre-rendering을 한다.

• Static Generation(추천됨): HTML이 빌드 타임에 생성되고 유저가 페이지를 요청할때 계속 재사용 된다.

• Server-side Rendering(SSR): HTML이 유저가 페이지를 요청했을때 생성한다.

중요한것은, 당신이 어떤 형태의 Pre rendering을 사용할것인지 Next.js가 선택권을 제공한다는 것이다. 대부분의 페이지에서 Static Generation을 사용해서 빠르게 렌더링하고 나머지 일부 페이지에 대해서는 SSR을 하게 되는 하이브리드 형태의 앱을 만들 수 있다.

물론, Static Generation이나 Server side rendering과 Client-side Rendering도 함께 사용할 수 있다. 이것은 페이지의 일부분이 client에서 사용되는 자바스크립트에 의해 렌더링 될 수 있다는 말이다. 이 부분을 좀 더 자세히 보고 싶으면 Data Fetching 부분을 읽어보고 오는걸 추천한다.

서버사이드렌더링보다는 Static Generation을 좀 더 추천한다. 왜냐면 성능이 더 좋기 때문이다. 스태틱하게 생성된 페이지는 CDN에 의해 캐시가 될 수 있기 때문에 빠르기도 하고 트래픽도 줄일 수 있다. 하지만 서버사이드렌더링을 사용해야만 하는 경우도 있다.

Static Generation, SSR, CSR 모두 동시에 사용될 수 있다. CSR의 경우 페이지의 일부가 브라우저에서 실행되는 클라이언트 자바스크립트에 의해 렌더링 된다는것이다.

페이지가 Static Generation되면 프로젝트가 빌드될떄 미리 페이지가 생성된다. next build명령어를 입력하면 static HTML들이 생성된다.

데이터 없이 Static Generation

기본적으로 Next.js는 페이지를 SSR이 아니라 Static하게 렌더링한다. 물론 이때 데이터를 fetching하지도 않는다. 예시를 하나 보자.

function About() {
  return <div>About</div>;
}

export default About;

이 About 페이지 컴포넌트는 그 어떤 데이터도 필요로 하지 않기 때문에 빌드 타임에 미리 HTML을 생성해둘 수 있다. Next.js는 1개의 페이지 컴포넌트당 1개의 HTML을 생성한다.

데이터와 함께 Static Generation

어떤 페이지는 pre rendering하기 위해서 외부 데이터를 필요로 할 수 있다. 아래 두가지 경우를 살펴보자.

1. 당신의 페이지 content가 외부 데이터에 의존하는 경우. (getStaticProps를 사용하라)

2. 당신의 페이지 paths가 외부 데이터에 의존하는 경우. (getStaticPaths를 사용하라)

1. 페이지 content가 외부 데이터에 의존하는 경우

당신의 블로그가 포스팅 목록을 렌더링하기 위해 CMS(content management system)에서 데이터를 가져와야 하는 경우

function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  );
}

export default Blog;

이때 getStaticProps를 사용하면 빌드 타임에 api를 호출해서 데이터를 받아온다음에 HTML을 미리 생성해놓는다.

function Blog({ posts }) {
  // 4. 이곳에서 사용되어 HTML이 생성됩니다.
}

// 1. 빌드 타임에 getStaticProps 호출
export async function getStaticProps() {
  // 2. 포스트 목록을 받아오기 위해 API 호출
  const res = await fetch("https://.../posts");
  const posts = await res.json();

  // 3. 여기서 리턴한 포스트 목록이
  return {
    props: {
      posts,
    },
  };
}

export default Blog;

2. 페이지 paths가 외부 데이터에 의존하는 경우

블로그에 작성된 포스트들은 id를 갖고 있다. 근데 Next.js는 pages폴더 아래에 있는 파일의 이름으로 라우팅된다고 했었다. 그럼 모든 포스트의 id에 대해서 파일을 생성해야 하냐고 생각할 수 있지만 그렇지 않다. dynamic routes을 사용하면 된다. 이 다이나믹 라우팅은 예를들어, pages/posts/[id].js와 같은 파일이 있을때 posts/1, posts/2 ...와 같이 다양한 경로가 들어갈 수 있다.

posts/1과 같이 라우팅을 하게 되면 Next.js는 그때 동적으로 1번 페이지를 생성하게 된다. 하지만 이 포스트의 id는 외부 데이터(데이터베이스)에 의존하기 떄문에 빌드 타임에 미리 생성해둘 수가 없다. 왜냐면, 블로그에서 새로운 글을 작성할 수 있기 때문이다. 그 글에 대해서도 접근이 가능해야 하는데 그럴때마다 재빌드할수도 없기 때문이다.

이렇듯 동적으로 생성되어야 하는 페이지에 대해서는 getStaticPaths를 사용하면 된다. 이 함수는 빌드타임에 호출되고 어떤 경로들에 대해서 미리 페이지를 생성할지 지정할 수 있다.

// 1. 빌드 타임에 getStaticPaths 호출
export async function getStaticPaths() {
  // 2. 포스트 목록 받아오는 API 호출
  const res = await fetch("https://.../posts");
  const posts = await res.json();

  // 3. 포스트 목록의 id만 꺼내서
  const paths = posts.map((post) => `/posts/${post.id}`);

  // 4. paths에 해당하는 경로만 빌드타임에 미리 만들어둔다.
  return { paths, fallback: false };
}

fallback: false의 의미는 paths에 해당하지 않는 페이지에 대해서 404가 떨어진다는 말이다. 위 함수를 작성한다음에 next build를 입력하면 /posts/1, /posts/2 와 같이 빌드 시점에서 데이터베이스에 들어있었던 포스트 목록에 대해서 미리 HTML페이지를 생성해둘 수 있다.

또한 아래와 같이 getStaticProps와 함께 사용할 수도 있다.

pages/posts/[id].js파일에서

function Post({ post }) {
  // 4. 받아온 데이터로 포스트를 pre render(static)한다.
}

// 1. 빌드타임에 호출
export async function getStaticPaths() {
  // 생성되어야 하는 경로들을 리턴함. /posts/1, /posts/2 ...
}

// 2. 1번에서 정해진 경로에 대해서 아래 함수가 반복적으로 호출된다.
// 2. getStaticPaths에서 리턴한 posts/1, posts/2 ...의 경로에 대해서 아래 함수 호출
export async function getStaticProps({ params }) {
  // posts/1과 같이 라우팅 되면 params.id는 1이 된다.
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();

  // 3. post데이터를 Post 페이지 컴포넌트에 넘긴다.
  return { props: { post } };
}

export default Post;

언제 Static Generation을 사용해야 하나요?

웬만한 경우에 모두 Static Generation을 사용하길 권장한다. SSR보다 훨씬 빠르기 때문이다. 예를들면 아래와 같이 동적으로 변하지 않는 페이지들이 Static Generation될 수 있다.

• 마케팅 페이지

• 블로그 포스트

• 이커머스 상품 리스트

• 도움말

이런 페이지들은 한번만 생성해두면 사용하는동안 자주 변하지 않기 때문에 Static Generation해두는 것이 좋다.

판단하기 어렵다면 스스로에게 질문해봐라. 내가 이 페이지를 유저의 요청이 있기 전에 미리 생성할 수 있을까? 그렇다면 Static Generation을 사용하라.

Static Generation을 Client-side rendering과 함께 사용하는 경우

페이지의 일부분을 pre-rendering하지 않고 클라이언트 자바스크립트로 생성할 수 있다.

서버사이드렌더링을 사용하는 경우

Next.js는 모든 요청에 대해서 페이지를 pre-renders한다. 이것은 CDN에 의해 캐시될 수 없기 때문에 상대적으로 느릴수 밖에 없다. 하지만 pre-rendered된 페이지는 항상 최신의 상태로 유지된다.

서버사이드렌더링

SSR 또는 Dynamic Rendering이라고 불리기도 한다.

SSR에서는 페이지가 유저의 요청이 들어왔을때 동적으로 생성된다. 페이지를 SSR로 만들고 싶다면 getServerSideProps 함수를 생성하면 된다. 이 함수는 매 요청마다 서버에 의해 실행된다.

빈번하게 업데이트 되는 데이터가 필요한 페이지에서는 pre-renders할 수가 없다. pre-renders의 핵심은 빌드 타임에 미리 HTML을 생성하는것이기 때문이다.

function Page({ data }) {
  // 4. data로 페이지를 렌더링한다.
}

// 1. 매 요청마다 아래 함수가 호출된다.
export async function getServerSideProps() {
  // 2. 외부 API를 호출한다.
  const res = await fetch(`https://.../data`);
  const data = await res.json();

  // 3. 데이터 전달
  return { props: { data } };
}

export default Page;

getStaticProps와 비슷하다고 느낄 수 있지만 차이점은 getServerSideProps는 매 요청마다 서버에 의해 실행 된다. getStaticProps는 빌드 타임에 실행된다.

요약

우리는 여태까지 Next.js의 pre-rendering의 두가지 형태를 살펴보았다.

1. Static Generation(추천됨): HTML이 빌드타임에 미리 생성되며 매 요청마다 재활용 된다. 페이지가 Static Generation되게 만드려면 page component에서 getStaticProps (getStaticPaths도 필요하다면 같이) 함수를 작성해서 export하면 된다.

2. Server side Rendering: HTML이 요청될때 생성된다. 페이지를 SSR하려면 getServerSideProps 함수를 작성하고 export하라. SSR은 Static Generation보다 느리기 때문이 꼭 필요한 경우에만 사용하라.