Les hyperliens sont l'un des joyaux du Web depuis sa création. Selon MDN, les hyperliens sont ce qui fait du Web, un Web. Bien qu'il soit utilisé à des fins telles que la création de liens entre des documents, son utilisation principale consiste à référencer différentes pages Web identifiables par une adresse Web unique ou une URL.

Le routage est un aspect important de chaque application Web, au même titre que les hyperliens vers le Web. C'est un mécanisme par lequel les requêtes sont acheminées vers le code qui les gère. Concernant le routage, les pages Next.js sont référencées et identifiables par un chemin URL unique. Si le Web se compose de pages Web de navigation interconnectées par des hyperliens , chaque application Next.js se compose de pages pouvant être routées (gestionnaires de routes ou routes) interconnectées par un routeur.

Next.js a un support intégré pour le routage qui peut être difficile à décompresser, en particulier lors de l'examen du rendu et de la récupération des données. Comme condition préalable à la compréhension du routage côté client dans Next.js, il est nécessaire d'avoir une vue d'ensemble des concepts tels que le routage, le rendu et la récupération de données dans Next.js.

Cet article sera utile aux développeurs React qui connaissent Next.js et qui souhaitent savoir comment il gère le routage. Vous devez avoir une connaissance pratique de React et Next.js pour tirer le meilleur parti de l'article, qui concerne uniquement le routage côté client et les concepts associés dans Next.js.

Routage et rendu

Le routage et le rendu sont complémentaires et joueront un rôle important tout au long de cet article. J'aime la façon dont Gaurav les explique :

Le routage est le processus par lequel l'utilisateur est dirigé vers différentes pages d'un site Web.

Le rendu est le processus de mise de ces pages sur l'interface utilisateur. Chaque fois que vous demandez un itinéraire vers une page particulière, vous affichez également cette page, mais tous les rendus ne sont pas le résultat d'un itinéraire.

Prenez cinq minutes pour y réfléchir.

Ce que vous devez comprendre à propos du rendu dans Next.js, c'est que chaque page est pré-rendue à l'avance avec le code JavaScript minimal nécessaire pour qu'elle devienne entièrement interactive grâce à un processus appelé hydratation. La manière dont Next.js procède dépend fortement de la forme de pré-rendu : génération statique ou rendu côté serveur , qui sont tous deux fortement couplés à la technique de récupération de données utilisée et séparés par le moment où le code HTML d'une page est généré.

En fonction de vos besoins en matière de récupération de données, vous pouvez vous retrouver à utiliser des fonctions de récupération de données intégrées telles que getStaticProps , getStaticPaths ou getServerSideProps , des outils de récupération de données côté client tels que SWR, react-query ou des approches traditionnelles de récupération de données telles que fetch-on- rendre, récupérer puis rendre, rendre au fur et à mesure que vous récupérez (avec Suspense).

Le pré-rendu (avant le rendu - à l'interface utilisateur ) est complémentaire du routage et fortement couplé à la récupération de données - un sujet à part entière dans Next.js. Ainsi, bien que ces concepts soient complémentaires ou étroitement liés, cet article se concentrera uniquement sur la simple navigation entre les pages (routage), avec des références à des concepts connexes si nécessaire.

Avec cela à l'écart, commençons par l'essentiel : Next.js a un routeur basé sur le système de fichiers construit sur le concept de pages.

pages

Les pages dans Next.js sont des composants React qui sont automatiquement disponibles en tant que routes. Ils sont exportés en tant qu'exportations par défaut à partir du répertoire des pages avec des extensions de fichier prises en charge telles que .js , .jsx , .ts ou .tsx .

Une application Next.js typique aura une structure de dossiers avec des répertoires de niveau supérieur tels que pages , public et styles .

 next-app ├── node_modules ├── pages │ ├── index.js // path: base-url (/) │ ├── books.jsx // path: /books │ └── book.ts // path: /book ├── public ├── styles ├── .gitignore ├── package.json └── README.md

Chaque page est un composant React :

 // pages/books.js — `base-url/book` export default function Book() { return
 Livres
}

Remarque : Gardez à l'esprit que les pages peuvent également être appelées "gestionnaires de route".

Pages personnalisées

