BackRetour au blog

Next.js 9.3

Next.js 9.3 introduit des améliorations pour la génération de sites statiques, un support natif pour SCSS, des tailles de bundle réduites, des pages 404 statiques et plus encore !

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

Tous ces avantages sont non disruptifs et entièrement rétrocompatibles. Pour mettre à jour, il vous suffit d'exécuter :

Terminal
npm i next@latest react@latest react-dom@latest

Support nouvelle génération pour la génération de sites statiques (SSG)

Lors de la construction de sites web ou d'applications web, vous devez généralement choisir entre 2 stratégies : Génération statique (SSG) ou rendu côté serveur (SSR).

Next.js est le premier framework hybride, vous permettant de choisir la technique qui correspond le mieux à votre cas d'usage, page par page.

Next.js 9.0 a introduit le concept d'Optimisation Statique Automatique. Lorsqu'une page n'a pas de besoins de récupération de données bloquants comme getInitialProps, elle sera automatiquement rendue en HTML au moment de la construction.

Il existe d'autres cas où vous pourriez vouloir rendre une page en HTML statique au moment de la construction, même avec des besoins de récupération de données bloquants. Un exemple de cela est les pages marketing alimentées par un système de gestion de contenu (CMS) sans interface ou une section blog du site.

Nous avons collaboré avec des utilisateurs intensifs de SSG et next export comme HashiCorp et discuté longuement des bonnes contraintes avec la communauté dans le RFC le plus commenté de l'histoire de Next.js pour créer une nouvelle manière unifiée de faire la récupération de données et la génération statique.

Aujourd'hui, nous sommes incroyablement heureux d'annoncer deux nouvelles méthodes de récupération de données : getStaticProps et getServerSideProps. Nous incluons également une manière de fournir des paramètres pour générer statiquement des pages pour des routes dynamiques : getStaticPaths.

Ces nouvelles méthodes présentent de nombreux avantages par rapport au modèle getInitialProps car il y a une distinction claire entre ce qui deviendra SSG vs SSR.

  • getStaticProps (Génération Statique) : Récupère les données au moment de la construction.

  • getStaticPaths (Génération Statique) : Spécifie les routes dynamiques à prérendre en fonction des données.

  • getServerSideProps (Rendu côté serveur) : Récupère les données à chaque requête.

  • Ces améliorations sont des ajouts d'API. Toutes les nouvelles fonctionnalités sont entièrement rétrocompatibles et peuvent être adoptées progressivement. Aucune dépréciation n'est introduite et getInitialProps continuera à fonctionner comme il le fait actuellement. Nous encourageons cependant l'adoption de ces nouvelles méthodes pour les nouvelles pages et projets.

getStaticProps

Si vous exportez une fonction async appelée getStaticProps depuis une page, Next.js pré-rendra cette page au moment de la construction. Ceci est particulièrement utile lorsque vous souhaitez rendre des pages statiques spécifiques depuis un CMS.

getStaticProps s'exécute toujours dans le contexte Node.js et le code est automatiquement élagué des bundles navigateur, garantissant que moins de code est envoyé au navigateur. Ainsi, vous n'avez pas à vous soucier de l'exécution du code de récupération de données dans les environnements Node.js et navigateur, qui présentent certaines incohérences.

Cela vous permet d'utiliser n'importe quelle technique de récupération de données asynchrone ou même synchrone, incluant fetch, REST, GraphQL, ou même accéder directement à une base de données.

pages/posts/[id].js
export async function getStaticProps(context) {
  return {
    props: {}, // sera passé au composant de page comme props
  };
}

Le paramètre context est un objet contenant les clés suivantes :

  • params : params contient les paramètres de route pour les pages utilisant des routes dynamiques. Par exemple, si le nom de la page est [id].js, alors params ressemblera à { id: ... }. Pour en savoir plus, consultez la documentation sur le routage dynamique. Vous devriez utiliser ceci avec getStaticPaths, que nous expliquerons plus tard.

Voici un exemple qui utilise getStaticProps pour récupérer une liste d'articles de blog depuis un CMS :

