Reactサーバーコンポーネント入門

以前、ユーザーがReactアプリケーションにアクセスすると、サーバーは1つ以上のJavaScriptファイルを含む空のHTMLファイルを返していました。ブラウザはHTMLを解析し、JavaScriptファイルをダウンロードしてクライアント側でWebページをレンダリングしていました。

Reactサーバーコンポーネント（RSC）の登場により、Reactの範囲が広がりました。名前が示すように、ReactサーバーコンポーネントはReactのサーバー側のコンポーネントです。これらはサーバー上でのみ実行され、サーバー側のメソッドを呼び出し、データベースにアクセスできます。各事前レンダリング後、RSCはHTMLをクライアントに送信し、クライアントはそれをハイドレートして正式にレンダリングします。このアプローチの利点は、元々クライアント側のJavaScriptファイルにパッケージ化されていたコードの一部をサーバー上で実行できるため、クライアント側の負担が軽減され、アプリケーション全体のパフォーマンスと応答速度が向上することです。

「サーバーリソースを最大限に活用する」ことが、RSCのリリースにおける最大の動機です。言い換えれば、インタラクションを必要としないものはすべてサーバーに配置する必要があります。Reactの公式は、非常に典型的な例、つまりmarkdownコンテンツのレンダリングを提供しました。

クライアント側コンポーネントのレンダリング

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

この例では、クライアント側コンポーネントでレンダリングする場合、クライアントはコンテンツをレンダリングするために少なくとも200kを超えるファイルをダウンロードする必要があります。ただし、ここでのmarkdownコンテンツは実際にはインタラクションを必要とせず、ユーザー操作によって情報の更新が必要になることもありません。これは、RSCを使用するというコンセプトに非常に合致しています。RSCを使用する場合：

サーバー側コンポーネントのレンダリング

import marked from'marked'; // パッケージサイズはゼロ
import sanitizeHtml from'sanitize-html'; // パッケージサイズはゼロ

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

依存関係パッケージはサーバーに配置され、サーバーはユーザーが見る必要のあるコンテンツのみを返します。クライアント側のパッケージは突然200k以上削減されます。

ここまでは、コミュニティの主流の意見は肯定的でしたが、Next.jsがRSCの特性に基づいて積極的に進出し、その後意見の相違が生じました。

コミュニティの意見の相違

意見の相違の最も根本的な理由は、Reactがサーバー側の概念を導入したことです。サーバー側コンポーネントとクライアント側コンポーネントには明らかな違いがあります。

サーバー側コンポーネントは、useStateやuseEffectなどのReactフックを使用できません。クライアント側コンポーネントは使用できます。
サーバー側コンポーネントは、ブラウザAPIにアクセスできません。クライアント側コンポーネントは、完全なブラウザAPI権限を持っています。
サーバー側は、サーバー側プログラムとAPIに直接アクセスする権利を持っています。一方、クライアント側コンポーネントは、リクエストを通じて一部のプログラムにのみアクセスできます。

Next.js v13およびv14のリリースに伴い、ReactのカナリアバージョンであるRSCがNext.jsによって本番環境に移行されました。「use client」と「use server」がますます多くの人々に議論されています。開発者は、現在「2つのReact」があると述べており、コミュニティはReactが長年にわたって進歩したのか後退したのかについて議論を開始しました。

コミュニティの反対意見

有名なソフトウェアエンジニア、Cassidy Williams

彼女は、過去2年間のReactの開発に関する問題を指摘しました。

「2つのReact」によってもたらされた新しい概念は、ほとんどの人にとって明確で理解しやすい知識ではありません。この分割は、さらなる混乱と学習障壁につながる可能性があります。
2022年6月以降、Reactは新しいリリースがないだけでなく、開発者に上位レイヤーフレームワークの使用を推奨しました。これらの上位レイヤーフレームワークは、RSCが安定バージョンにアップグレードされるのを待たずに、RSCに基づいて機能をリリースしました（ほぼNext.jsを名指ししています）。
近年、Reactのメンバーの一部が他の上位レイヤーフレームワークのチームに加わりました。彼らはバージョンの更新を怠っただけでなく、ドキュメントの更新も怠りました。

React Queryの開発者、Tanner Linsley

彼はまた、Reactの開発に対する懸念と不満を表明しました。

ReactがフックとサスペンスAPIを導入して以来、Reactはいくつかの概念に過度に焦点を当てています。これらの新しい概念は、技術的にはシングルスレッドUI APIの制限と境界を押し広げますが、ユーザーに価値を提供するという彼の日常業務にはほとんど影響を与えません。
RSCのリリースから判断すると、Reactチームはクライアント側のパフォーマンスをそれほど強く追求していません。

地図技術と可視化技術の専門家、Tom MacWright

彼は、Reactエコシステムの断片化を批判しました。

現在、Reactの更新は遅いです。代わりに、2つの上位レイヤーフレームワーク、Remix（Shopifyが出資）とNext.js（Vercelが出資）が激しい競争を繰り広げています。
ReactチームとNext.jsチームの間の重複が大きすぎるため、Vercelが主導的な優位性を持っています。Remixなど、VercelおよびFacebookエコシステムに属さない他のフレームワークは、Reactで修正されたがリリースされていないバグの影響を受けます。

コミュニティの肯定的な態度

コミュニティの反対意見が増加する中で、Reactの主要な貢献者であるDan Abramovも何度か意見を表明しました。彼は技術的な変化に対してオープンな姿勢を持っています。

Next.jsのApp Routerには大きな野心がありますが、まだ開発の初期段階にあり、将来より優れたものになるように反復されます。
クライアント側コンポーネントの仕事はUI = f(state)であり、サーバー側コンポーネントの仕事はUI = f(data)です。Reactは、両方の利点を組み合わせてUI = f(data, state)を実現したいと考えています。彼は、コミュニティにこの目標の実現を共同で推進するよう呼びかけました。
Next.jsがRSCを本番バージョンにリリースしたことについて、Danは「本番対応」は主観的な判断であると考えています。 RSCはまだカナリアバージョンですが、Facebookはすでに広範囲に使用しています。彼は、実践での検証がテクノロジーをより迅速に改善し、最終的に成熟と安定を実現できると信じています。
新しいテクノロジーの開発は、継続的なテスト、フィードバック、反復を含む漸進的なプロセスです。コミュニティの力は非常に重要です。

全体として、Danは、誰もが偏見を捨て、実践でReactの次の段階の変革を共同で模索することを望んでいます。

結論

RSCは、最新のWebアプリケーション開発を強化する上で間違いなくプラスの意義を持っています。最も明白な利点は、大規模アプリケーションのパフォーマンスを向上させ、クライアント側の負荷を軽減し、データ取得プロセスを最適化できることです。これらのタスクをRSCを通じて完了することは、以前のSSRソリューションよりも便利です。

Node v20のリリースとRSCの適用により、フロントエンドとサーバー側の距離がさらに縮まりました。フロントエンドの「バックエンド化」、つまりフロントエンドエンジニアが、データクエリの最適化、サーバーリソースの管理など、従来バックエンドに属していた作業をより多く処理するのを目撃する機会があります。これは実際にはフロントエンドエンジニアの扉を開き、Web全体を包括的に習得する機会を与えてくれます。