Open4

React Server Component(RSC)

いないいない

まじ概要...

そもそもRSCはむずいぜ..

難しい理由は...
→いろんな問題を一気に解決する技術だから難しい...
→1つの問題があってそれを解決する技術だったらわかりやすいのだが..
(例)
Reactのhooksなど...
→以前はhocを多用していて、つらみがたくさんあった
→それを解決するためのhooks

RSCはまじでいろんな問題を解決してしまっている...
→そのためあっちこっちに話題が飛びがち
→例えるなら、電子レンジ?
→いろんなことできちゃう。料理できるは、単純に温められるは...(微妙な例w)

今回は、JSのバンドルサイズ削減という側面から見たRSCについて
(こっちの側面から理解すればわかりやすい!)

歴史

歴史知らないと、なんで良いのかわからんぜよ。
→やっぱ歴史大事
→賢者は歴史に学ぶ

minify→関数名・変数名などを最小化。空白の削除やコメントアウト削除
ツリーシェイキング→未使用の文字列などを削除。loadashなどで、未使用のメソッドがJSのバンドルに含まれてしまったらあれなので、減らす。
デッドコード削除→到達不可能なコードを削除するらしい...

  1. 具体的には真っ白なページ表示されちゃうやん...みたいな。初期ロード時間が長くなりすぎるのを避けるために当時はチャンク分けみたいなことを行われた。このページではこのJSはいらないよね..みたいなときに、不要なJSを削除したりできる。ただWebpackでこれを実現しようとするとだるい!!!!
    1. JSのレンダリングをクローラーができん!SPAは
<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script src="/path/to/main.js"></script>
  </body>
</html>

はこれが返されちゃって、SEO的によろしくない。(クローラーにインデックスされない)
googleはJSのレンダリングに対応しているらしいが、Next.jsなどでプリレンダリングを行って初期画面を表示させといたほうがよき

SSR

SPAはJSを解析しないとDOMが表示されない...
SSRでは、ひとまずHTMLが表示されるぜ!
→新たな問題!ハイドレーション

SSRは、基本的にHTML(これがReactから生成される仮想DOMツリーみたいな感じ) + scriptみたいな形で送られる(RSCはこのscriptが必要なくなる!)

ハイドレーションはまじで重い!!

prefetch
→Next.jsのLinkなどでは、href属性で指定されてあるページをロードしたりする

セレクティブハイドレーション
→Above the Foldコンテンツ以外のロードを遅らせるのみ!

↑これらのアプローチはロードするJSの総量自体は変化していない。ロードタイミングを変えているのみなのだ

React Server Components

SSRはサーバー側「でも」レンダリング行われている
RSCはサーバー側「のみ」レンダリング行われている
→JSのバンドルサイズを減らせる技術が、RSC。「ここってインタラクティブじゃないやん」の部分でJSを使わないことによりハイドレーション必要なくなる!

use client

"use client"ディレクティブある場合でも、そのコンポーネントはSSRされるぜ!
たぶん1番ややこい
→クライアント=「クライアントコンポーネントのクライアント」と「ブラウザという意味のクライアント」

クライアントコンポーネント
=ブラウザ側でのみ動作するコンポーネントを指すのではなく、JavaScriptバンドルが含まれるコンポーネントと解釈してください。CSRはもちろん、SSRもJavaScriptバンドルが含まれるため、クライアントコンポーネントと言えます。'use client'の「クライアント」は、このクライアントコンポーネントのことを指します。

CSRでのクライアントがブラウザ側!!

"use client"つけてもSSRはされる

Next.jsはデフォルトでRSC + SSR

RSCとSSRは併用できる

RSCはサーバー側だけで実行されるという性質を持っているだけで、レンダリングに関しては説明していません。Next.jsはそもそも絶対プリレンダリングされてSSRされている
→ふつうはSSRしたほうが効率良いので、RSC+SSR

シリアライズ可能な値しか渡せない

関数は、ネットワークを介してpropsとして受け渡せない

Server Actionは関数をそのまま渡しているのでは!?
→関数の所在地を渡している
→クライアントコンポーネントにserver actionを渡すと、その所在地にある関数を実行するみたいなイメージ。
RPCと言われるもの
ただServer ActionsはまだGAされていないので、ここまで抑える必要はない...??

フレームワークの使用が必要になる

RSCをつけるのは結局Next.jsだけ

Remixさんはv3から

データフェッチの恩恵も受けられる...?

RSCは他にも、Reactのデータフェッチにおける問題も解決している!

RSCでデータフェッチすることで何が良くなったのか?という点について...
→リクエストウォーターフォールの問題解決?

バンドルサイズが減らされることでTTYが良くなり、DX/UXともに改善される

※DXの向上
サーバーサイドの苦労100 + クライアントの苦労100だったのがRSCにより150になるイメージ。
全体としてみたら減っているイメージ。

Server Actionsの良さ

  • クライアント側に渡す関数自体をいろんなpageに使い回せる
  • クライアントコンポーネントにそのまま渡せる
  • キャッシュのpurgeができる

ただブラウザ側でJSをオフにしてフォーム送信したい...みたいなことをしたとて、結局バリデーションなどしたみで JSいるくね?ってなる。

Progressive Enhancementなどのメリットがそこまであるとはという。。。

学習コスト的な面

パフォーマンス向上というメインテーマに対しての概念変化による学習コストが中々に大きそうで、そこまでして移行するべきものなのか悩ましい
→そういう意味ではRemixは割りと良い

Vercel使わない場合、Next.jsのpages routerでやるか〜〜となった場合は圧倒的にRemix。
Remix > pages router らしい

いないいない