BackRetour au blog

Next.js 9.4

Next.js 9.4 introduit React Fast Refresh, la régénération statique incrémentielle, un nouveau support pour les variables d'environnement, un fetch intégré et plus encore !

Nous sommes ravis de vous présenter aujourd'hui Next.js 9.4, qui inclut :

Fast Refresh

Fast Refresh est une nouvelle expérience de hot reloading qui vous donne un retour instantané sur les modifications apportées à vos composants React. Il est maintenant activé par défaut pour tous les projets sur Next.js 9.4 ou supérieur.

Le hot reloading existe depuis longtemps mais a historiquement été trop fragile pour être activé par défaut dans votre workflow. Pour cette raison, Next.js implémentait auparavant une forme rudimentaire de hot reloading qui réinitialisait l'ensemble de l'état de votre application.

L'ancienne implémentation du hot reloading n'était pas résiliente aux erreurs de compilation ou d'exécution et effectuait un rechargement complet de votre application si vous faisiez une faute de frappe en modifiant votre CSS ou JavaScript. C'était sous-optimal et interrompait votre train de pensée.

Fast Refresh s'intègre profondément dans React lui-même (via React Refresh), permettant à Next.js d'effectuer des mises à jour précises et prévisibles de votre arbre de composants React.

Cela signifie que Next.js ne mettra à jour que le code dans le fichier que vous avez modifié, et ne re-rendra que ce composant, sans perdre l'état du composant. Cela inclut les styles (inline, CSS-in-JS, ou CSS/Sass Modules), le markup, les gestionnaires d'événements et les effets (via useEffect).

Une session d'édition mettant en avant des erreurs de compilation et d'exécution (avec récupération rapide), et des modifications qui préservent l'état.

Dans le cadre de cette expérience, nous avons complètement repensé l'overlay d'erreur pour qu'il soit plus utile et pour rendre votre application résiliente aux fautes de frappe ou aux erreurs d'exécution. Cela inclut, mais sans s'y limiter :

  • Des localisations d'erreur précises, résolues à la ligne et colonne originales de votre code, avant compilation
  • Des extraits de code source pertinents contextuellement, avec la possibilité de cliquer-pour-ouvrir dans votre éditeur
  • La reprise de session de développement après la correction d'une erreur de syntaxe, sans perdre l'état de l'application
  • Le rejet automatique des erreurs d'exécution non gérées lorsque vous corrigez l'erreur

Nous tenons à remercier Dan Abramov pour ses contributions inestimables et son aide dans la mise en œuvre de cette fonctionnalité.

Régénération Statique Incrémentielle (bêta)

Next.js a introduit les méthodes de génération de site statique dans la version 9.3 avec un objectif clair : nous devrions obtenir les bénéfices du statique (toujours rapide, toujours en ligne, distribué globalement), mais avec un excellent support pour les données dynamiques, pour lesquelles Next.js est connu.

Pour obtenir le meilleur des deux mondes, Next.js supporte la Génération Statique Incrémentielle, mettant à jour le contenu statique après avoir déjà construit votre site. Par exemple, dans la version 9.3, nous avons introduit l'option fallback: true dans getStaticPaths, qui vous permet d'ajouter de nouvelles pages à l'exécution.

Nous avons récemment mis en place un exemple montrant comment Next.js peut pré-rendre statiquement un nombre infini de pages de cette manière.

Aujourd'hui, nous introduisons également la Régénération Statique Incrémentielle (bêta), qui est un mécanisme pour mettre à jour les pages existantes, en les re-rendant en arrière-plan à mesure que le trafic arrive. Inspiré par stale-while-revalidate, cela garantit que le trafic est servi sans interruption, toujours statiquement, et que la nouvelle page construite est poussée seulement après avoir fini sa génération.

pages/blog/[slug].js
export async function getStaticProps() {
  return {
    props: await getDataFromCMS(),
    // nous tenterons de re-générer la page :
    // - lorsqu'une requête arrive
    // - au maximum une fois par seconde
    unstable_revalidate: 1,
  };
}

Contrairement au SSR, la Régénération Statique Incrémentielle garantit que vous conservez les bénéfices du statique :

  • Pas de pics de latence. Les pages sont servies de manière constamment rapide.
  • Les pages ne tombent jamais hors ligne. Si la re-génération de page en arrière-plan échoue, l'ancienne page reste inchangée.
  • Faible charge sur la base de données et le backend. Les pages sont re-calculées au maximum une fois simultanément.

