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?

@fd_ai_teacher

Next.js App RouterでハマったRSCの罠！ハイドレーションエラーとデータフェッチ戦略

0
Posted at

多くのNext.js開発者がApp Routerへの移行で直面するのが、ハイドレーションエラーと、従来のPages Routerとは全く異なるデータフェッチ戦略です。特にReact Server Components (RSC) の登場により、「どこでデータをフェッチし、どこに"use client"を書くべきか」という根本的な設計思想が変わりました。

この記事では、Next.js App RouterとRSC環境下で頻発するハイドレーションエラーの具体的な解決策と、RSCでの最適なデータフェッチ戦略について、コード例を交えながら徹底解説します。これを読めば、App Routerの強力な機能を最大限に活用し、パフォーマンスの高いアプリケーションを構築するためのベストプラクティスが身につきます。

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

このセクションでは、Next.js App Routerの基本的な概念と、RSCが従来のReactコンポーネントとどう異なるのかを理解します。

Next.js 13で導入され、バージョン13.4で安定版となったApp Routerは、Reactの最新機能であるReact Server Components (RSC) を前提としたルーティングシステムです。appディレクトリ内のすべてのコンポーネントは、デフォルトでServer Componentとして扱われます。

React Server Components (RSC) とは？

RSCは、従来のクライアントサイドでレンダリングされるコンポーネントとは異なり、ビルド時またはリクエスト時にサーバー上でレンダリングされる新しいタイプのコンポーネントです。これにより、以下のような大きなメリットがあります。

  • クライアントバンドルサイズの削減: サーバーでレンダリングされるため、クライアントに送信されるJavaScriptの量を劇的に減らせます。
  • 初期ロードパフォーマンスの向上: データフェッチをサーバーで完結させ、HTMLを事前に生成できるため、TTFB (Time To First Byte) が改善されます。
  • データソースへの直接アクセス: サーバー上で実行されるため、データベースやバックエンドAPIに直接アクセスでき、APIルートを介した不要なネットワークホップを削減できます。

一方で、RSCはブラウザ環境に依存する機能（useState, useEffect, windowオブジェクトなど）を使用できません。これらの機能が必要な場合は、明示的にClient Componentとしてマークする必要があります。

"use client" ディレクティブの役割

appディレクトリ内のコンポーネントはデフォルトでRSCですが、インタラクティブな機能やブラウザAPIを使用したい場合は、ファイルの先頭に"use client"ディレクティブを記述して、そのコンポーネントをClient Componentとしてマークします。

// 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>
  );
}

Client Componentは、Server Componentの子として使用できます。この際、Server ComponentはClient Componentの静的なプレースホルダーをレンダリングし、クライアントサイドでそのプレースホルダーがハイドレーションされ、インタラクティブになります。

Next.js App Routerでのハイドレーションエラーの原因と解決策

このセクションでは、Next.js App Routerで頻発するハイドレーションエラーの具体的な原因を特定し、その効果的な回避策をコード例と共に示します。

ハイドレーションエラーは、サーバーで事前レンダリングされたHTMLと、クライアントでハイドレーション時に生成されるDOM構造やコンテンツが一致しない場合に発生します。App RouterのRSCモデルでは、この不一致が起こりやすいため、特に注意が必要です。

よくあるハイドレーションエラーの原因

  1. ブラウザ専用APIの使用:

    • Server Component内でwindow、document、localStorageなどのブラウザ専用APIにアクセスしようとすると、サーバーサイドではこれらのオブジェクトが存在しないため、エラーまたは不一致が発生します。
    • 解決策: ブラウザAPIに依存するロジックは、必ず"use client"ディレクティブを持つClient Component内のuseEffectフック内で使用します。
    // BAD: Server Componentで直接localStorageにアクセス
// app/components/BadComponent.tsx
// const item = localStorage.getItem('theme'); // サーバーでエラー

// GOOD: Client ComponentでuseEffect内でアクセス
// app/components/ThemeSwitcher.tsx
"use client";
import { useState, useEffect } from 'react';