pages/blog.js
// Vous pouvez utiliser n'importe quelle bibliothèque de récupération de données
import fetch from 'node-fetch';
 
// posts sera rempli au moment de la construction par getStaticProps()
function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  );
}
 
// Cette fonction est appelée au moment de la construction dans l'environnement Node.js.
// Elle ne sera pas appelée côté client, donc vous pouvez même faire
// des requêtes directes à la base de données. Voir la section "Détails techniques".
export async function getStaticProps() {
  // Appel d'un endpoint API externe pour obtenir les posts.
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  // En retournant { props: posts }, le composant Blog
  // recevra `posts` comme prop au moment de la construction
  return {
    props: {
      posts,
    },
  };
}
 
export default Blog;

Quand devrais-je utiliser getStaticProps ?

Vous devriez utiliser getStaticProps si :

  • Les données nécessaires pour rendre la page sont disponibles au moment de la construction avant la requête d'un utilisateur.
  • Les données proviennent d'un CMS sans interface.
  • Les données peuvent être mises en cache publiquement (non spécifiques à un utilisateur).
  • La page doit être pré-rendue (pour le SEO) et être très rapide — getStaticProps génère des fichiers HTML et JSON, qui peuvent tous deux être mis en cache par un CDN pour la performance.

Pour en savoir plus sur getStaticProps, référez-vous à la Documentation sur la récupération de données.

getStaticPaths

Si une page a des routes dynamiques et utilise getStaticProps, elle doit définir une liste de chemins qui doivent être rendus en HTML au moment de la construction.

Si vous exportez une fonction async appelée getStaticPaths depuis une page qui utilise des routes dynamiques, Next.js pré-rendra statiquement tous les chemins spécifiés par getStaticPaths.

pages/posts/[id].js
export async function getStaticPaths() {
  return {
    paths: [
      { params: { ... } } // Voir la section "paths" ci-dessous
    ],
    fallback: true or false // Voir la section "fallback" ci-dessous
  };
}

La clé paths (requise)

La clé paths détermine quels chemins seront pré-rendus. Par exemple, supposons que vous ayez une page utilisant des routes dynamiques nommée pages/posts/[id].js. Si vous exportez getStaticPaths depuis cette page et retournez ce qui suit pour paths :

return {
  paths: [
    { params: { id: 1 } },
    { params: { id: 2 } }
  ],
  fallback: ...
}

Alors Next.js générera statiquement posts/1 et posts/2 au moment de la construction en utilisant le composant de page dans pages/posts/[id].js.

Notez que la valeur pour chaque params doit correspondre aux paramètres utilisés dans le nom de la page :

  • Si le nom de la page est pages/posts/[postId]/[commentId], alors params devrait contenir postId et commentId.
  • Si le nom de la page utilise des routes catch-all, par exemple pages/[...slug], alors params devrait contenir slug qui est un tableau. Par exemple, si ce tableau est ['foo', 'bar'], alors Next.js générera statiquement la page à /foo/bar.

La clé fallback (requise)

L'objet retourné par getStaticPaths doit contenir une clé fallback booléenne.

Fallback: false

Si fallback est false, alors tout chemin non retourné par getStaticPaths résultera en une page 404. Ceci est utile si vous savez que tous les chemins seront connus au moment de la construction.

Voici un exemple qui pré-rend un article de blog par page appelé pages/posts/[id].js. La liste des articles de blog sera récupérée depuis un CMS et retournée par getStaticPaths. Ensuite, pour chaque page, elle récupère les données de l'article depuis un CMS en utilisant getStaticProps.

pages/posts/[id].js
import fetch from 'node-fetch';
 
function Post({ post }) {
  // Rendu de l'article...
}
 
// Cette fonction est appelée au moment de la construction
export async function getStaticPaths() {
  // Appel d'un endpoint API externe pour obtenir les posts
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  // Obtient les chemins que nous voulons pré-rendre basés sur les posts
  const paths = posts.map((post) => `/posts/${post.id}`);
 
  // Nous pré-rendrons uniquement ces chemins au moment de la construction.
  // { fallback: false } signifie que les autres routes devraient renvoyer 404.
  return { paths, fallback: false };
}
 
