いつ読むか?

  • RSC を使ったアプリの構成を新規に設計するとき、全体のベストプラクティスを確認したいとき
  • 個別にキャッチアップした RSC 関連の技術要素 (Suspense、cache()'use client') が何を解決するのか、位置づけを整理したいとき
  • page にデータ取得が集中して、コンポーネントが再利用しづらくなってきたと感じたとき
  • コンポーネントのディレクトリ構成 (features 分割、Atomic Design との対応) を決めるとき
  • Suspense や skeleton の置き場所をチームで議論するとき

読書メモ

RSC の設計原則を全体像として整理できる記事。

  • page は composer (同期・データを取得しない)、各コンポーネントが自分でデータを取得する。loader パターンの密結合を解消し、再利用性が上がる
  • cache() でレンダーツリー横断のリクエスト重複排除
  • skeleton は同ファイルに co-locate (ズレ防止)、Suspense は page 側に置いてローディング順序を意図的に制御
  • 'use client'葉ノードまで押し下げる
  • 各コンポーネントが自律的なので、ルーティングのディレクトリから外して features 単位で管理するのが自然 (複数ルートで再利用できる)

サーバー性能コンポーネントの自律性の両立が RSC の本質、という視点が軸。

考えたこと

  • features ≒ organisms と捉えると、Atomic Design のコンポーネント分類とディレクトリ構成の親和性が高そう (記事にはない着想)