export default function ThemeSwitcher() {
  const [theme, setTheme] = useState('light');

  useEffect(() => {
    // localStorageはクライアントサイドでのみ利用可能
    const storedTheme = localStorage.getItem('theme');
    if (storedTheme) {
      setTheme(storedTheme);
    }
  }, []);

  return (
    <button onClick={() => {
      const newTheme = theme === 'light' ? 'dark' : 'light';
      setTheme(newTheme);
      localStorage.setItem('theme', newTheme);
    }}>
      Switch to {theme === 'light' ? 'Dark' : 'Light'}
    </button>
  );
}

  2. 非決定的な値のレンダリング:

    • Math.random()やDate.now()のような、サーバーとクライアントで異なる結果を返す可能性のある値を直接JSX内で使用すると、DOMの不一致が生じます。
    • 解決策: 非決定的な値は、Client ComponentのuseEffect内で生成するか、サーバーで生成した値をpropsとして渡し、クライアントではその値をそのまま使用するようにします。日付や時刻の表示も、Intl.DateTimeFormatを使用する際は、サーバーとクライアントでロケールやオプションが一貫するように明示的に指定します。
    // BAD: Math.random()を直接使用
// app/page.tsx
// export default function Page() {
//   return <div>Random Number: {Math.random()}</div>; // サーバーとクライアントで値が異なる
// }

// GOOD: クライアントで生成するか、サーバーで確定した値を渡す
// app/page.tsx (Server Component)
import RandomDisplay from './components/RandomDisplay';

export default function Page() {
  const serverRandom = Math.random(); // サーバーで一度だけ生成
  return (
    <div>
      <p>Server-generated Random (fixed): {serverRandom}</p>
      <RandomDisplay /> {/* クライアントで生成するコンポーネント */}
    </div>
  );
}

// app/components/RandomDisplay.tsx (Client Component)
"use client";
import { useState, useEffect } from 'react';

export default function RandomDisplay() {
  const [clientRandom, setClientRandom] = useState(0);

  useEffect(() => {
    setClientRandom(Math.random()); // クライアントで生成
  }, []);

  return <p>Client-generated Random (dynamic): {clientRandom}</p>;
}

  3. 認証状態に基づく条件付きレンダリング:

    • ユーザーの認証状態に基づいてコンテンツを条件付きでレンダリングする場合、初期ロード時にサーバーとクライアントで認証状態の判断が異なるとハイドレーションエラーになります。例えば、サーバーでは認証済みと判断して特定のUIをレンダリングしたが、クライアントではまだ認証トークンが読み込まれておらず未認証と判断する場合などです。
    • 解決策: 認証状態に依存するコンテンツは、Client Component内で遅延レンダリングするか、サーバーとクライアントで初期状態が一致するように工夫します。例えば、認証状態が不明な間はローディングスピナーを表示し、クライアントサイドで認証状態が確定した後にコンテンツを表示します。

  4. 無効なHTMLネスト:

    • HTMLの仕様に反する要素のネスト（例: <p><div></div></p> や <ul><p></p></ul>）もハイドレーションエラーの原因となります。ブラウザは無効なHTMLを自動修正することがありますが、サーバーとクライアントで修正結果が異なると不一致が生じます。
    • 解決策: 常に正しいHTML構造を意識して記述します。開発モードのコンソールやリンターが警告してくれる場合が多いので、それに従います。

ハイドレーションエラーのデバッグ方法

  • 開発モードでの確認: Next.jsは開発モードでハイドレーションエラーが発生すると、詳細な警告メッセージをコンソールに出力します。このメッセージを注意深く読み、どのコンポーネントでどの要素が不一致を起こしているのかを確認します。
  • React DevTools: React DevToolsの「Components」タブで、サーバーとクライアントのDOMツリーを比較し、不一致箇所を特定します。
  • suppressHydrationWarning: これはデバッグ目的以外では推奨されませんが、一時的にハイドレーションエラーを抑制し、原因特定のための手がかりを得るために使用できます。本番環境での使用は避けるべきです。

Next.js App Routerにおける最適なデータフェッチ戦略

このセクションでは、Next.js App Router環境下でのデータフェッチのベストプラクティスと、RSCとClient Component間でのデータ受け渡し方法について解説します。

App Routerでは、データフェッチの主役はServer Componentです。これにより、データソースにより近い場所でデータを取得し、クライアントへのJavaScriptバンドルを最小限に抑えることができます。

Server Componentでのデータフェッチ

Server Componentでは、async/await構文を直接使用してデータをフェッチできます。useEffectやuseStateは不要です。

// app/page.tsx (Server Component)
async function getPosts() {
  // `fetch` APIは自動的にキャッシュされる。
  // `cache: 'no-store'` でSSR (毎回再フェッチ)
  // `next: { revalidate: 60 }` でISR (60秒ごとに再フェッチ)
  const res = await fetch('https://api.example.com/posts', { next: { revalidate: 3600 } }); // 1時間ごとに再フェッチ
  if (!res.ok) {
    throw new Error('Failed to fetch posts');
  }
  return res.json();
}