// Ceci est également appelé au moment de la construction
export async function getStaticProps({ params }) {
  // params contient l'`id` du post.
  // Si la route est comme /posts/1, alors params.id est 1
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();
 
  // Passe les données du post à la page via props
  return { props: { post } };
}
 
export default Post;

Fallback: true

Si fallback est true, alors le comportement de getStaticProps change, Next.js rendra les chemins fournis en HTML au moment de la construction. Lorsqu'un chemin n'a pas été généré au moment de la construction, il sera généré à la demande lorsqu'un utilisateur demandera la page.

Ceci est utile lorsque votre application a de nombreuses routes qui peuvent être générées statiquement mais que vous ne voulez pas augmenter les temps de construction pour les pages en ne générant qu'un sous-ensemble au moment de la construction.

L'utilisateur qui déclenche la génération de la page recevra un HTML de secours, généralement une page avec un état de chargement. La raison à cela est que le HTML statique peut être servi depuis un CDN, garantissant que la page est toujours rapide, même lorsqu'elle n'a pas encore été générée.

Un exemple de génération statique à la demande de pages supplémentaires :

pages/posts/[id].js
import { useRouter } from 'next/router';
import fetch from 'node-fetch';
 
function Post({ post }) {
  const router = useRouter();
 
  // Si la page n'est pas encore générée, ceci sera affiché
  // initialement jusqu'à ce que getStaticProps() termine son exécution
  if (router.isFallback) {
    return <div>Chargement...</div>;
  }
 
  // Rendu de l'article...
}
 
// Cette fonction est appelée au moment de la construction
export async function getStaticPaths() {
  return {
    // Seuls `/posts/1` et `/posts/2` sont générés au moment de la construction
    paths: [{ params: { id: 1 } }, { params: { id: 2 } }],
    // Active la génération statique de pages supplémentaires
    // Par exemple : `/posts/3`
    fallback: true,
  };
}
 
// Ceci est également appelé au moment de la construction
export async function getStaticProps({ params }) {
  // params contient l'`id` du post.
  // Si la route est comme /posts/1, alors params.id est 1
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();
 
  // Passe les données du post à la page via props
  return { props: { post } };
}
 
export default Post;

Pour en savoir plus sur getStaticPaths, référez-vous à la Documentation sur la récupération de données.

getServerSideProps

Si vous exportez une fonction async appelée getServerSideProps depuis une page, Next.js rendra cette page à chaque requête (Rendu côté serveur - SSR).

getServerSideProps s'exécute toujours côté serveur et le code est automatiquement élagué (tree-shaken) des bundles navigateur, garantissant qu'un minimum de code est envoyé au navigateur. Ainsi, vous n'avez pas à vous soucier de l'exécution du code de récupération de données à la fois dans les environnements serveur et navigateur, qui présentent certaines incohérences. Cela améliore les performances dans de nombreux cas car le serveur aura généralement une connexion plus rapide à la source de données. Cela renforce également la sécurité en exposant moins la logique de récupération de données.

Cela vous permet d'utiliser n'importe quelle technique de récupération de données asynchrone ou même synchrone, y compris fetch, REST, GraphQL, ou même un accès direct à une base de données.

Lors de la navigation entre les pages en utilisant next/link au lieu d'exécuter getServerSideProps dans le navigateur, Next.js effectuera une requête vers le serveur qui renverra le résultat de l'appel à getServerSideProps.

pages/index.js
export async function getServerSideProps(context) {
  return {
    props: {}, // sera passé au composant de page en tant que props
  };
}

Le paramètre context est un objet contenant les clés suivantes :

Voici un exemple qui utilise getServerSideProps pour récupérer des données au moment de la requête et les afficher :

pages/index.js
function Page({ data }) {
  // Afficher les données...
}
 
// Cette fonction est appelée à chaque requête
export async function getServerSideProps() {
  // Récupérer les données depuis une API externe
  const res = await fetch(`https://.../data`);
  const data = await res.json();
 
  // Passer les données à la page via les props
  return { props: { data } };
}
 
export default Page;

Pour en savoir plus sur getServerSideProps, consultez la documentation sur la récupération de données.

