Quoi de neuf dans Next.js 13 ? — fracassant

Octobre est venu et reparti, et avec lui, Next.js a publié une nouvelle version majeure remplie (jeu de mots) avec des tonnes de nouvelles fonctionnalités – dont certaines peuvent être adoptées de manière transparente à partir de votre application Next.js 12, tandis que d’autres pas tellement .

Si vous ne faites que sauter dans le train en marche, il peut être déroutant de distinguer le battage médiatique, la désinformation et ce qui est stable pour vos applications de production, mais n’ayez crainte ! Je suis ici pour vous donner un bon aperçu et vous mettre au courant.

Quelle désinformation ?

Comme pour toutes les versions de Next.js, il y a quelques API qui sont déplacées dans le noyau stable et pour une utilisation recommandée, et il y en a encore d’autres dans le canal expérimental. Les API « expérimentales » font toujours l’objet de débats. La fonctionnalité principale est là, mais la question de comment ces API se comportent et comment elles peuvent être utilisées est toujours susceptible de changer car il peut y avoir des bogues ou des effets secondaires inattendus.

Dans la version 13, les versions expérimentales étaient importantes et ont pris le devant de la scène. Cela a amené de nombreuses personnes à considérer l’ensemble de la version comme instable et expérimentale – mais ce n’est pas le cas. Next.js 13 est en fait assez stable et permet une mise à niveau fluide depuis la version 12 si vous n’avez pas l’intention d’adopter une API expérimentale. La plupart des modifications peuvent être adoptées progressivement, ce que nous détaillerons plus loin dans cet article.

Résumé des versions

Avant d’approfondir ce que chaque annonce implique, vérifions une liste rapide et équilibrons les expériences et les fonctionnalités stables.

Expérimental

• Annuaire d’applications ;
• Nouveau Bundler (Turbopack);
• Optimisation des polices.

Écurie

• « Nouveau » composant d’image pour remplacer l’ancien Image composant par défaut ;
• Prise en charge du module ES pour next.config.mjs;
• « Nouveau » Link composant.

Le répertoire des applications

Cette fonctionnalité est en fait une grande réécriture architecturale. Il place les composants du serveur React au premier plan, exploite un tout nouveau système de routage et des crochets de routeur (sous next/navigation à la place de next/router), et retourne toute l’histoire de récupération de données.

Tout cela est destiné à permettre de grandes améliorations de performances, comme le rendu avec impatience de chaque partie de votre vue qui ne dépend pas des données tout en suspendre (vous avez bien lu !) les éléments qui récupèrent les données et sont rendus sur le serveur.

En conséquence, cela apporte également un énorme changement de modèle mental dans la façon dont vous concevez votre application Next.js.

Comparons comment les choses étaient et comment elles fonctionneront dans le répertoire App. Lors de l’utilisation du /pages répertoire (l’architecture que nous utilisions jusqu’à présent), les données sont récupérées au niveau de la page et sont transmises en cascade vers les composants feuille.

En revanche, étant donné que le répertoire de l’application est alimenté par les composants serveur, chaque composant est en charge de ses propres donnéesce qui signifie que vous pouvez maintenant récupérer puis rendre chaque composant dont vous avez besoin et mettez-les en cache individuellement, en effectuant Régénération statique incrémentielle (ISR) à un niveau beaucoup plus granulaire.

De plus, Next.js poursuivra les optimisations : les requêtes seront dédupliquées (ne permettant pas à différents composants de déclencher la même requête en parallèle), grâce à un changement dans la façon dont le fetch La méthode d’exécution fonctionne avec le cache. Par défaut, toutes les requêtes utiliseront une heuristique de cache forte (« force-cache »), qui peut être désactivée via la configuration.

Vous avez bien lu. Next.js et React Server Components interfèrent tous les deux avec le fetch standard afin de fournir des optimisations de récupération de ressources.

Vous n’avez pas besoin d’aller « all-in »

Il est important de souligner que la transition de la /pages l’architecture à /app peut être fait progressivement, et les deux solutions peuvent coexister tant que les routes ne se chevauchent pas. Il y a actuellement aucune mention dans la feuille de route de Next.js sur l’abandon de la prise en charge de /pages.

lecture recommandée: ISR vs DPR : grands mots, explication rapide par Cassidy Williams

Nouveau Bundler et Benchmarks

Depuis sa première version, Next.js utilise webpack sous la capuche. Cette année, nous avons vu apparaître une nouvelle génération de bundlers, écrits dans des langages de bas niveau, tels que ESBuild (qui alimente Vite), Parcel 2 (Rust) et d’autres. Nous avons également vu Vercel préparer le terrain pour un grand changement dans Next.js. Dans la version 12, ils ont ajouté CFC à leur processus de construction et de transpilation comme une étape pour remplacer les deux Babel et Terser.

