nextjs14(Cache・サーバとクライアント・Build時について)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/576094/6074fe88-9f1f-e71a-b21f-d623bc46a4af.png)

https://github.com/kazu2377/quizmaster

`next_tu`にサンプルあり
- idはSSG
- cacheはfetchとSSR（動的）中でno-storeを使用している。ただforce-cache使用箇所はSSGとして取得している
- otenkiはSSG(静的)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/576094/d56fcc72-d4d5-075a-481b-a8c9077cb883.png)

```
[id]→SSG
cache→no-storeがあるのでSSR
otenki→特にfetchも使用せず、固定な静的なのでstatic(SSG?)中に、use cliant（CSR）でも関係無いサーバで作れるから

use cliant　ディレクティブをつけるとクライアント再度でレンダリングされる。
use server Serverサイドで実行される関数などに使用する

Build時にforce-cacheやno-storeを見て静的か、動的にするかを決める。また、引数わたしなどではgenerateStaticParams、getStaticPropsなど（フォルダ[id]）などは自動で作成してくれるのでSSGとなる（すでにページはできている）isrはrevalideteをつける。

つまり、自分の作成したいコンポーネントについてはサーバかクライアントサイドか、こまめに動かしたいならクライアントサイド、
静的な部分が多いならサーバーサイド、そしてデータfetchは１度だけBuild時につくらせるか、複数ページか、それとも毎回取得
させるかで、Cacheの引数をかえる。
```

※補足：SSGはBuild時に下記が動いてページデータを取得してidにセットして自動で静的ページを作成してくれる。
```javascript
//http://worldtimeapi.org/api/timezone/America/Argentina/Salta
export async function generateStaticParams() {
  const posts = await fetch("https://api.vercel.app/blog", {
    cache: "force-cache",
  }).then((res) => res.json());

  return posts.map((post: Post) => ({
    id: String(post.id),
  }));
}

```


:::note
コンポーネント単位のレンダリング方式の選択:

Next.js 13 以降では、React Server Components（RSC）の概念が導入され、コンポーネント単位でサーバーサイドレンダリング（SSR）とクライアントサイドレンダリング（CSR）を組み合わせることが可能です。
:::

1. **`use client` ディレクティブについて**:
   - `use client` をファイルの先頭に記述すると、そのファイル内のコンポーネントはクライアントサイドでレンダリングされることを明示します。
   - これにより、`useState` や `useEffect` などのクライアントサイド専用のフックを使用できます。
   - デフォルトでは、Next.js のコンポーネントはサーバーコンポーネントとして扱われます。
   - `use client` を指定すると、クライアントサイドでのレンダリングが必要なコンポーネントであることを示します。
   - これにより、クライアントサイドでの動的な振る舞いを持つコンポーネントを明示的に定義できます。
   - 詳細については、以下の資料が参考になります。
     - [Next.js 13の新ディレクティブ解析: 「use client」 と 「use server」](https://aichi.blog/?p=3281)
     - [【Next.js】use clientとuse serverの違いについて詳しく解説 - Qiita](https://qiita.com/RintaroNasu/items/777189b55ca71e01de40)

2. **`use server` ディレクティブについて**:
   - `use server` を使用すると、サーバーサイドでのみ実行される関数や処理を定義できます。
   - これにより、サーバーサイドでのデータフェッチや処理を明示的に指定できます。
   - サーバーサイドでの処理を明示的に指定することで、クライアントサイドとの役割分担が明確になります。
   - 詳細については、以下の資料が参考になります。
     - [Next.js 13の新ディレクティブ解析: 「use client」 と 「use server」](https://aichi.blog/?p=3281)

3. **`fetch` のキャッシュオプションについて**:
   - `fetch` 関数の `cache` オプションにより、データ取得時のキャッシュ戦略を指定できます。
   - `cache: 'force-cache'` を指定すると、ビルド時にデータが取得され、その結果がキャッシュされます。
   - このキャッシュはデプロイ間でも保持されるため、再デプロイしてもキャッシュは破棄されません。
   - そのため、ページは静的コンテンツとして扱われ、リクエストごとに再生成されることはありません。
   - 一方、`cache: 'no-store'` を指定すると、キャッシュを使用せず、リクエストのたびに新しいデータを取得します。
   - これにより、常に最新のデータを表示することができます。
   - 詳細については、以下の資料が参考になります。
     - [Next.js 13 の cache 周りを理解する - fetchCache - Zenn](https://zenn.dev/cybozu_frontend/articles/next-caching-fetch-cache)
     - [データ取得とキャッシュ | Next.js 公式ドキュメント 日本語翻訳](https://ja.next-community-docs.dev/docs/app/building-your-application/data-fetching/fetching)

4. **動的ルートと静的生成**:
   - `[id]` のような動的ルートを持つページで `getStaticProps` や `getStaticPaths` を使用すると、ビルド時に特定のパラメータに対応するページが静的に生成されます。
   - これにより、特定のパラメータに対応するページがビルド時に生成され、リクエスト時に即座に提供されます。
   - ただし、全ての可能なパラメータに対応するページをビルド時に生成することは、ビルド時間や生成されるページ数の観点から現実的でない場合があります。
   - そのため、必要に応じて `fallback` オプションを使用して、未生成のページをリクエスト時に動的に生成することができます。
   - 詳細については、以下の資料が参考になります。
     - [データ取得とキャッシュ | Next.js 公式ドキュメント 日本語翻訳](https://ja.next-community-docs.dev/docs/app/building-your-application/data-fetching/fetching)

5. **Incremental Static Regeneration (ISR) について**:
   - `revalidate` オプションを使用すると、指定した時間間隔でページの再生成が行われます。
   - これにより、静的生成と動的更新のバランスを取ることができます。
   - 例えば、`revalidate: 10` と指定すると、10秒ごとにページの再生成が行われ、最新のデータが反映されます。
   - これにより、頻繁に更新されるデータを持つページでも、静的生成の利点を享受しつつ、最新の情報を提供することが可能です。
   - 詳細については、以下の資料が参考になります。
     - [データ取得とキャッシュ | Next.js 公式ドキュ