Topics

Next.js Pages Router en App Router: de vaak verwarrende verschillen verduidelijkt

  • column

Next.js, een populair framework voor webontwikkeling, introduceerde in versie 13 de nieuwe App Router als standaardrouteringssysteem.

Ik weet zeker dat er mensen zijn die betrokken zijn bij projecten waarbij zowel Pages Router als App Router worden gebruikt en die niet weten hoe ze het moeten schrijven. Zo ben ik!

Er zijn met name grote verschillen tussen de Pages Router en de App Router op gebieden die betrekking hebben op de kern van applicatieontwikkeling, zoals het definiëren van routes op basis van bestandsstructuur, het verwerken van dynamische onderdelen van URL's, het werken met rendering en het ophalen van gegevens uit API's.

Ik zal, ter herinnering, de belangrijkste verschillen tussen Pages Router en App Router kort toelichten, zodat u ze beter begrijpt en niet afgeleid wordt. Ik zal de nadruk leggen op de punten die vaak door elkaar worden gehaald.

Verschillen in bestandsroutering

Pages Router: De eenvoud van het omzetten van bestandsnamen in paden

Geplaatst onder de pagina's directory.js, .jsx, .ts, .tsxHet is zo eenvoudig als het omzetten van de bestandsnaam in een URL-pad.

voorbeeld:src/page/about.tsx⇒ Routering is/aboutDat zal het zijn.

App Router: Organiseren op map en specifieke bestandsnaam

App-routersrc/appU kunt routes uitstippelen door er mappen en bestanden onder te plaatsen.

Als u echter een specifieke bestandsnaam met de naam 'pagina' toevoegt aan de bestandsnaam die voor de routering wordt gebruikt, wordt deze behandeld als de inhoud van de pagina die bij dat pad hoort.

voorbeeld:src/app/about/page.tsx⇒ Routering is/aboutDat zal het zijn.

Speciale bestanden die App Router kenmerken

Naast page.tsx zijn er nog andere belangrijke bestanden in App Router.

app/
├── page.tsx --> Pagina-inhoud. Dit is het bestand dat u het vaakst zult gebruiken.
├── route.tsx --> API-definitie (kan niet gelijktijdig met page.js bestaan).
├── layout.tsx --> Algemene weergave.
├── loading.tsx --> Laadscherm.
├── error.tsx --> Foutscherm.
├── global-error.tsx --> Algemeen foutscherm.
├── template.tsx --> Algemene weergave (layout resetten).
├── default.tsx --> Standaardscherm.
└── not-found.tsx --> Scherm dat wordt weergegeven wanneer de functie notFound wordt uitgevoerd.

Wat mij persoonlijk verraste, was not-found.tsx. Alleen al door deze pagina voor te bereiden, wordt deze automatisch weergegeven wanneer je een niet-bestaande URL opent. Ik was onder de indruk van hoe eenvoudig de implementatie was.

Weergaveverschillen

Componenten in de Pages Router zijn in principe ontworpen om interactief te zijn aan de clientzijde. Het renderen aan de serverzijde gebeurt voornamelijk om de initiële weergave te versnellen en voor SEO-doeleinden.useState of useEffectU kunt React Hooks zoals deze gratis gebruiken in uw paginacomponent en de onderliggende componenten daarvan.

Aan de andere kant, App Routerapp/De componenten inTenzij expliciet anders aangegeven, wordt het standaard behandeld als een servercomponent..DaaromuseState of useEffect zoalsReact-hooks zijn niet beschikbaarActies aan de clientzijde, zoals onClickEr zijn ook geen gebeurtenis-handlers beschikbaar.

Om dus een CSR te maken met behulp van App Router,use clientSchrijven:

use client

Servercomponent en clientcomponentGrenzen vaststellenis.use clientAls u dit declareert, worden niet alleen dat onderdeel, maar ook alle importen ervan beschouwd als clientcomponenten.

Dynamische routering [○○]