Mode Prévisualisation

Comme mentionné précédemment dans cet article, la Génération Statique est utile lorsque vos pages récupèrent des données depuis un CMS headless. Cependant, ce n'est pas idéal lorsque vous rédigez un brouillon sur votre CMS headless et que vous souhaitez le prévisualiser immédiatement sur votre page. Comme le résultat est statique, prévisualiser les modifications devient plus difficile car vous devriez régénérer cette page statique.

L'introduction de getStaticProps dans Next.js ouvre de nouvelles possibilités comme tirer parti des capacités de rendu à la demande de Next.js sous certaines conditions.

Par exemple, lors de la prévisualisation d'un brouillon depuis votre CMS headless, vous voudriez contourner le rendu statique et effectuer un rendu à la demande de la page avec le contenu du brouillon au lieu du contenu publié. Vous voudriez que Next.js contourne la Génération Statique uniquement pour ce cas spécifique.

Nous sommes heureux d'annoncer une nouvelle fonctionnalité intégrée de Next.js pour répondre à ce besoin : le Mode Prévisualisation.

Le Mode Prévisualisation permet aux utilisateurs de contourner la page générée statiquement pour effectuer un rendu à la demande (SSR) d'une page de brouillon depuis, par exemple, un CMS.

Cependant, vous n'êtes pas limité à certains systèmes CMS. Le Mode Prévisualisation s'intègre directement avec getStaticProps et getServerSideProps, il peut donc être utilisé avec n'importe quel type de solution de récupération de données.

Le Mode Prévisualisation est déjà disponible lors de l'utilisation de next start, ou de manière transparente en déployant sur le Réseau Edge de Vercel.

Essayez vous-même le mode prévisualisation sur https://next-preview.vercel.app/

Apprenez-en plus sur le Mode Prévisualisation en consultant la documentation.

Collaboration avec les fournisseurs de CMS

getStaticProps vous permet de récupérer des données depuis n'importe quelle source de données, y compris les systèmes CMS.

Nous collaborons activement avec de nombreux acteurs clés de l'écosystème CMS pour fournir des exemples et des guides sur l'intégration avec Next.js.

Les exemples sur lesquels nous travaillons actuellement incluent :

Si votre entreprise est active dans l'écosystème CMS, nous serions ravis de travailler avec vous ! N'hésitez pas à contacter notre équipe par email ou Twitter.

Prise en charge intégrée de Sass pour les feuilles de style globales

Next.js 9.2 a introduit une prise en charge intégrée des feuilles de style CSS globales pour remplacer le plugin next-css avec de meilleures valeurs par défaut afin de fournir un résultat plus optimisé.

Juste après la sortie, nous avons été de plus en plus sollicités pour intégrer la prise en charge de Sass, car de nombreuses entreprises migrant vers Next.js ont un système de design existant basé sur Sass.

En examinant l'utilisation des plugins Next.js, nous avons constaté qu'environ 30 % des applications Next.js utilisent next-sass aujourd'hui, contre 44 % utilisant du CSS vanilla et 6 % utilisant Less.

De plus, next-sass avait les mêmes contraintes manquantes que next-css. Cela signifie que vous pouviez importer un fichier Sass dans chaque fichier du projet, mais ce fichier Sass importé serait global pour toute l'application.

Après avoir considéré ces statistiques et les retours, nous sommes ravis d'annoncer que Next.js prend désormais en charge nativement l'importation de feuilles de style Sass.

Pour commencer à utiliser les imports Sass globaux dans votre application, installez sass :

Terminal
npm install sass

Ensuite, importez le fichier Sass dans pages/_app.js.

Par exemple, considérez la feuille de style suivante nommée styles.scss à la racine de votre projet :

$primary-color: #333;
 
body {
  padding: 20px 20px 60px;
  margin: 0;
  color: $primary-color;
}

Créez un fichier pages/_app.js s'il n'est pas déjà présent. Puis, importez le fichier styles.scss :

pages/_app.js
import '../styles.scss';
 
// Cette exportation par défaut est requise dans un nouveau fichier `pages/_app.js`.
export default function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