Ce sont des pages spéciales qui résident dans le répertoire des pages mais ne participent pas au routage. Ils sont précédés du symbole de soulignement, comme dans _app.js et _document.js .

• _app.js
  Il s'agit d'un composant personnalisé qui réside dans le dossier pages. Next.js utilise ce composant pour initialiser les pages.
• _document.js
  Comme _app.js , _document.js est un composant personnalisé que Next.js utilise pour augmenter les balises <html> et <body> de vos applications. Cela est nécessaire car les pages Next.js ignorent la définition du balisage du document environnant.

 next-app ├── node_modules ├── pages │ ├── _app.js // ️ Custom page (unavailable as a route) │ ├── _document.jsx // ️ Custom page (unavailable as a route) │ └── index.ts // path: base-url (/) ├── public ├── styles ├── .gitignore ├── package.json └── README.md

Lien entre les pages

Next.js expose un composant Link de l'API next/link qui peut être utilisé pour effectuer des transitions de route côté client entre les pages.

 // Import the <Link/> component import Link from "next/link"; // This could be a page component export default function TopNav() { return ( <nav> <Link href="/">Home</Link> <Link href="/">Publications</Link> <Link href="/">About</Link> </nav> ) } // This could be a non-page component export default function Publications() { return ( <section> <TopNav/> {/* ... */} </section> ) }

Le composant Link peut être utilisé à l'intérieur de n'importe quel composant, page ou non. Lorsqu'il est utilisé dans sa forme la plus basique comme dans l'exemple ci-dessus, le composant Link se traduit par un lien hypertexte avec un attribut href . (Plus d'informations sur le Link dans la section suivante/lien ci-dessous.)

Routage

Le système de routage basé sur des fichiers Next.js peut être utilisé pour définir les modèles de routage les plus courants. Pour tenir compte de ces modèles, chaque route est séparée en fonction de sa définition.

Indexer les itinéraires

Par défaut, dans votre application Next.js, la route initiale/par défaut est pages/index.js qui sert automatiquement de point de départ de votre application en tant que / . Avec une URL de base de localhost:3000 , cette route d'index est accessible au niveau de l'URL de base de l'application dans le navigateur.

Les routes d'index agissent automatiquement comme route par défaut pour chaque répertoire et peuvent éliminer les redondances de nommage. La structure de répertoires ci-dessous expose deux chemins d'accès : / et /home .

 next-app └── pages ├── index.js // path: base-url (/) └── home.js // path: /home

L'élimination est plus évidente avec les routes imbriquées .

Itinéraires imbriqués

Un itinéraire comme pages/book est profond d'un niveau. Pour aller plus loin, il faut créer des itinéraires imbriqués, ce qui nécessite une structure de dossiers imbriqués. Avec une URL de base de https://www.smashingmagazine.com , vous pouvez accéder à la route https://www.smashingmagazine.com/printed-books/printed-books en créant une structure de dossiers similaire à celle ci-dessous :

 next-app └── pages ├── index.js // top index route └── printed-books // nested route └── printed-books.js // path: /printed-books/printed-books

Ou éliminez la redondance des chemins avec des routes d'index et accédez à la route des livres imprimés sur https://www.smashingmagazine.com/printed-books .

 next-app └── pages ├── index.js // top index route └── printed-books // nested route └── index.js // path: /printed-books

Les routes dynamiques jouent également un rôle important dans l'élimination des redondances.

Itinéraires dynamiques

À partir de l'exemple précédent, nous utilisons la route d'index pour accéder à tous les livres imprimés. Pour accéder à des livres individuels, il faut soit créer des itinéraires différents pour chaque livre, comme :

 // ️ Don't do this. next-app └── pages ├── index.js // top index route └── printed-books // nested route ├── index.js // path: /printed-books ├── typesript-in-50-lessons.js // path: /printed-books/typesript-in-50-lessons ├── checklist-cards.js // path: /printed-books/checklist-cards ├── ethical-design-handbook.js // path: /printed-books/ethical-design-handbook ├── inclusive-components.js // path: /printed-books/inclusive-components └── click.js // path: /printed-books/click

qui est hautement redondant, non évolutif et peut être corrigé avec des routes dynamiques telles que :

 // Do this instead. next-app └── pages ├── index.js // top index route └── printed-books ├── index.js // path: /printed-books └── [book-id].js // path: /printed-books/:book-id

La syntaxe des crochets - [book-id] - est le segment dynamique et n'est pas limitée aux seuls fichiers. Il peut également être utilisé avec des dossiers comme dans l'exemple ci-dessous, rendant l'auteur disponible sur la route /printed-books/:book-id/author .

 next-app └── pages ├── index.js // top index route └── printed-books ├── index.js // path: /printed-books └── [book-id] └── author.js // path: /printed-books/:book-id/author

Le ou les segments dynamiques d'une route sont exposés en tant que paramètre de requête accessible dans n'importe quel composant de connexion impliqué dans la route avec l'objet de query du crochet useRouter() — (Plus d'informations à ce sujet dans la section API suivante/routeur ).

 // printed-books/:book-id import { useRouter } from 'next/router'; export default function Book() { const { query } = useRouter(); return ( <div> <h1> book-id <em>{query['book-id']}</em> </h1> </div> ); }

 // /printed-books/:book-id/author import { useRouter } from 'next/router'; export default function Author() { const { query } = useRouter(); return ( <div> <h1> Fetch author with book-id <em>{query['book-id']}</em> </h1> </div> ); }

