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
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
4 Signs Your Business is Dying
shpigford
180
21k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Gamification - CAS2011
davidbonilla
80
5k
Optimizing for Happiness
mojombo
376
70k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Building Your Own Lightsaber
phodgson
103
6.1k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Unsuck your backbone
ammeep
668
57k
Site-Speed That Sticks
csswizardry
0
28
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