Next.js v— Réflexion sur les erreurs

Bonjour ! Ceci est un autre article sur next.js. Et enfin, à propos de la nouvelle version ! Chaque version est un ensemble de fonctionnalités nouvelles, intéressantes et controversées. Cette version ne fera pas exception. Cependant, la nouvelle version n'est pas tant intéressante pour ses nouvelles fonctionnalités que pour le changement de priorités et d'organisation dans next.js. Et oui, comme vous l'avez peut-être deviné d'après le titre, une partie importante de cette version est précieuse pour réfléchir aux erreurs précédentes.

Je travaille avec next.js depuis la version 8 environ. Pendant tout ce temps, j'ai suivi son développement avec intérêt (parfois non sans déception). Récemment, j'ai publié une série d'articles sur les difficultés avec le nouveau routeur d'applications - "Routeur d'applications Next.js. Un chemin vers le futur ou un mauvais tournant", "Mise en cache Next.js. Un cadeau ou une malédiction", " Plus de bibliothèques pour le dieu des bibliothèques ou comment j'ai repensé i18n". Tout cela était le résultat d’un très faible développement d’idées et de capacités dans les versions précédentes de next.js. Et pour cette raison, mon intérêt pour la nouvelle version n’a fait que croître. Parallèlement à cela, il y a une volonté de comprendre le vecteur de changements dans le cadre.

Dans cet article, je ne m'attarderai pas sur ce que sont les composants App Router ou serveur - ceux-ci sont décrits en détail dans les articles précédents. Nous nous concentrerons uniquement sur la nouvelle version et uniquement sur les nouvelles modifications.

Remarque : L'article reflète les changements les plus intéressants du point de vue de l'auteur. Ils diffèrent de la liste officielle, car l'auteur les a sélectionnés à partir des commits et des PR dans le cadre.

Sortie de Next.js v15

Tout d'abord, un peu sur les changements dans les processus de développement internes de next.js. Pour la première fois, l'équipe framework a publié une release candidate (version RC). Évidemment, ils l'ont fait en raison de la décision de l'équipe React.js de publier React v19 RC.

Habituellement, l'équipe next.js dans ses versions stables utilise calmement React de la branche de version "Canary" (cette branche est considérée comme stable et recommandée pour une utilisation par les frameworks). Cette fois, cependant, ils ont décidé de faire les choses différemment (spoiler - pas en vain).

Le plan pour les deux équipes était simple : publier une version préliminaire, laisser la communauté vérifier les problèmes et, dans quelques semaines, publier une version complète.

Tweet du développeur de l'équipe principale de React.js https://x.com/acdlite/status/1797668537349328923

Cela fait plus de six mois que la release candidate de React.js est sortie, mais la version stable n'a toujours pas été publiée. Le retard dans la publication de la version stable de React.js a également eu un impact sur les plans de next.js. Par conséquent, contrairement à la tradition, ils ont publié un total de 15 versions de correctifs supplémentaires tout en travaillant déjà sur la 15ème version (généralement 3 à 5 correctifs puis une version). Ce qui est remarquable ici, c'est que ces versions de correctifs n'incluaient pas toutes les modifications accumulées, mais résolvaient uniquement les problèmes critiques, ce qui s'écarte également des processus habituels de next.js.

Le processus de publication de base dans next.js est que tout est fusionné dans la branche Canary, puis, à un moment donné, cette branche est publiée en tant que version stable.

Cependant, en conséquence, l'équipe next.js a décidé de se dissocier de la version React.js et de publier une version stable du framework avant la sortie de la version stable de React.js.

Gestion des versions de la documentation

Encore un changement organisationnel très utile. Enfin, il est possible de visualiser différentes versions de la documentation. Voici pourquoi c'est si important :

Premièrement, la mise à jour de next.js peut souvent être une tâche assez difficile en raison de changements majeurs. En fait, c'est pourquoi il y a encore plus de 2 millions de téléchargements mensuels pour la version 12 et plus de 4 millions pour la version 13 (pour être honnête, la version 14 compte plus de 20 millions de téléchargements).

Par conséquent, les utilisateurs des versions précédentes ont besoin d'une documentation spécifique à leur version, car la nouvelle pourrait être réécrite à moitié.

Gestion des versions de la documentation Next.js - nextjs.org/docs

Un autre problème est que Next.js utilise essentiellement un seul canal. Des modifications de la documentation y sont également apportées. Par conséquent, les descriptions des modifications apportées aux versions Canary sont immédiatement apparues dans la documentation principale. Ils sont désormais affichés sous la section "canari".

