React Server Componentsについてざっくりと理解するためのメモ。
何が嬉しい技術なのか
bundleのサイズ削減
参考: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#zero-bundle-size-components
- アプリケーションの静的にレンダリングすれば良い部分をサーバー側にやらせることができる(ユーザーのインタラクションによって変化しない部分)
- MarkdownのRenderやDateのフォーマットなどのライブラリは容量が大きくなりがちである→これらのレンダリングをサーバー側にやらせて結果だけをクライアントに返すことで、クライアントサイドではライブラリをダウンロードする必要すらなくなる。
- 「インタラクティブなコンポーネントは従来通りクライアントにやらせて、そうではない静的な部分はサーバーサイドが受け持つ」ということができるのがRSCの新しい部分である(という風に理解した)
React runtime will be loaded, which is cacheable and predictable in size.
(Next.js betaドキュメントより)
アプリケーションの規模が大きくなってもランタイムの大きさは一定、かつキャッシュすることもできる
combining the rich interactivity of client-side apps with the improved performance of traditional server rendering:
(RFCより)
クライアントサイドで動くリッチなインタラクティブ性と昔ながらのサーバーレンダリングによるパフォーマンス向上の両立ができる。
サーバーサイドでのデータフェッチ
参考: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#full-access-to-the-backend
- RSCではHTTP APIだけでなく、ローカルのファイル・非公開のAPI・DBなどあらゆるデータソースを使える
- originに近いところでfetchすることによるパフォーマンス向上も見込める
また、RSCではPromiseを返す関数をコンポーネントとして使えるようになった(参考: RFC)
シンプルに書きやすくて良い。アドベントカレンダーの記事にも書いたが、再帰的に呼び出すコンポーネントとかでめちゃくちゃよかった。
SSRとは違うのか?
目的が違う(と思う)
それぞれの技術の目的を整理すると…
- SSR
- 初期描画を速くする → hydrateの時に、レンダリング済みコンポーネントの実装がダウンロードされる(ので最終的なバンドルサイズの削減が目的ではない)
- JavaScriptが使えない環境(SNSのOGP表示のためのリクエストなど)に向けてレンダリング結果を返す
- RSC
- クライアントサイドにダウンロードされるJSの削減
- サーバーサイドでのレンダリングによるパフォーマンスの向上
RSC自体はSSRとの組み合わせはマストではない。
Next.jsではRSCとSSRを組み合わせている。
どのように実現されているのか
- クライアントはサーバーに対してリクエストをする
- サーバーは対応するパスのコンポーネントをレンダリングする。レンダリングの結果をクライアントにストリーミングする。
- この時Server Componentsはネイティブコンポーネントになるまでレンダリング、クライアントコンポーネントはそのまま
- クライアントはサーバーからのレスポンスを解釈しながら、レンダリングを行なっていく
- 完全にレスポンスが返ってきていなくても逐次レンダリングをする
サーバーは必ずしもツリーの一番上から順番に送信するわけではなく、順次レンダリングできたところから順番に送信する。
上記のようなページをレンダリングすると
サーバーはクライアントに対してこんな感じの1行ごとに記号とJSONが含まれたレスポンスを返し、クライアントではこれを解釈している。
J1から始まる行が今回の場合ページコンポーネントで、CSSとかが入っているので横に長いが最後の方を見ると
というような部分がある。
@から始まっているのがコンポーネントへの参照で、 @5
@6
@7
というコンポーネントをrenderingしなさいというような意味になっている(fallback
とか書いてるのはSuspenseを使っているため。fallbackに渡したコンポーネントもRSCなのでレンダリングされてここに返ってきている)
@5
@6
@7
というのはそれぞれ、ストリームの M5
M6
M7
の行と対応しているため、該当する行がストリームされてきたら順次置き換えられていく。
Mから始まる行のうち、RSCに対応するものはレンダリングされて内容が返ってくる(ここでいうと J5
と J6
)
逆に、クライアントコンポーネントはコンポーネントの参照だけが返ってくる。( M7
)これを見てReactランタイムはコンポーネントを取得しにいく。
面白いのはJ1(ページ全体のDOMを表す行)より先にM7があるということ、このクライアントコンポーネントが必要になるのがわかっているから先に読み込んでおくようにクライアントサイドに指示している感じ。
今回、疑似的にめちゃくちゃfetchに時間がかかるコンポーネントを用意した。その場合のストリームを見ると以下のようになる。
J6
の行だけ3秒待ってから返ってくるが、それ以外の部分は先に返ってきているのがわかる。(ちなみにNext.jsでは rsc
というヘッダーをつけてリクエストをするとレンダリングされたHTMLではなくRSCのストリームが返ってくる)