Next.js 9.1

Aujourd'hui, nous sommes ravis d'annoncer Next.js 9.1 avec la prise en charge des répertoires src et public.

Nouveautés de cette version

• Prise en charge du répertoire src : Le répertoire pages peut désormais être imbriqué dans le dossier src, prenant en charge une plus grande variété de configurations d'applications.
• Prise en charge du répertoire public : Définissez des fichiers à monter à la racine de l'URL de votre application (par exemple favicon.ico).

Prévisualisations dans cette version

• Prise en charge CSS intégrée : Les applications pourront bientôt importer du CSS global et bénéficier du rechargement à chaud en développement ainsi que des optimisations avancées en production, de la compilation et du polyfilling.
• Pages d'erreur statiques : Exportez statiquement les pages d'erreur attendues (comme 404) pour une meilleure disponibilité (CDN).
• Module / Nomodule : Envoyez des bundles JavaScript plus petits aux utilisateurs utilisant des navigateurs modernes.
• Amélioration du découpage des bundles : Envoyez moins d'octets à vos utilisateurs, améliorant ainsi le TTI et la vitesse de transition des pages. Les gros chunks de bibliothèques sont également mis en cache à long terme entre les déploiements.

Comme toujours, nous nous efforçons de garantir que tous ces avantages soient rétrocompatibles. Pour mettre à jour, il vous suffit d'exécuter :

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

Si votre application utilise une version de Next.js antérieure à la version 9, vous pouvez consulter le guide de mise à niveau pour les changements que vous pourriez devoir effectuer.

Depuis notre dernière version majeure, nous sommes heureux d'avoir vu des entreprises comme TikTok, Hilton, Elastic, Realtor et JW Player lancer des projets avec Next.js. Consultez la vitrine pour en savoir plus !

Prise en charge du répertoire src

Next.js possède un répertoire spécial pages où chaque fichier devient une route distincte, suivant l'approche convention over configuration. Ce répertoire doit se trouver à la racine d'une application Next.js.

En discutant avec des entreprises utilisant Next.js et en inspectant certains codebases privés, nous avons constaté qu'un modèle courant que les développeurs souhaitaient était d'avoir un répertoire src pour leur code et d'y inclure également le répertoire pages.

À partir de Next.js 9.1, il est désormais possible de créer un répertoire src/pages au lieu de créer un répertoire pages à la racine de l'application.

L'utilisation du répertoire src est facultative et couvre le cas où votre entreprise a déjà cette norme en place.

Le dossier pages dans le répertoire src

Prise en charge du répertoire public

Outre le répertoire pages, Next.js possède un autre répertoire spécial appelé static, dont les fichiers étaient mappés sur la route /static.

Par exemple, static/my-image.png serait mappé sur /static/my-image.png.

Cette convention a bien fonctionné depuis la première version de Next.js et ne pose pas de problèmes particuliers.

Cependant, avec le temps, nous avons constaté que /static ne couvre pas tout ce qui est nécessaire dans une application web. Par exemple, robots.txt doit être servi depuis la racine du domaine.

À partir de Next.js 9.1, nous introduisons un nouveau répertoire appelé public.

Tous les fichiers du répertoire public seront mappés sur la racine du domaine.

Par exemple, public/robots.txt sera mappé sur /robots.txt.

Comme public couvre également le cas d'utilisation du répertoire static, nous avons décidé de déprécier le répertoire static en faveur de la création d'un dossier public/static avec les mêmes fonctionnalités.

Comme toujours, nous nous efforçons d'assurer la rétrocompatibilité, donc le répertoire static continuera à fonctionner avec un message de dépréciation.

À venir

Les fonctionnalités suivantes sont actuellement sous un drapeau expérimental et seront publiées une fois l'implémentation finale prête.

Prise en charge CSS intégrée

Actuellement, Next.js dispose d'une solution CSS-in-JS intégrée appelée styled-jsx. Cette solution fonctionne bien pour styliser des composants React individuels.

Cependant, en discutant avec des entreprises, nous avons constaté qu'il existe un besoin courant de réutiliser certains styles existants ou un système de conception basé sur CSS.

En général, cela signifie ajouter le plugin next-css pour ajouter la prise en charge des imports CSS.

Nous avons constaté qu'environ 50 % de tous les utilisateurs de Next.js ajoutent ce plugin à leur application.

En raison de cette utilisation extensive, nous ajoutons une prise en charge intégrée des imports CSS avec rechargement automatique des styles en développement et des optimisations de production qui n'étaient pas possibles auparavant avec le plugin next-css.

L'implémentation initiale est actuellement testée sur des applications Next.js en production.

Les imports CSS globaux seront introduits en premier :

// Les styles globaux peuvent être importés depuis _app.js
import '../styles/global.css';
import App from 'next/app';
 
export default App;

Après les imports CSS globaux, nous introduirons la prise en charge des modules CSS via l'extension .module.css :

// Les styles scopés sont importés via .module.css
import styles from '../styles/index.module.css';
 
export default function HomePage() {
  return <h1 className={styles.heading}>Hello World</h1>;
}

Cela nous permettra d'offrir une expérience de développement bien meilleure lors de l'utilisation des imports CSS.

Vous pouvez en savoir plus sur ce travail en cours dans le RFC sur GitHub.

Pages d'erreur statiques