export default async function Page() {
  const posts = await getPosts(); // サーバーでデータをフェッチ
  return (
    <main>
      <h1>Blog Posts</h1>
      <ul>
        {posts.map((post: any) => (
          <li key={post.id}>
            <h2>{post.title}</h2>
            <p>{post.content}</p>
          </li>
        ))}
      </ul>
    </main>
  );
}

キャッシュ戦略の制御

fetch APIのオプションやNext.jsの再検証API (revalidatePath, revalidateTag) を使うことで、データキャッシュを細かく制御できます。

  • cache: 'no-store': 毎回リクエスト時にデータを再フェッチします (SSR)。
  • next: { revalidate: 60 }: 60秒ごとにデータを再フェッチします (ISR)。
  • revalidatePath('/path'), revalidateTag('tag'): 特定のパスまたはタグに関連するデータを手動で再検証します。これはServer ActionsやRoute Handlerでデータ変更後にキャッシュをクリアする際に特に有用です。

Server ComponentとClient Component間のデータ受け渡し

Server ComponentでフェッチしたデータをClient Componentに渡す場合は、通常のReactのpropsとして渡します。この時、渡すデータはシリアライズ可能な形式である必要があります。DateオブジェクトやMap、Setなどはそのままでは渡せません。

// app/components/PostList.tsx (Client Component)
"use client";

import { useState } from 'react';

interface Post {
  id: number;
  title: string;
  content: string;
}

interface PostListProps {
  initialPosts: Post[];
}

export default function PostList({ initialPosts }: PostListProps) {
  const [posts, setPosts] = useState(initialPosts); // Server Componentから受け取ったデータを初期値に

  // Client Componentでインタラクティブな操作や追加のデータフェッチなど
  const addPost = () => {
    setPosts([...posts, { id: Date.now(), title: 'New Post', content: 'Added from client!' }]);
  };

  return (
    <div>
      <button onClick={addPost}>Add Client Post</button>
      <ul>
        {posts.map(post => (
          <li key={post.id}>
            <h3>{post.title}</h3>
            <p>{post.content}</p>
          </li>
        ))}
      </ul>
    </div>
  );
}

// app/page.tsx (Server Component)
import PostList from './components/PostList';

async function getPosts() {
  const res = await fetch('https://api.example.com/posts');
  if (!res.ok) {
    throw new Error('Failed to fetch posts');
  }
  return res.json();
}

export default async function Page() {
  const posts = await getPosts(); // Server Componentでフェッチ
  return (
    <main>
      <h1>My Blog</h1>
      <PostList initialPosts={posts} /> {/* Client Componentにpropsとして渡す */}
    </main>
  );
}

ウォーターフォール問題の回避とストリーミング

複数のデータをフェッチする場合、awaitを順番に書くとウォーターフォール問題（前のフェッチが終わるまで次のフェッチが始まらない）が発生し、ロード時間が長くなります。Promise.allを使うことで、これらを並行して実行できます。

// app/page.tsx (Server Component)
async function getPosts() { /* ... */ }
async function getUsers() { /* ... */ }

export default async function Page() {
  // Promise.all で並行してデータフェッチ
  const [posts, users] = await Promise.all([getPosts(), getUsers()]);

  return (
    <main>
      <h1>Posts and Users</h1>
      {/* ... レンダリングロジック ... */}
    </main>
  );
}

さらに、Next.js App RouterはReactのSuspenseとストリーミングをサポートしています。loading.tsxファイルやSuspense境界を組み合わせることで、データフェッチ中でもUIの重要な部分をすぐに表示し、ユーザー体験を向上させることができます。

// app/dashboard/loading.tsx (自動的にSuspense境界として機能)
export default function Loading() {
  return <p>Loading dashboard data...</p>;
}

// app/dashboard/page.tsx (Server Component)
import { Suspense } from 'react';
import PostsSection from './PostsSection';
import UsersSection from './PostsSection';

export default async function DashboardPage() {
  return (
    <main>
      <h1>Dashboard</h1>
      {/* それぞれのセクションがデータをフェッチする間、Fallbackが表示される */}
      <Suspense fallback={<p>Loading posts...</p>}>
        <PostsSection />
      </Suspense>
      <Suspense fallback={<p>Loading users...</p>}>
        <UsersSection />
      </Suspense>
    </main>
  );
}

