React Server Components で複雑さに立ち向かう #コンポーネント_findy / findy 2023-10-04

© 2023 LayerX Inc.
React Server Components で複雑さに立ち向かう
他人事ではない React Server Components の世界
2023-10-04 コンポーネント設計のすゝめ〜ベストプラクティスを学ぶLunch LT〜
@izumin5210

View Slide

© 2023 LayerX Inc. 2
React Server Components、使ってますか？ 󰢨󰢧
はじめに - 他人事ではないReact Server Components

View Slide

「うちは SEO とか関係ないしな〜」
「SSR(Server Side Rendering)とかいらないな〜」
…なんて、思ってませんか？

View Slide

そんなことないよ！
このあたりを意識しつつ付き合えば、
アナタのアプリでも恩恵ある！かも！
…という話をします。

View Slide

▸ Wantedly, Inc. (2018-04 - 2022-08)
▸ LayerX (2022-09-)
‐ バクラク事業部 Enabling Team
‐ Backend と Web Frontend 中心にやってます
▸ 最近のお気に入りパッケージは @floating-ui/react
画像を入れてね
whoami
@izumin5210

View Slide

React Server Components の話

View Slide

React Server Components ってなんだっけ
React Server Components おさらい
React Server Componentsの仕組み：詳細ガイド | POSTD
https://postd.cc/how-react-server-components-work/
▸ Server でのみ処理する Component と
Client でも処理する Component を
混ぜることができる
▸ Server Component はただの HTML タグになる
‐ 状態・イベントハンドラ・副作用などを持てない
▸ なので SSR とは別物！
‐ 従来のコンポーネントはすべて
Client Component である

View Slide

React Server Components は何が嬉しい？
（重要だが、時間がないのでこの発表では省略！）
パフォーマンス
設計
「本質的には単純な処理で済むもの」と「複雑さが必要なもの」を
分けて、前者を本当に単純に書けるようになる

View Slide

Components のシンプルでいい部分・複雑な部分
設計
「本質的には単純な処理で済むもの」と「複雑さが必要なもの」を
分けて、前者を本当に単純に書けるようになる
「単純な処理で済むもの」
▸ 状態・副作用・インタラクティビティをもたないもの
‐ cf. Rails や PHP のテンプレートエンジンで
組み立てるHTML
▸ 1回 return したらそれで完了の
「高級テンプレートエンジンとしての React」
「複雑さが必要なもの」
▸ 状態・副作用・インタラクティビティをもつもの
‐ cf. Rails や PHP が返した HTML に
リッチな体験を付与するクライアントサイド JavaScript

View Slide

コンポーネント使い分けの話
React Server Components の世界では何が変わるんだろう？

View Slide

▸ Server Component にできるものはそのほうがいい
‐ 責務が小さい（状態やイベントハンドリングがない）もののほうが理解しやすい・壊れにくい
‐ バンドルサイズやクライアントサイドで実行される JS の量も（おそらく）小さいので
ユーザ体験にも有利
‐ デフォルトでは SC になるのも、基本的にはそちらが有利だからのはず
▸ いつ Client Component にする？
React Server Components でのコンポーネント設計
Server Component（SC) か Client Component(CC) か
このページ以降、React Server Component, Server Comonent, Client Component を
それぞれ RSC, SC, CC と略すことがあります

View Slide

▸ Server Component にできるものはそのほうがいい
▸ いつ Client Component にする？
‐ CC じゃないとできないことをするとき(e.g. イベントハンドリング)
‐ ブラウザ上で動的な振る舞いをしたいときは CC にするしかない
‐ CC に依存されるとき
‐ CC が SC を import することはできない
‐ children として渡されるぶんには問題ない
Server Component か Client Component か

View Slide

Q. SC はテスト・Storybook では困らないの？
A. （場合によっては）困ります
Server Component で困るケース

View Slide

▸ Server でしか実行できない要素を持つ SC は、
現状の Storybook や Testing Library で扱えない
‐ e.g. 非同期(async), フレームワークが提供するサーバでのみ扱えるもの（e.g. リクエストヘッダ）
‐ 非同期でない server-only component はテストできるようになった*
非同期 SC は非同期で static な HTML を返すみたいなもの（厳密には違う）なので、
いままでのむしろ単純にテストできるような気もするが…。このへんは深ぼってみると面白いかもしれない。
▸ 「SC としても CC としても扱えるコンポーネント」であれば問題ない
Server Component で困るケース: Test, Storybook
* Next.jsでServer Componentsがちょっとだけテストできるようになってた
https://zenn.dev/cybozu_frontend/articles/next-rsc-testing

View Slide

