RSCの時代にReactとフレームワークの境界を探る

2025-09-06 フロントエンドカンファレンス北海道2025

Transcript

1. RSCの時代にReactとフレームワーク の境界を探る 2025-09-06 フロントエンドカンファレンス北海道2025
2. 発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート ぎりぎりReactのクラスコンポーネントを 使ったことがある。 2
3. React Server Components (RSC) React 19で安定化されたReactの機能。 従来のコンポーネントよりも前の別段階で レンダリングされる。 別段階は、リクエスト時のサーバー側だったり、 ビルド時だったりする。 3
4. RSCを使う方法 RSCはReact用フレームワークと一緒に使用する。 •Next.js RSC対応の先駆者、webpackベースの重量級 •@lazarv/react-server Viteベースの軽量フレームワーク •React Router これもViteベース（現在はプレビュー機能） •Waku やっぱりViteベースのミニマルなフレームワーク など 4
5. 疑問 フレームワークを介さないと使えないのに、 RSCは本当にReactの機能なの？ フレームワークとRSCの境界はどこにあるの？ 5
6. 答え① 複数の異なるフレームワークで利用できるのは、 RSCがReact本体の機能だからですよね。 でも、 RSCのやりたいことを実現するために フレームワークの助けが必要だから こうなっています。 6
7. This Talk RSCのやりたいこととはどのようなことで、 フレームワークがそれをどう助けているのかを 解説します。 7
8. でもフレームワーク無しで RSCを動かす 8
9. フレームワーク無しでRSCを動かす RSCを“動かす”だけなら、フレームワーク無しで できる。 しかし、我々が良く知るRSCとは別物になる。 ←このZenn本で詳しく解説しています 9
10. 我々が良く知るRSC 10 import { Client } from “./client.tsx”; export const SC = () => { return ( <div> <Client /> </div> ); }; server.tsx “use client”; export const Client = () => { return ( <p>client!</p> ); }; client.tsx import サーバーからクライアントをimportしてコンポーネントを使用できる。
11. フレームワーク無しのRSC 11 const Client = { /* 省略 */ }; export const SC = () => { return ( <div> <Client /> </div> ); }; server.tsx export const Client = () => { return ( <p>client!</p> ); }; client.tsx 独立 サーバーとクライアントは独立した、別々のプログラムになる。
12. フレームワーク無しのRSC 12 const Client = { /* 省略 */ }; export const SC = () => { return ( <div> <Client /> </div> ); }; server.tsx server.tsxはサーバー側用のReactランタイムで 実行。Clientはサーバー側でレンダリングしない。 Clientは「Clientというコンポーネント」の ままクライアント側に送られる。 クライアント側がClientのレンダリングを 担当。
13. フレームワーク無しのRSC 13 export const Client = () => { return ( <p>client!</p> ); }; client.tsx client.tsxはクライアント用のReactランタイムで 実行。 SC部分がただのHTMLとなった状態で クライアント側のランタイムに渡される。 こちらはClientの定義を知っており、 Clientをレンダリングできる。
14. フレームワーク無しのRSCの問題 14 const Client = { /* 省略 */ }; export const SC = () => { return ( <div> <Client /> </div> ); }; server.tsx export const Client = () => { return ( <p>client!</p> ); }; client.tsx 別々のプログラムで2つの定義を同期させる必要がある。非常にDX悪い。
15. フレームワークがやっている こと 15
16. RSCでフレームワークがやっていること importでサーバーとクライアントが繋がった Reactプログラムを、 「サーバー側用」と「クライアント用」の 2つの別々のプログラムへとビルドする。 ビルド サーバー 用 クライ アント用
17. RSCでフレームワークがやっていること このようなビルド工程はバンドラがやっている ことの応用である。 そのため、フレームワークでも、RSC対応の根本 部分はバンドラのプラグインとして実装される。 17
18. Reactフレームワークの構造 18 サーバー用 Reactランタイム クライアント用 Reactランタイム Reactの機能 バンドラの機能 RSC規約に従った サーバー・クライアント分割 及びビルド フレームワーク の個性 ルーティング キャッシュ 最適化 など バンドラプラグイン
19. RSC規約とは “use client” でクライアントの世界への入り口を 示すのがRSCの規約。 Reactフレームワークは同じRSC規約をサポート している。 サーバーとクライアントを「1つのプログラム」に 統合するために必要。 19
20. RSC規約とバンドラの関係 “use client” のようなディレクティブは、 JavaScriptの言語仕様上は意味のない記述。 （”use strict”だけは例外） よって、RSCをサポートするためには バンドラのようなビルドツールが必須。 20
21. バンドラプラグインの実装 RSC規約に基づいた変換例を見てみよう。 今回は @vitejs/plugin-rsc を対象にする。 21 ビルド サーバー 用 クライ アント用
22. サーバー用のビルド方法 サーバー用モジュールからクライアント用ファイ ルをimportする際に、クライアント用モジュール をスタブ的なものに置き換える。 22 置き換え 本当のクライア ント用コードと 切り離される
23. 置き換えの実例 置き換え前（実際のクライアント用モジュール） 'use client'; export function Greet({ name }: { name: string }) { return <>Hello {name}</>; } 23 Waku v0.25.0 のソースコードから一部改変して引用（次のスライドも同じ） https://github.com/wakujs/waku/blob/473d481f0d926e05c9b0b8af5d2b777ff47eb70b/packages /waku/tests/vite-plugin-rsc-transform-internals.test.ts
24. 置き換えの実例 置き換え後（サーバー側から見える同モジュール） import { registerClientReference } from 'react-server-dom-webpack/server.edge’; export const Greet = registerClientReference(()=>{ throw new Error('It is not possible to invoke a client function from the server: /src/App.tsx#Greet'); }, '/src/App.tsx', 'Greet'); 24
25. 置き換えで何をやっているか 実際のクライアント側モジュールでexportされていた ものに対応するクライアントへの参照を、React本体の 機能として用意されているregisterClientReferenceを 使って用意している。 （クライアントへの参照の実態はファイル名とexport名） 25 本物ではなく参照
26. 置き換えによるRSCの動作 Reactのサーバー側ランタイムは クライアントへの参照を認識し、残したままで レンダリングを行う。 クライアント側では、残された参照を解決することが でき、レンダリングの続きを行うことができる。 26
27. バンドラプラグインの実装 @vitejs/plugin-rscのソースコードを見る。 Wakuからも使用されている、Vite公式のRSC用 プラグイン。 引用元: https://github.com/vitejs/vite-plugin- react/blob/b81bf6ac8a273855c5e9f39d71a32d76fd31b61c/packages/plugin-rsc/src/plugin.ts 27
28. バンドラプラグインの実装① { name: 'rsc:use-client', async transform(code, id) { /* 中略 */ const ast = await parseAstAsync(code) if (!hasDirective(ast.body, 'use client')) { delete manager.clientReferenceMetaMap[id] return } /* 以下略 */ 28 ‘use client’ を持つ ファイルが変換対象
29. バンドラプラグインの実装② const result = transformDirectiveProxyExport_(ast, { /* 省略 */ runtime: (name, meta) => { let proxyValue = /* 省略 */ return ( `$$ReactServer.registerClientReference(` + ` ${proxyValue},` + ` ${JSON.stringify(referenceKey)},` + ` ${JSON.stringify(name)})` ) }, 29 各exportを registerClientRefere nce呼び出しに変換
30. 実装を見て分かったこと プラグインは、“use client”を頼りに クライアントモジュールをサーバー向けに変換し、 サーバー用のビルドを行う。 バンドラはサーバーとクライアントの境目だけ変換 すればいいため、バンドラに寄り添った規約に なっている。 （実際は開発サーバーとか色々考慮して変換している） 30
31. 気になる人は 探せば“use server”に関連した変換などもある。 実装の側からRSCについて理解したい人は、 プラグインの実装を読んでみよう。 31
32. 結局、Reactとフレーム ワークの境目はどこ？ 32
33. 疑問（再掲） フレームワークを介さないと使えないのに、 RSCは本当にReactの機能なの？ フレームワークとRSCの境界はどこにあるの？ 33
34. Reactフレームワークの構造（再掲） 34 サーバー用 Reactランタイム クライアント用 Reactランタイム Reactの機能 バンドラの機能 RSC規約に従った サーバー・クライアント分割 及びビルド フレームワーク の個性 ルーティング キャッシュ 最適化 など バンドラプラグイン
35. 答え②: 境目はこんな感じ 35 サーバー用 Reactランタイム クライアント用 Reactランタイム Reactの機能 バンドラの機能 サーバー・クライアント分割とビルド RSC規約 フレームワーク の個性 ルーティング キャッシュ 最適化 など バンドラプラグイン
36. Reactとフレームワークの境目 Reactは、ランタイムのAPIを提供する。 フレームワークは、ReactのAPIを使って サーバーとクライアントを実装する。 加えて、ReactはRSC規約を定義する。 その規約を実装するのはフレームワーク。
37. ポイント RSC規約は、定義する主体と実装する主体が 異なる。 React側で規約を定義している理由は、おそらく フレームワークを問わず共通の開発体験を保証 するためだろう。 （同じWeb標準を複数ブラウザが実装しているのに近いかも）
38. まとめ RSCは、”use client”のような規約をReactが 規定しフレームワークが実装している。 実際に、Next.js、@vitejs/plugin-rsc、 @lazarv/react-serverなどがRSC規約を実装し、 RSCをサポートしている。 RSC規約は通常、バンドラプラグインとして実装 される。 38