Next 15

Layout

Route Group

• 이름이 소괄호로 감싸진 폴더

• 경로상에 아무런 영향을 끼치지 않음

• 동시에 각기 다른 경로를 갖는 페이지 파일들을 하나의 폴더로 묶을 수 있는 기능

• 경로가 다른 특정 페이지들에 동일한 레이아웃을 사용하고 싶을 때 사용됨

서버 컴포넌트

서버 측 사전 렌더링에서 딱 한번 실행되는 컴포넌트

반대로 클라이언트 컴포넌트는, 1. 서버 측 사전 렌더링, 2. 하이드레이션 총 2번 실행된다.

주의사항

• 서버 컴포넌트는 브라우저에서 실행될 코드가 포함되면 안된다.

  • 리엑트 훅, 이벤트 핸들러, 브라우저에서 실행되는 기능을 담은 라이브러리

  • Link 컴포넌트는 서버 컴포넌트에서 사용 가능 (서버에서는 정적인 <a> 태그로 렌더링되고 이동 자체는 요소가 가진 기능이기 때문)

• 클라이언트 컴포넌트는 클라이언트에서만 실행되지 않는다.

• 클라이언트 컴포넌트에서 서버 컴포넌트를 import 할 수 없다.

  • 하이드레이션 진행 중에 서버컴포넌트는 포함되지 않기 때문에 문제 발생

  • 이 경우 next.js는 자동으로 서버 컴포넌트를 클라이언트 컴포넌트로 변경 (왼만하면 피하기)

  • 클라이언트 컴포넌트에서 children props를 사용하여 서버 컴포넌트를 자식으로 사용하는 방법은 OK

• 서버 컴포넌트에서 클라이언트 컴포넌트에게 직렬화되지 않는 props는 전달할 수 없다.

  • JSON으로 직렬화할 수 없는 데이터 -> 함수, 클래스, Map/Set,

  • 그 외 직렬화 가능한 데이터

    • string, number, boolean, null, undefined

    • array, object

RSC Payload

React Server Component의 순수 데이터(결과물)

React Server Component를 직렬화한 결과

• 사전 렌더링 과정 중에는 서버 컴포넌트들만 따로 먼저 실행하여 RSC Payload 형태로 직렬화되는 과정 존재

• 서버 컴포넌트들만 따로 실행시키게 되면 그 결과로 HTML 태그가 바로 실행되는게 아닌 RSC Payload라는 JSON과 비슷한 문자열이 생성됨

• RSC Payload는 서버 컴포넌트의 모든 데이터가 포함됨

  • 렌더링 결과

  • 연결된 클라이언트 컴포넌트 위치

  • 클라이언트 컴포넌트에게 전달하는 props 값

네비게이팅

Page Routing과 동일하게 페이지 이동은 Client Side Rendering 방식으로 처리 단, 서버 컴포넌트 개념이 추가되어 방식이 조금 변경됨

• 페이지 이동 요청 후 JS 번들과 같이 서버 컴포넌트 결과물인 RSC Payload도 함께 전달

• 프로그래밍 방식으로 페이지 이동은 useRouter (next/navigation) 사용 *클라이언트 컴포넌트에서만

Prefetching

현재 페이지에서 링크들이 존재하여 연결된 페이지의 데이터들을 미리 불러오는 기법

• 연결된 페이지가 정적 페이지(SSG)인 경우 RSC Payload + JS Bunlde 프리패칭하지만 동적 페이지(SSR)인 경우 RSC Payload만 가져옴

  • 기본적으로 SSG (데이터가 향후 업데이트 되지 않을것이므로 JS Bundle 까지 프리패칭)

  • 빌드 타임에서 가져오기 어려운 경우(예: 쿼리 파라미터 사용 등)은 모두 동적 페이지로 분류

데이터 패칭

• 서버 컴포넌트는 async 를 붙여서 데이터 패칭 가능

• 기존 getStaticProps, getServerSideProps를 대체

  • 더이상 페이지 컴포넌트로부터 서버에서 패칭한 데이터를 넘겨 받지 않아도됨

  • "Fetching data where it's needed"