Next.js possède une page spéciale rendue lorsqu'une erreur se produit, cette page est appelée en interne /_error. Cette page peut être personnalisée par les utilisateurs en créant un fichier pages/_error.js qui exporte un composant React.

Les erreurs rendues sont généralement divisées en 2 cas : les erreurs attendues et les erreurs inattendues.

Les erreurs attendues sont, par exemple, la page 404.

Une erreur inattendue serait, par exemple, lorsqu'une erreur est levée dans getInitialProps ou lors du rendu de l'arbre React, ce qui rend une 500.

Nous prévoyons d'ajouter l'optimisation statique automatique pour les erreurs attendues car, en général, elles n'ont pas besoin d'être rendues dynamiquement.

Il y aura une option de désactivation si un utilisateur souhaite rendre ces pages dynamiquement, mais par défaut, la 404 sera une page statique. Cela réduit la charge sur le serveur lors de l'utilisation de la cible server et réduit les coûts lors de l'utilisation de la cible serverless.

Un autre avantage de rendre la page statique est qu'elle peut être mise en cache automatiquement lors de l'utilisation d'un CDN.

Collaboration avec Google Chrome

Comme partagé dans l'annonce de Next.js 9, l'équipe Google Chrome investit des ressources pour améliorer Next.js et a travaillé sur plusieurs efforts pour apporter des améliorations de performance à grande échelle pour toutes les applications Next.js.

Pour en savoir plus sur cette collaboration, vous pouvez lire l'annonce de Next.js 9 et regarder cette présentation de Nicole Sullivan à React Rally.

Module / Nomodule

Lorsque vous écrivez du code dans Next.js, vous écrivez généralement du JavaScript "moderne". Vous pouvez utiliser toutes les dernières fonctionnalités stables et Next.js s'assurera automatiquement que ces fonctionnalités sont transformées ou polyfillées via la compilation du code à l'aide de Babel.

À ce stade, nombre de ces fonctionnalités JavaScript sont prises en charge par la majorité des navigateurs. Cependant, en général (y compris dans Next.js), le code est livré sous forme d'un seul bundle JavaScript qui s'exécute sur tous les navigateurs que votre application prend en charge.

Dans le cas de Next.js, cela signifie compiler le JavaScript moderne vers un format compatible avec Internet Explorer 11.

Par exemple, actuellement, Next.js doit fournir des polyfills pour la syntaxe async/await car le code pourrait être exécuté dans des navigateurs qui ne prennent pas en charge async/await, ce qui le ferait planter.

Pour éviter de casser les anciens navigateurs tout en envoyant du JavaScript moderne aux navigateurs qui prennent en charge la nouvelle syntaxe, Next.js utilisera le modèle module/nomodule. Le modèle module/nomodule fournit un mécanisme fiable pour servir du JavaScript moderne aux navigateurs modernes tout en permettant aux anciens navigateurs de revenir à du code ES5 polyfillé.

Cette nouvelle fonctionnalité est actuellement testée en production par plusieurs applications Next.js à grande échelle pour collecter des données réelles. Les résultats de ces tests sont prometteurs et plus de détails sur les améliorations de performance de ce changement seront partagés prochainement.

Amélioration du découpage des bundles

Next.js possède actuellement plusieurs bundles JavaScript qu'il charge pour rendre une page interactive. Les plus notables sont :

• Le bundle JavaScript de la page.
• Un fichier avec le JavaScript commun.
• Le bundle runtime client-side de Next.js.
• Les imports dynamiques (généralement ajoutés via next/dynamic).

Pour garantir que la page devient interactive, tous ces bundles doivent être chargés car ils dépendent tous les uns des autres pour pouvoir démarrer React dans le navigateur.

Comme ces bundles doivent être chargés pour que React démarre, il est important qu'ils soient aussi optimisés que possible et ne téléchargent pas trop de code inutile du reste de l'application.

Pour cette raison, il existe un bundle commons qui contient le JavaScript commun entre les pages. Le calcul de la stratégie actuelle de découpage des bundles pour générer commons est basé sur une heuristique de ratio : si un module est utilisé dans 50 % de toutes les pages, il sera marqué comme module commun.

Cependant, les applications pourraient être composées de nombreuses parties différentes. Par exemple, des pages marketing, un blog et un tableau de bord. S'il y avait un grand nombre de pages marketing par rapport au tableau de bord, le calcul des commons causerait un résultat plus optimisé pour les pages marketing.

Notre objectif est d'optimiser ces deux cas en même temps dans une seule application.

Alex Castle a défini une nouvelle couche de chunking (création de fichiers JavaScript séparés) qui permet un découpage des commons plus optimisé avec plusieurs fichiers et surtout lorsque de nombreuses pages sont impliquées.

Comme pour la prise en charge module/nomodule, l'amélioration du découpage des bundles est testée en production par plusieurs applications Next.js à grande échelle pour collecter des données réelles. Les résultats de ces tests et plus de détails sur les améliorations de performance de ce changement seront partagés prochainement dans un article de blog séparé.

Communauté

Nous sommes enthousiastes à propos des changements à venir qui amélioreront les performances de toutes les applications Next.js.

De plus, la communauté Next.js continue de s'étendre :

• Nous avons eu plus de 800 contributeurs ayant soumis au moins 1 commit.
• Sur GitHub, le projet a été star plus de 41 350 fois.
• Le répertoire d'exemples contient plus de 210 exemples.

La communauté Next.js compte désormais plus de 11 250 membres. Rejoignez-nous !

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