Next.jsの考え方

PageRouter：propsを利用して下位へデータを渡す。
APPRouter：末端にてデータをフェッチする。
こうすることでコンポーネントごとの非同期が設けやすいように思う。

あくまで、サーバコンポーネントとして振る舞う。

データフェッチ専用の層を設けることが推奨されている。
以下のような構成。
app/products/fetcher.ts
app/products/_lib/fetcher.ts
app/products/_lib/fetcher/product.ts

非同期コンポーネントは兄弟もしくは兄弟の子孫コンポーネントとして配置されてる場合、並行にレンダリングデータフェッチの並行化。
＜コンポーネントA＞
＜コンポーネントB＞
　＜コンポーネントB−a＞
A・B-aは並行フェッチされる。

Promise.allやpreloadでも並行可。

DataLoaderを利用いて一括で取得する方法あり。
キャッシュ機能があり、ユーザからのリクエストを跨いで共有するリスクがある。リクエスト単位でDataLoaderのインスタンスを生成する。

これは一度試しておきたい。

ユーザ操作に基づくデータフェッチはSeverComponentは適しておらず、ServerActionとuseActionStateを利用する。

useActionStateの第一引数に検索処理（サーバアクションとして定義）を設定。
この戻り値を表示させる。

クライアントサイド処理：onClickとかのイベントハンドラの利用、ブラウザ
サードパーティコンポーネント
RSC Payload転送量の削減

Server Componentsはじめサーバーモジュールを利用不可。

"use client";が記載されたモジュールからインポートされたモジュールはすべて全て暗黙的にクライアントモジュールとして扱われる。
↓
対策：コンポーネントツリーの末端をClient Componentsにする

Compositionパターン：
子どもにpropsとしてseverコンポーネントを渡すことはできる。

テスト対象となるServer Componentsは「テストしにくいデータフェッチ部分」と「テストしやすいHTMLを表現する部分」で分離しておくことが望ましい

Static Rendering：build時やrevalidate後
Dynamic Rendering：ユーザーリクエスト時

Route Segment Configを利用してDynamic Renderingに切り替えることもできます。具体的には、page.tsxやlayout.tsxに以下どちらかを設定することでDynamic Renderingを強制できます。

// layout.tsx | page.tsx
export const dynamic = "force-dynamic";

// layout.tsx | page.tsx
export const revalidate = 0; // 1以上でStatic Rendering

キャッシュ関連の情報はチュートリアルには記載がなかった。

App Routerでは可能な限りStatic Renderingにすることが推奨されている。

Dynamic Renderingに特化したページ。

ユーザ情報に紐づかないものをキャッシュ対象とするよう設計する。

Router Cacheは、App Routerにおけるクライアントサイドキャッシュ。

要約：データ操作はServer Actionsで実装することを基本としましょう。

ブラウザバックではRouter Cacheが利用されます。この際には画面は即時に描画され、スクロール位置も正しく復元されるが、revalidatePath()などを呼び出すなどすると、Router Cacheが破棄されるため、スクロール位置を失う。

重いデータフェッチに対して、Suspenseを用いてfallbackを元に即座にレスポンスを送信して、フェッチ完了後にデータを送信させる。

１秒を超過するようであれば、Suspenseを適用させることを検討する。

画面の一部にfallbackを表示しそれが後に置き換えられるため、いわゆるLayout Shiftが発生する可能性ある。

置き換え後の高さが固定であれば、同様の高さとすることで回避する方法はある。

<Suspense>境界
外側をStatic Rendering
内側をDynamic Renderingとすることが可能。
既存のモデルを簡素化しつつも高いパフォーマンスを実現します。