スライド「App Router時代のデータ取得アーキテクチャ」を読んで - Githubissues

KATO-Hiro / Daily-hit

Wants to make & prototype list inspired by https://masuidrive.tadalist.com/lists/1941485/public

MIT License

0 stars 0 forks source link

スライド「App Router時代のデータ取得アーキテクチャ」を読んで #1274

Closed KATO-Hiro closed 1 year ago

KATO-Hiro commented 1 year ago

要約

Next.jsとは?
- React app向けに、ルーター・サーバー実装を提供してくれるFW
- ルーター: URLに応じて、コンテンツを出し分ける機構
- サーバー実装: SSRやキャッシュ機能を担当
- バンドルの最適化
App Routerとは?
- Next.js 13で追加された、新しいルーターの実装
- 従来のPages Routerと対比して呼ばれる
- React Server Components (RSC)上に作られている
SSRとは?
- サーバ
- リクエストURL → switch文相当の何か(*1)→レンダリング→HTML文字列
- クライアント
- (*1)→バンドルされたJS→レンダリング→DOM
- Q: サーバでstaticな処理をすることで、更新回数を減らしている?
- Q: SSRが必要/有効な場面とは?
データフェッチングとは?
- appの外部からデータを取得し、表示に利用すること
- SSRを不使用: クライアントからfetchして処理
- SSRを使用: ややこしく、FWがサポートしてくれる
React18前後の事情
- 18以前
- サーバサイドレンダリング用のAPIは同期的であり、レンダリングの最中にデータフェッチングは不可能
- React appの外部API(getServerSidePropsなど)を使う
- 18以降
- Suspenseのサポートにより、SSR時も非同期的なレンダリング可能に(Streaming対応SSR)
  - サスペンドしたら待機、解消したら追加のコンテンツを出力
  - データフェッチングがレンダリングの一部に
  - △: データフェッチングのロジックがサーバ・クライアントの両方で必要に
  - △: リクエストの重複排除などを考えると大変。Streaming SSRだけに頼るのは難しい。
- Suspenseの導入で、ステートに頼らずローディング中を表現できるようになった
React Sever Components (RSC)とは?
- サーバ側コンポーネント・クライアント側コンポーネントという概念が導入される
- app全体で見れば、サーバ側・クライアント側で実行される部分に分割されている
- サーバ側・クライアント側でそれぞれレンダリングが行われる
RSC + SSR
- RSCはFWを介して利用することが多い + SSRもサポートしているので、併用することが多い
- SSR要素: 本来クライアント側で行うレンダリングをサーバ側でも行う
RSCとデータフェッチング
- サーバ側コンポーネントないで、直接データフェッチングできることが売りの一つ
- コンポーネントをasync関数にできる
- 状態管理なしで、データフェッチング可能
- ポイント: データフェッチングがサーバ側に含まれているため、SSRしてもサーバ・クライアントで処理が重複しない
以前のNext.jsとの比較
- 共通点: クライアント側のレンダリングよりも前にデータフェッチングを済ませるので、ハイドレーション周辺の大変さがない
- 相違点: データフェッチングをappのレンダリングの一部として行うかどうか?
なぜ、RSCではデータフェッチングがReact appの外から中側に移動したか?
- A: データフェッチングの方法の標準化のため
- FW間での共通化が進んだ = Reactが定める標準に合わせている
データ取得のポイント
- 目指す目標: サーバ・クライアントの連携をRSCに任せ、ユーザランドで苦労しない
- 苦労の具体例: GraphQLクライアントのきゃっしゃをサーバ側からクライアント側にコピー
- データ取得をサーバ側・クライアント側に分けて考える
- サーバ側: SSR(=初期レンダリング)に反映されてほしいもの
- クライアント側: 初期レンダリングには含まれなくていいもの
- サーバ側で行う必要があるデータ取得は、全部Server Component内で行う
- RSCの担当以外でサーバ・クライアント側でデータ共有をしない
Server Components内のデータフェッチング
- Fetch on renderでいいのか?
- コンポーネントがレンダリングされたら、そのコンポーネントが必要とするデータの取得が始まる
- 通信の直列化: レンダリング→fetch→レンダリング→fetch...
- サーバ側では、fecthにかかる時間が短いことが多い場合は、問題になりづらい
- SC内では、コンポーネントがそれぞれデータを取得しても良い
  - リクエストをまとめたい場合などは、状況に応じて判断
- SCのテスト
- クライアント用コンポーネントのテスト考え方は同じ
- 方法
  - (2023年8月時点では実行できない)SCをレンダリングしてテスト
  - ロジックを関数に抜き出してテスト
- クライアント側の状態管理との連携
- 従来: データフェッチングの結果は一種の「状態」として扱われてきた
- Sc: クライアントから見れば、「上流側からpropsで降ってくる値」であり、状態ではない
- RSCと状態管理の懸念事項
- SCがフェッチした状態に関して、source of truthがあるため、一部の状態管理アーキテクチャとの相性が微妙
  - Redux、Recoil型のアーキテクチャでは、状態管理をReactコンポーネントから分離しているため、Reactの内→外というデータの流れが必要
- 明確な答えはない
データ取得のポイント: ハイドレーション周りの苦労を減らすこと
- サーバ側にデータ取得を寄せるのが有効

疑問点

DOMとは?
ハイドレーションとは?
source of truthとは?

感想

図解でRSC(サーバ側)とSSRとの違いが少しだけ分かった気がする
スライドの作者はどこから情報を入手している?
- 公式docsに書いてある?
- ReactやNext.jsのメンテナorコミッタ?

Keep

+

Problem

+

Try

+

出典

https://speakerdeck.com/uhyo/app-routershi-dai-nodetaqu-de-akitekutiya