React Server Components

目次

• 使用すべき場合
• 使用してはいけない場合
• 手順
• 詳細
• ソース

React の Server Components は、サーバー駆動のメンタルモデルで最新の UX を実現します。これはコンポーネントのサーバーサイドレンダリング (SSR) とは大きく異なり、クライアント側の JavaScript バンドルを大幅に削減できます。

使用すべき場合

• サーバー上でデータ取得とレンダリングを実行して、クライアント側の JavaScript を削減したい場合に使用します
• Next.js 13+ App Router で、ゼロ JS コストのサーバーレンダリングコンポーネントにより、パフォーマンスを向上させるのに役立ちます

使用してはいけない場合

• コンポーネントがクライアント側のインタラクティビティが必要な場合 — 状態 (useState)、エフェクト (useEffect)、イベントハンドラーは Client Component が必要です
• ブラウザのみの API に依存するコンポーネント (window、localStorage、IntersectionObserver など)
• コンポーネントがすでに小さく、サーバー/クライアント境界が節約より複雑さを追加する場合

手順

• Server Components (Next.js App Router などのフレームワークではデフォルト) をデータ取得と非インタラクティブな UI に使用します
• 'use client' ディレクティブは、インタラクティビティが必要なコンポーネント (イベントハンドラー、状態、エフェクト) にのみ追加します
• Server Components は重いライブラリ (markdown パーサー、日付フォーマッター) をクライアントバンドルのコストなしで使用できます
• Server Components は SSR を補完します — SSR の代替ではありません
• フレームワークがサポートしている場合は、フォーム送信やミューテーションに Server Functions または Server Actions ('use server') を使用します

詳細

更新 (React 19 / 最新フレームワーク): React Server Components は、フレームワークユーザー向けの本番機能になりました。従来の SSR とは異なり、RSC はコンポーネントの JavaScript をクライアントに送信することなく、UI の一部をサーバー上でレンダリングできます。Container/Presentational パターンはここで強力に機能します。「container」はデータをフェッチして、インタラクティブな Client Component に渡す Server Component になります。

Next.js App Router では、getServerSideProps を使用する必要がなくなりました。代わりに、app/ ディレクトリの任意の React コンポーネントを async にしてサーバー上でデータをフェッチできます。React Server Components は SSR の代替ではなく、SSR を補完するものです。通常、ページの大部分に RSC を使用し (SSR の一部としてレンダリングされてストリーミングされ)、インタラクティビティが必要なコンポーネントに 'use client' ディレクティブを追加します。

'use server' ディレクティブは Server Functions または Server Actions 用で、コンポーネントを Server Component としてマークするのではありません。Server Components にはディレクティブがなく、それらをサポートするフレームワークではデフォルトです。'use client' にオプトインしない限り。

React Server Components は、Next.js App Router などのフレームワークで本番対応になりました。以下のリソースが最も有用な開始点です。

• React Server Components リファレンスは、現在最適な概要です。
• RFC は、より深い実装コンテキストに役立ちます。
• Next.js App Router ドキュメントで Server Components への最新のアプローチをご覧ください
• Shopify Hydrogen と Server Components

サーバーサイドレンダリングの制限

現在のクライアント側 JavaScript のサーバーサイドレンダリングは、最適ではない場合があります。コンポーネント用の JavaScript はサーバー上で HTML 文字列にレンダリングされます。この HTML はブラウザに配信され、一見 First Contentful Paint または Largest Contentful Paint が高速に見える場合があります。

ただし、インタラクティビティには JavaScript をフェッチする必要があり、これはしばしばハイドレーションステップで実現されます。サーバーサイドレンダリングは通常、初期ページロードに使用されるため、ハイドレーション後は再び使用される可能性は低いです。

注: サーバーのみの React アプリを構築する際に SSR を活用し、クライアント上でのハイドレーションを完全に回避することは確かに可能ですが、モデルの大きなインタラクティビティにはしばしば React の外に出る必要があります。Server Components が有効にするハイブリッドモデルは、コンポーネントごとにこれを決定できます。

React Server Components を使用すると、コンポーネントを定期的に再フェッチできます。新しいデータがある場合に再レンダリングされるコンポーネントを持つアプリケーションはサーバー上で実行でき、クライアントに送信する必要があるコードを制限します。

Server Components の前に、markdown レンダラーと sanitizer を使用するとバンドルに追加されます。

// Server Components *前*
import marked from "marked"; // 35.9K (11.2K gzipped)
import sanitizeHtml from "sanitize-html"; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* render */);
}

Server Components

React の新しい Server Components はサーバーサイドレンダリングを補完し、JavaScript バンドルに追加する必要なく中間抽象フォーマットへのレンダリングを有効にします。これはサーバーツリーをクライアントツリーとマージしながら状態を失わずに有効にし、より多くのコンポーネントへのスケーリングを可能にします。

