え、起動早くない？
yarn dev実行したところ、サーバーが起動するのが早いなと感じた。
使いたいライブラリめもっとく
clsx。これ何回か見たことあるけどいいよね。
今度合いそうなプロジェクトあったら使おう。
page.tsxがなるものがページの肝ね
ページ作る時の話で、/のパスのページファイルは、/app/page.tsxとなるらしい。
あ、ページにしたいファイルはpage.tsxという命名にしないと公開されないんだ！appディレクトリにページ公開しないファイルもいっぱいあるしね。
まあ確かに、元々のNext.jsだと/sampleのページを作るとしたときに、ファイルを/pages/sample.tsxにするか/pages/sample/index.tsxにするかちょっと悩んだもんな。
やっときたねLayout…。ずっと待ってた。
page.tsxと並列で配置するlayout.tsxが肝ですな。
ページコンポーネントをchildrenとして受け取るlayout.tsxをpage.tsxと並列で配置すれば、そこ以下の階層のページ含めてレイアウトが適用される〜。
いじってみたところ、上層にレイアウトファイル置くと、下層のページにレイアウトファイル追加しても上書きされなさそうだから、下層ページにレイアウト置くことが多くなるのかなあ。 Route Group作ったらその層だけで適用できた！
結局レイアウトコンポーネントも他ページとも共通化したいだろうから、共通のレイアウト用コンポーネントを各ページのlayout.tsxに呼び出す形になるのかなあ。
Router周りのhookがけっこう変わってる
今まではuseRouterに現在のルート情報や、ルーター周りのアクションメソッドが全部入ってたけど、分けたみたいだな。
分割した方が読み込むコードが最適化されるとかそういう経緯なのかなあ🧐
usePathname
今のpathnameを返す
const pathname = usePathname()
// urlが /dashboard であれば '/dashboard'と返るuseParams
今のdynamic paramsを返す
const params = useParams()
// useSearchParams
今のクエリストリングの情報を返す。
get(), has(), getAll(), keys(), values(), entries(), forEach(), toString() のメソッドが用意されてる
const searchParams = useSearchParams()
console.log(searchParams.get('page'))
// /search?page=1 だと "1"useRouter
useRouterはpushやreplaceなどアクション系メソッドが集約されてる
reportWebVitalsがhookになった（useReportWebVitals）
元々web vitalsを取得するreportWebVitalsがあったけどhookになった様子。
使い道としては、ローカル開発時に出力結果みるとか、本番環境とかでも出力結果を他分析ツールに送りたい時とか。
Routeセクションはちょっとまじで読み返す
データ取得方法の検討も必要になりそう（並列処理or逐次）
逐次的にせざるを得ない（１つ目の返り値を元に２つ目のリクエストを走らせる）場合以外は、並列にした方がいい感じかな。ちなみに並列処理が全部終わったかは、Promise.all(), Promise.allSettled()あたりが使える。ただ、そのうちの１つのAPIがめちゃ遅かったら、他のも影響を受けるため、やっぱり適材適所。
Static Rendering / Dynamic Rendering
Server Renderingのストラテジー。
Static RenderingはSSGの時のサーバー側のレンダリング方法で、Dynamic RenderingはSSRの時。
言葉的に初めて聞いたからメモした。
Static Renderingしたときは、コンテンツはキャッシュされる。そのため、ウェブサイトの読み込みが早く、サーバーのロードも減って、クローラーがインデックスしやすいのでSEOにも有効。
loading.tsx
loading.tsxってファイル追加すれば、promiseがpending状態の間、そこで定義したUIを表示してくれちゃう。
スケルトン表示とかに良いね〜〜。
PPR
Partial Prerenderingのこと。いくつかの部分を動的に保ちながら、静的なローディングシェルでルートをレンダリングすることができる機能。ダイナミックな部分は並列にストリーミングされる。
続く