// app/dashboard/PostsSection.tsx (Server Component)
async function getPosts() { /* ... */ }
export default async function PostsSection() {
  const posts = await getPosts();
  return (
    <section>
      <h2>Posts</h2>
      {/* ... posts の表示 ... */}
    </section>
  );
}

Server Actionsの活用とキャッシュ無効化

このセクションでは、Next.js 14で安定版となったServer Actionsの具体的な使い方と、データ変更後のキャッシュ無効化について解説します。

Server Actionsは、クライアントサイドのJavaScriptを記述することなく、フォームの送信やデータ変更などのサーバーサイドのロジックを直接呼び出すことができる強力な機能です。従来のAPIルート (pages/api や app/api) の多くのユースケースを置き換えることができます。

"use server" ディレクティブ

Server Actionsは、ファイルの先頭に"use server"ディレクティブを記述した非同期関数です。

// app/actions.ts
"use server";

import { revalidatePath } from 'next/cache'; // キャッシュ無効化のためのAPI

export async function createTodo(formData: FormData) {
  const todoContent = formData.get('todo');
  if (!todoContent || typeof todoContent !== 'string') {
    return { success: false, message: 'Todo content is required.' };
  }

  // ここでデータベースにtodoを保存するロジックを記述
  // 例: await db.todo.create({ data: { content: todoContent } });
  console.log('Server Action: Creating todo', todoContent);

  // データベース保存後、特定のパスのキャッシュを無効化して再フェッチを促す
  revalidatePath('/'); // ルートパスのデータを再検証
  // revalidateTag('todos'); // 特定のタグが付けられたデータを再検証することも可能

  return { success: true, message: `Todo "${todoContent}" created.` };
}

フォームからのServer Actionsの呼び出し

Server Actionsは、HTMLの<form>要素のactionプロパティに直接渡すことができます。これにより、クライアントサイドのJavaScriptなしで、フォームデータがサーバーに送信され、指定されたServer Actionが実行されます。

// app/page.tsx (Server Component)
import { createTodo } from './actions';

export default function Page() {
  return (
    <main>
      <h1>Todo App</h1>
      <form action={createTodo}> {/* Server Actionを直接指定 */}
        <input type="text" name="todo" placeholder="Add a new todo" required />
        <button type="submit">Add Todo</button>
      </form>
      {/* ここにtodoリストを表示するServer Componentを配置 */}
    </main>
  );
}

Client ComponentからServer Actionを呼び出すことも可能です。その場合は、startTransitionやuseFormStatusなどのReact Hooksを利用します。

キャッシュの無効化 (revalidatePath, revalidateTag)

Server Actionsでデータを変更した後、Next.jsのキャッシュを適切に無効化することが非常に重要です。そうしないと、ユーザーは古いデータを見続けることになります。

  • revalidatePath(path: string): 指定されたパスのデータを再検証します。そのパスがレンダリングするすべてのServer Componentのデータが再フェッチされます。
  • revalidateTag(tag: string): fetch APIにnext: { tags: ['my-tag'] }オプションを付けてフェッチしたデータのうち、指定されたタグを持つものだけを再検証します。よりきめ細やかなキャッシュ制御が可能です。

適切なキャッシュ無効化戦略を適用することで、データの鮮度とパフォーマンスを両立させることができます。

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

このセクションでは、Next.js App RouterとRSCを最大限に活用するための設計原則と、一般的な落とし穴を避けるためのベストプラクティスをまとめます。

1. Server-Firstの原則

  • ベストプラクティス: App Routerでは、すべてのコンポーネントをデフォルトでServer Componentとして扱い、インタラクティブ性が必要な場合にのみ"use client"を使用してClient Componentに切り替えます。これにより、クライアントに送信されるJavaScriptの量を最小限に抑え、初期ロードパフォーマンスを最大化します。
  • トレードオフ: すべてをServer Componentにすると、クライアントサイドのインタラクティブ性が制限されます。Client Componentとの境界を明確にし、必要最小限の範囲で"use client"を使用することが重要です。

2. コンポーネントの境界と責任

  • ベストプラクティス:

    • Server Component: データの読み込み、UIの構成、セキュリティが重要なロジック（APIキーの利用など）を担当します。
    • Client Component: インタラクティブ性、ローカルUIステート、ブラウザAPIの使用を担当します。
    • Client Componentは可能な限りツリーの下位に、リーフノードとして配置し、その親はServer Componentのままに保つようにします。
    • Server Component内でClient Componentを子として使用する場合、childrenプロップを介して渡すことで、Server Componentのレンダリングを最適化できます。
    // app/layout.tsx (Server Component)
