Next.js 6.1

Nous sommes fiers de vous présenter aujourd'hui Next.js 6.1 prêt pour la production, avec :

• Une meilleure fiabilité du rechargement à chaud (hot reloading)
• Des améliorations du codebase
• Des codemods pour Next.js

En plus de la sortie de Next.js 6.1, nous sommes ravis d'annoncer que nextjs.org est désormais open source

Fiabilité améliorée du rechargement à chaud

Dans les versions antérieures à Next.js 6.1, Next.js implémentait react-hot-loader pour le compte de l'utilisateur. Cette bibliothèque préserve l'état React entre les rechargements à chaud.

Ce faisant, react-hot-loader ajoute quelques comportements non standard à React, par exemple, il ignore shouldComponentUpdate et le type d'élément finit par être un composant proxy au lieu du véritable composant React.

Pour garantir que Next.js soit aussi proche que possible de React par défaut, nous avons supprimé react-hot-loader en tant que dépendance, ce qui assure un comportement plus similaire entre les modes développement et production. Notez que la fonctionnalité de rechargement à chaud de Next.js n'a pas été supprimée, elle a toujours été gérée en interne par Next.js.

Rechargement à chaud pour TypeScript et autres extensions personnalisées

Par défaut, Next.js recherche automatiquement tout fichier .js ou .jsx dans le répertoire pages pour définir les routes.

Avec l'introduction du webpack universel dans Next.js 5, il est devenu possible d'avoir des pages de haut niveau compilées en JS. Un bon exemple est TypeScript, qui utilise .ts et .tsx.

pageExtensions est une clé de configuration dans next.config.js visant à permettre aux plugins Next.js de définir les extensions qui doivent être considérées comme des pages. Par exemple, @zeit/next-typescript définit .ts et .tsx ou @zeit/next-mdx qui documente comment avoir des pages .mdx de haut niveau.

Auparavant, lors de l'implémentation de pageExtensions, les plugins Next.js devaient implémenter le hot-self-accept-loader utilisé pour le rechargement à chaud. Ce n'est plus nécessaire, lorsqu'une extension est ajoutée à pageExtensions, le hot-self-accept-loader est automatiquement appliqué.

Améliorations du codebase

Récemment, nous avons préparé le terrain pour les prochaines fonctionnalités, ce qui a impliqué des changements sous le capot qui amélioreront la qualité du code à long terme.

L'un de ces changements est que le répertoire server/build a été déplacé vers build à la racine. Cela rend la configuration webpack et babel plus facile à trouver pour les nouveaux contributeurs.

Nous nous sommes également concentrés sur l'ajout de types Flow dans tout le codebase.

Un changement plus visible pour les utilisateurs est que .next/dist a été renommé en .next/server. Le répertoire .next contient les résultats de la compilation. Par exemple, lorsque vous exécutez next build, le résultat sera stocké dans .next.

Les fichiers de pré-rendu se trouvent maintenant dans le répertoire server

Les occurrences des mêmes constantes ont été déplacées dans un fichier commun : constants.js

Codemods pour Next.js

Lors de la sortie de Next.js 6.0, la propriété url injectée magiquement dans les composants de page a été dépréciée. La raison pour laquelle url disparaît est que nous voulons rendre les choses très prévisibles et explicites. Avoir une propriété url magique qui apparaît de nulle part ne sert pas cet objectif.

La méthode recommandée pour obtenir les mêmes propriétés que url est d'utiliser withRouter :

// ancienne version
class Page extends React.Component {
  render() {
    const { url } = this.props;
    return <div>{url.pathname}</div>;
  }
}
export default Page;

Comment le pathname était accédé dans les versions avant Next.js 6 avec url

// nouvelle version
import { withRouter } from 'next/router';
class Page extends React.Component {
  render() {
    const { router } = this.props;
    return <div>{router.pathname}</div>;
  }
}
export default withRouter(Page);

Comment le pathname doit être accédé dans les versions après Next.js 6 avec router injecté par withRouter

Comme nous nous engageons à simplifier le processus de mise à niveau des applications Next.js, nous avons créé un moyen simple de mettre à niveau les utilisations de url vers withRouter.

Le résultat de cet effort est next‑codemod, une bibliothèque de codemods qui rend la mise à niveau des fonctionnalités dépréciées vers leur nouvelle utilisation aussi simple que l'exécution d'une commande.

Le premier codemod que nous fournissons est url-to-withrouter qui transforme automatiquement de nombreux cas où url était utilisé en withRouter.

  jscodeshift -t ./url-to-withrouter.js pages/**/*.js

Cela transformera les utilisations de url en withRouter.

En savoir plus ici

Contribuer à Next.js

La communauté Next.js grandit, avec plus de 450 contributeurs ayant déjà soumis au moins 1 commit dans le cœur de Next.js ou les exemples.

Il existe plusieurs façons de contribuer à Next.js :

• Rejoindre la communauté et donner des conseils sur GitHub

• Contribuer des exemples de cas d'utilisation courants : répertoire des exemples

• Consulter les bonnes premières issues et aide recherchée sur GitHub

  

  Il y a 30 issues ouvertes avec le label bonne première issue. Offrant aux nouveaux contributeurs l'opportunité de contribuer.

nextjs.org open source

Nous sommes ravis d'annoncer que nextjs.org est désormais open source afin qu'il puisse servir de référence d'implémentation Next.js et que les problèmes/améliorations puissent être signalés directement sur le projet.

Futur

Nous travaillons sur quelques nouvelles fonctionnalités pour améliorer la fiabilité et les performances, voici quelques points forts :

Webpack 4

Webpack 4 apporte de nombreuses améliorations : un meilleur découpage du code, moins de configuration nécessaire par défaut, et surtout des temps de compilation plus rapides. Dans les tests initiaux que nous avons effectués sur une application avec plus de 200 pages, next build est passé de 100 secondes à 70 secondes en moyenne. Lors d'une deuxième exécution (avec caches), un next build a pris 21 secondes en moyenne.

Next.js sans serveur (Serverless)

Nous apportons progressivement des changements pour préparer le déplacement de next start vers son propre package : next-server. Ce package sera fortement optimisé pour la taille d'installation et le temps de démarrage. Ces optimisations sont nécessaires pour le cas d'utilisation "serverless" où une nouvelle instance de l'application est exécutée à chaque requête ou toutes les quelques requêtes. Ce qui signifie que le "démarrage à froid" de l'application doit être optimisé pour être aussi rapide que possible.