[번역] Next.js 14

원글: https://nextjs.org/blog/next-14

Next.js 14는 다음과 같은 가장 중점으로 둔 릴리스이다.

• Turbopack: App & Pages Router에서 5,000번의 테스트 통과
  • 로컬 서버 시작이 53% 더 빠르다.
  • Fasth Refresh로 코드 업데이트 94% 빠르다
• Server Actions (안정 버전) : 점진적으로 강화된 Mutations

Next.js 컴파일러 : Turbocharged

Next.js 13부터, 우리는 Pages와 App Router 모두에서 Next.js의 로컬 개발 성능을 향상시키기 위해 노력해왔다.

이전에는, 이 작업을 위해 next dev 및 Next.js의 다른 부분을 수정했다. 그 이후로 우리는 접근을 보다 단계적으로 변경했다. 이는 우리가 모든 Next.js 기능을 지원하는 것에 우선 집중했기 때문에 Rust 기반 컴파일러가 곧 안정된다는 것을 의미합니다.

다음 개발을 위한 5,000개의 통합 테스트는 현재 기본 Rust 엔진인 Turbopack에서 통과되었습니다. 이러한 테스트에는 7년간의 버그 수정 및 재현이 포함되어 있습니다.

대규모 Next.js 응용 프로그램인 vercel.com에서 테스트한 결과 다음과 같은 사실을 알게 되었습니다.

• 로컬 서버 시작이 최대 53.3% 더 빠르다.
• 고속 리프레시로 코드 업데이트가 최대 94.7% 더 빠르다.

테스트 합격률이 100%에 도달하면 다음 마이너 릴리스에서 Turbopack을 안정 버전으로 마이그레이션할 것이다. 또한 사용자 지정 구성 및 ecosystem 플러그인에서 webpack 사용을 계속 지원합니다.

---

Form과 Mutations

Next.js 9에서 프론트엔드 코드와 함께 백엔드 엔드 포인트를 신속하게 구축하는 방법인 API Routes를 도입했다.

예를 들어, api/ 디렉토리에서 새 파일을 만들어 보자.

pages/api/submit.ts

import type { NextApiRequest, NextApiResponse } from 'next';
 
export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  const data = req.body;
  const id = await createItem(data);
  res.status(200).json({ id });
}
import type { NextApiRequest, NextApiResponse } from 'next';
 
export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  const data = req.body;
  const id = await createItem(data);
  res.status(200).json({ id });
}

그런 다음 클라이언트 측에서 React 및 onSubmit과 같은 이벤트 핸들러를 사용하여 API 경로를 가져올 수 있다.

pages/index.tsx

import { FormEvent } from 'react';
 
export default function Page() {
  async function onSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
 
    const formData = new FormData(event.currentTarget);
    const response = await fetch('/api/submit', {
      method: 'POST',
      body: formData,
    });
 
    // Handle response if necessary
    const data = await response.json();
    // ...
  }
 
  return (
    <form onSubmit={onSubmit}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}
import { FormEvent } from 'react';
 
