quoi de neuf dans la version 15 et qu’est-ce que cela signifie pour nous ? / Blogs / Perficient

Je travaille avec Next.Js depuis un certain temps et j’observe son développement avec intérêt pendant tout ce temps. La semaine dernière, j’étais heureux d’assister à la Next.js Conf à San Francisco. Perficient était fier de parrainer cet événement, c’est pourquoi j’ai représenté notre pratique Sitecore avec David Lewis – mon collègue de Optimizely Practice.

Vercel a publié la nouvelle version 15 du framework Next.js. Ce fut une journée vraiment innovante et j’aimerais partager ce que je retiens de l’événement sur cette nouvelle version.

Vercel a sérieusement travaillé sur les erreurs

L’équipe next.js avait déjà pris de mauvaises décisions, elle avait précipité les versions, avait des opinions arrêtées malgré la communauté : réécriture de la récupération, mise en cache matérielle, beaucoup de bugs, etc. et encore une fois, ignorant les demandes de la communauté. Il a fallu près d’un an pour se rendre compte que cela ne mènerait à rien et pour résoudre les problèmes réels. Désormais, avec la version 15, on a enfin le sentiment que le framework résout les problèmes de la communauté. Encore une fois, comme par le passé.

Réagir 19

Ici, nous obtenons une situation assez étrange. Plus de six mois se sont écoulés depuis la release candidate de React.js, mais la version stable n’a pas encore été publiée. Le retard de la version stable de React.js affecte directement les plans de Next.js. puisque les deux sont assez liés. Par conséquent, next.js utilise actuellement la version RC de React.js, mais ce n’est qu’en partie une déclaration vraie. En fait, next.js utilise actuellement deux configurations React.js :

• la 19ème version Canary pour App Router et
• la 18ème version pour Pages Router

Il est intéressant de noter qu’à un moment donné, ils voulaient inclure la 19e version de Pages Router, mais ont ensuite annulé ces modifications. Le support complet de la 19ème version de React.js est promis après la sortie de sa version stable.

Composant de formulaire

Cette innovation next.js est en fait déjà familière depuis react-dommais avec quelques améliorations. Vous bénéficiez de l’implémentation de Next.Js principalement dans les cas où la soumission réussie d’un formulaire implique une transition vers une autre page. Dans ce cas, le loading.tsx et layout.tsx les abstractions de la page suivante seront préchargées.

import Form from 'next/form'
 
export default function Page() {
  return (
    <Form action="/search">
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  )
}

Expérience développeur (DX)

Lorsqu’on parle de next.js, on ne peut s’empêcher de mentionner l’expérience du développeur. En plus des déclarations typiques « Plus rapide, plus haut, plus fort », plusieurs améliorations utiles ont été apportées à DX.

1. Un soutien tant attendu pour ESlint v9. Next.js n’a jamais pris en charge ESlint v9. Ceci malgré le fait qu’eslint (v8) et certaines de ses propres dépendances étaient déjà marquées comme obsolètes. À cause de cela, les développeurs ont été essentiellement obligés de conserver les packages obsolètes.
2. L’interface d’erreur dans next.js – qui est déjà claire et pratique – a été légèrement améliorée :
   1. Ajout d’un bouton pour copier la pile d’appels ;
   2. Ajout de la possibilité d’ouvrir la source de l’erreur dans l’éditeur sur une ligne spécifique.
3. Ajouté Indicateur statique – un élément dans le coin de la page montrant que la page est construite en mode statique. Le pré-construit L’indicateur de page est avec nous depuis des années, il a donc été légèrement mis à jour et adapté pour App Router.
4. Également ajouté un répertoire avec des informations de débogage – .next/diagnostics. C’est là que l’on peut trouver des informations sur le processus de construction et toutes les erreurs qui se produisent (cela aide parfois à analyser les problèmes).

Versionner la documentation

Un changement très utile : enfin, vous pouvez visualiser différentes versions de la documentation. Mais pourquoi est-ce si important pour l’expérience de développement ?