Comme les feuilles de style sont globales par nature, elles doivent être importées dans le composant <App> personnalisé. Ceci est nécessaire pour éviter les conflits de noms de classe et d'ordre pour les styles globaux.

En développement, exprimer les feuilles de style de cette manière permet à vos styles d'être automatiquement mis à jour sur la page lors de leur édition.

En production, tous les fichiers Sass et CSS seront automatiquement concaténés en un seul fichier .css minifié. Ce fichier CSS sera chargé via une balise <link> et automatiquement injecté dans le balisage HTML par défaut généré par Next.js.

Cette nouvelle fonctionnalité est entièrement rétrocompatible. Si vous utilisez @zeit/next-sass ou d'autres plugins liés au CSS, la fonctionnalité est désactivée pour éviter les conflits.

Si vous utilisez actuellement @zeit/next-sass, nous vous recommandons de supprimer le plugin de votre next.config.js et package.json, passant ainsi à la prise en charge intégrée de Sass lors de la mise à niveau.

Prise en charge intégrée des modules CSS Sass pour les styles au niveau des composants

Next.js prend désormais en charge les modules CSS avec les fichiers Sass en utilisant la convention de nommage [name].module.scss.

Contrairement à la prise en charge précédemment disponible dans Next.js 5+ avec next-sass, les fichiers Sass globaux et les modules CSS peuvent désormais coexister — next-sass nécessitait que tous les fichiers .scss de votre application soient traités comme globaux ou locaux, mais pas les deux.

Les modules CSS limitent la portée des styles Sass en créant automatiquement des noms de classe uniques. Cela vous permet d'utiliser le même nom de classe Sass dans différents fichiers sans craindre de collisions.

Ce comportement fait des modules CSS la manière idéale d'inclure des styles Sass au niveau des composants. Les fichiers de modules CSS peuvent être importés n'importe où dans votre application.

Pour commencer à utiliser les modules CSS Sass dans votre application, assurez-vous d'avoir sass installé :

Terminal
npm install sass

Maintenant, considérez un composant réutilisable Button dans le dossier components/ :

Premièrement, créez components/Button.module.scss avec le contenu suivant :

/*
Vous n'avez pas besoin de vous inquiéter que .error {} entre en conflit avec d'autres fichiers `.css` ou
`.module.css` !
*/
$color: white;
 
.error {
  color: $color;
  background-color: red;
}

Ensuite, créez components/Button.js, en important et utilisant le fichier CSS ci-dessus :

components/Button.js
import styles from './Button.module.scss';
 
export function Button() {
  return (
    <button
      type="button"
      // Notez comment la classe "error" est accessible en tant que propriété de l'objet
      // `styles` importé.
      className={styles.error}
    >
      Destroy
    </button>
  );
}

Les modules CSS pour les fichiers Sass sont une fonctionnalité optionnelle et sont uniquement activés pour les fichiers avec l'extension .module.scss. Les feuilles de style <link> classiques et les styles Sass globaux sont toujours pris en charge.

En production, tous les fichiers de modules CSS sont automatiquement concaténés en de nombreux fichiers .css minifiés et découpés. Ces fichiers .css représentent les chemins d'exécution critiques dans votre application, garantissant que la quantité minimale de CSS est chargée par page pour que votre application s'affiche.

Comme ci-dessus, cette nouvelle fonctionnalité est entièrement rétrocompatible. Si vous utilisez @zeit/next-sass ou d'autres plugins liés au CSS, la fonctionnalité est désactivée pour éviter les conflits.

Si vous utilisez actuellement @zeit/next-sass, nous vous recommandons de supprimer le plugin de votre next.config.js et package.json, passant ainsi à la prise en charge intégrée de Sass.

Optimisation Statique Automatique pour les 404

La sortie de Next.js 9 a introduit le concept d'Optimisation Statique Automatique : lorsqu'une page n'a pas d'exigences de données bloquantes, Next.js générera automatiquement la page en HTML statique au moment de la construction. Cependant, il y avait une page qui n'était pas automatiquement rendue en HTML statique : la page 404. La principale raison pour laquelle la page 404 n'était pas rendue statiquement automatiquement était que la page /_error alimentant les 404 gérait plus que les 404, par exemple, les erreurs.