Server Components は SSR の代替ではありません。ペアで使用すると、中間フォーマットへの高速レンダリング、その後このサーバーサイドレンダリングインフラストラクチャが HTML へのレンダリングをサポートし、初期ペイントが高速に保つことができます。Server Components が発行するクライアントコンポーネントを SSR し、他のデータ取得メカニズムで SSR が使用されるのと同様です。

ただし、今回は JavaScript バンドルが大幅に小さくなります。初期の探索では、バンドルサイズの wins が重要である可能性が示されていますが (-18-29%)、インフラストラクチャ作業がさらに完了すると、React チームは現実での wins についてより明確な考えを持つでしょう。

import marked from "marked"; // バンドルサイズはゼロ
import sanitizeHtml from "sanitize-html"; // バンドルサイズはゼロ

function NoteWithMarkdown({text}) {
  // 前と同じ
}

自動コード分割

ユーザーが必要な時点で必要なコードのみを提供することは、コード分割を使用してベストプラクティスと見なされてきました。これはアプリをより小さなバンドルに分割し、クライアントに送信する必要があるコード量を減らすことができます。Server Components の前は、React.lazy() を使用して「分割ポイント」を手動で定義するか、routes/pages などの新しいチャンクを作成するためにメタフレームワークによって設定されたヒューリスティックに依存する必要があります。

Server Components の前:

// Server Components *前*
import React from "react";

// これらの 1 つは*クライアント上でレンダリングされると開始します*:
const OldPhotoRenderer = React.lazy(() => import("./OldPhotoRenderer.js"));
const NewPhotoRenderer = React.lazy(() => import("./NewPhotoRenderer.js"));

function Photo(props) {
  // フィーチャーフラグ、ログイン/アウト、コンテンツの種類などで切り替え:
  if (FeatureFlags.useNewPhotoRenderer) {
    return <NewPhotoRenderer {...props} />;
  } else {
    return <PhotoRenderer {...props} />;
  }
}

コード分割の課題の一部は以下の通りです:

• メタフレームワーク (Next.js など) の外では、import ステートメントを動的インポートに置き換えて、この最適化を手動でタックルする必要があります。
• アプリケーションがコンポーネントの読み込みを開始する時期を遅延させ、ユーザーエクスペリエンスに影響を与える可能性があります。

Server Components は、クライアントコンポーネント内のすべての通常のインポートを可能なコード分割ポイントとして扱う自動コード分割を導入します。また、開発者がコンポーネントを選択する時期をより早く (サーバー上で) 選択でき、クライアントがレンダリングプロセスの早い段階で取得できます。

Server Components を使用:

import React from "react";

// これらの 1 つは*レンダリングされてクライアントにストリーミングされると開始します*:
import OldPhotoRenderer from "./OldPhotoRenderer.client.js";
import NewPhotoRenderer from "./NewPhotoRenderer.client.js";

function Photo(props) {
  // フィーチャーフラグ、ログイン/アウト、コンテンツの種類などで切り替え:
  if (FeatureFlags.useNewPhotoRenderer) {
    return <NewPhotoRenderer {...props} />;
  } else {
    return <PhotoRenderer {...props} />;
  }
}

Server Components は Next.js SSR に取って代わるのか?

いいえ。それらはかなり異なります。Server Components の初期導入は、実際には、研究と実験が続く中で、Next.js などのメタフレームワークを通じて実験されます。

Dan Abramov から Next.js SSR と Server Components の違いの概要:

• Server Components のコードはクライアントに配信されません。 React を使用した SSR の多くの実装では、コンポーネントコードはとにかく JavaScript バンドル経由でクライアントに送信されます。これはインタラクティビティを遅延させる可能性があります。
• Server Components はツリーの任意の場所からバックエンドへのアクセスを有効にします。 古い Next.js データ API では、ロジックはしばしば getServerSideProps() などのページレベル関数に住む必要がありました。Server Components を使用すると、データ取得はそれが必要なコンポーネントに近く住むことができます。
• Server Components はクライアント側の状態をツリー内で保持しながら再フェッチできます。 これは、メイントランスポートメカニズムが HTML よりもはるかに豊富であり、サーバーレンダリング部分の再フェッチ (例: 検索結果リスト) がツリー内の状態 (検索入力テキスト、フォーカス、テキスト選択など) を吹き飛ばさないようにできるためです。

Server Components の初期統合作業の一部は webpack プラグイン経由で実行されます:

• すべてのクライアントコンポーネントを特定します
• ID => chunk URL の間にマッピングを作成します
• Node.js ローダーはクライアントコンポーネントへのインポートをこのマップへのリファレンスに置き換えます。
• 一部の作業はより深い統合 (例: Routing などの部分) が必要になります。これが Next.js などのフレームワークで機能させることが貴重になる理由です。

Dan が指摘しているように、この作業の目標の 1 つは、メタフレームワークをはるかに改善できることです。

ソース

• patterns.dev/react/react-server-components

参考資料

• React Server Components リファレンス
• Server Functions リファレンス
• RFC
• Server components デモ