Maîtriser la gestion des erreurs Next.js avec le routeur d’application —

Dans cet article, nous allons apprendre à gérer les erreurs dans Next.js avec App Router et les nouvelles conventions de fichiers d’erreurs dans Next.js.

La gestion des erreurs est un aspect clé du développement de toute application Web, et dans le passé, Next.js a aidé les développeurs avec cette expérience grâce à des pages d’erreur personnalisées comme les pages 404 et 500.

Cependant, ces pages ont leurs limites dans le Routeur de pagestelles que la prise en charge limitée d’intégrations d’interface utilisateur spécifiques, la prise en charge obsolète des limites d’erreur React et la fonctionnalité limitée de l’application lorsque des erreurs se produisent.

Mais avec la sortie de Next.js version 13.4le nouveau Routeur d’application a été marqué stable pour la production. Le routeur d’applications améliore la prise en charge et l’expérience des développeurs pour la gestion des erreurs et d’autres éléments essentiels de la création d’applications Web.

Le scénario et la mise en place

Pour faciliter la compréhension de la nouvelle API de gestion des erreurs, nous allons explorer sa mise en œuvre dans une application Next.js pour l’authentification des utilisateurs.

L’authentification des utilisateurs est sujette à de nombreuses erreurs, donc apprendre à gérer les erreurs dans ce contexte vous sera très utile lorsque vous créerez d’autres applications.

Avant de commencer, obtenez le code de l’application de démonstration que nous utiliserons dans l’article en clonant le référentiel lié ici (sur la branche principale). Une fois que vous avez exécuté l’application, vous devriez voir l’erreur illustrée ci-dessous.

Dans cette application de démonstration, la page principale – qui affiche un tableau – n’est accessible qu’aux utilisateurs connectés, mais une erreur (dans ce cas, d’origine humaine, mais cela peut légitimement se produire) s’est produite et a conduit à la session variable assignée comme null.

Remarque : l’authentification ne sera pas implémentée dans l’application de démonstration par souci de simplicité.

Cela conduit bien sûr à une erreur, et en ce moment, l’application se bloque complètement, car elle ne sait pas comment gérer l’erreur !

Nous allons maintenant apprendre à gérer cette erreur pour empêcher notre application de planter, améliorant ainsi considérablement l’UX de l’application.

Création de la page d’erreur

Pour éviter que l’application ne plante, dans le app/ répertoire, créez un error.tsx déposer. La création de ce fichier crée automatiquement une limite d’erreur React qui enveloppe la page principale. Puis, dans le error.tsx fichier, exportez la fonction suivante :

"use client";

export default function Error() {
  return (
    <div className="grid h-screen px-4 bg-white place-content-center">
      <div className="text-center">
        <h1 className="font-black text-gray-200 text-9xl">401</h1>

        <p className="text-2xl font-bold tracking-tight text-gray-900 sm:text-4xl">
          Unauthroized!
        </p>

        <p className="mt-4 text-gray-500">
          You must be logged in to access the page
        </p>

        <button
          type="button"
          className="inline-block px-5 py-3 mt-6 text-sm font-medium text-white bg-indigo-600 rounded hover:bg-indigo-700 focus:outline-none focus:ring"
        >
          Try Again
        </a>
      </div>
    </div>
  );
}

Remarque : les composants d’erreur doivent être des composants clients ! Assurez-vous de les marquer comme tels.

La fonction exportée agira comme un composant de secours. Si une erreur est renvoyée dans la limite, l’erreur sera interceptée et le composant de secours sera rendu, qui devrait apparaître comme indiqué ci-dessous.

Deux accessoires sont transmis au composant de secours d’erreur lorsqu’une erreur se produit – l’objet d’erreur lui-même et une fonction pour essayer de récupérer de l’erreur (généralement appelée reset):

"use client";

type ErrorProps = {
  error: Error;
  reset: () => void;
};

export default function Error({ error, reset }: ErrorProps) {
  
}

Nous pouvons maintenant accéder au message d’erreur via le error prop et affichez-le à l’écran comme suit :

