0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@DaokFrontier

Next.js App Routerの深層：Server Componentsとキャッシュ戦略を理解する

0
Posted at

多くのNext.js開発者がApp Routerに移行する際、**「Server ComponentsとClient Componentsの使い分けが難しい」「データフェッチのキャッシュが意図通りに効かない、あるいは古くなる」**といった課題に直面します。特に、Next.jsが提供する多層的なキャッシュメカニズムは複雑で、その内部動作を理解せずに利用すると、予期せぬ挙動に悩まされがちです。

この記事では、Next.js App RouterにおけるReact Server Components (RSC) の深層と、データフェッチを最適化するためのキャッシュ戦略について、具体的なコード例と設定を通して解説します。本記事を読めば、RSCとClient Componentsの最適な使い分け、そしてNext.jsの強力なキャッシュ機能を最大限に活用し、パフォーマンスの高いアプリケーションを構築するための実践的な知識が得られます。

App RouterとReact Server Components (RSC) の基本

このセクションでは、Next.js App RouterにおけるReact Server Components (RSC) の基本的な概念と、Client Componentsとの違い、そしてそれぞれの役割について解説します。

Next.js 13以降で導入されたApp Routerは、Reactの最新機能であるServer Componentsをデフォルトで利用します。Server Componentsは、その名の通りサーバーサイドで排他的に実行されるコンポーネントです。これにより、クライアントに送信されるJavaScriptバンドルサイズを大幅に削減し、初期ロードパフォーマンスを向上させることができます。

Server Componentsの特性とClient Componentsとの違い

Server Componentsの主な特性は以下の通りです。

  • サーバー上で実行: クライアントサイドのJavaScriptバンドルに含まれません。
  • データフェッチに最適: データベースアクセスやAPIコールなど、サーバーサイドでのみ実行されるべき処理に適しています。
  • 状態管理・インタラクティブ性なし: useStateやuseEffectなどのReact Hooks、ブラウザAPI（window、documentなど）は使用できません。
  • デフォルトの動作: App Routerでは、特別な指定がない限り、すべてのコンポーネントがServer Componentとして扱われます。

一方、Client Componentsは従来のReactコンポーネントに近い動作をします。

  • クライアント上で実行: クライアントサイドのJavaScriptバンドルに含まれ、ブラウザで実行されます。
  • インタラクティブ性: useStateやuseEffectを使用して状態管理やライフサイクルイベントを扱えます。
  • ブラウザAPIの利用: windowやlocalStorageなどのブラウザAPIにアクセスできます。
  • 明示的な宣言: ファイルの先頭に"use client"ディレクティブを記述することで、Client Componentとしてマークします。

Server ComponentsとClient Componentsの使い分けの原則は、「インタラクティブ性が必要な最小限の部分だけをClient Componentにする」ことです。

// app/page.tsx (Server Componentの例)
// デフォルトでServer Componentとして動作
import Link from 'next/link';
import ProductList from './components/ProductList'; // Server Componentをインポート

export default async function HomePage() {
  // サーバーサイドで直接データをフェッチ
  // const products = await fetchProductsFromDB(); 

  return (
    <div>
      <h1>Next.js App Routerへようこそ！</h1>
      <p>これはServer Componentです。</p>
      {/* 別のServer Componentを内包 */}
      <ProductList /> 
      <Link href="/dashboard">ダッシュボードへ</Link>
    </div>
  );
}

// app/components/Counter.tsx
'use client'; // Client Componentであることを明示

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

Server Componentであるapp/page.tsxから、Client Componentであるapp/components/Counter.tsxを直接インポートして利用することは可能です。しかし、Client ComponentがServer Componentを直接インポートすることはできません。この境界を理解することが、App Routerでの開発において非常に重要です。

Next.jsの多層的なキャッシュ戦略を理解する

このセクションでは、Next.jsが提供する4つの主要なキャッシュメカニズムと、それらがどのように連携してパフォーマンスを向上させるかを掘り下げます。Next.jsのキャッシュは非常に強力であり、適切に理解・制御することでアプリケーションの応答性とスケーラビリティを劇的に改善できます。