Utiliser React

Au début, j'ai mentionné que Next.js utilise actuellement la version RC de React.js. Mais en réalité, ce n’est pas tout à fait vrai, ou plutôt pas tout à fait vrai. En fait, Next.js utilise actuellement deux configurations React.js : la 19e version Canary pour App Router et la 18e version pour Pages Router.

Fait intéressant, à un moment donné, ils voulaient également inclure la 19e version de Pages Router, mais ont ensuite annulé ces modifications. Désormais, une prise en charge complète de React.js version 19 est promise après la sortie de sa version stable.

Parallèlement à cela, la nouvelle version apportera plusieurs améliorations utiles pour les fonctions actions du serveur (oui, l'équipe React les a renommées) :

• Optimisation du poids et des performances ;
• Gestion des erreurs améliorée ;
• Correction de la revalidation et des redirections des fonctions du serveur.

Je suppose que j'inclurai également la nouvelle fonctionnalité de Next.js dans cette section : le composant Form. Dans l'ensemble, il s'agit de la forme familière de React-Dom, mais avec quelques améliorations. Ce composant est principalement nécessaire si la soumission réussie du formulaire implique la navigation vers une autre page. Pour la page suivante, les abstractions chargement.tsx et layout.tsx seront préchargées.

import Form from 'next/form'

export default function Page() {
  return (
    

; {/* On submission, the input value will be appended to the URL, e.g. /search?query=abc */} ; Submit;

; ) }

Expérience développeur (DX)

Quand on parle de Next.js, nous ne pouvons pas ignorer l'expérience du développeur. En plus du standard "Faster, Higher, Stronger" (dont nous parlerons également, mais un peu plus tard), plusieurs améliorations utiles ont été publiées.

Support tant attendu pour la dernière version d'ESLint. Next.js ne prenait pas en charge ESLint v9 jusqu'à présent. Ceci malgré le fait qu'eslint lui-même (v8) et certaines de ses sous-dépendances sont déjà marquées comme obsolètes. Cela a abouti à une situation désagréable où les projets étaient essentiellement obligés de conserver des packages obsolètes.

L'interface d'erreur a été légèrement améliorée (qui dans Next.js est déjà claire et pratique) :

• Ajout d'un bouton pour copier la trace de la pile ;
• Ajout de la possibilité d'ouvrir la source d'erreur dans l'éditeur sur une ligne spécifique.

Exemple de copie de la pile d'erreurs dans next.js

Un "Indicateur statique" a été ajouté - un élément dans le coin de la page indiquant que la page a été construite en mode statique.
Dans l’ensemble, c’est une chose mineure, mais il est amusant qu’ils l’aient inclus dans les changements clés comme quelque chose de nouveau. L'indicateur d'une page "pré-construite" existe depuis environ la version 8 (2019) et ici, essentiellement, ils l'ont juste légèrement mis à jour et adapté pour l'App Router.

Un répertoire contenant des informations de débogage a également été ajouté - .next/diagnostics. Il contiendra des informations sur le processus de construction et toutes les erreurs qui se produisent. On ne sait pas encore si cela sera utile dans une utilisation quotidienne, mais cela sera certainement utilisé lors du dépannage des problèmes avec les devrels de Vercel (oui, ils aident parfois à résoudre des problèmes).

Réponse de l'équipe Next.js à un [tweet sur la lenteur de la construction du projet](https://x.com/darshansrc/status/1797339543571755425)

Changements dans le processus de construction

Après avoir discuté de DX, cela vaut la peine de parler du processus de construction. Et avec lui, Turbopack.

Turbopack

Et la plus grande nouveauté dans ce domaine. Le Turbopack est désormais entièrement terminé pour le mode développement ! "100% des tests existants réussis sans erreurs avec Turbopack"

Maintenant, l'équipe Turbo travaille sur la version de production, passant progressivement par les tests et les affinant (actuellement terminés à environ 96 %)

Exemple de section du journal des modifications dans next.js

Turbopack ajoute également de nouvelles fonctionnalités :

• Définition d'une limite de mémoire pour les builds avec Turbopack ;
• Tree Shaking (suppression du code inutilisé).

import Form from 'next/form'

export default function Page() {
  return (
    

; {/* On submission, the input value will be appended to the URL, e.g. /search?query=abc */} ; Submit;

; ) }

Ces améliorations et d'autres améliorations apportées à Turbopack "ont réduit l'utilisation de la mémoire de 25 à 30 %" et ont également "accéléré la création de pages lourdes de 30 à 50 %".

Autre

Des problèmes de style importants ont été corrigés. Dans la version 14, des situations survenaient souvent où l'ordre des styles était rompu pendant la navigation, ce qui faisait que le style A devenait supérieur au style B, et vice versa. Cela a changé leur priorité et, par conséquent, les éléments semblaient différents.

La prochaine amélioration tant attendue. Le fichier de configuration peut désormais être écrit en TypeScript - next.config.ts

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

Une autre mise à jour intéressante consiste à réessayer de créer des pages statiques. Cela signifie que si une page échoue au moment de la construction (par exemple, en raison de problèmes Internet), elle tentera de se reconstruire.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

Et pour conclure cette section, une fonctionnalité très recherchée par la communauté - la possibilité de spécifier le chemin vers des fichiers supplémentaires à construire. Avec cette option, vous pouvez par exemple spécifier que les fichiers ne se trouvent pas dans le répertoire de l'application, mais dans des répertoires comme modules/main, modules/invoices.

Cependant, pour le moment, ils ne l'ont ajouté qu'à des fins internes à l'équipe. Et dans cette version, ils ne le présenteront certainement pas. À l'avenir, soit il sera utilisé pour les besoins de Vercel, soit ils le testeront et le présenteront dans la prochaine version.

Modifications apportées à l'API Framework

La partie la plus pénible des mises à jour de Next.js : les modifications de l'API. Et dans cette version, il y a aussi des mises à jour de dernière minute.

Plusieurs API de framework internes sont devenues asynchrones : cookies, en-têtes, paramètres et searchParams (appelées API dynamiques).

const nextConfig = {
  experimental: {
    staticGenerationRetryCount: 3,
  },
}

C'est un changement majeur, mais l'équipe Next.js promet que toutes ces fonctionnalités pourront être mises à jour automatiquement en appelant leur codemod :

npx @next/codemod@canary next-async-request-api .

Un autre changement, mais probablement pas pertinent pour beaucoup. Les clés geo et ip ont été supprimées de NextRequest (utilisées dans les routes middleware et API). Essentiellement, cette fonctionnalité ne fonctionnait qu'à Vercel, tandis qu'ailleurs, les développeurs créaient leurs propres méthodes. Pour Vercel, cette fonctionnalité sera déplacée vers le package @vercel/functions

Et quelques mises à jour supplémentaires :

• Dans revalidateTag, vous pouvez désormais transmettre plusieurs balises à la fois ;
• Les clés images.remotePatterns.search et images.localPatterns ont été ajoutées à la configuration pour next/image. Ceux-ci permettent un meilleur contrôle des restrictions d’adresse pour la compression d’images.

import Form from 'next/form'

export default function Page() {
  return (
    

; {/* On submission, the input value will be appended to the URL, e.g. /search?query=abc */} ; Submit;

; ) }

Mise en cache

À mon avis personnel, c'est là que les changements les plus importants pour Next.js ont eu lieu. Et la plus grande nouvelle est - La mise en cache est désormais désactivée par défaut ! Je n'entrerai pas dans les détails sur les problèmes de mise en cache, cela a été largement abordé dans l'article "Next.js Caching. Gift or Curse".

Passons en revue tous les principaux changements apportés à la mise en cache :

• Plus précisément, fetch utilise désormais la valeur no-store par défaut au lieu du cache forcé ;
• Les routes API fonctionnent désormais en mode force-dynamique par défaut (auparavant, la valeur par défaut était force-statique, ce qui signifie qu'elles étaient compilées dans une réponse statique pendant le temps de construction [si les API dynamiques n'étaient pas utilisées sur la page]);
• La mise en cache dans le routeur client a également été désactivée. Auparavant, si un client visitait une page au sein d'un itinéraire, elle était mise en cache sur le client et restait dans cet état jusqu'à ce que la page soit rechargée. Désormais, la page actuelle sera chargée à chaque fois. Cette fonctionnalité peut être reconfigurée via next.config.js :

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