Mettre à jour next.js en raison de changements majeurs est souvent une tâche assez difficile. Pour cette raison, on peut encore voir plus de 2 millions de téléchargements mensuels pour la version 12 et plus de 4 millions pour la version 13. Les utilisateurs ont donc besoin d’une documentation pour leurs versions particulières, puisque la documentation récente pourrait être à moitié modifiée.

Turbopack

Probablement la plus grande nouvelle :

• Turbopack est entièrement terminé pour le mode développement ! « 100 % des tests existants se sont déroulés sans erreur avec Turbopack »
• L’équipe turbo travaille désormais sur la version de production, passant progressivement par les tests et les couvrant tous (actuellement environ 96 %)

Turbopack ajoute également de nouvelles fonctionnalités :

1. Définition d’une limite de mémoire pour une version Turbopack ;
2. Arbre secoué (en d’autres termes, c’est la suppression du code inutilisé) :

3. const nextConfig = {
     experimental: {
       turbo: {
         treeShaking: true,
         memoryLimit: 1024 * 1024 * 512 // bytes (512MB)
       },
     },
   }

   À eux seuls, ces changements de turbopack ont ​​réduit l’utilisation de la mémoire de 25 à 30 % et ont accéléré l’assemblage de pages lourdes de 30 à 50 %.

4. Correction de problèmes importants avec les styles. Dans la version 14, il y avait souvent des situations où les styles étaient rompus dans l’ordre lors de la navigation, et de ce fait, le style A devenait supérieur au style B, puis inférieur. Cela a changé leur priorité et, par conséquent, les éléments étaient différents.
5. La prochaine amélioration tant attendue. Vous pouvez maintenant écrire la configuration en TypeScript, et le fichier correspondant serait next.config.ts :

   import type { NextConfig } from 'next';
    
   const nextConfig: NextConfig = {
     /* here goes you config */
   };
    
   export default nextConfig;

   Même syntaxe fortement typée que d’habitude, mais très agréable à avoir, finalement !

6. Une autre innovation intéressante consiste à réessayer une génération de page ayant échoué avant d’échouer réellement la construction de pages statiques. Si l’assemblage de la page échoue en raison de problèmes de connectivité, elle réessayera :

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

Modifications de l’API du framework

Ce sont généralement les parties les plus pénibles des mises à jour next.js. La version 15 dispose également de mises à jour critiques.

Un ensemble d’API de framework est devenu asynchrone. Et ce sont les abstractions les plus centrées sur le framework, à savoir :

• cookies,
• headers,
• params et
• paramètres de recherche (également appelées API dynamiques).

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
  // ...
}

Les changements sont effectivement importants, mais l’équipe Next.js suggère que l’on puisse mettre à jour automatiquement les nouvelles API en appelant leur codemod:

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

Mise en cache

À mon avis, c’est là que se sont produits les changements les plus importants. Et la nouveauté la plus importante est que la mise en cache est désormais désactivée par défaut !

Jetons un coup d’œil à ce qui a changé :

• En fait, fetch utilise désormais la valeur no-store par défaut au lieu du cache forcé ;
• Les routes API utilisent le mode force-dynamique par défaut (auparavant, il était force-statique par défaut) ;
• La mise en cache dans le routeur client a également été désactivée. Auparavant, si un client visitait une page dans le chemin, elle était mise en cache sur le client et restait dans cet état jusqu’au rechargement de la page. Désormais, la page actuelle sera chargée à chaque fois. Cette fonctionnalité peut être modifiée via next.config.js :

  const nextConfig = {
    experimental: {
      staleTimes: {
        dynamic: 30 // defaults to 0
      },
    },
  }

• De plus, même si la mise en cache client est activée, elle sera probablement mise à jour au bon moment. À savoir, si le cache de pages activé sur le serveur expire.
• Les composants du serveur sont désormais mis en cache en mode développement. De ce fait, les mises à jour en cours de développement sont plus rapides.
• Suite à ce qui précède, on peut réinitialiser le cache en rechargeant simplement une page ou également désactiver complètement la fonctionnalité via next.config.js :

  const nextConfig = {
    experimental: {
      serverComponentsHmrCache: false, // defaults to true
    },
  }