Étant donné que les pages 404 sont rendues pour les routes inexistantes, rendre la page à la demande pourrait entraîner des coûts et une charge serveur accrus.

Nous avons cherché à vous mettre dans une situation optimale de deux manières :

  • L'expérience par défaut de Next.js génère une page 404 statique
  • Lors de la personnalisation de la page 404, elle s'assure toujours que vous obtenez une page statique

Cette fonctionnalité est entièrement rétrocompatible, donc si vous avez actuellement un pages/_error.js personnalisé, il continuera à être utilisé pour la page 404 jusqu'à ce que vous ajoutiez pages/404.js.

Page 404 statique par défaut

Lorsque votre application n'a pas de page pages/_error.js personnalisée, Next.js générera automatiquement la page 404 de manière statique et l'utilisera lorsqu'un 404 doit être servi. Cela se produit automatiquement et aucune modification n'est nécessaire.

Page 404 personnalisée avec pages/404.js

Pour remplacer la page 404 par défaut, vous pouvez maintenant créer un pages/404.js qui sera toujours automatiquement optimisé statiquement au moment de la construction. Cette page est utilisée à la place de pages/_error.js pour rendre un 404 si votre application en possède un.

pages/404.js
export default () => <h1>Ceci est la page 404</h1>;

Runtime réduit de 32+ kB (15 kB+ Gzip)

Next.js prend en charge les mêmes navigateurs que React lui-même, sans configuration requise. Cela inclut Internet Explorer 11 (IE11) et tous les navigateurs populaires (Edge, Firefox, Chrome, Safari, Opera, etc.).

Dans le cadre de cette compatibilité, nous compilons également votre application pour qu'elle soit compatible avec IE11 : cela vous permet d'utiliser en toute sécurité des fonctionnalités de syntaxe ES6+, Async/Await, les propriétés de reste/décomposition d'objet, et plus encore — le tout sans aucune configuration nécessaire.

Une partie de ce processus de compilation implique également l'injection transparente des polyfills nécessaires (par exemple Array.from ou Symbol). Cependant, ces polyfills ne sont nécessaires que pour moins de 10 % du trafic web, dans la plupart des cas pour supporter IE11.

À partir de Next.js 9.3, Next.js chargera automatiquement les polyfills nécessaires pour supporter les navigateurs legacy, et ne les chargera que dans ces navigateurs legacy.

En pratique, cela signifie que 32 kB ou plus seront éliminés de votre taille de Premier Chargement pour 90 %+ de vos utilisateurs.

Ces économies de taille sont encore plus importantes pour les applications plus volumineuses qui dépendent de davantage de fonctionnalités de navigateur.

Cette optimisation est entièrement automatique et aucune modification de l'application n'est nécessaire pour en profiter !

Communauté

Nous sommes très enthousiastes de voir l'adoption continue de Next.js :

  • Nous avons eu plus de 927 contributeurs indépendants.
  • Sur GitHub, le projet a été mis en favori plus de 46 600 fois.
  • Le répertoire d'exemples contient plus de 226 exemples.

La communauté Next.js compte désormais plus de 15 250 membres. La communauté peut désormais être trouvée sur les discussions GitHub, un nouvel endroit pour discuter et poser des questions ! Rejoignez-nous !

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

Un merci spécial à Jeff Escalante pour ses retours significatifs sur les nouvelles méthodes de récupération de données.

Un immense merci à tous ceux qui ont contribué à cette version : @arcanis, @lgordey, @ijjk, @martpie, @jaywink, @fabianishere, @dijs, @TheRusskiy, @quinnturner, @timneutkens, @lfades, @vvo, @adithwip, @rafaelalmeidatk, @bmathews, @Spy-Seth, @EvgeniyKumachev, @chibicode, @piglovesyou, @HaNdTriX, @Timer, @janicklas-ralph, @devknoll, @prateekbh, @ethanryan, @MoOx, @rifaidev, @msweeneydev, @motiko, et @balazsorban44 pour leur aide !