Next.js Pages Router en App Router: de verwarrende verschillen opgehelderd

Next.js, een webontwikkelings-framework dat veel steun geniet, introduceerde in versie 13 een nieuwe App Router als het standaardrouting-systeem.

Wanneer je met beide Pages Router en App Router projecten werkt, kan het gebeuren dat je denkt: 'Welke schrijfwijze gebruikte ik ook alweer?' En ja, dat gebeurt mij ook!

Vooral in kerngebieden van applicatieontwikkeling bestaan er aanzienlijke verschillen tussen Pages Router en App Router. Dit begint met hoe routering op basis van bestandsstructuur wordt gedefinieerd, vervolgt met hoe dynamische URL-onderdelen worden behandeld, gaat over de rendering-mechanica, en omvat ook ophalen van gegevens van API's.

Met focus op de punten die vaak door elkaar worden gehaald, zal ik hier de belangrijkste verschillen tussen Pages Router en App Router kort samenvatten als referentie!

Verschil in bestandsrouting

Pages Router: eenvoud waarbij bestandsnamen rechtstreeks het pad worden

De eenvoud van Pages Router is dat bestandsnamen van .js, .jsx, .ts, .tsx bestanden in de pages-directory rechtstreeks het URL-pad vormen.

Voorbeeld: src/page/about.tsx　⇒　De routing wordt: /about

App Router: gestructureerd met mappen en specifieke bestandsnamen

Met App Router kun je mappen en bestanden onder src/app plaatsen om routing in te stellen.

Echter: bestanden met de specifieke naam 'page' worden behandeld als de inhoud van de pagina die overeenkomt met dat pad.

Voorbeeld: src/app/about/page.tsx　⇒　De routing wordt: /about

De "speciale bestanden" die App Router karakteriseren

Naast page.tsx zijn er in App Router andere bestanden met bijzondere betekenis.

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関数がスローされたときの画面

Wat me persoonlijk opviel is not-found.tsx. Als je dit bestand toevoegt, wordt het automatisch weergegeven wanneer bezoekers een niet-bestaande URL openen. Ik was aangenaam verrast hoe eenvoudig dit te implementeren is.

Verschillen in rendering

In Pages Router zijn componenten in principe bedoeld om interactief te zijn aan de clientzijde, en server-side rendering wordt vooral gebruikt voor snellere initiële weergave en SEO. React-hooks zoals useState en useEffect kunnen vrij worden gebruikt in paginacomponenten en hun onderliggende componenten.

Aan de andere kant worden componenten in de app/ map van App Router standaard als servercomponenten behandeld, tenzij expliciet anders aangegeven. Daarom kunnen hooks als useState en useEffect van React niet worden gebruikt. Ook kunnen event handlers zoals onClick aan de clientzijde niet worden gebruikt.

Om CSR in App Router in te schakelen, schrijft u use client.

use client

Dit is de grens tussen Server Component en Client Component. Wanneer u use client declareert, wordt niet alleen dat component, maar ook alles wat het importeert als Client Component beschouwd.

Dynamische routering [○○]

Dynamische routering in Next.js is een mechanisme om "dynamische URL's" te ondersteunen, waarbij onderdelen van de URL veranderen op basis van gebruikers of inhoud, zoals in artikel-detailpagina's op blogs of nieuwssites.

Stel dat u links hebt die naar artikel A en artikel B navigeren.

Bijvoorbeeld een schermafbeelding van een pagina met links naar artikel A en artikel B

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>
  );
}

De navigatiebestemming van elke link

Als u dynamische routering wilt gebruiken, kunt u een bestand maken met de naam [slug], zodat zowel post/A als post/B dezelfde template kunnen gebruiken.
*De naamgeving van [ ] is willekeurig, dus het hoeft niet slug te zijn

In het geval van App Router

/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>
  );
}

U gebruikt params. params.slug bevat het [slug] gedeelte van de URL.

* params parameter ophalen hoefde tot nu toe niet asynchrone te zijn, maar vanaf Next.js 15 is dit gewijzigd om asynchrone uit te voeren. Daarom moet props als Promise-type worden gedefinieerd.

In het geval van 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>
  );
}

We gebruiken useRouter. In router.query.slug staat de waarde van het gedeelte [slug] van de URL.

API-gegevensprocedure ophalen

microCMS, dat ook actief wordt gebruikt in deze Liberogic-kolom, werkt goed samen met frameworks zoals Next.js.

In het geval van App Router

Je kunt eenvoudig fetch of async await gebruiken.

Echter, bestanden waarin use client is gedeclareerd, worden CSR, dus async await kan niet worden gebruikt!


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();
}

Oproepbestemming

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

In het geval van Pages Router

Gebruik getStaticProps en geef de opgehaalde gegevens door als props aan het pagina-component.


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,
    },
  };
}

Oproepbestemming

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

Begrijp twee routers en beheers Next.js volledig!

In mijn geval was mijn eerste project met Next.js met App Router.

Later raakte ik Pages Router aan in een ander project en dacht: "Moet ik index.tsx of page.tsx gebruiken voor een nieuw pagina?"

Deze inhoud is slechts een klein deel van Next.js, maar door de verschillen tussen App Router en Pages Router opnieuw te onderzoeken, kon ik mijn kennis beter organiseren.

Persoonlijk vind ik de schrijfstijl van App Router duidelijker en aangenamer, maar ik wil ook goed voorbereid zijn op projecten met Pages Router.

Het ideaal is om Next.js dieper te begrijpen en de verschillende routers naar behoefte per project of eindresultaat in te kunnen zetten!