Merge pull request #49 from Atotti/Ritsu

Ritsu

Ritsu/chapter18/README.md

@@ -0,0 +1,43 @@
+# 静的レンダリングと動的レンダリング
+この章のトピック
+- 静的レンダリングとは
+- 動的レンダリングとは
+- ダッシュボードを動的にする方法
+- 遅いデータのフェッチのシミュレート
+
+## 静的レンダリングとは何か
+静的レンダリングでは、データの取得とレンダリングは、ビルド時または再検証中にサーバー上で行われる。結果はコンテンツ配信ネットワーク（CDN）に配布およびキャッシュできる。
+ユーザーがアプリケーションにアクセスするたびに、キャッシュされた結果が提供される。
+
+静的レンダリングの利点
+- **ウェブサイトの高速化** - 事前にレンダリングされたコンテンツをキャッシュしてグローバルに配信することができる。これにより、世界中のユーザーがウェブサイトのコンテンツにより迅速かつ確実にアクセスすることができる。
+- **サーバー負荷の軽減** - コンテンツがキャッシュされ、サーバーはユーザーリクエストごとにコンテンツを動的に生成する必要がない。
+- **SEO** - 事前にレンダリングされたコンテンツは、ページの読み込み時にすでに利用可能であるため、検索エンジンクローラーにとってインデックス付けが容易で、検索エンジンのランキングが向上する可能性がある。
+
+静的レンダリングは、**データがない**または**ユーザー間で共有されるデータを含むUIに役立つ**。定期的に更新されるパーソナライズされたデータを含むダッシュボードには適さない可能性。
+
+### Contents Delivery Network (CDN)
+
+## 動的レンダリングとは何か
+動的レンダリングでは、**リクエスト時**に、コンテンツがユーザーごとにサーバー上にレンダリングされる。
+
+動的レンダリングの利点
+- **リアルタイムデータ** - 動的レンダリングにより、アプリケーションはリアルタイムまたは頻繁に更新されるデータを表示できる。
+- **ユーザー固有のコンテンツ** - ダッシュボードやユーザープロフィールなどのパーソナライズされたコンテンツを提供し、ユーザーインタラクションに基づいてデータを更新することが簡単になる。
+- **リクエスト時の情報** - Cookie や URL 検索パラメータなど、リクエスト時にのみ知ることができる情報にアクセスできる。
+
+
+## ダッシュボードを動的にする
+デフォルトでは、`@vercel/postgres`は独自のキャッシュセマンティクスを設定しないため、フレームワークは独自の性的および動的動作を設定できるようになる。
+サーバーコンポーネントまたはデータ取得関数内で`unstable_noStore`と呼ばれるNext.js APIを使用して、静的レンダリングをオプトアウトすることができる。
+```
+import { unstable_noStore as noStore } from 'next/cache';
+```
+```
+export asynx function brbrbr(query: string){
+    noStore();
+}
+```
+
+## 遅いデータフェッチのシミュレーション
+動的レンダリングを使用すると、アプリケーションの速度は最も遅いデータフェッチと同じになる。

Ritsu/chapter19/README.md

@@ -0,0 +1,10 @@
+# ストリーミング
+データリクエストが遅い場合にどのようにユーザーエクスペリエンスを改善できるか？
+この章のトピック
+- ストリーミングとは
+- `loading.tsx`とサスペンスを使用したストリーミングを実装する方法
+- ローディングスケルトンとは何か
+- ルートグループとは何か
+- アプリケーション内でサスペンス境界を配置する場所
+
+## ストリーミングとは

Ritsu/chapter20/REAMDME.md

@@ -0,0 +1,36 @@
+# PPR(Partial Prerendering)
+
+この章のトピック
+- PPR（部分プリレンダリング）とは何か
+- PPRの仕組み
+
+## 静的コンテンツと動的コンテンツの結合
+現在、ルート内で動的関数(`noStote()`, `cookies()`)を呼び出すとルート全体が動的になる。
+これが今日のほとんどのWebアプリの構築方法であり、アプリケーション全体、または特定のルートで動的か静的なレンダリングを選ぶことができる。
+ただし、ほとんどのルートは完全に静的または動的ではありません。静的コンテンツと動的コンテンツの両方を含むルートがある場合がある。たとえばECサイトでは、商品ページの大部分を事前にレンダリングできる場合もありますが、ユーザーのカートや推奨される商品をオンデマンドで動的に取得したい場合もある。
+
+### ダッシュボードページにおける動的・静的コンテンツ
+![Alt text](image.png)
+
+- `<SideNav>`コンポーネントはデータに依存せず、ユーザーに合わせてカスタマイズされていないため、静的にすることができる。
+- `<Page>`コンポーネントは頻繁に変更されるデータに依存しており、ユーザーに合わせてカスタ
+- 静的ルートシェルが提供されるため、初期ロードが高速になる。
+- シェルには、動的コンテンツがマイズされるため、動的である。
+
+## PPRとは
+ルートの動的部分を分離することができる、Next.js 14 の実験的な機能。
+![Alt text](image-1.png)
+
+ユーザーがルートを訪問すると、非同期で読み込まれる hole が残る。
+- 非同期の hole は並行してストリーミングされるため、ページの全体的な読み込み時間が短縮される。
+これは、ルート全体が完全に静的または動的である現在のアプリケーションの動作とは異なります。
+
+PPRは、超高速の静的エッジ配信と完全な動的機能を組み合わせたもので、Webアプリのデフォルトのレンダリングモデルになる可能性があると考えている。静的サイト生成と動的配信の長所を組み合わせます。
+
+## PPRはどのように機能するのか
+PPRはReactの`Concurrent API`, `Suspense`を使用して、何らかの条件が満たされるまで、アプリケーションのレンダリングを延期する。（データがロードされるまでなど）
+
+フォールバックは、ほかの静的コンテンツとともに初期静的ファイルに埋め込まれる。ビルド時にルートの静的部分が事前レンダリングされ、残りの部分はユーザーがリクエストするまで延期される。
+
+PPRは、Suspenseを使用してルートの動的部分をラップしている限り、Next.jsはどの部分が静的でどの部分が動的かを認識するため、コードを変更する必要はない。
+