• De plus, même si la mise en cache côté client est activée, elle sera apparemment mise à jour au bon moment. Plus précisément, si le cache d'une page activée sur le serveur expire.
• Les composants du serveur sont désormais mis en cache en mode développement. Cela accélère les mises à jour en cours de développement. Le cache peut être vidé simplement en rechargeant la page. Vous pouvez également désactiver complètement cette fonctionnalité via next.config.js :

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

• Vous pouvez désormais gérer l'en-tête "Cache-Control". Auparavant, il était toujours écrasé de manière rigide par les valeurs internes de Next.js. Cela a provoqué des artefacts lors de la mise en cache via CDN ;
• next/dynamic met en cache les modules et les réutilise, plutôt que de les charger à nouveau à chaque fois ;

Cela concerne les "malentendus historiques". De nouvelles API apparaîtront également dans Next.js. À savoir ce qu’on appelle les E/S dynamiques. Il n'a encore été écrit nulle part, donc ce qui suit sera les suppositions de l'auteur basées sur les changements.

Les E/S dynamiques semblent être un mode avancé de construction dynamique. Quelque chose comme PPR (Partial Prerendering), ou plus précisément, son complément. En bref, le pré-rendu partiel est un mode de création de page dans lequel la plupart des éléments sont construits au moment de la construction et mis en cache, tandis que les éléments individuels sont construits pour chaque requête.

