Clarifier les différences entre Next.js Pages Router et App Router, souvent confondus

Next.js, un framework de développement web très apprécié, a introduit un nouveau App Router comme système de routage par défaut à partir de la version 13.

Quand on travaille sur des projets utilisant à la fois Pages Router et App Router, il est facile de confondre « quelle syntaxe dois-je utiliser ? ». C'est exactement mon cas !!

En particulier, il existe des différences significatives entre Pages Router et App Router concernant les aspects fondamentaux du développement d'applications : la définition du routage basée sur la structure des fichiers, la gestion des parties dynamiques des URL, le mécanisme de rendu, et la récupération des données à partir d'une API.

En mettant l'accent sur les points « souvent source de confusion », j'ai documenté les principales différences entre Pages Router et App Router à titre de mémorandum !

Différences dans le routage des fichiers

Pages Router : la simplicité du nom de fichier devenant directement le chemin

Les fichiers .js, .jsx, .ts, .tsx placés dans le répertoire pages deviennent directement des chemins URL, ce qui offre une grande simplicité.

Exemple : src/page/about.tsx ⇒ Le routage devient /about.

App Router : structuration par dossiers et noms de fichiers spécifiques

App Router permet le routage en plaçant des dossiers et des fichiers dans src/app.

Cependant, seuls les fichiers nommés spécifiquement « page » sont traités comme le contenu de la page correspondant à ce chemin de routage.

Exemple : src/app/about/page.tsx ⇒ Le routage devient /about.

Les « fichiers spéciaux » qui caractérisent App Router

Outre page.tsx, App Router offre d'autres fichiers significatifs.

app/
├── page.tsx           --> ページの中身。これが一番よく使うファイル
├── route.tsx          --> APIの定義（page.jsと共存不可）
├── layout.tsx         --> 共通の見た目
├── loading.tsx        --> 読み込み中の画面
├── error.tsx          --> エラー時の画面
├── global-error.tsx   --> グローバルエラー画面
├── templete.tsx       --> 共通の見た目（リセットされるレイアウト）
├── default.tsx        --> デフォルトの画面
└── not-found.tsx      --> notFound関数がスローされたときの画面

Ce qui m'a particulièrement surpris, c'est not-found.tsx. En mettant en place cette page, elle s'affiche automatiquement lors d'un accès à une URL inexistante. J'ai été impressionné par la facilité de mise en œuvre.

Différences de rendu

Dans Pages Router, les composants sont conçus pour devenir interactifs côté client, et le rendu côté serveur vise principalement à accélérer l'affichage initial et améliorer le SEO. Les hooks React comme useState et useEffect peuvent être utilisés librement dans les composants de page et leurs composants enfants.

En revanche, les composants dans app/ du routeur App, sont traités par défaut comme des composants serveur, sauf s'ils sont explicitement marqués autrement. De ce fait, les useState et useEffect – des crochets React – ne peuvent pas être utilisés. Les actions côté client et les gestionnaires d'événements comme onClick ne peuvent pas non plus être utilisés.

Pour passer au CSR avec App Router, il faut alors déclarer use client.

use client

C'est une déclaration de la limite entre composant serveur et composant client. Une fois que use client est déclaré, non seulement ce composant, mais tous les composants importés sont considérés comme des composants client.

Routage dynamique [○○]

Le routage dynamique de Next.js est un mécanisme permettant de gérer les « URL dynamiques » où une partie de l'URL change en fonction de l'utilisateur ou du contenu, comme les pages détaillées d'articles de blog ou de nouvelles.

Par exemple, supposons qu'il y ait des liens menant respectivement vers l'article A et l'article B.

Par exemple, une capture d'écran d'une page avec des liens vers l'article A et l'article B côte à côte

import Link from "next/link";
const linkStyle=`ext-lg font-bold border-b border-primary px-1`

export default function page() {
  return (
    <div>
      <div className="flex gap-6">
        <Link href="/post/A" className={linkStyle}>記事Aへのリンク</Link>
        <Link href="/post/B" className={linkStyle}>記事Bへのリンク</Link>
      </div>
    </div>
  );
}

La destination de chaque lien

Pour utiliser le routage dynamique, si vous créez un fichier nommé [slug], vous pouvez utiliser le même modèle pour post/A comme pour post/B.
*Le nom entre [ ] est arbitraire, il ne doit pas nécessairement être slug

Dans le cas du routeur App:

/app/post/[slug]/page.tsx

export default aysinc function PostPage({ params }: { params: Promise<{ slug: string }>) {
  const {slug}= await params;
  return (
    <div>
      <h1>記事: {slug}</h1>
    </div>
  );
}

Vous utilisez params. params.slug contient la partie [slug] de l'URL.

* params n'a pas eu besoin d'être asynchrone jusqu'à présent, mais à partir de Next.js 15, cela a changé pour être asynchrone. Par conséquent, props doit être défini avec un type Promise.

Dans le cas de Pages Router

/pages/post/[slug].tsx


import { useRouter } from 'next/router';

export default function PostPage() {
  const router = useRouter();
  const { slug } = router.query;

  return (
    <div>
      <h1>記事: {slug}</h1>
    </div>
  );
}

Nous utilisons useRouter. router.query.slug contient la valeur de la portion [slug] de l'URL.

Méthode de récupération des données API

microCMS, qui est très actif dans cette colonne Liberogic, fonctionne bien avec des frameworks comme Next.js.

Dans le cas du routeur App:

Vous pouvez simplement utiliser fetch ou async await.

Cependant, les fichiers déclarés avec use client deviennent CSR, donc async await ne peuvent pas être utilisés !


async function getPost() {
  const res = await fetch(`https://.../api/data/`);

  // エラーハンドリング例
  if (!res.ok) {
     throw new Error(`Failed to fetch post: ${res.status}`);
  }

  return res.json();
}

Destination de l'appel

export default function Example() {
   const data = await getPost()
   // ... data を使って表示 ...
}

Dans le cas de Pages Router

Utilisez getStaticProps pour récupérer les données et les transmettre en tant que props au composant de page.


export async function getServerSideProps(context) {
  // context.req, context.res などにアクセス可能
  const res = await fetch(`https://.../api/data/`, {
     headers: { Cookie: context.req.headers.cookie } // 例: Cookieを渡す
  });
  const data = await res.json();

  return {
    props: {
      data,
    },
  };
}

Destination de l'appel

export default function Example({ data }) {
  // ... data を使って表示 ...
}

Comprendre les deux routeurs et maîtriser Next.js !

Dans mon cas, le premier projet où j'ai utilisé Next.js utilisait l'App Router.

Ensuite, j'ai travaillé sur un autre projet avec le Pages Router, et je me suis demandé : « Pour créer une nouvelle page, dois-je utiliser le nom de fichier index.tsx ou page.tsx ? »

Le contenu de cet article ne couvre qu'une petite partie de Next.js, mais en réexaminant les différences entre l'App Router et le Pages Router, j'ai pu mieux les organiser dans mon esprit.

Personnellement, je trouve la syntaxe de l'App Router plus claire et plus facile à comprendre, mais je veux aussi être capable de maîtriser les projets utilisant le Pages Router.

L'idéal serait de mieux comprendre Next.js en profondeur et de pouvoir choisir le routeur approprié selon le projet ou le type de production !