import Navbar from './components/Navbar'; // Server Component

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <Navbar /> {/* Server Component */}
        <main>{children}</main> {/* children は Server/Client どちらでもよい */}
      </body>
    </html>
  );
}

// app/components/Navbar.tsx (Server Component)
import ThemeToggle from './ThemeToggle'; // Client Component

export default function Navbar() {
  return (
    <nav>
      <h1>My App</h1>
      <ThemeToggle /> {/* Client Componentを子として使用 */}
    </nav>
  );
}

// app/components/ThemeToggle.tsx (Client Component)
"use client";
import { useState } from 'react';
export default function ThemeToggle() { /* ... */ }

  • トレードオフ: 境界が曖昧になると、意図せずサーバーサイドのコードがクライアントに漏洩したり、ハイドレーションエラーが発生したりするリスクがあります。

3. Route HandlerとServer Componentの使い分け

  • ベストプラクティス:
    • Server Component: データを読み込む際は、Route Handler (APIルート) を介さず、直接Server Component内でfetchまたはデータベースアクセスを行います。これにより、不要なネットワークホップを排除し、パフォーマンスを向上させます。
    • Route Handler: 外部サービスからのWebhook受信、複雑な認証ロジック、クライアントサイドからのデータ変更リクエスト（Server Actionsでは対応できないケース）など、特定のAPIエンドポイントとして機能させたい場合に利用します。
  • トレードオフ: Server Component内で完結できる処理をRoute Handlerにすると、冗長なネットワークリクエストが発生し、パフォーマンスが低下します。

4. 状態管理の考慮

  • ベストプラクティス:

    • App Routerでは、ReduxやZustandなどのクライアントサイドの状態管理ライブラリは、"use client"を持つコンポーネントツリー内で使用します。
    • グローバルなクライアントサイドの状態が必要な場合は、ルートレイアウトのようなServer Component内でClient ComponentのProviderをchildrenとして受け取る形にします。
    // app/providers.tsx
"use client";
import { createContext, useContext, useState } from 'react';

const MyContext = createContext<any>(null);

export function MyProvider({ children }: { children: React.ReactNode }) {
  const [value, setValue] = useState('initial');
  return (
    <MyContext.Provider value={{ value, setValue }}>
      {children}
    </MyContext.Provider>
  );
}

export const useMyContext = () => useContext(MyContext);

// app/layout.tsx (Server Component)
import { MyProvider } from './providers';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <MyProvider> {/* Client Component ProviderがServer Componentのchildrenを受け取る */}
          {children}
        </MyProvider>
      </body>
    </html>
  );
}

  • トレードオフ: クライアントサイドの状態管理ライブラリを多用しすぎると、RSCのメリットであるバンドルサイズの削減効果が薄れる可能性があります。URLの検索パラメータなど、サーバーで読み取れる形で状態を保持することも検討します。

まとめ

Next.js App RouterとReact Server Components (RSC) は、Web開発のパラダイムを大きく変える強力な機能です。

  • App Routerでは、すべてのコンポーネントがデフォルトでServer Componentであり、インタラクティブ性が必要な最小限の範囲で"use client"を使用してClient Componentに切り替える「Server-First」の原則が重要です。
  • ハイドレーションエラーは、サーバーとクライアントでDOM構造やコンテンツが一致しない場合に発生します。特にブラウザAPIの誤用や非決定的な値のレンダリングに注意し、Client Component内でuseEffectを使用するなどの対策が必要です。
  • データフェッチはServer Componentでasync/awaitを直接使用し、fetch APIのキャッシュオプションやrevalidatePath/revalidateTagでキャッシュ戦略を適切に制御することがベストプラクティスです。
  • Server Actionsを活用することで、クライアントサイドJavaScriptなしでサーバーサイドのデータ変更ロジックを実行でき、より効率的なフォーム処理やデータ操作が可能です。

これらの知識を習得し、適切な設計原則に従うことで、Next.js App Routerの真価を引き出し、パフォーマンスが高く、スケーラブルなアプリケーションを構築できるようになります。

さらに深く学びたい場合は、Next.js公式ドキュメントのApp Routerセクションを参照し、特にデータフェッチ、レンダリング、キャッシングの項目を熟読することをお勧めします。

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?