Extension des segments de route dynamiques avec Catch All Routes

Vous avez vu la syntaxe du support de segment de route dynamique comme dans l'exemple précédent avec [book-id].js . La beauté de cette syntaxe est qu'elle va encore plus loin avec Catch-All Routes . Vous pouvez déduire ce que cela fait à partir du nom : il capte toutes les routes.

Lorsque nous avons examiné l'exemple dynamique, nous avons appris comment il aide à éliminer la redondance de la création de fichiers pour qu'un seul itinéraire accède à plusieurs livres avec leur ID. Mais il y a autre chose que nous aurions pu faire.

Plus précisément, nous avions le chemin /printed-books/:book-id , avec une structure de répertoires :

 next-app └── pages ├── index.js └── printed-books ├── index.js └── [book-id].js

Si nous mettions à jour le chemin pour avoir plus de segments comme des catégories, nous pourrions nous retrouver avec quelque chose comme : /printed-books/design/:book-id , /printed-books/engineering/:book-id , ou mieux encore /printed-books/:category/:book-id .

Ajoutons l'année de sortie : /printed-books/:category/:release-year/:book-id . Est-ce que vous pouvez voir un motif? La structure du répertoire devient :

 next-app └── pages ├── index.js └── printed-books └── [category] └── [release-year] └── [book-id].js

Nous avons remplacé l'utilisation de fichiers nommés par des routes dynamiques, mais nous nous sommes quand même retrouvés avec une autre forme de redondance. Eh bien, il y a un correctif : Catch All Routes qui élimine le besoin d'itinéraires profondément imbriqués :

 next-app └── pages ├── index.js └── printed-books └── [...slug].js

Il utilise la même syntaxe de crochet sauf qu'il est préfixé par trois points. Pensez aux points comme à la syntaxe de propagation JavaScript. Vous vous demandez peut-être : si j'utilise les itinéraires fourre-tout, comment puis-je accéder à la catégorie ( [category] ) et à l'année de sortie ( [release-year] ). Deux façons:

