💡

この記事の要点

この記事の重要ポイント

  • 1

    The Pendulum Swings Back

  • 2

    RSC (React Server Components):コンポーネントがサーバーで実行され、HTMLとしてブラウザに飛ぶ。JavaScriptバンドルサイズが劇的に減る

  • 3

    Server Actions:`API Routes` を書く必要はもうない。関数をエクスポートするだけで、型安全なRPCが完成する

  • 4

    React Compiler:`useMemo` や `useCallback` は不要になった。コンパイラが自動で最適化する

  • 5

    Conclusion:SPA (Single Page Application) の時代は終わり、MPAとSPAの融合(Hybrid)が標準になる

はじめに: “useEffect” を捨てる時

📦
📦

クライアントの軽量化

  • Server Componentsでライブラリをサーバー側に封印

  • JavaScriptバンドルサイズの劇的な削減

Slide 1 of 3Remaining 2

2024年まで、私たちはデータを取得するために useEffect を書き、ローディング状態を管理し、スピナーを回していました。 それは「クライアントが頑張りすぎている」アーキテクチャでした。

React 19は、その仕事をサーバーに返します。 非同期コンポーネント (async function) が標準になり、データフェッチは「関数呼び出し」と同義になりました。

1. Server Components (RSC): ゼロ・バンドルへの挑戦

RSCの最大のメリットは、 「依存ライブラリをクライアントに送らなくていい」 ことです。 例えば、Markdownをパースする巨大なライブラリや、日付フォーマットライブラリ。 これらはサーバーで実行され、結果のHTMLだけがブラウザに届きます。

// サーバーでしか動かないので、fsやdbに直接アクセスできる
import db from "./db";

export default async function Page() {
  const users = await db.query("SELECT * FROM users");
  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

このコードには useEffectuseState もありません。 ただの await です。PHPの時代に戻ったようですが、体験はReactのままです。

2. Server Actions: APIの消滅

フォーム送信のために、わざわざ /api/form といったエンドポイントを作る必要はありません。

// form.tsx
export default function Form() {
  async function submit(formData: FormData) {
    "use server"; // 魔法の言葉
    await db.save(formData);
  }

  return (
    <form action={submit}>
      <button>Save</button>
    </form>
  );
}

この 'use server' ディレクティブだけで、Reactは裏側でAPIエンドポイントを生成し、型安全な通信路を確立します。 Zodなどのバリデーションライブラリと組み合わせれば、堅牢なバックエンドロジックがコンポーネント内に同居します。

3. React Compiler: メモ化地獄からの解放

「ここは再レンダリングされるから useMemo で囲んで…」 そんな不毛なコードレビューは、2026年には存在しません。

React Compiler (旧 React Forget) が、ビルド時に依存関係を解析し、必要な箇所だけを自動的にメモ化します。 エンジニアは「ロジック」を書くことに集中し、「パフォーマンスチューニング」はコンパイラに任せる。 素晴らしい分業です。

4. Comparison: Next.js 16 vs The Rest

React 19の機能をフルに使うには、フレームワークの支援が不可欠です。

項目 Next.js 16 (App Router) React 19 (Pure)
RSC対応 完全対応 (デフォルト) 要独自サーバー実装
Server Actions プログレッシブエンハンスメント 基本機能のみ
学習コスト 高い (独自の概念多い)
エコシステム Vercel最適化 自由

Deep Dive: RSC Transfer Payload の中身

Server Components は HTML ではなく、独自の JSON ライクな形式でクライアントに送られます。これにより、クライアント側の React State を壊さずに DOM を更新できます。

// 簡略化された RSC ペイロードのイメージ
M1:{"id":"./src/Button.js","name":"Button","chunks":[],"async":false}
J0:["$","div",null,{"className":"container","children":["$","@1",null,{"label":"Click me"}]}]

この形式を理解すると、なぜ「シリアライズできないデータ(関数など)」をサーバーからクライアントに直接渡せないのか、という RSC 特有の制限が腑に落ちるはずです。

結論: エンジニアは「フルスタック」を強制される

Server Componentsの登場により、フロントエンドエンジニアは「サーバー」を意識せざるを得なくなりました。 DBへの接続、キャッシング戦略、セキュリティ(SQLインジェクションなど)。 これらはもはや「バックエンドの仕事」ではありません。

境界線は溶けました。 2026年のReactエンジニアは、必然的にフルスタックエンジニアになります。

関連記事