BackZurück zum Blog

Next.js 6.1

Die Version Next.js 6.1 bietet verbesserte Zuverlässigkeit und Konsistenz in der Entwicklung

Wir freuen uns heute, die produktionsreife Version Next.js 6.1 vorzustellen, die folgende Features bietet:

  • Verbesserte Zuverlässigkeit beim Hot Reloading
  • Codebase-Verbesserungen
  • Next.js Codemods

Zusätzlich zum Release von Next.js 6.1 freuen wir uns bekannt zu geben, dass nextjs.org nun Open Source ist.

Verbesserte Zuverlässigkeit beim Hot Reloading

In Versionen vor Next.js 6.1 implementierte Next.js react-hot-loader für den Benutzer. Diese Bibliothek behält den React-Zustand zwischen Hot Reloads bei.

Dabei fügt react-hot-loader einige nicht-standardmäßige Verhaltensweisen zu React hinzu, zum Beispiel ignoriert es shouldComponentUpdate und der Element-type endete als Proxy-Komponente anstelle der eigentlichen React-Komponente.

Um sicherzustellen, dass Next.js so nah wie möglich am Standard-React ist, haben wir react-hot-loader als Abhängigkeit entfernt. Dies stellt sicher, dass sich der Entwicklungs- und Produktionsmodus im Verhalten näher sind. Beachten Sie, dass die Hot-Reloading-Funktion von Next.js nicht entfernt wurde. Hot Reloading wurde immer intern von Next.js gehandhabt.

Hot Reloading für TypeScript und andere benutzerdefinierte Erweiterungen

Standardmäßig sucht Next.js automatisch nach .js- oder .jsx-Dateien im pages-Verzeichnis, um Routen zu definieren.

Mit der Einführung von universal webpack in Next.js 5 kam die Möglichkeit, compile-to-js Top-Level-Seiten zu haben. Ein gutes Beispiel ist TypeScript, das .ts und .tsx verwendet.

pageExtensions ist ein Konfigurationsschlüssel in next.config.js, der Next.js-Plugins ermöglicht, Erweiterungen zu definieren, die als Seiten betrachtet werden sollten. Zum Beispiel definiert @zeit/next-typescript .ts und .tsx oder @zeit/next-mdx, der dokumentiert, wie Top-Level-.mdx-Seiten erstellt werden können.

Früher mussten Next.js-Plugins bei der Implementierung von pageExtensions den hot-self-accept-loader implementieren, der für Hot Reloading verwendet wird. Dies ist nicht mehr erforderlich. Wenn eine Erweiterung zu pageExtensions hinzugefügt wird, wird der hot-self-accept-loader automatisch angewendet.

Codebase-Verbesserungen

In letzter Zeit haben wir den Weg für kommende Features geebnet, was einige unter der Haube liegende Änderungen mit sich brachte, die langfristig die Codequalität verbessern werden.

Eine dieser Änderungen ist, dass das server/build-Verzeichnis in das Top-Level-build-Verzeichnis verschoben wurde. Dies macht die Webpack- und Babel-Konfiguration für neue Mitwirkende leichter zu finden.

Wir haben uns auch darauf konzentriert, Flow-Typen im gesamten Codebase hinzuzufügen.

Eine für Benutzer sichtbarere Änderung ist, dass .next/dist in .next/server umbenannt wurde. Das .next-Verzeichnis enthält die Build-Ausgabe. Wenn Sie beispielsweise next build ausführen, wird das Ergebnis in .next gespeichert.

Die Pre-Rendering-Dateien befinden sich jetzt im server-Verzeichnis

Vorkommen der gleichen Konstanten wurden in eine gemeinsame Datei verschoben: constants.js

Next.js Codemods

Als Next.js 6.0 veröffentlicht wurde, wurde die magisch injizierte url-Eigenschaft auf Seitenkomponenten als veraltet markiert. Der Grund, warum url entfernt wird, ist, dass wir Dinge sehr vorhersehbar und explizit machen wollen. Eine magische url-Eigenschaft, die aus dem Nichts kommt, hilft diesem Ziel nicht.

Die empfohlene Methode, um die gleichen Eigenschaften wie die url-Eigenschaft zu erhalten, ist die Verwendung von withRouter:

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

So wurde der Pfadname in Versionen vor Next.js 6 mit url abgerufen

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

So sollte der Pfadname in Versionen nach Next.js 6 mit router abgerufen werden, der von withRouter injiziert wird

Da wir uns verpflichtet haben, den Upgrade-Pfad für Next.js-Anwendungen einfach zu halten, haben wir uns entschieden, eine einfache Möglichkeit zu schaffen, um Verwendungen von url auf withRouter upzugraden.

Das Ergebnis dieser Bemühungen ist next‑codemod, eine Bibliothek von Codemods, die das Upgraden bestimmter veralteter Features auf ihre neue Verwendung so einfach wie das Ausführen eines Befehls machen.

Der erste Codemod, den wir bereitstellen, ist url-to-withrouter, der automatisch viele Fälle, in denen url verwendet wurde, in withRouter umwandelt.

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

Dies wird Verwendungen von url in withRouter umwandeln.

Mehr dazu hier lesen

Beitragen zu Next.js

Die Next.js-Community wächst, mit mehr als 450 Mitwirkenden, die mindestens 1 Commit in den Next.js-Kern oder die Beispiele eingebracht haben.

Es gibt viele Möglichkeiten, zu Next.js beizutragen:

nextjs.org Open Source

Wir freuen uns bekannt zu geben, dass nextjs.org nun Open Source ist, sodass es als Referenzimplementierung für Next.js dienen kann und Probleme/Verbesserungen direkt im Projekt gemeldet werden können.

Zukunft

Wir haben an einigen neuen Features gearbeitet, um die Zuverlässigkeit und Leistung zu erhöhen. Hier sind einige Highlights:

Webpack 4

Webpack 4 bringt viele Verbesserungen mit sich: besseres Code-Splitting, weniger Konfiguration ist standardmäßig erforderlich und vor allem schnellere Build-Zeiten. In ersten Tests, die wir an einer App mit über 200 Seiten durchgeführt haben, ging die durchschnittliche Build-Zeit von next build von 100 Sekunden auf 70 Sekunden zurück. Bei einem zweiten Durchlauf (mit Caches) dauerte ein next build durchschnittlich 21 Sekunden.

Serverless Next.js

Wir machen schrittweise Änderungen, um next start in sein eigenes Paket next-server auszulagern. Dieses Paket wird stark für Installationsgröße und Startzeit optimiert sein. Diese Optimierungen sind für den "serverless" Anwendungsfall notwendig, bei dem eine neue Instanz der App bei jeder oder jeder wenigen Anfragen ausgeführt wird. Das bedeutet, dass der "kalte Start" einer Anwendung so schnell wie möglich optimiert werden muss.