<p className="mt-4 text-gray-500">
  {error.message || "You must be logged in to access the page"}
</p>

La fonction de réinitialisation essaiera de restituer le contenu d’origine entouré par la limite d’erreur lorsque la fonction est appelée. Si cela réussit, le composant d’erreur de secours sera remplacé par le contenu du rendu.

Nous pouvons implémenter l’appel de la fonction de réinitialisation dans notre bouton avec un onClick gestionnaire :

<button
  type="button"
  onClick={() => reset()}
  className="inline-block px-5 py-3 mt-6 text-sm font-medium text-white bg-indigo-600 rounded hover:bg-indigo-700 focus:outline-none focus:ring cursor-pointer"
>
  Try Again
</button>

Et avec cela, nous avons réussi à gérer notre erreur !

Résumé du message d’erreur

Dans une application réelle avec authentification de l’utilisateur, il y aura probablement de nombreuses routes à protéger, ce qui nécessite plusieurs instances du même message d’erreur d’authentification en cas d’erreur d’authentification.

Pour résumer le message d’erreur (et ne pas l’écrire plusieurs fois), nous pouvons facilement créer une exception personnalisée relative à l’authentification.

Pour ce faire, créez un répertoire appelé lib et créer un fichier dans ce répertoire appelé exceptions.ts. Dans ce fichier, nous pouvons créer et exporter l’exception d’erreur d’authentification personnalisée comme suit :

export class AuthRequiredError extends Error {
  constructor(message = "Auth is required to access this page") {
    super(message);
    this.name = "AuthRequiredError";
  }
}

Nous pouvons maintenant lancer cette nouvelle coutume AuthRequiredError sur la page principale au lieu de l’habituel Error:

export default function Home() {
  if (!session) throw new AuthRequiredError();
  
}

L’erreur nous donnera soit le message par défaut passé dans le constructeur, soit une erreur plus spécifique que nous devrons peut-être transmettre ultérieurement.

En savoir plus sur la gestion des erreurs

Terminons par quelques éléments supplémentaires à noter concernant les erreurs de mise en page et les erreurs de serveur.

Erreurs dans les mises en page

Les erreurs peuvent se produire n’importe où dans une application (pas seulement page.tsx files), et le système de routage de fichiers utilisé par Next.js influence la façon dont error.tsx les limites fonctionnent sur les itinéraires et les mises en page imbriqués.

Les erreurs remontent jusqu’à la limite d’erreur parent la plus proche, qui peut être vue dans le diagramme ci-dessous.

Cette nature de bouillonnement d’erreurs signifie qu’un error.tsx La limite n’attrapera pas d’erreur dans un fichier de mise en page sur le même segment, car la limite d’erreur enveloppe le fichier de mise en page.

Si une erreur se produit dans la mise en page racine ou le modèle, utilisez un global-error.tsx fichier, comme illustré ci-dessous.

Le global-error.tsx limite enveloppe l’ensemble de l’application, alors assurez-vous d’ajouter votre propre <html> et <body> balises lors de l’utilisation de ce fichier.

Cette limite d’erreur intercepte toutes les erreurs qui n’ont pas été interceptées par d’autres error.tsx limites, et en tant que tel, il ne sera pas activé souvent.

Erreurs de serveur

Dans le cas où une erreur se produit dans un composant du serveur ou lors de la récupération des données, Next.js transmettra le correspondant Error objet au plus proche error.tsx frontière.

Conclusion et prochaines étapes

Bien que de nombreux développeurs considèrent la mise en œuvre de la gestion des erreurs comme un problème, il s’agit d’une partie essentielle d’une application, et la mise en œuvre réussie de la gestion des erreurs améliorera considérablement l’expérience utilisateur de l’application.

Next.js rend cela incroyablement simple à faire avec l’aide du routeur d’application et du error.tsx convention de fichier.

Vous pouvez consulter le Documents Next.js sur la gestion des erreurs pour en savoir plus sur la gestion des erreurs, et vous pouvez voir le code fini de cet article sur GitHub.