Next.js biedt een mechanisme voor het verwerken van 'dynamische URL's' waarbij een deel van de URL verandert afhankelijk van de gebruiker of de inhoud, zoals blog- of nieuwsartikeldetailpagina's.Dynamische routeringis.

Stel bijvoorbeeld dat er een link is die u naar artikel A en artikel B brengt.

Bijvoorbeeld een vastlegging 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>
  );
}

Linkbestemmingen

Vastleggen van post/A-pagina
Vastleggen van post/B-pagina

Als u dynamische routering wilt,[slug]Als u een bestand maakt met de naampost/AMaarpost/BMaar u kunt dezelfde sjabloon gebruiken.
*De naamgeving in [ ] is optioneel.slugHet hoeft niet zo te zijn

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

paramsWij gebruiken.params.slugnaar de URL[slug]Het onderdeel zal worden meegeleverd.

paramsVoorheen hoefde parameteracquisitie niet asynchroon te zijn, maar vanaf Next.js 15 is dit gewijzigd naar asynchroon.propsHet lijkt erop dat u het moet definiëren als een Promise-type.

Voor pagina's Rouer

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

useRouterWij gebruiken.router.query.slugnaar de URL[slug]De waarde van het onderdeel wordt ingevuld.

Hoe API-gegevens verkrijgen

microCMS, dat in deze column van Liberogic prominent wordt genoemd, werkt goed met frameworks als Next.js.

App-router

Houd het simpelfetchofaysnc awaitJe kunt gebruiken

Echter,use clientHet bestand dat dit aangeeft, wordt een CSR.aysnc awaitis niet meer bruikbaar!


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

Callee

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

Voor Pages Router

getStaticPropsDe gegevens verkregen met behulp vanpropsnaar het paginacomponent.


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

Callee

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

Begrijp de twee routers en beheers Next.js!

In mijn geval was het eerste project waarvoor ik Next.js gebruikte App Router.

Later, toen ik aan een ander project werkte en Pages Router gebruikte, vroeg ik me af: "Moet de bestandsnaam bij het maken van een nieuwe pagina index.tsx of page.tsx zijn?"

Dit artikel behandelt slechts een klein deel van Next.js, maar door te kijken naar de verschillen tussen App Router en Pages Router kon ik voor mezelf wat duidelijkheid scheppen.

Persoonlijk vind ik het prettig dat het schrijven van App Router zo eenvoudig is, maar ik wil ook Pages Router-projecten kunnen beheren.

De ideale situatie zou zijn dat u een dieper begrip krijgt van Next.js en verschillende routers kunt gebruiken, afhankelijk van het project of de werkzaamheden!

Geschreven door

Ik doe front-end development met JavaScript, React en Next.js, met de focus op markup. Ik word er blij van als een site waaraan ik heb gewerkt succesvol wordt gepubliceerd! Mijn hobby is gitaar spelen. Ik schrijf en speel graag code!

Hiratchi

Front-end engineer / Lid sinds 2022

Bekijk het artikel van deze medewerker

Wij zijn trots op onze betrouwbare teamstructuur en snelle reactiemogelijkheden.

Bij Liberogic stimuleren onze ervaren medewerkers projecten proactief, waardoor we hoog gewaardeerd worden door onze klanten.
Wij zorgen ervoor dat projectmanagers en directeuren correct worden toegewezen om een ​​soepel verloop van het gehele project te garanderen. Wij voorkomen onnodige kostenstijgingen door volledige toezeggingen en wijzen middelen toe aan de juiste mensen op de juiste plaatsen. Bovendien staan ​​we bekend om de snelheid waarmee we de inhoud van het werk begrijpen en offertes opstellen en indienen.

Houd er rekening mee dat we niet actief betrokken zijn bij SES-achtige werkzaamheden op locatie.

We ondersteunen bijna alle belangrijke projectmanagement- en chattools, waaronder Slack, Teams, Redmine, Backlog, Asana, Jira, Notion, Google Workspace, Zoom en Webex.

Bij grootschalige projecten met SES en offshoreHeeft u technische problemen of maakt u zich zorgen over hoe u deze kunt aanpakken?

Casestudy