환경 변수에서 NEXT_PUBLIC_ 접두사를 제거하면 서버에서만 읽을 수 있어 private하게 동작함

데이터 캐시

fetch 메서드를 통해 불러온 데이터를 Next 서버에 보관하는 기능

• 영구적으로 보관하거나, 특정 시간 주기로 갱신 가능

• 불필요한 데이터 요청 수를 줄여서 성능 개선

• fetch 전용

  • fetch('endpoint', { cache: 'force-cache' })

  • 일반 fetch가 아닌 next 전용 메서드임

• force-cache: 요청 결과를 무조건 캐싱, 한번 호출된 후 다시 호출되지 않음

• (default) no-store: 요청 결과를 캐싱하지 않음, 캐시를 절대하면 안되는 리소스에 사용

  • next15에서 변경됨 14에서는 기본으로 캐싱

• revalidate: 특정 주기마다 캐시를 갱신 (sec)

  • 페이지 라우팅 방식에 ISR과 유사

  • 만료 된 후의 첫 요청은 캐시된 데이터를 보여주고 갱신, 다음 요청 부터 갱신된 데이터 반환

• tags: 특정 태그 기반으로 캐시를 무효화할 수 있도록 설정

  • 온디멘드 리벨리데이트

  • 요청이 들어왔을 때 최신 데이터 갱신

cache가 되었는지 로깅 방법

// next.config.js
const nextConfig = {
  logging: {
    fetches: {
      fullUrl: true
    }
  }
}

리퀘스트 메모이제이션

여러 서버 컴포넌트에서 중복된 요청들을 캐싱해서 한 번만 요청하도록 최적화

• 데이터 캐시와는 다름

• 하나의 페이지를 렌더링하는 동안 중복된 요청들에 한해서 캐싱하기 위해 사용

• 렌더링이 종료되면 캐시 소멸

풀 라우트 캐시

Next 서버측에서 빌드 타임에 특정 페이지의 렌더링 결과를 캐싱하는 기능

• SSG와 유사한 방식

• 다이나믹 페이지로 생성되는 페이지 외 모두 정적 페이지로 생성됨 (Default)

  • 동적 함수를 사용하지 않고 데이터 캐시를 사용하는 경우

다이나믹 페이지로 설정되는 기준

서버 컴포넌트만 해당, 클라이언트 컴포넌트는 페이지 유형에 영향을 미치지 않음

• 특정 페이지가 접속 요청을 받을 때 마다매번 변화가 생기거나, 데이터가 달라지는 경우

• 캐시되지 않는 Data Fetching을 사용할 경우

  • 해당 컴포넌트를 사용하는 모든 컴포넌트들은 자동으로 다이나믹 페이지로 설정된다.

// 캐시 옵션 없이 fetch를 사용하는 경우
async function Comp() {
  const response = await fetch("..."); // or fetch("...", { cache: "no-store" })
  return <div>...</div>
}

• 동적 함수 (쿠키, 헤더, 쿼리스트링) 을 사용하는 컴포넌트가 있을 때

  • 요청에 따라 달라질 수 있는 값들

import { cookies, headers } from 'next/headers'

async function Comp() {
  const cookieStore = cookies();
  const theme = cookieStore.get('theme');
  
  const headersList = headers();
  const authorization = headersList.get('authorization');
  
  return <div>...</div>
}

async function Page({ searchParams }: { searchParams: { q: string } }) {
  const q = searchparams.q;
  //...
}

Revalidate

페이지 라우트의 ISR 방식과 유사

• 풀 라우트 캐시로 동작하는 페이지 내부에서 revalidate 옵션이 적용된 데이터 패칭이 존재한다면

• tanstack-query와 비슷, reavlidate time이 경과했다면 우선 풀라우트 캐싱된 페이지를 보여주고 데이터 캐시를 업데이트 후 풀 라우트 캐시 업데이트, 이후 요청엔 업데이트 된 페이지 반환

Suspense

• useSearchParams 훅은 현재 요청받은 페이지의 쿼리스트링을 조회하는 역할

