App Router 段階的な導入ガイド

このガイドでは以下について説明します:

Next.jsアプリケーションをバージョン12からバージョン13に更新する
pagesディレクトリとappディレクトリの両方で動作する機能をアップグレードする
既存のアプリケーションをpagesからappに段階的に移行する

アップグレード

Node.jsのバージョン

最小のNode.jsバージョンはv18.17です。詳細はNode.jsのドキュメントを参照してください。

Next.jsのバージョン

Next.jsバージョン13に更新するには、お好みのパッケージマネージャーで以下のコマンドを実行してください:

Terminal

npm install next@latest react@latest react-dom@latest

ESLintのバージョン

ESLintを使用している場合、ESLintのバージョンをアップグレードする必要があります:

Terminal

npm install -D eslint-config-next@latest

Good to know: VS CodeでESLintの変更を有効にするには、ESLintサーバーを再起動する必要があるかもしれません。コマンドパレット（Macではcmd+shift+p、Windowsではctrl+shift+p）を開き、ESLint: Restart ESLint Serverを検索してください。

次のステップ

更新後、次のセクションで次に取るべきステップを確認してください:

新機能のアップグレード: 改善されたImageおよびLinkコンポーネントなど、新機能へのアップグレードを支援するガイドです。
pagesディレクトリからappディレクトリへの移行: pagesからappディレクトリへの段階的な移行を支援するステップバイステップガイドです。

新機能のアップグレード

Next.js 13には、新しい機能と規約を備えた新しいApp Routerが導入されました。新しいRouterはappディレクトリで利用でき、pagesディレクトリと共存します。

Next.js 13へのアップグレードは、新しいApp Routerの使用を必須としません。pagesを引き続き利用し、新しいImageコンポーネント、Linkコンポーネント、Scriptコンポーネント、およびフォント最適化など、両ディレクトリで機能する新機能を使用できます。

`<Image/>` コンポーネント

Next.js 12では、一時的なインポートとしてImageコンポーネントの新しい改善を導入しました：next/future/image。これらの改善には、クライアントサイドのJavaScriptの削減、画像の拡張とスタイルの容易化、アクセシビリティの向上、およびネイティブブラウザーの遅延読み込みが含まれていました。

バージョン13では、この新しい動作がnext/imageのデフォルトになりました。

新しいImageコンポーネントへの移行を支援するための2つのcodemodがあります:

next-image-to-legacy-image codemod: next/imageインポートをnext/legacy/imageに安全かつ自動的にリネームします。既存のコンポーネントは同じ動作を維持します。
next-image-experimental codemod: インラインスタイルを危険な形で追加し、使用されていないpropsを削除します。このcodemodを使用するには、最初にnext-image-to-legacy-image codemodを実行する必要があります。

`<Link>` コンポーネント

<Link> コンポーネントは、子として手動で<a>タグを追加する必要がなくなりました。この動作はバージョン12.2で実験的なオプションとして追加され、現在はデフォルトです。Next.js 13では、<Link>は常に<a>をレンダリングし、propsを基礎となるタグに渡すことを可能にします。

例えば：

import Link from 'next/link'

// Next.js 12: `<a>`はネストされていないと除外されます
<Link href="/about">
  <a>About</a>
</Link>

// Next.js 13: `<Link>`は常に内部で`<a>`をレンダリングします
<Link href="/about">
  About
</Link>

リンクをNext.js 13にアップグレードするには、new-link codemodを利用できます。

`<Script>` コンポーネント

next/scriptの動作はpagesとappの両方をサポートするように更新されましたが、スムーズな移行を確保するためにいくつかの変更が必要です：

以前に_document.jsに含めていたbeforeInteractiveスクリプトをrootレイアウトファイル（app/layout.tsx）に移動します。
実験的なworker戦略はまだappで動作せず、この戦略で指定されたスクリプトは削除するか、別の戦略（例：lazyOnload）を使用するように変更する必要があります。
onLoad、onReady、およびonErrorハンドラはServer Componentsでは動作しないため、Client Componentに移動するか、削除する必要があります。