▸ Server でしか実行できない要素を持つ SC は、
現状の Storybook や Testing Library で扱えない
▸ 「SC としても CC としても扱えるコンポーネント」であれば問題ない
‐ 当面は「ロジックに関心を持つ SC」と「表示に関心をもつ SC」に分けておくのが吉
‐ Presentational and Container separation ！！
React Hooks, キャッシュ付き data fetch ライブラリ, MSW などの発展で
Presentation / Container を区別せず物事を単純に扱えるようになっていたのが巻き戻った感もちょっとあるが…
ここからどういう方向に進化していくかが楽しみでもありますね！
Server Component で困るケース: Test, Storybook

View Slide

React Server Components と
どう付き合っていくか

View Slide

Q. SSR/CSR だけでも複雑なのに、SC/CC が来てむしろ複雑になったのでは？
A. たしかに…？どうだろう…？
React Server Components とどう付き合っていくか
RSC で複雑になってない？

View Slide

RSC で複雑になってない？
▸ ここまでの話から、コンポーネント種別は大きく3つくらいに分かれる
‐ Server Component (server only)
‐ Server Component　(client でもOK)
‐ Client Component （SSR を許すもの・許さないものに分けることもあるかも）
▸ 「なるべく SC に寄せる」「SC は Presentaional/Container に分ける」
という基本ルールがあれば、そこまで複雑ではなくなる…？
‐ みなさんどう思いますか

View Slide

RSC、今から使う？
▸ Next.js は 13.4 から App Router が stable になった
‐ ので、理論上使える
▸ 一方、エコシステム・世の中の事例・情報ともに充実してるわけではない
‐ RSC 自体もまだまだ Research が必要です！という段階*
▸ そもそも、マネージ対象の Server が増えることなどにもデメリットはあるはず
▸ しかし、未来は Server をも活かしていく方向になる気配はある
* rfcs/text/0188-server-components.md at main · reactjs/rfcs
https://github.com/reactjs/rfcs/blob/7f8492f/text/0188-server-components.md#open-areas-of-research

View Slide

▸ 未来は Server をも活かしていく方向になる気配はある
‐ ならば Bet Technology していきたい！
RSC、今から使う？
▸ 段階的に試していく、たとえば実験的に SC を使う領域を作るなんてのもアリ
‐ Next.js であれば、 Pages Router （旧来の仕組み）
と App Router の共存が可能
‐ App Router であっても SC ではなく CC にすれば従来の挙動に近い
▸ いまのうちから勘所を掴んでおいて、
この流れが本格化したときにうまく恩恵に乗れるようにしておくといいかも！
ちなみに、最近リリースされたバクラク請求書発行では当初 Next.js App Router を使っていました！
が、App Router の機能が足りず Pages Router に戻すことに。
そんなこともあろうかと SC をめっちゃ薄くしてたので戻すのは簡単でした。が、無念…。

View Slide

▸ React Server Components は Web アプリ開発にどのような変化をもたらすか
‐ https://zenn.dev/izumin/articles/bc47e189e25874
‐ この発表のきっかけとなった自分の記事です
▸ 一言で理解するReact Server Components
‐ https://zenn.dev/uhyo/articles/react-server-components-multi-stage
▸ React Server Components について - Speaker Deck
‐ https://speakerdeck.com/yosuke_furukawa/react-server-components-nituite
▸ rfcs/text/0188-server-components.md · reactjs/rfcs
‐ https://github.com/reactjs/rfcs/blob/7f8492f/text/0188-server-components.md#open-areas-of-resea
rch
▸ Building Your Application: Rendering | Next.js
‐ https://nextjs.org/docs/app/building-your-application/rendering
参考資料たち。全部読めば React Server Components 完全理解だ！

View Slide

▸ Server Component をうまく使うことで、実装上の複雑さを低減しつつ、
パフォーマンスメリットも得ることができる
‐ 理想的には、なるべく Server Component によせて、
‐ App Router であっても SC ではなく CC にすれば従来の挙動に近い
まとめ
▸ コンポーネントの種類が増えて、むしろ複雑に感じるかもしれない
‐ 一口に Server Components といっても、「何ができるか」「（なんのために）どこで動くか」によってどうあるべきかは変わる
‐ 一方で、自分が「何をするコンポーネントを作っているのか」を意識すれば、迷うことは少ないかも
▸ とはいえイキナリ Server Components 全乗っかりは難しいかもしれない
‐ そういうときは、可能ならなるべく小さくはじめることもできる
‐ 実際に触ってみることで初めてわかること・つかめる勘所もあるはず

View Slide


View Slide

対戦おまちしております
▸ LayerX OpenDoor [検索] ▸ バクラクフロントエンドVision [検索]

View Slide

React Server Components で複雑さに立ち向かう #コンポーネント_findy / findy 2023-10-04

React Server Components で複雑さに立ち向かう #コンポーネント_findy / findy 2023-10-04

Masayuki Izumi

More Decks by Masayuki Izumi

Other Decks in Technology

Featured

Transcript