Next.jsは、主に以下の4つのキャッシュメカニズムを組み合わせて利用します。

  1. リクエストメモ化 (Request Memoization)
  2. データキャッシュ (Data Cache)
  3. フルルートキャッシュ (Full Route Cache)
  4. ルーターキャッシュ (Router Cache)

1. リクエストメモ化 (Request Memoization)

リクエストメモ化は、単一のReactレンダーパス内で、重複するfetchリクエストを排除する仕組みです。同じURLとオプションを持つfetchが複数回呼び出されても、実際にネットワークリクエストが発行されるのは一度だけになります。これは、Reactのcache関数によって実現されます。

// app/components/ProductList.tsx (Server Component)
import { cache } from 'next/cache'; // next/cacheからcache関数をインポート

interface Product {
  id: string;
  name: string;
}

// cache関数でラップすることで、同一リクエスト内での重複フェッチを防ぐ
const getProducts = cache(async (): Promise<Product[]> => {
  console.log('--- Fetching products from API (Memoized) ---');
  const res = await fetch('https://api.example.com/products');
  if (!res.ok) {
    throw new Error('Failed to fetch products');
  }
  return res.json();
});

export default async function ProductList() {
  const products = await getProducts(); // ここで一度フェッチ
  const anotherProducts = await getProducts(); // ここではネットワークリクエストは発生しない（メモ化）

  return (
    <div>
      <h2>商品リスト</h2>
      <ul>
        {products.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </div>
  );
}

getProducts関数をcacheでラップすることで、同じServer Component内や、同じリクエストツリー内の異なるServer Componentから複数回呼び出されても、実際のAPI呼び出しは一度しか行われません。これは不要なネットワークリクエストを防ぎ、パフォーマンスを向上させます。

2. データキャッシュ (Data Cache)

データキャッシュは、fetch APIを通じて取得されたデータをサーバー上に保存し、ユーザーリクエストやデプロイ間で再利用する仕組みです。これはNext.jsがfetch APIを拡張することで実現されており、cacheオプションやrevalidateオプションでその動作を制御できます。

  • cache: 'force-cache' (デフォルト): 静的なデータに対してキャッシュを強制します。SSG (Static Site Generation) のような動作になります。
  • cache: 'no-store': キャッシュを完全に無効化し、常に最新のデータをフェッチします。SSR (Server-Side Rendering) のような動作になります。
  • next: { revalidate: <seconds> }: 指定された秒数ごとにデータを再検証します。ISR (Incremental Static Regeneration) のような動作になります。
  • next: { tags: [...] }: 特定のキャッシュタグを設定し、後からrevalidateTagでオンデマンドに再検証できます。
// app/blog/[slug]/page.tsx (Server Component)
interface Post {
  id: string;
  title: string;
  content: string;
}

async function getPost(slug: string): Promise<Post> {
  // revalidateオプションでISRのような動作を実現
  // 60秒間はキャッシュを使い、その後はリクエスト時に再検証
  const res = await fetch(`https://api.example.com/posts/${slug}`, {
    next: { revalidate: 60, tags: ['posts', `post-${slug}`] }, 
  });
  if (!res.ok) {
    throw new Error('Failed to fetch post');
  }
  return res.json();
}

export default async function PostPage({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

この例では、getPost関数が60秒ごとに再検証されるように設定されています。また、tagsオプションを使ってpostsとpost-${slug}というタグを付与しており、これらのタグを使って後からオンデマンドでキャッシュを無効化できます。

3. フルルートキャッシュ (Full Route Cache)

フルルートキャッシュは、レンダリングされたHTMLとRSCペイロード（Server Componentsのレンダリング結果）をサーバーにキャッシュする仕組みです。これにより、後続のリクエストに対して、サーバーがコンポーネントを再レンダリングする手間を省き、高速なレスポンスを返します。

このキャッシュは、ルートセグメント設定のdynamicオプションやfetchのrevalidateオプションによって制御されます。

  • dynamic = 'auto' (デフォルト): 動的な関数（cookies(), headers()など）やfetchのcache: 'no-store'、revalidate: 0がない限り、静的にレンダリングされます。
  • dynamic = 'force-dynamic': ルートセグメントを常に動的にレンダリングします。フルルートキャッシュは無効になります。
  • dynamic = 'force-static': ルートセグメントを常に静的にレンダリングします。動的な関数が使われている場合はエラーになります。
// app/products/page.tsx
// このルートはデフォルトでフルルートキャッシュの対象となる
// 動的なデータフェッチがなければ、HTMLとRSCペイロードがキャッシュされる
export default async function ProductsPage() {
  // ... 製品リストの表示ロジック
  return (
    <div>
      <h1>製品一覧</h1>
      {/* ... */}
    </div>
  );
}

// app/admin/users/page.tsx
// フルルートキャッシュを無効にし、常に動的にレンダリングする例
export const dynamic = 'force-dynamic';

export default async function AdminUsersPage() {
  // 常に最新のユーザーリストをフェッチする必要がある場合など
  const users = await fetch('https://api.example.com/admin/users', { cache: 'no-store' }).then(res => res.json());

  return (
    <div>
      <h1>管理者ユーザーリスト</h1>
      <ul>
        {users.map(user => <li key={user.id}>{user.name}</li>)}
      </ul>
    </div>
  );
}

dynamic = 'force-dynamic'を設定すると、そのルートのフルルートキャッシュは完全にスキップされ、常にリクエスト時にHTMLとRSCペイロードが生成されます。これにより、常に最新のコンテンツが表示されるようになりますが、サーバーの負荷は高まります。

4. ルーターキャッシュ (Router Cache)

ルーターキャッシュは、クライアントサイドのキャッシュであり、ユーザーがnext/linkを使ってページ間を移動する際に、RSCペイロードをブラウザに保存します。これにより、同じページに再度アクセスする際のナビゲーションが高速化されます。

  • next/linkがビューポートに入ると、自動的にリンク先のページがプリフェッチされ、ルーターキャッシュに保存されます。
  • このキャッシュはセッションベースまたは時間ベースで、ブラウザを閉じるとクリアされるか、一定時間後に期限切れになります。

このルーターキャッシュは非常に強力ですが、古いデータが表示される「Stale Data」問題の主な原因となることがあります。ユーザーがハードリロード（Ctrl+RやCmd+R）しない限り、キャッシュされたRSCペイロードが使われ続けるためです。

Next.js 16のCache ComponentsとPartial Prerendering (PPR)

このセクションでは、Next.js 16で導入された新しいキャッシュモデルであるCache Componentsと、それを基盤とするPartial Prerendering (PPR) について解説します。これらの機能は、Next.jsのキャッシュ戦略をより明示的かつ強力なものにします。

Next.js 16以降では、next.config.tsでexperimental.cacheComponents: trueを有効にすることで、新しいキャッシュモデルを利用できます。（※バージョンアップに伴いexperimentalから外れる可能性があるので、公式ドキュメントで最新情報を確認してください。）

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  experimental: {
    cacheComponents: true, // Next.js 16以降で利用可能（要確認）
  },
};

export default nextConfig;

Cache Components (use cache)

use cacheディレクティブは、関数レベルでキャッシュを明示的に有効にするための機能です。以前のバージョンではfetchの内部で暗黙的にキャッシュが適用されていましたが、use cacheを使うことでキャッシュの境界とライフサイクルをより細かく制御できるようになります。

next/cacheからインポートされるcache関数を使用して、キャッシュしたい非同期関数をラップします。

// app/dashboard/page.tsx (Server Component)
import { cache } from 'next/cache'; // `next/cache`からcacheをインポート

interface Product {
  id: string;
  name: string;
  price: number;
}

// `cache`でラップすることで、この関数の結果がキャッシュされる
// revalidateとtagsオプションは、関数全体の結果に対するデータキャッシュを制御する
const getProducts = cache(
  async (): Promise<Product[]> => {
    console.log('--- Fetching products from API (Cache Components) ---');
    const res = await fetch('https://api.example.com/products', {
      // `fetch`自身の`cache`オプションは`use cache`と併用しない
    });
    if (!res.ok) {
      throw new Error('Failed to fetch products');
    }
    return res.json();
  },
  {
    tags: ['products'], // キャッシュタグ
    revalidate: 60, // 60秒ごとに再検証
  }
);

export default async function DashboardPage() {
  const products = await getProducts(); // キャッシュされたデータ、または再検証されたデータ

  return (
    <div>
      <h1>商品リスト</h1>
      <ul>
        {products.map((product) => (
          <li key={product.id}>
            {product.name} - ${product.price}
          </li>
        ))}
      </ul>
    </div>
  );
}

use cacheディレクティブ（cache関数）を利用することで、どのデータがどの期間キャッシュされるのかがコード上でより明確になります。これにより、デバッグが容易になり、予期せぬキャッシュ動作を減らすことができます。

Partial Prerendering (PPR)

Partial Prerendering (PPR) は、Cache Componentsが有効なApp Routerのデフォルトのレンダリング動作として実装されます。これは、静的なシェルを事前にレンダリングし、動的な部分をリクエスト時にストリーミングすることで、SSGの高速なTTFB（Time To First Byte）とSSRの鮮度を両立させることを目指します。

具体的には、Server Componentsツリーの中でcache関数でラップされた部分や、fetchリクエストでrevalidateが設定された部分は静的な部分として扱われ、それ以外の動的な部分（cache: 'no-store'やdynamic = 'force-dynamic'が設定された部分）は動的な部分としてストリーミングされます。

これにより、ユーザーはまず静的なページの大部分を素早く受け取り、その後に動的なコンテンツが徐々に表示されるため、知覚的なパフォーマンスが向上します。

PPRは、loading.tsxファイルと組み合わせることで、より良いユーザーエクスペリエンスを提供します。動的な部分がロードされる間、loading.tsxで定義されたUIが表示されます。

キャッシュの再検証 (Cache Invalidation)

このセクションでは、データが更新された際にキャッシュを最新の状態に保つための再検証（Cache Invalidation）戦略について解説します。特に、revalidateTagとrevalidatePathは、オンデマンドでキャッシュを無効化する強力なツールです。

オンデマンド再検証 (revalidateTag, revalidatePath)

データキャッシュやフルルートキャッシュは、設定されたrevalidate秒数に基づいて自動的に再検証されますが、データが更新された直後に最新の情報を表示したい場合があります。このような場合に、revalidateTagやrevalidatePathを使用します。これらのAPIは、Server ActionsやRoute Handlers、または外部のWebhookから呼び出すことができます。

// app/actions.ts (Server Actionの例)
'use server'; // Server Actionであることを明示

import { revalidateTag, revalidatePath } from 'next/cache';

interface UpdateProductParams {
  id: string;
  name: string;
  price: number;
}

export async function updateProduct(params: UpdateProductParams) {
  // データベース更新ロジックをここに記述
  console.log(`Updating product ${params.id} to ${params.name}`);
  // 例: await db.updateProduct(params.id, params.name, params.price);

  // 'products'タグを持つすべてのキャッシュを再検証
  revalidateTag('products'); 
  // 特定の商品詳細ページのキャッシュも再検証
  revalidatePath(`/products/${params.id}`); 
  
  return { success: true, message: `Product ${params.id} updated.` };
}

この例では、商品データが更新された後に、productsというタグが付与されたすべてのデータキャッシュ（getProducts関数など）と、特定の商品詳細ページのフルルートキャッシュを再検証しています。これにより、ユーザーはデータの更新後すぐに最新の情報を閲覧できるようになります。

再検証の戦略

  • 時間ベース (revalidateオプション): 比較的静的なデータや、多少古くなっても問題ないデータに適しています。例えば、ブログ記事の一覧や、あまり頻繁に更新されない製品情報など。
  • オンデマンド (revalidateTag, revalidatePath): リアルタイム性が求められるデータや、ユーザーアクションによって頻繁に更新されるデータに適しています。例えば、ユーザープロファイル、ECサイトの在庫情報、CMSからのコンテンツ更新など。

これらの再検証戦略を適切に組み合わせることで、パフォーマンスとデータの鮮度のバランスを取ることができます。

よくあるハマりどころと回避策

Next.js App Routerとキャッシュ戦略を導入する上で、開発者がつまずきやすいポイントとその解決策をまとめます。

1. 古いデータが表示される (Stale Data)

  • ハマりどころ: データを更新したにもかかわらず、ユーザーの画面に古いコンテンツが表示され続ける問題。特にルーターキャッシュや、revalidateオプションが適切に設定されていないデータキャッシュが原因となることが多いです。
  • 回避策:
    • revalidateオプションの確認: fetchリクエストやcache関数に設定したrevalidate秒数が適切か確認します。動的なコンテンツには短めの秒数、またはrevalidate: 0（常に再検証）を検討します。
    • cache: 'no-store'の活用: 常に最新のデータを表示すべき、ユーザー固有のデータや非常に頻繁に更新されるデータにはfetch(..., { cache: 'no-store' })を使用します。
    • オンデマンド再検証: データ更新をトリガーとするrevalidateTagやrevalidatePathをServer ActionsやAPIルートで呼び出し、必要なキャッシュを即座に無効化します。
    • ルーターキャッシュの理解: クライアントサイドのルーターキャッシュはブラウザを閉じない限り残るため、リアルタイム性が極めて重要な場合は、ユーザーに明示的にリロードを促すか、Router.refresh()などのクライアントサイドのAPIを検討する必要があるかもしれません。

2. Server ComponentとClient Componentの混同

  • ハマりどころ: Server Component内でuseStateやuseEffectを使用しようとしたり、Client Component内でServer Componentのみで利用可能なAPI（headers(), cookies()など）を使用しようとするとエラーになります。また、Client ComponentがServer Componentを直接インポートすることはできません。
  • 回避策:
    • "use client"ディレクティブの徹底: インタラクティブ性が必要な最小限のコンポーネントのみに"use client"を記述します。それ以外はすべてServer Componentであると認識します。
    • Server ComponentからClient Componentへのデータの受け渡し: Server Componentは、Client Componentを子要素またはプロパティとして受け取ることができます。このパターンを利用して、Server ComponentでフェッチしたデータをClient Componentに渡します。 
      // app/page.tsx (Server Component)
import InteractiveComponent from './components/InteractiveComponent';

async function getData() { /* ... */ return { message: 'Hello from Server!' }; }

export default async function HomePage() {
  const data = await getData();
  return (
    <div>
      <InteractiveComponent serverData={data.message} />
    </div>
  );
}

// app/components/InteractiveComponent.tsx
'use client';
import { useState } from 'react';

export default function InteractiveComponent({ serverData }: { serverData: string }) {
  const [clientState, setClientState] = useState(serverData);
  return (
    <div>
      <p>{clientState}</p>
      <button onClick={() => setClientState('Updated on Client!')}>Update</button>
    </div>
  );
}
    • Server Componentの「穴開け」: Client Componentの中にServer Componentを配置したい場合、Client ComponentのchildrenプロパティとしてServer Componentを渡す「穴開け」パターンを使用します。

3. 予期せぬキャッシュ動作とデバッグの難しさ

  • ハマりどころ: Next.jsのキャッシュは多層的で複雑なため、どのキャッシュレイヤーが問題の原因となっているのかを特定するのが難しい場合があります。
  • 回避策:
    • キャッシュレイヤーのメンタルモデル構築: 各キャッシュ（リクエストメモ化、データキャッシュ、フルルートキャッシュ、ルーターキャッシュ）がどこで、どのように機能するかを理解します。
    • デバッグ環境変数の活用: Next.js 16以降では、NEXT_PRIVATE_DEBUG_CACHE=1のような環境変数を設定することで、キャッシュに関する詳細なログを出力できる場合があります。（公式ドキュメントで最新のデバッグ方法を確認してください。）
    • 一時的なキャッシュ無効化: デバッグ目的で、特定のルートのフルルートキャッシュをexport const dynamic = 'force-dynamic';で無効にしたり、データキャッシュをfetch(..., { cache: 'no-store' })で無効にすることで、問題の切り分けを行います。
    • 開発サーバーのリスタート: 開発中にキャッシュの挙動がおかしいと感じたら、開発サーバーを一度再起動することで、多くのキャッシュがクリアされ、最新の状態で動作を確認できます。

設計上のトレードオフとベストプラクティス

このセクションでは、Next.js App Routerとキャッシュ戦略を設計する上でのトレードオフと、推奨されるベストプラクティスについて解説します。

設計上のトレードオフ

  • パフォーマンス vs データの鮮度:
    • キャッシュを積極的に利用すればするほど、初期ロードパフォーマンスは向上しますが、データの鮮度が犠牲になる可能性があります。
    • リアルタイム性が重要なデータにはcache: 'no-store'や短いrevalidate期間、またはオンデマンド再検証を適用し、パフォーマンスと鮮度のバランスを取る必要があります。
  • Server Components vs Client Components:
    • Server Componentsはバンドルサイズを削減し、初期ロードを高速化しますが、インタラクティブ性には制限があります。
    • Client Componentsはインタラクティブ性を提供しますが、クライアントにJavaScriptを送信します。このため、必要最小限に留めることが重要です。
  • ビルド時の静的生成 vs リクエスト時の動的レンダリング:
    • 静的生成（revalidate: false相当）は高速なTTFBを提供しますが、データが古くなる可能性があります。
    • 動的レンダリング（cache: 'no-store'相当）は常に最新のデータを提供できますが、サーバー負荷が増加し、TTFBが遅くなる可能性があります。
    • Partial Prerendering (PPR) はこの両者の良いとこ取りを目指し、静的なシェルを高速に提供しつつ、動的な部分をストリーミングします。

ベストプラクティス

  • Server Componentsをデフォルトで使用する:
    • インタラクティブ性、状態、またはブラウザAPIが必要な場合にのみ'use client'を追加します。これにより、クライアントに送信されるJavaScriptの量を減らし、ロード速度を向上させます。
  • データをコンポーネントの近くでフェッチする (Colocation):
    • Server Componentsでは、データを必要とするコンポーネントの内部またはその近くでデータフェッチを行うことで、保守性と可読性が向上します。
  • Client Componentsは小さく、焦点を絞る:
    • インタラクティブな部分のみをClient Componentsに抽出し、それらをコンポーネントツリーのリーフノード（末端）に配置するようにします。
  • キャッシュ戦略を慎重に設計する:
    • アプリケーションのデータ特性（静的、動的、ユーザー固有など）に基づいて、適切なキャッシュメカニズムと再検証戦略を選択します。
    • Next.js 16以降であれば、next.config.tsでexperimental.cacheComponents: trueを有効にし、use cacheディレクティブとrevalidate/tagsオプションでキャッシュを明示的に制御することを推奨します。
  • loading.tsxとerror.tsxを活用する:
    • Next.jsのファイル規約を利用して、データフェッチ中やエラー発生時に適切なUIを表示し、ユーザーエクスペリエンスを向上させます。
  • next/linkコンポーネントによるプリフェッチを活用する:
    • next/linkは自動的にリンク先のページをプリフェッチし、ルーターキャッシュに保存するため、高速なページ遷移を実現します。
  • Server Actionsをデータミューテーションに利用する:
    • データフェッチではなく、フォーム送信やデータ更新などのPOST操作にはServer Actionsを積極的に利用し、キャッシュの再検証と組み合わせることで、効率的なデータ管理が可能です。

まとめ

本記事では、Next.js App RouterにおけるReact Server Components (RSC) の基本的な概念から、Next.jsが提供する多層的なキャッシュ戦略、そしてNext.js 16で導入されたCache ComponentsとPartial Prerenderingについて詳細に解説しました。

重要なポイントは以下の通りです。

  • Server Componentsはデフォルトであり、データフェッチとパフォーマンス最適化に貢献します。インタラクティブ性が必要な最小限の箇所にのみClient Componentsを使い分けましょう。
  • Next.jsはリクエストメモ化、データキャッシュ、フルルートキャッシュ、ルーターキャッシュの4つのキャッシュメカニズムを組み合わせています。これらを理解することが、予期せぬ挙動を防ぎ、パフォーマンスを最大化する鍵です。
  • fetch APIのrevalidate、cache、tagsオプション、そしてrevalidateTagやrevalidatePathを使って、キャッシュの鮮度を制御しましょう。
  • Next.js 16以降のCache Components (use cache) とPartial Prerendering (PPR) は、より明示的なキャッシュ制御と優れたユーザーエクスペリエンスを提供します。

これらの知識を実践に活かすことで、Next.js App Routerでの開発をより効率的かつ堅牢に進めることができます。詳細なAPIの挙動や最新情報については、必ずNext.js公式ドキュメントをご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?