フォント最適化

以前、Next.jsはフォントCSSのインライン化によってフォントの最適化を支援しました。バージョン13では、新しいnext/fontモジュールが導入され、フォントの読み込み体験をカスタマイズしながら、優れたパフォーマンスとプライバシーを保証します。next/fontはpagesとappディレクトリの両方でサポートされています。

CSSのインライン化はpagesでは機能しますが、appでは機能しません。代わりにnext/fontを使用してください。

フォント最適化ページを確認して、next/fontの使用方法を学んでください。

`pages`から`app`への移行

🎥 視聴: App Routerを段階的に採用する方法を学びます→YouTube（16分）。

App Routerへの移行は、Next.jsが基盤として構築しているReactの機能、例えばServer Components、Suspenseなどを初めて使用することになるかもしれません。新しいNext.jsの機能と組み合わせて、特殊ファイルやレイアウトなどを学ぶことで、移行には新しい概念、メンタルモデル、行動の変化を伴います。

これらの更新の複合的な複雑さを軽減するため、移行を小さなステップに分解することをお勧めします。appディレクトリは、段階的にページごとに移行できるよう、意図的にpagesディレクトリと同時に動作するように設計されています。

appディレクトリは、ネストされたルートとレイアウトをサポートします。詳細はこちら.
ネストされたフォルダを使用してルートを定義し、特殊なpage.jsファイルを使用してルートセグメントを公開します。詳細はこちら.
特殊ファイルの規約により、各ルートセグメントにUIを作成します。最も一般的な特殊ファイルはpage.jsとlayout.jsです。
- page.jsを使用してルートに固有のUIを定義します。
- layout.jsを使用して複数のルートに共有されるUIを定義します。
- 特殊ファイルには.js、.jsx、または.tsxファイル拡張子を使用できます。
appディレクトリ内にコンポーネント、スタイル、テストなどの他のファイルを同じ場所に置くことができます。詳細はこちら.
getServerSidePropsやgetStaticPropsのようなデータフェッチ関数は、app内で新しいAPIに置き換えられました。getStaticPathsはgenerateStaticParamsに置き換えられました。
pages/_app.jsとpages/_document.jsは、単一のapp/layout.jsroot レイアウトに置き換えられました。詳細はこちら.
pages/_error.jsは、より細かいerror.js特殊ファイルに置き換えられました。詳細はこちら.
pages/404.jsは、not-found.jsファイルに置き換えられました。
pages/api/* APIルートは、route.js（Route Handler）特殊ファイルに置き換えられました。

ステップ1：`app`ディレクトリの作成

最新のNext.jsバージョンに更新します（13.4以上が必要）:

npm install next@latest

次に、プロジェクトのroot（またはsrc/ディレクトリ）に新しいappディレクトリを作成します。

ステップ2：Root レイアウトの作成

appディレクトリ内に新しいapp/layout.tsxファイルを作成します。これはapp内のすべてのルートに適用されるroot レイアウトです。

TypeScript
JavaScript

app/layout.tsx
export default function RootLayout({
  // レイアウトはchildrenプロップを受け取る必要があります。
  // これはネストされたレイアウトやページで埋められます
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

app/layout.js
export default function RootLayout({
  // レイアウトはchildrenプロップを受け取る必要があります。
  // これはネストされたレイアウトやページで埋められます
  children,
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

appディレクトリにはroot レイアウトが必須です。
root レイアウトは、Next.jsが自動的に作成しないため、<html>と<body>タグを定義する必要があります；
root レイアウトはpages/_app.tsxとpages/_document.tsxファイルを置き換えます。
レイアウトファイルには.js、.jsx、または.tsx拡張子を使用できます。

<head> HTML要素を管理するには、組み込みのSEOサポートを使用できます:

TypeScript
JavaScript

app/layout.tsx
import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Home',
  description: 'Welcome to Next.js',
}

app/layout.js
export const metadata = {
  title: 'Home',
  description: 'Welcome to Next.js',
}

`_document.js` および `_app.js` の移行

既存の_app または_documentファイルがある場合、その内容（例：グローバルスタイル）をroot レイアウト（app/layout.tsx）にコピーできます。app/layout.tsx内のスタイルはpages/*には適用されません。pages/*ルートが壊れないようにするため、移行中は_app/_documentを保持する必要があります。完全に移行した場合、それらを安全に削除できます。

Reactコンテキストプロバイダーを使用している場合、それらをClient Componentに移動する必要があります。

`getLayout()` パターンからレイアウトへの移行（任意）

Next.jsは、pagesディレクトリでページごとのレイアウトを達成するため、ページコンポーネントへのプロパティ追加を推奨しました。このパターンは、appディレクトリ内のネストされたレイアウトのネイティブサポートに置き換えられます。

前後の例を確認する

Before

components/DashboardLayout.js
export default function DashboardLayout({ children }) {
  return (
    <div>
      <h2>My Dashboard</h2>
      {children}
    </div>
  )
}

pages/dashboard/index.js
import DashboardLayout from '../components/DashboardLayout'

export default function Page() {
  return <p>My Page</p>
}

Page.getLayout = function getLayout(page) {
  return <DashboardLayout>{page}</DashboardLayout>
}

After

pages/dashboard/index.jsからPage.getLayoutプロパティを削除し、appディレクトリへのページ移行手順に従います。
app/dashboard/page.js
```
export default function Page() {
  return <p>My Page</p>
}
```

DashboardLayoutの内容を、pagesディレクトリの動作を保持するための新しいClient Componentとして移動します。

app/dashboard/DashboardLayout.js
'use client' // この指示文はファイルの一番上、インポートの前に配置します。

// これはClient Componentです
export default function DashboardLayout({ children }) {
  return (
    <div>
      <h2>My Dashboard</h2>
      {children}
    </div>
  )
}

DashboardLayoutをappディレクトリ内の新しいlayout.jsファイルにインポートします。

app/dashboard/layout.js
import DashboardLayout from './DashboardLayout'

// これはServer Componentです
export default function Layout({ children }) {
  return <DashboardLayout>{children}</DashboardLayout>
}

コンポーネントJavaScriptをクライアントに送信する量を減らすために、DashboardLayout.js（Client Component）の非インタラクティブな部分をインクリメンタルにlayout.js（Server Component）に移動できます。

ステップ3：`next/head`の移行

pagesディレクトリでは、next/head Reactコンポーネントを使用して、titleやmetaといった<head> HTML要素を管理しますが、appディレクトリでは、next/headは新しい組み込みのSEOサポートに置き換えられました。

Before:

TypeScript
JavaScript

pages/index.tsx
import Head from 'next/head'

export default function Page() {
  return (
    <>
      <Head>
        <title>My page title</title>
      </Head>
    </>
  )
}

pages/index.js
import Head from 'next/head'

export default function Page() {
  return (
    <>
      <Head>
        <title>My page title</title>
      </Head>
    </>
  )
}

After:

TypeScript
JavaScript

app/page.tsx
import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'My Page Title',
}

export default function Page() {
  return '...'
}

app/page.js
export const metadata = {
  title: 'My Page Title',
}

export default function Page() {
  return '...'
}

すべてのメタデータオプションを見る.

ステップ4：ページの移行

appディレクトリ内のページは、デフォルトでServer Componentsです。これは、pagesディレクトリ内のページがClient Componentsであることと異なります。
app内のデータ取得は変更されました。getServerSideProps、getStaticProps、getInitialPropsは、よりシンプルなAPIに置き換えられました。
appディレクトリは、ネストされたフォルダを使用してルートを定義し、特殊なpage.jsファイルを使用してルートセグメントを公開します。
pagesディレクトリ appディレクトリルート
index.js page.js /
about.js about/page.js /about
blog/[slug].js blog/[slug]/page.js /blog/post-1

`pages`ディレクトリ	`app`ディレクトリ	ルート
`index.js`	`page.js`	`/`
`about.js`	`about/page.js`	`/about`
`blog/[slug].js`	`blog/[slug]/page.js`	`/blog/post-1`

ページの移行を2つの主要なステップに分割することをお勧めします:

ステップ1: デフォルトでエクスポートされたページコンポーネントを新しいClient Componentに移動します。
ステップ2: 新しいClient Componentをappディレクトリ内の新しいpage.jsファイルにインポートします。

Good to know: これはpagesディレクトリとの最も比較可能な動作を持つため、最も簡単な移行パスです。

ステップ1: 新しいClient Componentを作成

Client Componentをエクスポートする新しい別ファイルをappディレクトリ内に作成します（例: app/home-page.tsxなど）。Client Componentsを定義するには、ファイルのトップに'use client'ディレクティブを追加します（インポートの前）。
- Pages Routerと同様に、初期ページロード時にClient Componentsを静的HTMLにプレンダリングする最適化ステップがあります。
pages/index.jsからapp/home-page.tsxにデフォルトでエクスポートされたページコンポーネントを移動します。

TypeScript
JavaScript

app/home-page.tsx
'use client'

// これはClient Componentです（`pages`ディレクトリ内のコンポーネントと同じ）
// データをプロップとして受け取り、状態とエフェクトにアクセスでき
// 初期ページ読み込み時にサーバーでプリレンダリングされます。
export default function HomePage({ recentPosts }) {
  return (
    <div>
      {recentPosts.map((post) => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  )
}

app/home-page.js
'use client'

// これはClient Componentです。データをプロップとして受け取り、
// 状態とエフェクトにアクセスでき、`pages`ディレクトリのページコンポーネントと同様です。
export default function HomePage({ recentPosts }) {
  return (
    <div>
      {recentPosts.map((post) => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  )
}

ステップ2: 新しいページを作成

appディレクトリ内に新しいapp/page.tsxファイルを作成します。これはデフォルトでServer Componentです。
ページ内でhome-page.tsxClient Componentをインポートします。
pages/index.jsでデータを取得していた場合、新しいデータ取得APIを使用してServer Componentにデータ取得ロジックを直接移動します。詳細はデータ取得アップグレードガイドを参照してください。

TypeScript
JavaScript

app/page.tsx
// Client Componentをインポートします
import HomePage from './home-page'

async function getPosts() {
  const res = await fetch('https://...')
  const posts = await res.json()
  return posts
}

export default async function Page() {
  // Server Componentで直接データを取得します
  const recentPosts = await getPosts()
  // 取得したデータをClient Componentに渡します
  return <HomePage recentPosts={recentPosts} />
}

app/page.js
// Client Componentをインポートします
import HomePage from './home-page'

async function getPosts() {
  const res = await fetch('https://...')
  const posts = await res.json()
  return posts
}

export default async function Page() {
  // Server Componentで直接データを取得します
  const recentPosts = await getPosts()
  // 取得したデータをClient Componentに渡します
  return <HomePage recentPosts={recentPosts} />
}

前のページでuseRouterを使用していた場合、新しいルーティングフックに更新する必要があります。詳細はこちら。
開発サーバーを起動し、http://localhost:3000にアクセスします。appディレクトリを介して提供される既存のインデックスルートが表示されるはずです。

ステップ5：ルーティングフックの移行

新しいルーターが、appディレクトリ内の新しい動作をサポートするために追加されました。

appでは、next/navigationからインポートされる3つの新しいフック：useRouter()、usePathname()、およびuseSearchParams()を使用する必要があります。

新しいuseRouterフックは、next/navigationからインポートされ、pages内でnext/routerからインポートされるuseRouterフックとは異なる動作を持っています。
- next/routerからインポートされるuseRouterフックは、appディレクトリではサポートされていませんが、pagesディレクトリでは引き続き使用できます。
新しいuseRouterは、pathname文字列を返しません。代わりにusePathnameフックを使用します。
新しいuseRouterは、queryオブジェクトを返しません。クエリパラメータと動的ルートパラメータは現在は分離されています。代わりにuseSearchParamsとuseParamsフックを使用します。
useSearchParamsとusePathnameを組み合わせてページの変更を監視できます。ルーターイベントのセクションで詳細を確認してください。
これらの新しいフックはClient Componentsでのみサポートされています。Server Componentsでは使用できません。

TypeScript
JavaScript

app/example-client-component.tsx
'use client'

import { useRouter, usePathname, useSearchParams } from 'next/navigation'

export default function ExampleClientComponent() {
  const router = useRouter()
  const pathname = usePathname()
  const searchParams = useSearchParams()

  // ...
}

app/example-client-component.js
'use client'

import { useRouter, usePathname, useSearchParams } from 'next/navigation'

export default function ExampleClientComponent() {
  const router = useRouter()
  const pathname = usePathname()
  const searchParams = useSearchParams()

  // ...
}

さらに、新しいuseRouterフックには以下の変更があります：

isFallbackは削除されました。fallbackは置き換えられました。
locale、locales、defaultLocales、domainLocalesの値は削除されました。組み込みのi18n Next.js機能は、appディレクトリ内で不要になりました。i18nについてはこちらをご覧ください。
basePathは削除されました。代替はuseRouterの一部ではありません。まだ実装されていません。
asPathは削除されました。asの概念は新しいルーターから削除されました。
isReadyは削除されました。もはや必要ありません。静的レンダリング中に、useSearchParams()フックを使用するコンポーネントは、プレンダリングステップをスキップし、代わりにクライアントでの実行時にレンダリングされます。
routeは削除されました。usePathnameまたはuseSelectedLayoutSegments()が代替を提供します。

useRouter() APIリファレンスを見る。

`pages`と`app`の間でのコンポーネント共有

コンポーネントを両方のルーター間で互換性を保つには、next/compat/routerからのuseRouterフックを参照してください。これはpagesディレクトリからのuseRouterフックですが、ルーター間でコンポーネントを共有する際に使用することを意図しています。それをappルーターでのみ使用する準備が整ったら、新しいnext/navigationからのuseRouterに更新します。

ステップ6：データ取得方法の移行

pagesディレクトリは、getServerSidePropsとgetStaticPropsを使用してページのデータを取得します。appディレクトリ内では、これらの前のデータ取得関数がfetch()とasync React Server Componentsの上に構築されたよりシンプルなAPIに置き換えられました。

TypeScript
JavaScript

app/page.tsx
export default async function Page() {
  // このリクエストは手動で無効化されるまでキャッシュされるべきです。
  // `getStaticProps`に類似。
  // デフォルトの`force-cache`を省略できます。
  const staticData = await fetch(`https://...`, { cache: 'force-cache' })

  // このリクエストは毎リクエストで再取得されるべきです。
  // `getServerSideProps`に類似。
  const dynamicData = await fetch(`https://...`, { cache: 'no-store' })

  // このリクエストは10秒間キャッシュされるべきです。
  // `getStaticProps`の`revalidate`オプションに類似。
  const revalidatedData = await fetch(`https://...`, {
    next: { revalidate: 10 },
  })

  return <div>...</div>
}

app/page.js
export default async function Page() {
  // このリクエストは手動で無効化されるまでキャッシュされるべきです。
  // `getStaticProps`に類似。
  // デフォルトの`force-cache`を省略できます。
  const staticData = await fetch(`https://...`, { cache: 'force-cache' })

  // このリクエストは毎リクエストで再取得されるべきです。
  // `getServerSideProps`に類似。
  const dynamicData = await fetch(`https://...`, { cache: 'no-store' })

  // このリクエストは10秒間キャッシュされるべきです。
  // `getStaticProps`の`revalidate`オプションに類似。
  const revalidatedData = await fetch(`https://...`, {
    next: { revalidate: 10 },
  })

  return <div>...</div>
}

サーバーサイドレンダリング（`getServerSideProps`）

pagesディレクトリでは、getServerSidePropsを使用してサーバー上でデータを取得し、ファイル内のデフォルトでエクスポートされたReactコンポーネントにpropsを転送します。ページの初期HTMLは、サーバーからのプリレンダリングされ、ブラウザでページを「ハイドレート」（インタラクティブに）することで続きます。

pages/dashboard.js
// `pages`ディレクトリ

export async function getServerSideProps() {
  const res = await fetch(`https://...`)
  const projects = await res.json()

  return { props: { projects } }
}

export default function Dashboard({ projects }) {
  return (
    <ul>
      {projects.map((project) => (
        <li key={project.id}>{project.name}</li>
      ))}
    </ul>
  )
}

App Routerでは、データの取得をReactコンポーネント内にコロケートできるServer Componentsを使用します。これにより、クライアントに送信するJavaScriptが少なくなり、サーバーからレンダリングされたHTMLを維持できます。

cacheオプションをno-storeに設定することで、取得したデータが一切キャッシュされないことを示すことができます。これはpagesディレクトリ内のgetServerSidePropsに類似しています。

TypeScript
JavaScript

app/dashboard/page.tsx
// `app`ディレクトリ

// この関数は任意の名前を付けることができます
async function getProjects() {
  const res = await fetch(`https://...`, { cache: 'no-store' })
  const projects = await res.json()

  return projects
}

export default async function Dashboard() {
  const projects = await getProjects()

  return (
    <ul>
      {projects.map((project) => (
        <li key={project.id}>{project.name}</li>
      ))}
    </ul>
  )
}

app/dashboard/page.js
// `app`ディレクトリ

// この関数は任意の名前を付けることができます
async function getProjects() {
  const res = await fetch(`https://...`, { cache: 'no-store' })
  const projects = await res.json()

  return projects
}

export default async function Dashboard() {
  const projects = await getProjects()

  return (
    <ul>
      {projects.map((project) => (
        <li key={project.id}>{project.name}</li>
      ))}
    </ul>
  )
}

リクエストオブジェクトへのアクセス

pagesディレクトリでは、Node.js HTTP APIに基づいてリクエストベースのデータを取得できます。

たとえば、getServerSidePropsからreqオブジェクトを取得し、リクエストのcookieおよびヘッダを取得することができます。

pages/index.js
// `pages`ディレクトリ

export async function getServerSideProps({ req, query }) {
  const authHeader = req.getHeaders()['authorization'];
  const theme = req.cookies['theme'];

  return { props: { ... }}
}

export default function Page(props) {
  return ...
}

appディレクトリでは、リクエストデータを取得するための新しい読み取り専用関数が公開されています：

headers: Web Headers APIに基づいており、Server Components内でリクエストヘッダを取得するために使用できます。
cookies: Web Cookies APIに基づいており、Server Components内でcookieを取得するために使用できます。

TypeScript
JavaScript

app/page.tsx
// `app`ディレクトリ
import { cookies, headers } from 'next/headers'

async function getData() {
  const authHeader = (await headers()).get('authorization')

  return '...'
}

export default async function Page() {
  // `cookies`または`headers`をServer Components内で
  // 直接使用するか、データ取得関数内で使用できます
  const theme = (await cookies()).get('theme')
  const data = await getData()
  return '...'
}

app/page.js
// `app`ディレクトリ
import { cookies, headers } from 'next/headers'

async function getData() {
  const authHeader = (await headers()).get('authorization')

  return '...'
}

export default async function Page() {
  // `cookies`または`headers`をServer Components内で
  // 直接使用するか、データ取得関数内で使用できます
  const theme = (await cookies()).get('theme')
  const data = await getData()
  return '...'
}

静的サイト生成（`getStaticProps`）

pagesディレクトリでは、getStaticProps関数を使用してページをビルド時にプリレンダリングします。この関数は、外部APIまたは直接データベースからデータを取得するために使用でき、これによりビルド中にページ全体に渡ってデータを渡すことができます。

pages/index.js
// `pages`ディレクトリ

export async function getStaticProps() {
  const res = await fetch(`https://...`)
  const projects = await res.json()

  return { props: { projects } }
}

export default function Index({ projects }) {
  return projects.map((project) => <div>{project.name}</div>)
}

appディレクトリでは、fetch()によるデータ取得はcache: 'force-cache'がデフォルトで、リクエストデータが手動で無効化されるまでキャッシュされます。これはpagesディレクトリ内のgetStaticPropsに類似しています。

app/page.js
// `app`ディレクトリ

// この関数は任意の名前を持つことができます
async function getProjects() {
  const res = await fetch(`https://...`)
  const projects = await res.json()

  return projects
}

export default async function Index() {
  const projects = await getProjects()

  return projects.map((project) => <div>{project.name}</div>)
}

動的パス（`getStaticPaths`）

pagesディレクトリでは、getStaticPaths関数を使用してビルド時にプリレンダリングされる動的パスを定義します。

pages/posts/[id].js
// `pages`ディレクトリ
import PostLayout from '@/components/post-layout'

export async function getStaticPaths() {
  return {
    paths: [{ params: { id: '1' } }, { params: { id: '2' } }],
  }
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://.../posts/${params.id}`)
  const post = await res.json()

  return { props: { post } }
}

export default function Post({ post }) {
  return <PostLayout post={post} />
}

appディレクトリでは、getStaticPathsはgenerateStaticParamsに置き換えられています。

generateStaticParamsはgetStaticPathsに類似して動作しますが、ルートパラメータを返すための簡略化されたAPIを提供し、レイアウト内で使用できます。generateStaticParamsの返り値の形は、ネストされたparamオブジェクトや解決されたパスの文字列ではなく、セグメントの配列です。

app/posts/[id]/page.js
// `app`ディレクトリ
import PostLayout from '@/components/post-layout'

export async function generateStaticParams() {
  return [{ id: '1' }, { id: '2' }]
}

async function getPost(params) {
  const res = await fetch(`https://.../posts/${params.id}`)
  const post = await res.json()

  return post
}

export default async function Post({ params }) {
  const post = await getPost(params)

  return <PostLayout post={post} />
}

appディレクトリの新しいモデルにおいてgenerateStaticParamsという名前を使用する方が適しています。getStaticPropsとgetServerSidePropsがもはや必要なくなったため、get接頭辞はより記述的なgenerateに置き換えられました。Paths接尾辞はParamsに置き換えられ、複数の動的セグメントを持つネストされたルーティングにはより適しています。

`fallback`の置き換え

pagesディレクトリでは、getStaticPathsから返されるfallbackプロパティを使用してビルド時にプリレンダリングされていないページの動作を定義します。このプロパティは、ページが生成される間にフォールバックページを表示するためにtrue、404ページを表示するためにfalse、またはリクエスト時にページを生成するためにblockingに設定できます。

pages/posts/[id].js
// `pages`ディレクトリ

export async function getStaticPaths() {
  return {
    paths: [],
    fallback: 'blocking'
  };
}

export async function getStaticProps({ params }) {
  ...
}

export default function Post({ post }) {
  return ...
}

appディレクトリでは、config.dynamicParamsプロパティがgenerateStaticParamsの外部でparamsをどのように処理するかを制御します：

true: （デフォルト）generateStaticParamsに含まれていない動的セグメントはオンデマンドで生成されます。
false: generateStaticParamsに含まれていない動的セグメントは404を返します。

これはpagesディレクトリのgetStaticPathsにおけるfallback: true | false | 'blocking'オプションを置き換えます。ストリーミングでは'blocking'とtrueの間の違いはわずかであるため、dynamicParamsにはfallback: 'blocking'オプションは含まれていません。

app/posts/[id]/page.js
// `app`ディレクトリ

export const dynamicParams = true;

export async function generateStaticParams() {
  return [...]
}

async function getPost(params) {
  ...
}

export default async function Post({ params }) {
  const post = await getPost(params);

  return ...
}

dynamicParamsがtrue（デフォルト）に設定されている場合、まだ生成されていないルートセグメントが要求された場合、それはサーバーレンダリングされてキャッシュされます。

インクリメンタル・スタティック・リジェネレーション（`getStaticProps`と`revalidate`）

pagesディレクトリでは、getStaticProps関数を使用して、一定期間後に自動的にページを再生成します。

pages/index.js
// `pages`ディレクトリ

export async function getStaticProps() {
  const res = await fetch(`https://.../posts`)
  const posts = await res.json()

  return {
    props: { posts },
    revalidate: 60,
  }
}

export default function Index({ posts }) {
  return (
    <Layout>
      <PostList posts={posts} />
    </Layout>
  )
}

appディレクトリでは、fetch()によるデータ取得でrevalidateを使用できます。これにより、リクエストが指定された秒数間キャッシュされます。

app/page.js
// `app`ディレクトリ

async function getPosts() {
  const res = await fetch(`https://.../posts`, { next: { revalidate: 60 } })
  const data = await res.json()

  return data.posts
}

export default async function PostList() {
  const posts = await getPosts()

  return posts.map((post) => <div>{post.name}</div>)
}

APIルート

APIルートはpages/apiディレクトリで変更なく動作しますが、appディレクトリではRoute Handlerに置き換えられました。

Route Handlersを使用して、Web RequestおよびResponse APIを使用して特定のルートのカスタムリクエストハンドラを作成できます。

TypeScript
JavaScript

app/api/route.ts
export async function GET(request: Request) {}

app/api/route.js
export async function GET(request) {}

Good to know: 以前にクライアントから外部APIを呼び出すためにAPIルートを使用していた場合、代わりにServer Componentsを使用してデータを安全に取得できます。データ取得についてもっと知る。

ステップ7：スタイリング

pagesディレクトリでは、グローバルスタイルシートはpages/_app.jsにのみ制限されています。appディレクトリでは、この制限が解除されました。グローバルスタイルは、どのレイアウト、ページ、またはコンポーネントにも追加できます。

Tailwind CSS

Tailwind CSSを使用している場合、tailwind.config.jsファイルにappディレクトリを追加する必要があります：

tailwind.config.js
module.exports = {
  content: [
    './app/**/*.{js,ts,jsx,tsx,mdx}', // <-- ここを追加
    './pages/**/*.{js,ts,jsx,tsx,mdx}',
    './components/**/*.{js,ts,jsx,tsx,mdx}',
  ],
}