• 쿼리스트링은 빌드타임에 존재할 수 없음

• 빌드타임에 클라이언트 컴포넌트를 실행할 때 빌드 타임에 알 수 없는 쿼리스트링 같은 값을 사용하는 훅을 만나면 에러를 발생

  • 클라이언트측에서만 실행되도록, 즉 사전 렌더링에 배제되도록 설정해야함

  • 해당 클라이언트 컴포넌트를 <Suspense> 로 감싸면 됨

  • 넥스트 서버는 사전 렌더링할 때 <Suspense>를 만나면 곧바로 렌더링하지 않고 Fallback 컴포넌트를 렌더링함

• 쿼리스트링을 불러오는 useSearcmParams 는 비동기로 동작함

  • 쿼리스트링을 불러와야 비동기가 종료됨

generateStaticParams

동적 경로를 갖는 페이지를 정적 페이지로서 빌드 타임에 생성되도록 하는 방법

• 빌드타임에 넥스트서버가 페이지에 어떤 경로(파라미터)가 존재할 수 있는지 정의하여 리턴

  • 미리 정의하지 않은 (파라미터)페이지에 대해서도 동일하게 모두 정적 페이지로 설정됨 (다만 동작이 조금 다름)

  • 미리 정의하지 않은 파라미터의 경우는 서버에 요청이 들어왔을 때 실시간으로 넥스트 서버에 생성되어 이후 요청에 풀 라우트 캐싱이 적용됨

  • 넥스트에서는 동적 경로를 갖는 페이지에 한해 예외적으로 generateStaticParams 함수가 존재한다면, 무조건 정적 페이지로 설정하게됨

• 파라미터 값은 문자열로만 작성

• generateStaticParams 를 사용하게 되면 페이지 내부에 데이터 캐싱이 적용되지 않은 데이터 패칭이 있더라도 무조건 해당 페이지는 강제로 정적페이지로 생성됨

• 페이지 라우터의 getStaticPaths 와 동일

export function generateStaticParams() {
  return [{ id: "1" }, { id: "2" }, { id: "3" }] // url 파라미터를 담은 배열을 반환
}

generateStaticParams로 미리 정의한 파람 외 다른값으로 들어온 페이지 요청건 모두 404로 보내버리고 싶은 경우

export const dynamicParams = false;

라우트 세그먼트 옵션

페이지 내부에서 사용되는 컴포넌트들의 데이터 패칭 캐싱, 리벨리데이트 타임을 강제로 설정

즉, 특정 페이지를 강제로 정적 페이지 또는 동적 페이지로 설정하는 방법

• dynamicParams와 같이 약속된 변수를 선언 후 값을 설정하여 반환하는 페이지 설정을 라우트 세그먼트 옵션이라함

dynamic

특정 페이지의 유형을 강제로 static, dynamic 페이지로 설정

export const dynamic = 'auto' | 'force-dynamic' | 'force-static' | 'error'  

• auto [default]: 아무것도 강제하지 않음

• force-dyanmic: 페이지를 강제로 동적 페이지로 설정

• force-static: 페이지를 강제로 정적 페이지로 설정

  • 동적 함수를 사용하는 페이지에서 문제 발생, 빈값으로 들어옴

• error: 페이지를 강제로 정적 페이지로 설정

  • 정적 페이지로 설정하면 안되는 이유(동적 함수, 데이터 패칭 캐시 등)은 빌드 오류를 발생시킴

정말 특별한 상황이 아니면 권장하지 않음

클라이언트 라우트 캐시

브라우저에 저장되는 캐시

• 페이지 이동을 효율적으로 하기 위해 페이지 일부 데이터(RSC Payload)를 보관함

• 여러 페이지가 공통된 레이아웃을 사용하는 경우 중복된 데이터를 계속해서 전달받게 되는 문제 발생

• 이런 비효율을 줄이기 위해 넥스트는 클라이언트 라우터 캐시 라는 새로운 캐시 공간을 마련해서 해당 데이터들을 자동 보관

• 기본적으로 새로고침시 모두 비워지게됨