1. Dans le cas de l'exemple des livres imprimés, l'objectif final est le livre, et chaque information de livre aura ses métadonnées jointes, ou
2. Les segments "slug" sont renvoyés sous la forme d'un tableau de paramètre(s) de requête.

 import { useRouter } from 'next/router'; export default function Book() { const { query } = useRouter(); // There's a brief moment where `slug` is undefined // so we use the Optional Chaining (?.) and Nullish coalescing operator (??) // to check if slug is undefined, then fall back to an empty array const [category, releaseYear, bookId] = query?.slug ?? []; return ( <table> <tbody> <tr> <th>Book Id</th> <td>{bookId}</td> </tr> <tr> <th>Category</th> <td>{category}</td> </tr> <tr> <th>Release Year</th> <td>{releaseYear}</td> </tr> </tbody> </table> ); }

Voici d'autres exemples pour la route /printed-books/[…slug] :

Comme c'est le cas avec la route fourre-tout, la route /printed-books génère une erreur 404 à moins que vous ne fournissiez une route d'index de secours.

 next-app └── pages ├── index.js └── printed-books ├── index.js // path: /printed-books └── [...slug].js

En effet, la route fourre-tout est "stricte". Soit il correspond à un slug, soit il génère une erreur. Si vous souhaitez éviter de créer des routes d'index parallèlement aux routes fourre-tout, vous pouvez utiliser les routes fourre-tout facultatives à la place.

Extension des segments de route dynamiques avec des routes fourre-tout facultatives

La syntaxe est la même que pour les routes fourre-tout, mais avec des doubles crochets à la place.

 next-app └── pages ├── index.js └── printed-books └── [[...slug]].js

Dans ce cas, la route fourre-tout (slug) est facultative et, si elle n'est pas disponible, revient au chemin /printed-books , rendu avec le gestionnaire de route [[…slug]].js , sans aucun paramètre de requête.

Utilisez les itinéraires fourre-tout avec les itinéraires d'index ou les itinéraires fourre-tout facultatifs seuls. Évitez d'utiliser des itinéraires fourre-tout et optionnels fourre-tout à côté.

Priorité des itinéraires

La capacité de pouvoir définir les schémas de routage les plus courants peut être un « cygne noir ». La possibilité que des itinéraires se heurtent est une menace imminente, surtout lorsque vous commencez à travailler sur des itinéraires dynamiques.

Lorsque cela a du sens, Next.js vous informe des conflits de route sous la forme d'erreurs. Quand ce n'est pas le cas, il applique la priorité aux routes en fonction de leur spécificité.

Par exemple, c'est une erreur d'avoir plus d'une route dynamique au même niveau.

 // This is an error // Failed to reload dynamic routes: Error: You cannot use different slug names for the // same dynamic path ('book-id' !== 'id'). next-app └── pages ├── index.js └── printed-books ├── [book-id].js └── [id].js

Si vous regardez attentivement les itinéraires définis ci-dessous, vous remarquerez le potentiel d'affrontements.

 // Directory structure flattened for simplicity next-app └── pages ├── index.js // index route (also a predefined route) └── printed-books ├── index.js ├── tags.js // predefined route ├── [book-id].js // handles dynamic route └── [...slug].js // handles catch all route

Par exemple, essayez de répondre à ceci : quelle route gère le chemin /printed-books/inclusive-components ?

• /printed-books/[book-id].js , ou
• /printed-books/[…slug].js .

La réponse réside dans la "spécificité" des gestionnaires de route. Les itinéraires prédéfinis viennent en premier, suivis des itinéraires dynamiques, puis des itinéraires fourre-tout. Vous pouvez considérer le modèle de demande/gestion de route comme un pseudo-code avec les étapes suivantes :

1. Existe-t-il un gestionnaire d'itinéraire prédéfini qui peut gérer l'itinéraire ?
   • true — traite la demande de route.
   • false — passez à 2.
2. Existe-t-il un gestionnaire de route dynamique capable de gérer la route ?
   • true — traite la demande de route.
   • false — passez à 3.
3. Existe-t-il un gestionnaire d'itinéraire fourre-tout capable de gérer l'itinéraire ?
   • true — traite la demande de route.
   • false - renvoie une page 404 introuvable.

Par conséquent, /printed-books/[book-id].js gagne.

Voici d'autres exemples :

L'API next/link

L'API next/link expose le composant Link comme un moyen déclaratif d'effectuer des transitions de route côté client.

 import Link from 'next/link' function TopNav() { return ( <nav> <Link href="/">Smashing Magazine</Link> <Link href="/articles">Articles</Link> <Link href="/guides">Guides</Link> <Link href="/printed-books">Books</Link> </nav> ) }

Le composant Link se résoudra en un lien hypertexte HTML normal. Autrement dit, <Link href="/">Smashing Magazine</Link> sera résolu en <a href="/">Smashing Magazine</a> .

La prop href est la seule prop requise pour le composant Link . Consultez la documentation pour une liste complète des accessoires disponibles sur le composant Link .

Il existe d'autres mécanismes du composant Link dont il faut être conscient.

Itinéraires avec segments dynamiques

Avant Next.js 9.5.3, la Link aux routes dynamiques signifiait que vous deviez fournir à la fois href et as prop à Link comme dans :

 import Link from 'next/link'; const printedBooks = [ { name: 'Ethical Design', id: 'ethical-design' }, { name: 'Design Systems', id: 'design-systems' }, ]; export default function PrintedBooks() { return printedBooks.map((printedBook) => ( <Link href="/printed-books/[printed-book-id]" as={`/printed-books/${printedBook.id}`} > {printedBook.name} </Link> )); }

Bien que cela ait permis à Next.js d'interpoler le href pour les paramètres dynamiques, c'était fastidieux, sujet aux erreurs et quelque peu impératif, et a maintenant été corrigé pour la majorité des cas d'utilisation avec la sortie de Next.js 10.

Ce correctif est également rétrocompatible. Si vous avez utilisé à la fois as et href , rien ne casse. Pour adopter la nouvelle syntaxe, supprimez la prop href et sa valeur, et renommez la prop as en href comme dans l'exemple ci-dessous :

 import Link from 'next/link'; const printedBooks = [ { name: 'Ethical Design', id: 'ethical-design' }, { name: 'Design Systems', id: 'design-systems' }, ]; export default function PrintedBooks() { return printedBooks.map((printedBook) => ( <Link href={`/printed-books/${printedBook.id}`}>{printedBook.name}</Link> )); }

Voir Résolution automatique de href.

Cas d'utilisation pour la prop passHref

Regardez attentivement l'extrait ci-dessous:

 import Link from 'next/link'; const printedBooks = [ { name: 'Ethical Design', id: 'ethical-design' }, { name: 'Design Systems', id: 'design-systems' }, ]; // Say this has some sort of base styling attached function CustomLink({ href, name }) { return <a href={href}>{name}</a>; } export default function PrintedBooks() { return printedBooks.map((printedBook) => ( <Link href={`/printed-books/${printedBook.id}`} passHref> <CustomLink name={printedBook.name} /> </Link> )); }

Les props passHref forcent le composant Link à transmettre la prop href au composant enfant CustomLink . Ceci est obligatoire si le composant Link recouvre un composant qui renvoie une balise de lien hypertexte <a> . Votre cas d'utilisation peut être dû au fait que vous utilisez une bibliothèque comme des composants stylés, ou si vous devez transmettre plusieurs enfants au composant Link , car il n'attend qu'un seul enfant.

Consultez la documentation pour en savoir plus.

Objets URL

Le prop href du composant Link peut également être un objet URL avec des propriétés telles que query qui est automatiquement formatée en une chaîne d'URL.

Avec l'objet printedBooks , l'exemple ci-dessous sera lié à :

1. /printed-books/ethical-design?name=Ethical+Design and
2. /printed-books/design-systems?name=Design+Systems .

 import Link from 'next/link'; const printedBooks = [ { name: 'Ethical Design', id: 'ethical-design' }, { name: 'Design Systems', id: 'design-systems' }, ]; export default function PrintedBooks() { return printedBooks.map((printedBook) => ( <Link href={{ pathname: `/printed-books/${printedBook.id}`, query: { name: `${printedBook.name}` }, }} > {printedBook.name} </Link> )); }

Si vous incluez un segment dynamique dans le pathname , vous devez également l'inclure en tant que propriété dans l'objet de requête pour vous assurer que la requête est interpolée dans le pathname :

 import Link from 'next/link'; const printedBooks = [ { name: 'Ethical Design', id: 'ethical-design' }, { name: 'Design Systems', id: 'design-systems' }, ]; // In this case the dynamic segment `[book-id]` in pathname // maps directly to the query param `book-id` export default function PrintedBooks() { return printedBooks.map((printedBook) => ( <Link href={{ pathname: `/printed-books/[book-id]`, query: { 'book-id': `${printedBook.id}` }, }} > {printedBook.name} </Link> )); }

L'exemple ci-dessus contient des chemins :

1. /printed-books/ethical-design , et
2. /printed-books/design-systems .

Si vous inspectez l'attribut href dans VSCode, vous trouverez le type LinkProps , avec la propriété href un type Url , qui est soit une string soit UrlObject comme mentionné précédemment.

L'inspection de l' UrlObject mène ensuite à l'interface avec les propriétés :

Vous pouvez en savoir plus sur ces propriétés dans la documentation du module d'URL Node.js.

Un cas d'utilisation du hachage consiste à créer un lien vers des sections spécifiques d'une page.

 import Link from 'next/link'; const printedBooks = [{ name: 'Ethical Design', id: 'ethical-design' }]; export default function PrintedBooks() { return printedBooks.map((printedBook) => ( <Link href={{ pathname: `/printed-books/${printedBook.id}`, hash: 'faq', }} > {printedBook.name} </Link> )); }

Le lien hypertexte se résoudra en /printed-books/ethical-design#faq .

En savoir plus dans la documentation.

L'API next/router

Si le next/link est déclaratif, alors le next/router est impératif. Il expose un crochet useRouter qui permet d'accéder à l'objet router à l'intérieur de n'importe quel composant de fonction. Vous pouvez utiliser ce crochet pour effectuer manuellement le routage, plus particulièrement dans certains scénarios où le next/link ne suffit pas, ou lorsque vous devez « vous connecter » au routage.

 import { useRouter } from 'next/router'; export default function Home() { const router = useRouter(); function handleClick(e) { e.preventDefault(); router.push(href); } return ( <button type="button" onClick={handleClick}>Click me</button> ) }

useRouter est un crochet React et ne peut pas être utilisé avec des classes. Besoin de l'objet router dans les composants de classe ? Utiliser withRouter .

 import { withRouter } from 'next/router'; function Home({router}) { function handleClick(e) { e.preventDefault(); router.push(href); } return ( <button type="button" onClick={handleClick}>Click me</button> ) } export default withRouter(Home);

L'objet router

Le crochet useRouter et le composant d'ordre supérieur withRouter renvoient un objet routeur avec des propriétés telles que pathname , query , asPath et basePath qui vous donne des informations sur l'état de l'URL de la page actuelle, locale , locales et defaultLocale qui donne des informations sur le paramètres régionaux par défaut actifs, pris en charge ou actuels.

L'objet routeur a également des méthodes telles que push pour naviguer vers une nouvelle URL en ajoutant une nouvelle entrée d'URL dans la pile d'historique, replace , similaire à push mais remplace l'URL actuelle au lieu d'ajouter une nouvelle entrée d'URL dans la pile d'historique.

En savoir plus sur l'objet routeur.

Configuration de route personnalisée avec next.config.js

Il s'agit d'un module Node.js standard qui peut être utilisé pour configurer certains comportements de Next.js.

 module.exports = { // configuration options }

N'oubliez pas de redémarrer votre serveur chaque fois que vous mettez à jour next.config.js . Apprendre encore plus.

Chemin de base

Il a été mentionné que la route initiale/par défaut dans Next.js est pages/index.js avec le chemin / . Ceci est configurable et vous pouvez faire de votre route par défaut un sous-chemin du domaine.

 module.exports = { // old default path: / // new default path: /dashboard basePath: '/dashboard', };

Ces modifications prendront automatiquement effet dans votre application avec tous les chemins / acheminés vers /dashboard .

Cette fonctionnalité ne peut être utilisée qu'avec Next.js 9.5 et supérieur. Apprendre encore plus.

Barre oblique finale

Par défaut, une barre oblique finale ne sera pas disponible à la fin de chaque URL. Cependant, vous pouvez changer cela avec:

 module.exports = { trailingSlash: true };

 # trailingSlash: false /printed-books/ethical-design#faq # trailingSlash: true /printed-books/ethical-design/#faq

Les fonctionnalités de chemin de base et de barre oblique de fin ne peuvent être utilisées qu'avec Next.js 9.5 et versions ultérieures.

Conclusion

Le routage est l'une des parties les plus importantes de votre application Next.js, et il se reflète dans le routeur basé sur le système de fichiers construit sur le concept de pages. Les pages peuvent être utilisées pour définir les modèles de route les plus courants. Les concepts de routage et de rendu sont étroitement liés. Prenez les leçons de cet article avec vous lorsque vous créez votre propre application Next.js ou travaillez sur une base de code Next.js. Et consultez les ressources ci-dessous pour en savoir plus.

Ressources associées

• Documentation officielle Next.js pour les pages
• Documentation officielle Next.js pour la récupération de données
• Documentation officielle de Next.js pour next.config.js
• Next.js 10 : résolution automatique de href
• Documentation officielle de Next.js pour next/link
• Documentation officielle Next.js pour next/router