• Vous pouvez contrôler l’en-tête « Cache-Control » qui était auparavant toujours écrasé par les valeurs internes de next.js. Cela provoquait des artefacts lors de la mise en cache via CDN ;
• next/dynamic met en cache les modules pour les réutiliser, plutôt que de les charger à nouveau à chaque fois ;

Prérendu partiel (PPR)

Cela pourrait être le principal teaser de la sortie. PPR est un mode d’assemblage de pages dans lequel Next.Js pré-rend et met en cache autant de routes que possible. tandis que certains éléments individuels sont construits sur chaque demande. Dans ce cas, la pièce pré-assemblée est immédiatement envoyée au client et le reste est chargé dynamiquement.

La fonctionnalité existait déjà il y a six mois dans la release candidate en tant qu’API expérimentale. Auparavant, PPR était activé pour l’ensemble du projet, mais depuis, on peut l’activer pour chaque segment (mise en page ou page) :

export const experimental_ppr = true

Un autre changement est le pré-rendu de repli partiel (PFPR). Grâce à cette amélioration, la pièce pré-assemblée est immédiatement envoyée au client et le reste est chargé dynamiquement. A ce moment, un composant de rappel est affiché à la place des éléments dynamiques.

import { Suspense } from "react"
import { StaticComponent, DynamicComponent } from "@/app/ui"
 
export const experimental_ppr = true
 
export default function Page() {
  return {
     <>
         <StaticComponent />
         <Suspense fallback={...}>
             <DynamicComponent />
         </Suspense>
     </>
  };
}

Instrumentation

L’instrumentation se présente sous la forme d’une API stable. Le fichier d’instrumentation permet aux utilisateurs d’affecter le cycle de vie du serveur Next.js. Fonctionne universellement avec tous les segments Pages Router et App Router.

Actuellement, l’instrumentation prend en charge les hooks :

• register – appelé une fois lors de l’initialisation du serveur next.js. Peut être utilisé pour l’intégration avec des bibliothèques de surveillance (OpenTelemetry, datalog) ou pour des tâches de projet spécifiques.
• onRequestError – un nouveau hook appelé sur toutes les erreurs du serveur. Peut être utilisé pour l’intégration avec des bibliothèques de suivi des erreurs (Sentry).

Intercepteur

Interceptor est un middleware au niveau de la route. Cela ressemble à un middleware existant à part entière, mais contrairement à celui-ci :

• Peut fonctionner dans le runtime node.js ;
• Fonctionne sur le serveur, a donc accès à l’environnement et à un seul cache ;
• Peut être ajouté plusieurs fois et est hérité de l’imbrication (comme le middleware fonctionnait lorsqu’il était en version bêta) ;
• Fonctionne, entre autres, pour les fonctions serveur.

Dans ce cas, lors de la création d’un fichier intercepteur, toutes les pages sous l’arborescence deviennent dynamiques.

• Si l’on garde Vercel à l’esprit, le middleware sera désormais efficace comme simple contrôle primaire au niveau du CDN (afin qu’il puisse immédiatement renvoie des redirections si la demande n’est pas autorisée), et les intercepteurs fonctionneront sur le serveur, effectuant des vérifications complètes et des opérations complexes.
• Pour l’auto-hébergeur, apparemment, une telle division sera moins efficace puisque les deux abstractions fonctionnent sur le serveur. Peut-être qu’il suffira d’utiliser uniquement un intercepteur.

V0 est la nouvelle interface utilisateur générative de Vercel

Dernier point mais non le moindre, vous pouvez utiliser la v0 en d’autres termes : une interface utilisateur générative, qui combine les meilleures pratiques de développement frontend avec tout le potentiel de l’IA générative. Actuellement, la v0 est disponible en version bêta et j’étais heureux de l’essayer en action lors de l’événement. Je suis heureux de dire qu’il est en effet puissant et compétent – ​​il a réussi à me fournir la configuration pour Sitecore dès la première invite !

Enfin, je suis heureux de conclure que notre ceinture d’outils a été réapprovisionnée avec de nouveaux outils pratiques qui permettent de fournir les solutions ultimes sans avoir à réinventer le vélo ».

Bravo Vercel !