Dans la version 13, ils ont annoncé Turbopack, un nouveau bundler écrit en Rust avec très revendications de performance audacieuses. Oui, il y a eu une controverse sur Twitter pour savoir quel bundler est le plus rapide dans l’ensemble et comment ces repères ont été mesurés. Pourtant, il est indiscutable de savoir à quel point Turbopack peut réellement aider de grands projets écrits en Next.js avec une ergonomie bien meilleure que tout autre outil (pour commencer, avec une configuration intégrée).

Cette fonctionnalité n’est pas seulement expérimentale, mais ne fonctionne en fait qu’avec next dev. Vous ne devriez pas (et à partir de maintenant ne peut pas ) l’utiliser pour une version de production.

Optimisation des polices

Le nouveau @next/font permet d’optimiser les performances de vos polices Web pendant la construction. Il téléchargera les ressources de police pendant la construction et les hébergera dans votre propre /public dossier. Cela permettra d’économiser un aller-retour vers un autre serveur, d’éviter une poignée de main supplémentaire et, en fin de compte, de livrer votre police de la manière la plus rapide possible et de la mettre en cache correctement avec le reste de vos ressources.

N’oubliez pas que lors de l’utilisation de ce package, il est important d’avoir une connexion Internet fonctionnelle lorsque vous exécutez votre build de développement pour la première fois afin qu’il puisse le mettre en cache correctement, sinon il reviendra aux polices système si adjustFontFallback n’est pas défini.

En outre, @next/font dispose d’un module spécial pour Google Web Fonts, facilement disponible car ils sont largement utilisés :

import { Jost } from '@next/font/google';
// get an object with font styles:
const jost = Jost();
// define them in your component:
<html className={jost.className}>

Le module fonctionnera également si vous utilisez des polices personnalisées :

import localFont from '@next/font/local';

const myFont = localFont({ src: './my-font.woff2' });

<html className={myFont.className}>

Même si cette fonctionnalité est encore en version bêta, elle est considérée comme suffisamment stable pour que vous puissiez l’utiliser en production.

Nouveaux composants d’image et de lien

Les composants les plus importants du package Next.js ont sans doute été légèrement remaniés. Prochain Image vit une double vie depuis Next.js 12 en @next/image et @next/future/image. Dans Next.js 13, le composant par défaut est activé :

• next/image se déplace vers next/legacy/image;
• next/future/image se déplace vers next/image.

Ce changement est accompagné d’un codemod, une commande qui tente de migrer automatiquement le code dans votre application. Cela permet une migration en douceur lors de la mise à niveau de Next.js :

npx @next/codemod next-image-to-legacy-image ./pages

Si vous effectuez ce changement et que vous n’avez pas configuré de tests de régression visuelle, je vous recommande de jeter un coup d’œil à vos pages dans tous les principaux navigateurs pour voir si tout semble correct.

Pour le nouveau composant Link, le changement doit également être fluide. La <a> élément à l’intérieur <Link> n’est pas nécessaire ni recommandé plus. Le codemod le supprimera ou ajoutera un legacyBehavior prop à votre composant.

npx @next/codemod new-link ./pages

En cas d’échec du codemod, vous recevrez un avertissement de linting sur dev, alors gardez un œil sur votre terminal !

Modules ES et transpilation automatique des modules

Là, deux mises à niveau sont passées sous le radar pour la plupart, mais je les considère particulièrement utile pour les personnes travaillant avec Monorepos. Jusqu’à présent, il n’était pas très ergonomique de partager la configuration entre les fichiers de configuration et les autres fichiers pouvant être utilisés en runtime. C’est parce que next.config.js est écrit avec CommonJS comme système de modules, qui ne peut pas importer à partir de fichiers ESM. Maintenant, Next.js prend en charge ESM simplement en ajoutant type: "module" à ton package.json et renommer next.config.js → next.config.mjs.

Noter: Le « m » signifie « module » et fait partie de la spécification Node.js pour la prise en charge ESM.

Pour Monorepos utilisant des packages internes (packages JavaScript qui ne sont pas publiés sur NPM mais qui sont plutôt consommés à partir de la source par des applications sœurs dans le monorepo), un plugin spécial était nécessaire pour transpiler ces modules au moment de la construction lors de leur consommation. À partir de Next.js 13, cela peut être arrangé sans plugin en passant simplement une propriété (expérimentale) à votre next.config.mjs:

const nextConfig = {
  experimental: {
    transpilePackages: ['@my-org/internal-package'],
  },
};

Vous pouvez voir un exemple dans le Modèle Apex-Monorepo. Avec ces paramètres, il est possible de développer simultanément le composant de dépendance et votre application sans aucune publication ni solution de contournement.

Qu’est-ce que Prochain?

Si vous êtes toujours intéressé à jouer et à en savoir plus sur ces fonctionnalités, je lancerai un Masterclass avancée Next.js du 30 novembre au 15 décembre 2022 — Je serais ravie de vous y accueillir et de répondre à toutes vos questions !

Jusque-là, faites-le moi savoir dans les commentaires ci-dessous ou tweetez-moi à @AtilaFassina sur la façon dont votre migration a été et vos réflexions sur les fonctionnalités expérimentales.

(vf, yk, le)