Ainsi, les E/S dynamiques finalisent [probablement] l'architecture de cette logique. Il étend les capacités de mise en cache afin qu'elle puisse être activée et désactivée précisément en fonction du mode et du lieu d'utilisation (que ce soit dans un bloc "dynamique" ou non).

import Form from 'next/form'

export default function Page() {
  return (
    

; {/* On submission, the input value will be appended to the URL, e.g. /search?query=abc */} ; Submit;

; ) }

Parallèlement à cela, la directive "use cache" est ajoutée. Il sera disponible dans les environnements d'exécution nodejs et Edge et, apparemment, dans tous les segments et abstractions du serveur. En spécifiant cette directive en haut d'une fonction ou d'un module exportant une fonction, son résultat sera mis en cache. La directive ne sera disponible que lorsque DynamicIO est activé.

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

De plus, spécifiquement pour l'utilisation du cache, les méthodes cacheLife et cacheTag sont ajoutées

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

cacheTag sera utilisé pour la revalidation à l'aide de revalidateTag, et cacheLife définira la durée de vie du cache. Pour la valeur cacheLife, vous devrez utiliser l'une des valeurs prédéfinies. Plusieurs options seront disponibles dès le départ ("secondes", "minutes", "heures", "jours", "semaines", "max"), des options supplémentaires peuvent être spécifiées dans next.config.js :

const nextConfig = {
  experimental: {
    staticGenerationRetryCount: 3,
  },
}

Prérendu partiel (PPR)

Probablement la fonctionnalité principale de la prochaine version. Comme mentionné précédemment, PPR est un mode de création de page dans lequel la plupart des éléments sont assemblés au moment de la construction et mis en cache, tandis que les éléments individuels sont assemblés pour chaque requête. Dans le même temps, la partie pré-construite est immédiatement envoyée au client, tandis que le reste est chargé dynamiquement.

Comment fonctionne le prérendu partiel

La fonctionnalité elle-même a été introduite il y a six mois dans la version candidate en tant qu'API expérimentale. Cette API restera dans cet état, et nous la considérerons probablement comme stable uniquement dans la version 16 (ce qui est une bonne chose, car les fonctionnalités majeures sont souvent devenues stables dans un délai de six mois à un an).

Concernant les changements. Comme mentionné précédemment, il s’agit principalement d’une mise à jour des principes de travail. Cependant, du point de vue de l’utilisation du PPR, cela n’a pratiquement rien affecté. Parallèlement, il a reçu plusieurs améliorations :

Auparavant, il n'y avait qu'un indicateur dans la configuration, mais maintenant, pour activer PPR, vous devez spécifier « incrémental ». Ceci est apparemment fait pour rendre la logique plus transparente - le contenu peut être mis en cache par les développeurs même dans PPR, et pour le mettre à jour, vous devez appeler des méthodes de revalidation.

import { cookies } from 'next/headers';

export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');

  // ...
}

De plus, auparavant, PPR était lancé pour l'ensemble du projet, mais il doit désormais être activé pour chaque segment (mise en page ou page) :

const nextConfig = {
  images: {
    localPatterns: [
      {
        pathname: '/assets/images/**',
        search: 'v=1',
      },
    ],
  },
}