Les deux fonctionnalités incrémentielles (ajout de pages et mise à jour différée), ainsi que le mode preview, sont déjà entièrement supportés par next start et la plateforme edge de Vercel dès maintenant.

Prochainement, nous travaillerons sur un RFC supplémentaire pour aborder deux capacités supplémentaires de génération statique incrémentielle :

  • Re-générer et invalider plusieurs pages à la fois (comme votre index de blog et un certain article de blog)
  • Re-générer en écoutant des événements (comme les webhooks CMS), avant le trafic utilisateur

Exemples de CMS

Suite à notre annonce de génération de site statique next-gen, nous voulions partager des scénarios réels de récupération de contenu depuis des API de CMS Headless et leur rendu en HTML Next.js.

Nous avons collaboré avec les créateurs de certains des meilleurs systèmes CMS au monde : Contentful, DatoCMS, Prismic, Sanity et TakeShape, avec d'autres à venir.

Ces exemples sont non seulement prêts à l'emploi et 100% open source sous licence MIT, mais ils intègrent également les meilleures pratiques disponibles :

DatoCMS obtient des résultats impeccables grâce à son support intégré d'optimisation d'images.

DatoCMS obtient des résultats impeccables grâce à son support intégré d'optimisation d'images.

DatoCMS obtient des résultats impeccables grâce à son support intégré d'optimisation d'images

Nous avons également collaboré avec TinaCMS sur une nouvelle direction excitante pour les CMS : l'édition de contenu directement dans la page. Consultez leur guide pour apprendre comment l'implémenter pour votre projet.

Nouveau Support pour les Variables d'Environnement

Un retour commun que nous avons reçu des entreprises utilisant Next.js est qu'il n'était pas clair quand une variable d'environnement était intégrée dans le bundle navigateur et quand elle était seulement disponible dans l'environnement Node.js.

Aujourd'hui, nous annonçons deux fonctionnalités entièrement rétrocompatibles qui aideront à rationaliser ce processus.

Premièrement, vous pouvez maintenant préfixer la variable d'environnement avec NEXT_PUBLIC_ pour l'exposer au navigateur. Lorsque cette variable d'environnement est utilisée, elle sera alors intégrée dans le bundle JavaScript du navigateur.

Vous n'avez plus besoin d'ajouter un next.config.js et d'ajouter la clé env pour exposer ces variables.

pages/index.js
// La variable d'environnement sera exposée au navigateur
console.log('Version de mon application', process.env.NEXT_PUBLIC_VERSION);
 
export default function HomePage() {
  return <h1>Hello World</h1>;
}

Le deuxième changement est que Next.js supporte maintenant le chargement de .env par défaut. Vous permettant de définir facilement des variables d'environnement de développement et de production.

Vous pouvez en savoir plus sur le chargement de .env dans la documentation des Variables d'Environnement.

Ces nouvelles fonctionnalités simplifieront l'utilisation des variables d'environnement en suivant ces conventions :

  • Les variables d'environnement sont uniquement disponibles dans l'environnement Node.js par défaut
  • Les variables d'environnement préfixées par NEXT_PUBLIC_ sont exposées au navigateur

Amélioration du Support Intégré de Fetch

Dans Next.js 9.1.7 nous avons annoncé le polyfill de l'API fetch() dans le navigateur. Aujourd'hui, ce polyfill a été étendu à l'environnement Node.js également.

En pratique, vous n'avez plus besoin d'utiliser aucun type de polyfill fetch côté serveur (par exemple isomorphic-unfetch ou node-fetch) car Next.js fournira automatiquement fetch() dans tous les environnements.

Par exemple, lors de l'utilisation de getStaticProps, qui s'exécute avec Next.js au moment du build :

pages/blog.js
export async function getStaticProps() {
  // fetch n'a plus besoin d'être importé depuis isomorphic-unfetch
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  return {
    props: {
      posts,
    },
  };
}
 
function Blog({ posts }) {
  // Afficher les posts...
}
 
export default Blog;

Rapport Intégré des Web Vitals

La semaine dernière, l'équipe Google Chrome a introduit les Core Web Vitals. Les Core Web Vitals sont les signaux de qualité clés pour fournir une excellente UX sur le web, sur lesquels sont construits les célèbres rapports Lighthouse.

Garder une trace de ces métriques est extrêmement utile si vous voulez que votre site web ou application web soit aussi rapide que possible, ce qui est l'un des objectifs principaux de Next.js.