また、グローバルスタイルをapp/layout.jsファイルにインポートする必要があります：

app/layout.js
import '../styles/globals.css'

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

Tailwind CSSでのスタイリングについてもっと学ぶ

Codemods

Next.jsは、機能が廃止されたときにコードベースをアップグレードするのに役立つCodemod変換を提供します。詳細はCodemodsを参照してください。

アップグレード​

Node.jsのバージョン​

Next.jsのバージョン​

ESLintのバージョン​

次のステップ​

新機能のアップグレード​

<Image/> コンポーネント​

<Link> コンポーネント​

<Script> コンポーネント​

フォント最適化​

pagesからappへの移行​

ステップ1：appディレクトリの作成​

ステップ2：Root レイアウトの作成​

_document.js および _app.js の移行​

getLayout() パターンからレイアウトへの移行（任意）​

ステップ3：next/headの移行​

ステップ4：ページの移行​

ステップ5：ルーティングフックの移行​

pagesとappの間でのコンポーネント共有​

ステップ6：データ取得方法の移行​

サーバーサイドレンダリング（getServerSideProps）​

リクエストオブジェクトへのアクセス​

静的サイト生成（getStaticProps）​

動的パス（getStaticPaths）​

fallbackの置き換え​

インクリメンタル・スタティック・リジェネレーション（getStaticPropsとrevalidate）​

APIルート​

ステップ7：スタイリング​

Tailwind CSS​

Codemods​