⛩️

RSCがSPAに与える意味についての考察、Wakuを試してみませんか?

2025/01/13に公開

こんにちは、Wakuの作者です。RSCのためのReactフレームワークであるWakuですが、SPAもサポートしたいと思っています。RSCとSPAに関して思ったことを雑多ですが記事にしたので、よろしければご覧ください。

https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/

以下、ChatGPTによる翻訳です。


はじめに

RSCはReact Server Componentの略ですが、この投稿では以下の2つの主要な要素を含む広義のアーキテクチャとしてRSCを使用します。

  • コア機能:Reactコンポーネントやその他の値をシリアライズおよびデシリアライズする能力。
  • コア機能に基づくベストプラクティス:まだ探索の余地があると感じています。

SPA(Single Page Application)は、静的ファイルとしてデプロイされることが多いです。別のサーバーが存在する場合もありますが、それは通常SPA自体を提供するためのものではありません。この文脈では、SPAには複数のページが含まれることがありますが、その厳密な定義についてはここでは議論しません。

名前が示すように、RSCは通常ランタイムサーバーを必要とし、サーバーがある方が強力です。しかし、「RSCはサーバーなしでも使える」とよく言われます。

この記事では、このトピックについてのランダムで簡潔な考察を共有したいと思います。

議論を絞るために、SSR(サーバーサイドレンダリング)を範囲外とします。SSRはランタイムサーバーやビルド時にHTMLを生成する機能を追加するものであり、どちらにしても価値のある追加機能の一つに過ぎません。

RSCはSPAsにすぐにどのような利点をもたらすか?

ランタイムサーバーがなくても、RSCはSPAに特定の利点を提供します。

ランタイムサーバーがない場合、RSCの利点はなさそうに思えます。しかし、もしJSバンドルサイズを減らしたい場合、RSCのシリアライズ機能はSPAにメリットをもたらします。コンポーネントツリーの一部がある程度静的である場合、ビルド時にコンポーネントをレンダリングし、それらをシリアライズできます。

RSCのペイロードはテキストであり、静的ファイルとして提供可能です。RSCペイロードを生成するためのJSコードを送信する必要はありません。例えば、Markdownレンダラーをビルド時に実行し、クライアントでMarkdownをレンダリングする必要がなければ、JSバンドルにMarkdownレンダラーを含める必要はありません。

RSCペイロードの静的ファイルは最初にロードされる必要はありません。SPAsはJSバンドルを遅延ロードするように、これらをオンデマンドでフェッチできます。つまり、クライアントの作業の一部をビルドプロセスにオフロードできるということです。

この文脈では、SPAsは必ずしも「クライアントファースト」を意味しません。コンポーネントツリーは「サーバーファースト」であり、その上でクライアントコンポーネントを追加します。アプリが主にクライアントコンポーネントで構築されている場合でも、サーバーコンポーネントとクライアントコンポーネントを混在させることができます。

私の考えでは一つの欠点は、メンタルシフトです。サーバーコンポーネントとクライアントコンポーネントのどちらにするかを考える必要があります。純粋なSPAではそのような心配は不要です。これはトレードオフと言えます。

SPA向けのAPIサーバーがある場合、RSCは何ができるか?

SPAにAPIサーバーがあれば、RSCを使用できます。通常、APIレスポンスにはJSONを使用しますが、これをRSCペイロードに置き換えることが可能です。

JSONの代わりにRSCペイロードを使用するメリットは以下の通りです:

  • データに加えてレンダリング済みのコンポーネントを送信できる:これにより、コンポーネントをレンダリングするためのJSバンドルを送信する必要がなくなります。
  • データをストリーミングできる:データをチャンクごとに時間をかけて送信し、ユーザーは到着次第それを確認できます。
  • データフォーマットを定義する必要がない:RSCペイロードはクライアント側でそのままレンダリング可能です。

基本的には、これはReact用の別のワイヤプロトコルと言えます。通常、"use server"ディレクティブを使用します。これにより、サーバーとのシームレスな統合が可能になり、型チェックにも役立ちます。

その他のポイント

ルーターライブラリは、RSCの機能を統合する上で重要な役割を果たします。これらはユーザー向けAPIを提供し、RSCの複雑さを隠します。必ずしもルーターである必要はありません。RSCの複雑さを隠すための別のライブラリがあっても良いのですが、現時点ではルーターが最も一般的なライブラリのようです。

締めくくり

これらは、RSCがSPAにどのように役立つかについての私の初期の考えでした。このトピックにはもっと発見があるでしょうし、実際の動作例とともに再訪するべきかもしれません。Wakuを使えば、RSCを静的サイトで使用する例を作成できます。実際にどのように機能するか興味がある方は、ぜひ試してみてください。

Discussion