Retour • 23/10/2024

NextJS 15 : Toutes les nouveautés importantes

Écris par Melvyn Malherbe le 23/10/2024

NextJS 15 est disponible et il change beaucoup de code dont une nouveauté très importante qu'il faut vraiment que tu prennes en compte.

Dans cet article je vais te lister ces nouveautés pour que tu puisses migrer en toute sécurité.

Changement critique : async pour les headers etc...

À partir de maintenant, les headers, cookies, les params ou même les searchParams deviennent asynchrones.

export default function Page() { 
export default async function Page() { 
  const headersList = headers(); 
  const headersList = await headers(); 

  return <div>Ip : {headersList.get('x-forwarded-for')}</div>;
}

Ceci s'applique aussi pour les paramètres :

export default function Page(props: { params: { id: string } }) { 
export default async function Page(props: { params: Promise<{ id: string }> }) { 
  const params = props.params; 
  const params = await props.params; 

  return <div>Id : {params.id}</div>;
}

Ceci a un effet cataclysmique sur ton code et pour t'aider à migrer très rapidement NextJS te propose un "codemod" :

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

Maintenant tu te demandes sûrement pourquoi ce changement ?

La réponse c'est que dans un futur proche, NextJS va changer son système de cache. Avant, si tu utilisais headers ou cookies dans ton code, la page était automatiquement considérée comme "dynamique", mais c'était "compliqué à comprendre".

Bientôt, une page sera considérée comme "dynamique" uniquement si elle est async et qu'elle await quelque chose.

Un nouvel utilitaire, "use cache" sera mis en place afin de pouvoir désactiver le "dynamique" au besoin. (on en parlera bientôt).

Les API Route et le Client Router ne cache plus par défaut

Avant, n'importe quelle API Route en GET, si elle n'utilisait pas de headers ou autre était gardée en cache ce qui était la raison pour laquelle ma technique pour publier des articles automatiquement fonctionnait si bien.

C'est terminé, maintenant les routes GET ne sont plus gardées en cache par défaut et tu dois "opt-in" volontairement :

// Tu DOIS rajouter cette ligne pour forcer le cache
export dynamic = 'force-static'

export const GET = async () => {
  // ...
}

Client Router ne cache plus

Il faut savoir qu'avant quand tu faisais une navigation et que tu mettais à jour une valeur, quand tu revenais sur la page, la valeur n'était pas mise à jour.

Par exemple tu faisais ça :

1. Tu vas sur /users
2. Tu vas sur /users/1
3. Tu mets à jour le nom de l'utilisateur de "michel" à "john"
4. Tu reviens sur /users
5. Tu reviens sur /users/1
6. Le nom est toujours "michel"

Ceci créait une énorme frustration dans la communauté.

Maintenant c'est terminé, ce "client router cache" n'est plus. Tu peux cependant venir ré-activer ce cache dans la config :

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30, // Le nombre de secondes qu'une page dynamique est gardée en cache
      static: 180, // Le nombre de secondes qu'une page statique est gardée en cache
    },
  },
};

module.exports = nextConfig;

Ajout de React 19

React 19 est maintenant adopté par NextJS 15 alors même que React 19 n'est pas encore totalement stable. (une habitude pour NextJS maintenant).

Si tu veux en savoir plus sur la migration à faire, tu peux te rendre sur l'upgrade guide de React 19.

React Compiler en expérimental

Il est possible maintenant de opt-in pour le React Compiler en NextJS. Pour rappel, le React Compiler est un outil qui vient analyser ton code pour définir à quel endroit il serait utile de venir rajouter des useMemo ou useCallback afin qu'il le fasse automatiquement sans que tu aies à le faire manuellement. Pour en savoir plus.

Hydration error improvements

Les erreurs d'hydratation sont maintenant bien plus explicites :

Image de Vercel

ce qui te permet de plus facilement debug tes applications.

Turbo Pack dev

TurboPack est enfin prêt pour le développement après des années d'attente, et je pensais pas le dire mais c'est vraiment génial.

TurboPack est bien plus rapide et optimisé que Webpack pour le serveur et d'après mes récents tests, mon application Codeline est 5 à 10 fois plus rapide avec TurboPack.

Pour l'activer, il suffit de faire :

npm run --turbo

Static Route Indicator

Avec NextJS 15, vous pouvez maintenant voir un indicateur qui définit quelle route est statique ou dynamique.

Ce petit indicateur explicite ce qui était implicite et compliqué à comprendre.

Indicateur de route statique

NextJS veut mettre plus d'effort à expliciter ce qui était avant compliqué à comprendre et peu explicite. C'est chose faite.

Exécuter du code APRÈS la réponse

Dû au fonctionnement "Serverless" de NextJS ou plutôt de Vercel, il n'est pas possible d'exécuter du code après la réponse.

Donc imaginons que tu veuilles envoyer un mail quand une personne met un commentaire sur ton site, tu es obligé d'attendre que le mail soit envoyé avant de pouvoir répondre à la requête.

Ce qui va donner une impression de lenteur inutile pour ton utilisateur. Heureusement pour toi, NextJS vient d'ajouter une méthode after() qui permet de résoudre ce problème.

Il faut commencer par l'activer :

const nextConfig = {
  experimental: {
    after: true,
  },
};

export default nextConfig;

Et ensuite tu vas pouvoir importer et utiliser after() dans ton code :

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';

export default function Layout({ children }) {
  after(() => {
    // ce code sera exécuté après la réponse
    log();
  });

  return <>{children}</>;
}

Je t'invite à regarder cette vidéo YouTube pour mieux comprendre les avantages :

Mais en conclusion, cet outil est vraiment efficace car il va permettre de venir effectuer du code pas forcément essentiel après la réponse sans avoir besoin de faire des hacks horribles.

instrumentation.js

Cet outil te permet de venir gérer une sorte de middleware de l'erreur pour gérer les cas d'erreur et pouvoir par exemple les logger dans Sentry, un outil de monitoring de bug dans nos applications.

<Form /> component

Il y a un nouveau composant qui vient par défaut en NextJS qui est le <Form /> et qui va te permettre de pouvoir profiter du "Progressive enhancement" qui est un mot vulgaire pour dire qu'il va faire du travail plus intelligemment.

En fait, si ton utilisateur a son JavaScript chargé et activé, il va prefetch la page suivante et venir la charger en background.

Sinon, il va faire une simple redirection.

Dans cette vidéo je te fais une démo assez concrète :

Support de next.config.ts

Enfin, il est possible d'ajouter une configuration TypeScript et TypeSafe à notre application NextJS.

import type { NextConfig } from 'next';

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

export default nextConfig;

Amélioration de la sécurité des server-action

Par défaut, avant, chaque méthode exportée dans un fichier qui commence par "use server" était incluse dans le bundle côté client ce qui pouvait créer des leaks, comme remonté dans ce tweet

Ce bug est maintenant corrigé et uniquement les méthodes que tu utilises vraiment dans ton code seront incluses dans le bundle côté client. Un bon moyen pour sécuriser tes server actions est aussi d'utiliser next-safe-action dont j'ai déjà parlé.

Support pour eslint 9

Jusqu'à maintenant, Next ne supportait pas bien eslint 9 avec la nouvelle "flat config" mais c'est maintenant résolu ✅

Conclusion

Je t'ai présenté toutes les mises à jour majeures que tu devais vraiment connaître, tu peux retrouver la liste complète des changements sur la release note officielle. Mais sache que le reste, c'est des changements mineurs ou moins importants.

Si tu as aimé, sache que j'ai une formation gratuite en NextJS qui va te permettre de monter en compétence rapidement :