App Routerについて

App Routerとは：URL = フォルダ構造

例:［urserId］/top/［scoreId］の場合

app/
 └── [userId]/
      └── top/
           └── [scoreId]/
                └── page.tsx

/123/top/abc

↓

userId = "123"
scoreId = "abc"

paramsはどこから来る？

Nextが自動で渡す。したがって、paramsを使いたい場合は、自分で渡していなくても、受け取れる。

export default async function Page({ params }) {}

Next16の重要なポイント

params: Promise<{ userId: string; scoreId: string }>

const { scoreId } = await params

App Router のルーティング関連データ（params / searchParams）が Promise 扱いになったので、await する

何が画期的なのか

まず、昔（Pages Router時代）

構造はこうだった：

pages/
  dashboard.tsx
  dashboard/settings.tsx

レイアウトはどうしてた？

• _app.tsx に全部まとめる

• もしくは各ページで手動でラップ

エラー？→ 自分で try/catch

ローディング？→ useState で手動管理

API？→ pages/api/ に別管理

つまり、画面・レイアウト・エラー・APIが全部バラバラ

大規模開発ではこれが破綻する。

App Routerが何を変えたか

例：

app/
 └── dashboard/
      ├── layout.tsx
      ├── page.tsx
      ├── loading.tsx
      ├── error.tsx
      ├── not-found.tsx
      └── route.ts

このフォルダは:

/dashboard

というURLの責任を 完全に持つ。

つまり、これが全部「dashboardフォルダの中」にある。

①画面:page.tsx

②共通枠:layout.tsx

③ローディング:loading.tsx

④エラー処理:error.tsx

⑤404処理:not-found.tsx

⑥API処理:route.ts

これが全部「dashboardフォルダの中」にある。URL単位で、画面・共通枠・エラー・ローディング・APIを全部まとめられることは、影響範囲が明確になるため、よいこと。

「このURLで何が起きるか」はそのフォルダを見れば全部わかる。

「URL単位で責務が閉じる」設計になったことが素晴らしい👍

Server Componentがデフォルト

App Routerの基本：

page.tsx = Server Component

layout.tsx = Server Component

つまり：

• ブラウザの状態管理は使えない

• useState 使えない

• useEffect 使えない

• useSearchParams 使えない

なぜ？

👉 これらはブラウザ専用機能だから

Server Componentは：

• Node.js上で実行

• HTMLを生成するだけ

• JSはブラウザに送られない

じゃあどうやってuseState使うの？

そのファイルの先頭に：

'use client'

と書く。

すると：

• そのファイルはClient Componentになる

• ブラウザで実行される

• useStateが使える

これは、別記事に書く「Server ComponentとClient Component」で詳細を記載！