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
React Server Componentsは誰のためのものか?
Search
noyan
October 12, 2023
0
390
React Server Componentsは誰のためのものか?
noyan
October 12, 2023
Tweet
Share
More Decks by noyan
See All by noyan
利用者の生産性をどう上げるか 中規模モノレポの苦しみ
noyan_
0
320
Goで書いて学ぶ HTTP Server / Write and learn HTTP Server in Go
noyan_
0
11
React Fiber Architectureとレスポンス性の向上 / React fiber architecture and responsiveness
noyan_
0
9
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
38
7.1k
A Tale of Four Properties
chriscoyier
156
23k
We Have a Design System, Now What?
morganepeng
50
7.2k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
What's in a price? How to price your products and services
michaelherold
243
12k
Building an army of robots
kneath
302
43k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
KATA
mclloyd
29
14k
Done Done
chrislema
181
16k
Become a Pro
speakerdeck
PRO
25
5k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
React Server Components は誰のため のものか? 2023-03-03 Tokyo Study noyan 1
React Server Components の仕組み React の Server Components は、サーバーでコンポーネントをレンダ リングする。
SSR はブラウザで実行できるコードをサーバーで実行するが、RSC は サーバーでのみレンダリングするコンポーネントを実装する。 既存のコンポーネントと組み合わせて、サーバーとクライアントの両 方を行き来できるようにする。 クライアントへ配信するコード量を減らす 直接バックエンドにアクセスできる 2
以下の形でコンポーネントを利用できる。 // Parent.js import Component from "./Component.js"; function Parent() {
return <Component />; } // Component.js "use client"; export default function Component() { let [state, setState] = useState(false); return <OtherClientComponent onClick={() => setState(true)} value={state} />; } 3
この時、RSC のレンダリング結果はシリアライズされた形で Client に 配信される。 M1:{"pika":"chu"} J0:["$","div",null,{"children":[["$","h1",null,{"children":"React Server Components example"}],[["$","p",null,{"children":"Hello,
world!"}],["$","@1",null,{}]]]}] 実装する時間がなかったので uhyo さんの記事から拝借しています。 https://zenn.dev/uhyo/books/rsc-without-nextjs/viewer/client- component 4
何が嬉しい・嬉しくないか 5
嬉しいところ これまで努力していた部分が React 側の仕組みに乗っかる形で改善で きるようになる 自然にラウンドトリップが減る クライアントサイドで実行する必要のないコードはそもそも配信さ れない Stream と
Suspense を組み合わせて、ローディング周りの体験を最 適化できる 配信される JS が削減されるので、TTI が減少 再レンダリングの計算コストも改善 6
嬉しいところ RSC はサーバーアプリケーションのコードをサーバー・クライアント 意識せずにまとめることができる「コロケーション」と、これまでコ ストがかかっていた部分を自然と改善できるようにするアーキテクチ ャーと考えている。 7
嬉しくないところ:でも結局 SSR は必要になる JSON ライクなペイロードで配信されるため、FCP や SEO を考慮す ると SSR
が必要 「最初は SSR して、その後は RSC で」となった時、RSC が必要な タイミングはいつだろう? Server Component は Client からインポートできない( 全ての Server Component は Root と接続していなければならない) Server Component は Props の変更に応じて出力を切り替えるこ とができるが、状態を持たない Server Component は自ら再レン ダリングすることはない 8
嬉しくないところ:でも結局 SSR は必要になる どうもページ遷移しか対象ではなさそう 画面遷移のタイミングであれば、既存の技術はそこまで問題はな い 逆にページ遷移ごとにサーバー側でレンダリングしていると体験 が悪い(link の prefetch
が必須になってくる) 動的に StyleSheet を生成する(runtime) CSS in JS 系ライブラリと は相性が悪い(Concurrent に続き... ) RSC を活用するために、クエリパラメータを盛大に活用するのか? 9
嬉しいところ・嬉しくないところ RSC は、できなかったことができるようになるアーキテクチャではな く、React 内部では不可能であってもアプリケーション全体で頑張れ ば可能だったことが React( を内包するフレームワーク) で可能になる ということではないか。
10
最後に 現在のアプリケーション開発において必要になっているものはなんだろう? ここ数年、もはや「今までできなかったことができるようになった!」は 減少 これからはむしろ、頑張ればできたことが簡単にできるようになっていく 時代 OSS のコンパイラによるレンダリングパフォーマンス改善が企業のサポー トを受けられる時代ではない その上で必要になってくるのは、ビジネスのアプリケーション開発に特化
した何かではないか? Docsaurus みたいに、もっとユースケースが具体化したドロップインソ リューション・・・? 11