export default function Page() {
  async function onSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
 
    const formData = new FormData(event.currentTarget);
    const response = await fetch('/api/submit', {
      method: 'POST',
      body: formData,
    });
 
    // Handle response if necessary
    const data = await response.json();
    // ...
  }
 
  return (
    <form onSubmit={onSubmit}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Next.js 14에서는 데이터 뮤테이션을 만드는 개발자의 경험을 단순화하고 싶다. 더 나아가, 사용자의 네트워크 연결이 느리거나 저전력 장치에서 양식을 제출할 때 사용자 환경을 개선하고 싶다.

서버 액션 (안정됨)

API Routes를 수동으로 작성할 필요가 없다면 어떻게 될까? 대신 리액트 컴포넌트에서 직접 호출되는 서버에서 안전하게 실행되는 함수를 정의할 수 있다.

App Router는 React Canary 채널에 구축되어 프레임워크가 새로운 기능을 채택하기에 안정적이다. v14부터 Next.js는 안정적인 서버 작업이 포함된 최신 React Canary로 업그레이드되었다.

Pages Router의 이전 예제는 단일 파일로 단순화할 수 있다.

app/page.tsx

export default function Page() {
  async function create(formData: FormData) {
    'use server';
    const id = await createItem(formData);
  }
 
  return (
    <form action={create}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}
export default function Page() {
  async function create(formData: FormData) {
    'use server';
    const id = await createItem(formData);
  }
 
  return (
    <form action={create}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

지금까지 서버 중심 프레임워크를 사용한 개발자에게 서버 작업은 익숙해야 한다. 이는 form 및 FormData Web API와 같은 웹의 기초를 기반으로 한다.

form을 통해 서버 작업을 사용하면 점진적인 향상에 도움이 되지만 필수는 아니다. form을 사용하지 않고 함수로 직접 호출할 수도 있다. TypeScript를 사용하면 클라이언트와 서버간에 완전한 종단 간 안전한 타입을 얻을 수 있다.

데이터 변경, 페이지 리렌더링 또는 리다이렉션은 한 번의 네트워크 왕복에서 수행할 수 있으므로 업스트림 공급자가 느린 경우에도 클라이언트에 올바른 데이터가 표시된다.. 게다가 같은 라우트에서 많은 다른 액션과 같은 다양한 액션을 만들고 재사용할 수 있습니다.

캐싱, 재검증, 리다이렉트 등

서버 작업은 App Router 모델 전체에 깊게 통합되어 있습니다. 다음과 같은 작업을 할 수 있다.

• revalidatePath() 또는 revalidateTag() 를 사용하여 캐시된 데이터의 재확인
• redirect()를 통해 다른 경로로 리다이렉션
• cookies()를 통해 쿠키 설정 및 읽기
• useOptimistic() 을 사용하여 낙관적인 UI 업데이트 처리
• useFormState() 를 사용하여 서버에서 오류를 잡아서 표시
• useFormStatus()를 사용하여 클라이언트의 로드 상태 표시

서버 액션을 사용한 양식 및 뮤테이션 또는 서버 구성 요소 및 서버 액션의 보안 모델 및 모범 사례에 대해 자세히 알아보십시오.

---

부분 사전 렌더링 (프리뷰)

Next.js 용으로 작업하는 부분 사전 렌더링 (빠른 초기 정적 응답이있는 동적 콘텐츠의 컴파일러 최화) 프리뷰를 공유하고 싶다.

부분 프리 렌더링은 SSR, SSG, ISR의 10년에 걸친 R&D를 기반으로 구축되었습니다.

동기 부여

여러분의 의견을 들었다. 현재 고려해야 할 런타임, 구성 옵션, 렌더링 방법이 너무 많다. 정적 속도와 신뢰성을 보장하면서 완전히 동적이고 개인화된 응답도 지원하고 싶다.

글로벌하고 뛰어난 성능과 개인화를 실현하려면 복잡성을 희생해서는 안된다.

우리의 과제는 개발자가 배워야 하는 새로운 API를 도입하지 않고 기존 모델을 단순화하고 더 나은 개발자 경험을 만드는 것이다. 서버 측 콘텐츠의 부분적인 캐시는 이전부터 존재했지만, 이러한 접근법은 여전히 개발자 경험과 우리가 목표로하는 결합성의 목표를 충족해야 한다.

부분 사전 렌더링에서는 새로운 API를 배울 필요가 없다.

React 서스펜스를 기반으로 구축

부분 프리 렌더링은 서스펜스 경계에 의해 정의된다. 작동 방식은 다음과 같다. 다음 전자상거래 페이지를 생각해보자.

app/page.tsx

export default function Page() {
  return (
    <main>
      <header>
        <h1>My Store</h1>
        <Suspense fallback={<CartSkeleton />}>
          <ShoppingCart />
        </Suspense>
      </header>
      <Banner />
      <Suspense fallback={<ProductListSkeleton />}>
        <Recommendations />
      </Suspense>
      <NewProducts />
    </main>
  );
}
export default function Page() {
  return (
    <main>
      <header>
        <h1>My Store</h1>
        <Suspense fallback={<CartSkeleton />}>
          <ShoppingCart />
        </Suspense>
      </header>
      <Banner />
      <Suspense fallback={<ProductListSkeleton />}>
        <Recommendations />
      </Suspense>
      <NewProducts />
    </main>
  );
}

부분 사전 렌더링을 사용하도록 설정하면 이 페이지는 <Suspense /> 경계를 기반으로 정적 셸을 생성한다. React Suspense의 fallback은 사전 렌더링된다.

셸의 Suspense fallback은 쿠키를 읽고 장바구니를 결정하고 사용자 기반 배너를 표시하는 등 동적 구성 요소로 대체된다.

요청이 발생하면 정적 HTML 셸이 즉시 제공된다.

<main>
  <header>
    <h1>My Store</h1>
    <div class="cart-skeleton">
      <!-- Hole -->
    </div>
  </header>
  <div class="banner" />
  <div class="product-list-skeleton">
    <!-- Hole -->
  </div>
  <section class="new-products" />
</main>
<main>
  <header>
    <h1>My Store</h1>
    <div class="cart-skeleton">
      <!-- Hole -->
    </div>
  </header>
  <div class="banner" />
  <div class="product-list-skeleton">
    <!-- Hole -->
  </div>
  <section class="new-products" />
</main>

<ShoppingCart />는 쿠키에서 읽어 사용자 세션을 확인하므로 이 컴포넌트는 정적 셸과 동일한 HTTP 요청의 일부로 스트리밍된다. 추가 네트워크 왕복이 필요하지 않다.

import { cookies } from 'next/headers'
 
export default function ShoppingCart() {
  const cookieStore = cookies()
  const session = cookieStore.get('session')
  return ...
}
import { cookies } from 'next/headers'
 
export default function ShoppingCart() {
  const cookieStore = cookies()
  const session = cookieStore.get('session')
  return ...
}

가장 상세한 정적 쉘을 사용하려면 추가 Suspense boundary를 추가해야 할 수 있다. 그러나 현재 이미 loading.js를 사용하고 있다면 이것은 암묵적 Suspense boundary이므로 정적 셸을 생성하기 위해 변경할 필요가 없다.

곧 공개

부분 프리 렌더링은 현재 개발 중이다. 향후 마이너 릴리스에서 더 많은 업데이트를 공유할 예정이다.

---

메타데이터 개선

페이지 콘텐츠를 서버에서 스트리밍하기 전에 먼저 뷰포트, 색 구성표 및 테마에 대한 중요한 메타데이터를 브라우저에 제출해야 합니다.

이러한 메타 태그가 첫 페이지 콘텐츠와 함께 전송되도록 하면 테마 색상 변경으로 인한 페이지 깜박임과 뷰포트 변경으로 인한 레이아웃 이동을 방지하고 사용자 환경이 원활하게 됩니다.

Next.js 14에서는 블로킹 메타 데이터와 비 블로킹 메타 데이터를 분리했습니다. 메타데이터 옵션의 일부만 차단되므로 비블로킹 메타데이터로 부분적으로 미리 렌더링된 페이지가 정적 셸을 제공하지 못하도록 해야 합니다.

다음 메타데이터 옵션은 현재 더 이상 사용되지 않으며 향후 주요 버전에서는 메타데이터에서 제거될 예정입니다.

뷰포트: 뷰포트의 초기 줌 및 기타 속성을 설정합니다. colorScheme: 뷰포트의 지원 모드(라이트/다크)를 설정합니다. themeColor : 뷰포트 주위의 크롬이 렌더링하는 색상을 설정합니다. Next.js 14부터는 이러한 옵션을 대체하는 새로운 옵션 viewport 및 generateViewport가 추가되었습니다. 다른 모든 메타데이터 옵션은 동일하게 유지됩니다.

이러한 새로운 API는 이제 배포를 시작할 수 있습니다. 기존 메타데이터 옵션은 계속 작동합니다.

https://nextjs.org/docs/app/api-reference/functions/generate-viewport