Un autre changement est le pré-rendu de repli partiel (PFPR). C'est précisément grâce à cette amélioration que la partie pré-construite est immédiatement envoyée au client, tandis que le reste est chargé dynamiquement. À la place des éléments dynamiques, un composant de rappel est affiché pendant ce temps.

import Form from 'next/form'

export default function Page() {
  return (
    

; {/* On submission, the input value will be appended to the URL, e.g. /search?query=abc */} ; Submit;

; ) }

Instrumentation

L'instrumentation est marquée comme une API stable. Le fichier d'instrumentation permet aux utilisateurs de se connecter au cycle de vie du serveur Next.js. Il fonctionne sur l'ensemble de l'application (y compris tous les segments de Pages Router et App Router).

Actuellement, l'instrumentation prend en charge les hooks suivants :

register - appelé une fois lors de l'initialisation du serveur Next.js. Il peut être utilisé pour l'intégration avec des bibliothèques d'observabilité (OpenTelemetry, datadog) ou pour des tâches spécifiques à un projet.

onRequestError - un nouveau hook appelé pour toutes les erreurs du serveur. Il peut être utilisé pour les intégrations avec les bibliothèques de suivi des erreurs (Sentry).

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

Intercepteur

Intercepteur, également connu sous le nom de middleware au niveau de la route. C'est quelque chose comme un middleware à part entière [déjà existant], mais contrairement à ce dernier :

• Cela peut fonctionner dans le runtime Node.js ;
• Il fonctionne sur le serveur (ce qui signifie qu'il a accès à l'environnement et au cache unifié);
• Il peut être ajouté plusieurs fois et est hérité lors de l'imbrication (de la même manière que le middleware fonctionnait lorsqu'il était en version bêta);
• Cela fonctionne également pour les fonctions de serveur.

De plus, lors de la création d'un fichier intercepteur, toutes les pages ci-dessous dans l'arborescence deviennent dynamiques.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

En parlant de Vercel, le middleware sera désormais efficace comme simple contrôle primaire au niveau du CDN (ainsi, par exemple, renvoyant immédiatement les redirections si la requête n'est pas autorisée), tandis que les intercepteurs fonctionneront sur le serveur, effectuant des contrôles à part entière et des opérations complexes.

En auto-hébergement, cependant, une telle division sera apparemment moins efficace (puisque les deux abstractions fonctionnent sur le serveur). Il peut suffire d'utiliser uniquement des intercepteurs.

Conclusions

Écrasement de la récupération, mise en cache agressive, nombreux bugs et ignorer les demandes de la communauté. L'équipe Next.js a pris des décisions erronées, a précipité les versions et a conservé son point de vue malgré les commentaires de la communauté. Il a fallu près d'un an pour reconnaître les problèmes. Et ce n'est que maintenant, enfin, qu'on a le sentiment que le cadre aborde à nouveau les problèmes de la communauté.

Par contre, il existe d'autres frameworks. Il y a un an, lors de la présentation de React.js, il semblait que tous les frameworks seraient bientôt à égalité avec Next.js. React a commencé à mentionner Next.js moins fréquemment comme outil principal, les frameworks présentaient les systèmes de build à venir, la prise en charge des composants et des fonctions du serveur, ainsi qu'une série de changements et d'intégrations globales. Le temps a passé et, essentiellement, aucun d’entre eux n’a encore atteint ce point.

Bien sûr, les conclusions finales ne pourront être tirées qu'après un certain temps, mais pour l'instant, il semble que les changements apportés à React.js, au lieu du nivellement attendu des frameworks, ont conduit à une domination encore plus grande de Next.js et à un divergence plus large entre les frameworks (puisque la mise en œuvre des composants et des actions du serveur était laissée à la discrétion des frameworks).

Dans le même temps, OpenAI est passé à Remix ("en raison de sa plus grande stabilité et commodité") :

Utilisation du remix dans ChatGPT

Et apparemment, ils ont commencé avant des changements importants dans Next.js

Tweet sur le passage de ChatGPT à Remix à partir d'août 2024

En général, dans les prochaines enquêtes stateofjs et stackoverflow, nous assisterons probablement à un remaniement important.

Crédits

Les exemples de code ou leurs fondements sont tirés de la documentation next.js, ainsi que des commits, des PR et du noyau next.js ;

Post-scriptum

Si vous avez besoin d'un outil pour générer de la documentation basée sur des fichiers MD - jetez un œil à robindoc.com, si vous travaillez avec next.js - vous trouverez peut-être quelque chose d'utile dans les solutions de nimpl.tech.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!