Next.jsのApp RouterとPages Router、なぜApp Routerを選んだか
Next.jsを学び始めると、「App Router」と「Pages Router」という2つの仕組みがあることに気づきます。情報を調べると、どちらの説明も出てくるため、初めて触る人ほど混乱しやすいポイントです。この記事では、両者の違いと、このブログでApp Routerを選んだ理由を整理します。
💭 振り返ってみて思うこと
正直、最初にNext.jsを調べ始めたとき、この2つの違いが一番分かりにくいポイントでした。ネット上の情報も、書かれた時期によってPages Router前提のものとApp Router前提のものが混在していて、どちらを参考にすればいいのか迷った記憶があります。結論としては「今から新しく始めるならApp Router一択」で良かったのですが、その結論にたどり着くまでに無駄な回り道をしてしまったので、この記事で同じ悩みを持つ人の時間を少しでも節約できればと思っています。
App RouterとPages Routerの違い
| 観点 | Pages Router | App Router |
|---|---|---|
| 登場時期 | Next.jsの初期から存在する仕組み | 比較的新しい仕組み |
| ディレクトリ | pages/ |
app/ |
| データ取得の書き方 | getStaticPropsなどの専用関数 |
コンポーネント内で直接データ取得できる |
| レイアウトの共通化 | やや工夫が必要 | layout.tsxで自然に表現できる |
| 情報の新しさ | 情報は多いが古いものも混在 | 新しい機能はこちらに追加されていく |
なぜApp Routerを選んだか
このブログを構築する際、最終的にApp Routerを選んだ理由は主に3つです。
- 今後の新機能はApp Router側に追加されていく方針であること: 長期的に情報のキャッチアップがしやすいと判断しました
- レイアウトの共通化がシンプルに書けること: ヘッダー・フッターのような共通パーツを
layout.tsxにまとめられるため、このブログのようにカテゴリー・タグなど複数の一覧ページを持つ構成と相性がよいと感じました - コンポーネント内でそのままデータ取得の処理を書けること: Markdownファイルを読み込んで記事一覧を作る、というこのブログの構成にとって、書き方がシンプルになりました
Pages Routerを選ぶ場面もある
App Routerが新しい標準という位置付けではありますが、Pages Routerを選ぶ理由が無いわけではありません。
- 既存のPages Router製プロジェクトを保守している場合、無理に移行する必要はない
- Pages Router向けの情報・ライブラリの方が豊富に揃っている領域もある
- チームメンバーがPages Routerに慣れている場合、学習コストを避けたいこともある
新しく個人ブログを立ち上げる、という今回のようなケースでは、これらの事情に当てはまらなかったため、素直にApp Routerを選びました。
App Routerを使う上でつまずきやすかった点
"use client"の使い分け: サーバー側で実行されるコンポーネントと、ブラウザ側で動く必要があるコンポーネント(例: テーマ切り替えボタン)を区別する必要があり、最初は混乱しました- データ取得のタイミングの違い: Pages Routerの
getStaticPropsのような専用関数が無くなった分、「いつ・どこでデータを取得するか」を自分で設計する必要があります
よくある質問
Q. 既存のPages Routerのプロジェクトを今からApp Routerに移行すべきですか? A. 必須ではありません。安定して動いているプロジェクトを無理に移行する必要はなく、新規プロジェクトから採用するので十分です。
今の結論
App RouterとPages Routerは、どちらも有効な選択肢ですが、これから新しくNext.jsのプロジェクトを始めるのであれば、今後の機能追加の方向性を考えてApp Routerを選ぶのが素直な判断だと思います。このブログもその考えのもとApp Routerで構築していて、今のところ選び直したいと思ったことはありません。