Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RSCの時代にReactとフレームワークの境界を探る
Search
uhyo
September 06, 2025
Technology
13
4k
RSCの時代にReactとフレームワークの境界を探る
2025-09-06 フロントエンドカンファレンス北海道2025
uhyo
September 06, 2025
Tweet
Share
More Decks by uhyo
See All by uhyo
意外と難しいGraphQLのスカラー型
uhyo
5
790
知られざるprops命名の慣習 アクション編
uhyo
12
3.2k
libsyncrpcってなに?
uhyo
0
700
Next.jsと状態管理のプラクティス
uhyo
7
14k
10ヶ月かけてstyled-components v4からv5にアップデートした話
uhyo
5
660
更新系と状態
uhyo
9
3.8k
React 19アップデートのために必要なこと
uhyo
8
2.8k
color-scheme: light dark; を完全に理解する
uhyo
8
740
React 19 + Jotaiを試して気づいた注意点
uhyo
9
3.6k
Other Decks in Technology
See All in Technology
プレーリーカードを活用しよう❗❗デジタル名刺交換からはじまるイベント会場交流のススメ
tsukaman
0
180
Liquid AI Hackathon Tokyo プレゼン資料
aratako
0
110
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
12
81k
Implementing and Evaluating a High-Level Language with WasmGC and the Wasm Component Model: Scala’s Case
tanishiking
0
140
初めてのDatabricks Apps開発
taka_aki
1
150
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
AI時代におけるデータの重要性 ~データマネジメントの第一歩~
ryoichi_ota
0
700
ソフトウェアエンジニアの生成AI活用と、これから
lycorptech_jp
PRO
0
510
Geospatialの世界最前線を探る [2025年版]
dayjournal
1
240
AI Agent Dojo #2 watsonx Orchestrateフローの作成
oniak3ibm
PRO
0
130
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
10
5k
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.8k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
4 Signs Your Business is Dying
shpigford
185
22k
Facilitating Awesome Meetings
lara
56
6.6k
The Invisible Side of Design
smashingmag
302
51k
Why Our Code Smells
bkeepers
PRO
340
57k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Navigating Team Friction
lara
190
15k
Building Applications with DynamoDB
mza
96
6.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
190
55k
Become a Pro
speakerdeck
PRO
29
5.6k
Transcript
RSCの時代にReactとフレームワーク の境界を探る 2025-09-06 フロントエンドカンファレンス北海道2025
発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート ぎりぎりReactのクラスコンポーネントを 使ったことがある。 2
React Server Components (RSC) React 19で安定化されたReactの機能。 従来のコンポーネントよりも前の別段階で レンダリングされる。 別段階は、リクエスト時のサーバー側だったり、 ビルド時だったりする。
3
RSCを使う方法 RSCはReact用フレームワークと一緒に使用する。 •Next.js RSC対応の先駆者、webpackベースの重量級 •@lazarv/react-server Viteベースの軽量フレームワーク •React Router これもViteベース(現在はプレビュー機能) •Waku
やっぱりViteベースのミニマルなフレームワーク など 4
疑問 フレームワークを介さないと使えないのに、 RSCは本当にReactの機能なの? フレームワークとRSCの境界はどこにあるの? 5
答え① 複数の異なるフレームワークで利用できるのは、 RSCがReact本体の機能だからですよね。 でも、 RSCのやりたいことを実現するために フレームワークの助けが必要だから こうなっています。 6
This Talk RSCのやりたいこととはどのようなことで、 フレームワークがそれをどう助けているのかを 解説します。 7
でもフレームワーク無しで RSCを動かす 8
フレームワーク無しでRSCを動かす RSCを“動かす”だけなら、フレームワーク無しで できる。 しかし、我々が良く知るRSCとは別物になる。 ←このZenn本で詳しく解説しています 9
我々が良く知る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してコンポーネントを使用できる。
フレームワーク無しのRSC 11 const Client = { /* 省略 */ };
export const SC = () => { return ( <div> <Client /> </div> ); }; server.tsx export const Client = () => { return ( <p>client!</p> ); }; client.tsx 独立 サーバーとクライアントは独立した、別々のプログラムになる。
フレームワーク無しのRSC 12 const Client = { /* 省略 */ };
export const SC = () => { return ( <div> <Client /> </div> ); }; server.tsx server.tsxはサーバー側用のReactランタイムで 実行。Clientはサーバー側でレンダリングしない。 Clientは「Clientというコンポーネント」の ままクライアント側に送られる。 クライアント側がClientのレンダリングを 担当。
フレームワーク無しのRSC 13 export const Client = () => { return
( <p>client!</p> ); }; client.tsx client.tsxはクライアント用のReactランタイムで 実行。 SC部分がただのHTMLとなった状態で クライアント側のランタイムに渡される。 こちらはClientの定義を知っており、 Clientをレンダリングできる。
フレームワーク無しの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
RSCでフレームワークがやっていること importでサーバーとクライアントが繋がった Reactプログラムを、 「サーバー側用」と「クライアント用」の 2つの別々のプログラムへとビルドする。 ビルド サーバー 用 クライ アント用
RSCでフレームワークがやっていること このようなビルド工程はバンドラがやっている ことの応用である。 そのため、フレームワークでも、RSC対応の根本 部分はバンドラのプラグインとして実装される。 17
Reactフレームワークの構造 18 サーバー用 Reactランタイム クライアント用 Reactランタイム Reactの機能 バンドラの機能 RSC規約に従った サーバー・クライアント分割
及びビルド フレームワーク の個性 ルーティング キャッシュ 最適化 など バンドラプラグイン
RSC規約とは “use client” でクライアントの世界への入り口を 示すのがRSCの規約。 Reactフレームワークは同じRSC規約をサポート している。 サーバーとクライアントを「1つのプログラム」に 統合するために必要。 19
RSC規約とバンドラの関係 “use client” のようなディレクティブは、 JavaScriptの言語仕様上は意味のない記述。 (”use strict”だけは例外) よって、RSCをサポートするためには バンドラのようなビルドツールが必須。 20
バンドラプラグインの実装 RSC規約に基づいた変換例を見てみよう。 今回は @vitejs/plugin-rsc を対象にする。 21 ビルド サーバー 用 クライ
アント用
サーバー用のビルド方法 サーバー用モジュールからクライアント用ファイ ルをimportする際に、クライアント用モジュール をスタブ的なものに置き換える。 22 置き換え 本当のクライア ント用コードと 切り離される
置き換えの実例 置き換え前(実際のクライアント用モジュール) '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
置き換えの実例 置き換え後(サーバー側から見える同モジュール) 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
置き換えで何をやっているか 実際のクライアント側モジュールでexportされていた ものに対応するクライアントへの参照を、React本体の 機能として用意されているregisterClientReferenceを 使って用意している。 (クライアントへの参照の実態はファイル名とexport名) 25 本物ではなく参照
置き換えによるRSCの動作 Reactのサーバー側ランタイムは クライアントへの参照を認識し、残したままで レンダリングを行う。 クライアント側では、残された参照を解決することが でき、レンダリングの続きを行うことができる。 26
バンドラプラグインの実装 @vitejs/plugin-rscのソースコードを見る。 Wakuからも使用されている、Vite公式のRSC用 プラグイン。 引用元: https://github.com/vitejs/vite-plugin- react/blob/b81bf6ac8a273855c5e9f39d71a32d76fd31b61c/packages/plugin-rsc/src/plugin.ts 27
バンドラプラグインの実装① { 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’ を持つ ファイルが変換対象
バンドラプラグインの実装② const result = transformDirectiveProxyExport_(ast, { /* 省略 */ runtime:
(name, meta) => { let proxyValue = /* 省略 */ return ( `$$ReactServer.registerClientReference(` + ` ${proxyValue},` + ` ${JSON.stringify(referenceKey)},` + ` ${JSON.stringify(name)})` ) }, 29 各exportを registerClientRefere nce呼び出しに変換
実装を見て分かったこと プラグインは、“use client”を頼りに クライアントモジュールをサーバー向けに変換し、 サーバー用のビルドを行う。 バンドラはサーバーとクライアントの境目だけ変換 すればいいため、バンドラに寄り添った規約に なっている。 (実際は開発サーバーとか色々考慮して変換している) 30
気になる人は 探せば“use server”に関連した変換などもある。 実装の側からRSCについて理解したい人は、 プラグインの実装を読んでみよう。 31
結局、Reactとフレーム ワークの境目はどこ? 32
疑問(再掲) フレームワークを介さないと使えないのに、 RSCは本当にReactの機能なの? フレームワークとRSCの境界はどこにあるの? 33
Reactフレームワークの構造(再掲) 34 サーバー用 Reactランタイム クライアント用 Reactランタイム Reactの機能 バンドラの機能 RSC規約に従った サーバー・クライアント分割
及びビルド フレームワーク の個性 ルーティング キャッシュ 最適化 など バンドラプラグイン
答え②: 境目はこんな感じ 35 サーバー用 Reactランタイム クライアント用 Reactランタイム Reactの機能 バンドラの機能 サーバー・クライアント分割とビルド
RSC規約 フレームワーク の個性 ルーティング キャッシュ 最適化 など バンドラプラグイン
Reactとフレームワークの境目 Reactは、ランタイムのAPIを提供する。 フレームワークは、ReactのAPIを使って サーバーとクライアントを実装する。 加えて、ReactはRSC規約を定義する。 その規約を実装するのはフレームワーク。
ポイント RSC規約は、定義する主体と実装する主体が 異なる。 React側で規約を定義している理由は、おそらく フレームワークを問わず共通の開発体験を保証 するためだろう。 (同じWeb標準を複数ブラウザが実装しているのに近いかも)
まとめ RSCは、”use client”のような規約をReactが 規定しフレームワークが実装している。 実際に、Next.js、@vitejs/plugin-rsc、 @lazarv/react-serverなどがRSC規約を実装し、 RSCをサポートしている。 RSC規約は通常、バンドラプラグインとして実装 される。 38