L'équipe Chrome a publié une extension Chrome Core Web Vitals qui vous permet, en tant que développeur, d'obtenir un retour visuel sur la performance de vos pages.

Lorsque vous construisez des applications web de production, vous voulez également savoir comment votre site performe pour vos visiteurs et (potentiels) clients. Vous pourriez même vouloir suivre l'amélioration ou la régression de ces métriques au fil du temps pour voir si vos changements ont l'impact souhaité sur votre audience.

Afin d'aider à rapporter les Core Web Vitals à votre service d'analytics, nous avons introduit, en collaboration avec Google, une nouvelle méthode appelée reportWebVitals qui peut être exportée depuis pages/_app.js :

pages/_app.js
// Sera appelée une fois pour chaque métrique à rapporter.
export function reportWebVitals(metric) {
  // Ces métriques peuvent être envoyées à n'importe quel service d'analytics
  console.log(metric);
}
 
function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}
 
export default MyApp;

Pour utiliser cette méthode en combinaison avec votre service d'analytics, référez-vous à la section "Envoyer les résultats à Analytics" de la documentation. Si vous voulez en savoir plus sur les Core Web Vitals, vous pouvez consulter web.dev/vitals.

Imports Absolus et Alias

Si vous travaillez sur un grand projet, certaines de vos déclarations import pourraient souffrir du spaghetti ../../../ :

import Button from '../../../../components/button';

Dans de tels cas, au lieu d'imports relatifs, nous pourrions vouloir utiliser des imports absolus. En supposant que le répertoire components existe à la racine, nous pourrions vouloir que les déclarations import ressemblent à :

import Button from 'components/button';

Nous sommes ravis d'annoncer que Next.js 9.4 rend la configuration des imports absolus très simple pour les projets JavaScript et TypeScript. Tout ce que vous avez à faire est d'ajouter la config baseUrl à jsconfig.json (projets JS) ou tsconfig.json (projets TS).

jsconfig.json / tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "."
  }
}

Cela permettra les imports absolus depuis . (le répertoire racine). Cela s'intègre également avec VSCode et d'autres éditeurs, supportant la navigation dans le code et d'autres fonctionnalités de l'éditeur.

Note : Si vous avez précédemment modifié votre configuration d'alias de module Webpack pour activer les imports absolus, cette configuration peut maintenant être supprimée.

De plus, Next.js 9.4 supporte également l'option paths, qui vous permet de créer des alias de module personnalisés. Par exemple, ce qui suit vous permet d'utiliser @/design-system au lieu de components/design-system :

jsconfig.json / tsconfig.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/design-system/*": ["components/design-system/*"]
    }
  }
}

Vous pouvez ensuite utiliser votre alias comme ceci :

// Importe 'components/design-system/button'
import Button from '@/design-system/button';

Vous devez spécifier baseUrl si vous spécifiez paths. Vous pouvez en savoir plus sur l'option paths dans la documentation TypeScript.

Support Configurable de Sass

Lorsque le support intégré de Sass a été lancé dans Next.js 9.3 nous avons reçu le retour qu'un sous-ensemble d'utilisateurs voulait configurer le compilateur Sass. Par exemple pour configurer includePaths.

C'est maintenant possible en utilisant la clé sassOptions dans next.config.js :

next.config.js
const path = require('path');
 
module.exports = {
  sassOptions: {
    includePaths: [path.join(__dirname, 'styles')],
  },
};

Amélioration de la Sortie des Logs

Nous avons repensé la sortie en ligne de commande pour être plus cohérente et afficher moins de données dupliquées comme l'URL de déploiement, l'attente du démarrage du serveur de développement et plus encore. Nous avons également modifié l'espacement du type de message pour être cohérent d'un message à l'autre, ce qui signifie qu'ils ne sautent plus d'une ligne à l'autre.

Exécution de next dev sur les versions avant 9.4

Exécution de next dev sur 9.4

Communauté

Nous sommes ravis de voir l'adoption continue de Next.js :

  • Nous avons eu plus de 1066 contributeurs indépendants.
  • Sur GitHub, le projet a été star plus de 48 000 fois.

Rejoignez la communauté Next.js sur GitHub Discussions. Discussions est un espace communautaire qui vous permet de vous connecter avec d'autres utilisateurs de Next.js et de poser des questions.

Si vous utilisez Next.js, n'hésitez pas à partager l'URL de votre projet avec la communauté.

Nous sommes reconnaissants envers notre communauté et tous les retours et contributions externes qui ont aidé à façonner cette version.