Next.js 7

Nach 26 Canary-Releases und 3,4 Millionen Downloads freuen wir uns, die produktionsreife Version von Next.js 7 vorzustellen, mit folgenden Neuerungen:

• Verbesserte Developer Experience (DX): 57 % schnellere Startzeit, 42 % schnellere Neukompilierung
• Bessere Fehlerberichterstattung mit react-error-overlay
• Aktualisierte Kompilierungspipeline: Webpack 4 und Babel 7
• Standardisierte dynamische Imports
• Unterstützung für statische CDNs
• Kleinere initiale HTML-Nutzlast
• React Context mit SSR zwischen App und Seiten

Zu guter Letzt freuen wir uns, diese Neuigkeiten auf der komplett neu gestalteten Website nextjs.org zu präsentieren.

DX-Verbesserungen

Eines der Hauptziele von Next.js ist es, die beste Produktionsleistung mit der bestmöglichen Developer Experience zu bieten. Diese Version bringt viele signifikante Verbesserungen für die Build- und Debug-Pipelines mit sich.

Kompilierungsgeschwindigkeit

Dank Webpack 4, Babel 7 und vielen Optimierungen in unserer Codebase startet Next.js im Entwicklungsmodus jetzt bis zu 57 % schneller.

Dank unseres neuen inkrementellen Kompilierungscaches werden Änderungen am Code jetzt 40 % schneller gebaut.

Hier einige Beispieldaten, die wir gesammelt haben:

Als Bonus erhalten Sie während der Entwicklung und beim Build jetzt besseres Echtzeit-Feedback dank webpackbar:

Bessere Fehlerberichterstattung mit React Error Overlay

Genaue und hilfreiche Fehlermeldungen sind entscheidend für eine gute Entwicklungs- und Debugging-Erfahrung. Bisher haben wir nur die Fehlermeldung und ihren Stack-Trace angezeigt. Ab jetzt nutzen wir react-error-overlay, um den Stack-Trace mit folgenden Informationen anzureichern:

• Genaue Fehlerpositionen für Server- und Client-Fehler
• Hervorhebungen des Quellcodes für Kontext
• Ein vollständiger, detaillierter Stack-Trace

Hier ein Vergleich der Fehleranzeige vorher und nachher:

Die vorherige Overlay-Ansicht links, react-error-overlay rechts

Als Bonus ermöglicht react-error-overlay das einfache Öffnen Ihres Texteditors durch Klicken auf einen bestimmten Codeblock.

Webpack 4

Seit seiner ersten Version nutzt Next.js Webpack für das Bundling Ihres Codes und die Wiederverwendung des reichen Ökosystems von Plugins und Erweiterungen. Wir freuen uns, bekannt zu geben, dass Next.js jetzt von der neuesten Version Webpack 4 angetrieben wird, die zahlreiche Verbesserungen und Bugfixes mitbringt.

Dazu gehören:

• Unterstützung für .mjs-Quelldateien
• Verbesserungen beim Code-Splitting
• Bessere Tree-Shaking-Unterstützung (Entfernung von ungenutztem Code)

Eine weitere neue Funktion ist die WebAssembly-Unterstützung. Next.js kann sogar WebAssembly server-seitig rendern. Hier ein Beispiel.

Hinweis: Dieses Update ist vollständig abwärtskompatibel. Wenn Sie jedoch benutzerdefinierte Webpack-Loader oder Plugins über next.config.js verwenden, müssen Sie diese möglicherweise aktualisieren.

CSS-Imports

Mit Webpack 4 wurde eine neue Methode zur Extraktion von CSS aus Bundles eingeführt, genannt mini-extract-css-plugin.

@zeit/next-css, @zeit/next-less, @zeit/next-sass und @zeit/next-stylus nutzen jetzt mini-extract-css-plugin.

Die neue Version dieser Next.js-Plugins löst 20 bestehende Probleme im Zusammenhang mit CSS-Imports. Beispielsweise wird jetzt das Importieren von CSS in dynamischen import()-Aufrufen unterstützt:

import './my-dynamic-component.css';
 
export default function MyDynamicComponent() {
  return <h1>My dynamic component</h1>;
}

import dynamic from 'next/dynamic'
 
const MyDynamicComponent = dynamic(import('../components/my-dynamic-component'))
 
export default function Index() {
  return () {
    <div>
      <MyDynamicComponent/>
    </div>
  }
}

Eine wichtige Verbesserung ist, dass Sie nicht mehr Folgendes zu pages/_document.js hinzufügen müssen:

<link rel="stylesheet" href="/_next/static/style.css" />

Stattdessen injiziert Next.js die CSS-Datei automatisch. In der Produktion fügt Next.js außerdem automatisch einen Content-Hash zur CSS-URL hinzu, um sicherzustellen, dass Ihre Endbenutzer niemals veraltete Versionen der Datei erhalten und unveränderliches permanentes Caching ermöglicht wird.

Kurz gesagt, alles, was Sie tun müssen, um das Importieren von .css-Dateien in Ihrem Next.js-Projekt zu unterstützen, ist das withCSS-Plugin in Ihrer next.config.js zu registrieren:

const withCSS = require('@zeit/next-css');
module.exports = withCSS({
  /* my next config */
});

Standardisierte dynamische Imports

Next.js unterstützt dynamische Imports über next/dynamic seit Version 3.

Als frühe Anwender dieser Technologie mussten wir unsere eigene Lösung für die Handhabung von import() entwickeln.

Infolgedessen begann Next.js, sich von der Unterstützung zu entfernen, die Webpack später dafür einführte, und einige Features fehlten.

Daher unterstützte Next.js einige der seitdem von Webpack eingeführten import()-Features nicht.

Beispielsweise war das manuelle Benennen und Bündeln bestimmter Dateien nicht möglich:

import(/* webpackChunkName: 'my-chunk' */ '../lib/my-library');

Ein weiteres Beispiel war die Verwendung von import() ohne die Einbindung in das next/dynamic-Modul.

Ab Next.js 7 greifen wir nicht mehr in das Standardverhalten von import() ein. Das bedeutet, Sie erhalten volle import()-Unterstützung out of the box.

Diese Änderung ist ebenfalls vollständig abwärtskompatibel. Die Verwendung einer dynamischen Komponente bleibt so einfach wie:

import dynamic from 'next/dynamic';
 
const MyComponent = dynamic(import('../components/my-component'));
 
export default function Index() {
  return (
    <div>
      <MyComponent />
    </div>
  );
}

Dieses Beispiel erstellt eine neue JavaScript-Datei für my-component und lädt sie nur, wenn <MyComponent /> gerendert wird.

Am wichtigsten ist, dass das <script>-Tag nicht in die initiale HTML-Dokumentnutzlast aufgenommen wird, wenn die Komponente nicht gerendert wird.

Um unsere Codebasis weiter zu vereinfachen und das hervorragende React-Ökosystem zu nutzen, wurde next/dynamic in Next.js 7 unter der Haube mit react-loadable neu geschrieben (mit einigen geringfügigen Anpassungen). Dies führt auch zwei großartige neue Features für dynamische Komponenten ein:

• Timeouts über die timeout-Option in next/dynamic
• Eine Verzögerung der Ladekomponente über die delay-Option in next/dynamic. Diese Verzögerung ermöglicht es Ihrer loading-Komponente, x Zeit zu warten, bevor der Ladezustand gerendert wird, falls der Import sehr schnell ist.

Babel 7

Next.js 6 führte Babel 7 ein, während es noch in der Beta-Phase war. Seitdem wurde die stabile Version von Babel 7 veröffentlicht, und Next.js 7 nutzt jetzt diese Version.

Eine vollständige Liste der Änderungen finden Sie in den Release Notes von Babel.

Zu den Hauptfeatures gehören:

• TypeScript-Unterstützung, für Next.js können Sie @zeit/next-typescript verwenden
• Unterstützung der Fragment-Syntax <>
• Unterstützung für babel.config.js
• overrides-Eigenschaft, um Presets/Plugins nur auf eine Teilmenge von Dateien oder Verzeichnissen anzuwenden

Wenn Sie keine benutzerdefinierte Babel-Konfiguration in Ihrem Next.js-Projekt haben, gibt es keine Breaking Changes.

Falls Sie jedoch eine benutzerdefinierte Babel-Konfiguration haben, müssen Sie die jeweiligen benutzerdefinierten Plugins/Presets auf die neueste Version aktualisieren.

Falls Sie von einer Version vor Next.js 6 aktualisieren, können Sie das hervorragende Tool babel-upgrade verwenden.

Zusätzlich zum Upgrade auf Babel 7 setzt das Next.js-Babel-Preset (next/babel) jetzt standardmäßig die modules-Option auf commonjs, wenn NODE_ENV auf test gesetzt ist.

Diese Konfigurationsoption war oft der einzige Grund, eine benutzerdefinierte .babelrc in einem Next.js-Projekt zu erstellen:

{
  "env": {
    "development": {
      "presets": ["next/babel"]
    },
    "production": {
      "presets": ["next/babel"]
    },
    "test": {
      "presets": [["next/babel", { "preset-env": { "modules": "commonjs" } }]]
    }
  }
}

Mit Next.js 7 wird dies zu:

{
  "presets": ["next/babel"]
}

An diesem Punkt kann die .babelrc entfernt werden, da Next.js dann automatisch next/babel verwendet, wenn keine Babel-Konfiguration vorhanden ist.

Kleinere initiale HTML-Nutzlast

Da Next.js HTML vorrendert, werden Seiten in eine Standardstruktur mit <html>, <head>, <body> und den benötigten JavaScript-Dateien eingebettet.

Diese initiale Nutzlast war zuvor etwa 1,62 kB groß. Mit Next.js 7 haben wir die initiale HTML-Nutzlast optimiert, sie beträgt jetzt 1,5 kB, eine Reduzierung um 7,4 %, was Ihre Seiten schlanker macht.

Die Hauptwege, wie wir die Größe reduziert haben, sind:

• Das __next-error-div wurde entfernt
• Die Inline-Skripte wurden minimiert, in einer zukünftigen Version werden sie komplett entfernt
• Nicht verwendete __NEXT_DATA__-Eigenschaften wurden entfernt, wenn sie nicht genutzt werden, z.B. die nextExport- und assetPrefix-Eigenschaften.

Unterstützung für statische CDNs

In Next.js 5 haben wir die assetPrefix-Unterstützung eingeführt, eine Möglichkeit, Next.js automatisch Assets von einem bestimmten Ort, normalerweise einer CDN, laden zu lassen. Diese Option funktioniert gut, wenn Ihre CDN Proxying unterstützt. Sie fordern eine URL wie folgt an:

https://cdn.example.com/_next/static/<buildid>/pages/index.js

Typischerweise prüft die CDN, ob sie die Datei in ihrem Cache hat, oder fordert sie direkt vom Origin-Server an.

Genau so funktioniert das Edge Network.

Einige Lösungen erfordern jedoch das Hochladen eines Verzeichnisses direkt in die CDN. Das Problem dabei war, dass die URL-Struktur von Next.js nicht der Ordnerstruktur im .next-Verzeichnis entsprach. Zum Beispiel unsere frühere URL:

https://cdn.example.com/_next/static/<buildid>/pages/index.js
// abgebildet auf:
.next/page/index.js

Mit Next.js 7 haben wir die Verzeichnisstruktur von .next geändert, um sie der URL-Struktur anzupassen:

https://cdn.example.com/_next/static/<buildid>/pages/index.js
// abgebildet auf:
.next/static/<buildid>/pages/index.js

Obwohl wir die Verwendung von Proxying-CDN-Typen empfehlen, ermöglicht diese neue Struktur Benutzern eines anderen CDN-Typs, das .next-Verzeichnis in ihre CDN hochzuladen.

Styled JSX v3

Wir freuen uns, styled-jsx 3 vorzustellen, die standardmäßig enthaltene CSS-in-JS-Lösung in Next.js ist jetzt bereit für React Suspense.

Ein oft unklarer Punkt war, wie eine Kindkomponente gestylt werden sollte, wenn diese Komponente nicht Teil des aktuellen Komponentenbereichs ist. Zum Beispiel, wenn Sie eine Kindkomponente einbinden, die spezifische Stile nur benötigt, wenn sie innerhalb der Elternkomponente verwendet wird:

const ChildComponent = () => (
  <div>
    <p>some text</p>
  </div>
);
 
export default function Index() {
  return (
    <div>
      <ChildComponent />
      <style jsx>{`
        p {
          color: black;
        }
      `}</style>
    </div>
  );
}

Der obige Code versucht, das p-Tag auszuwählen, funktioniert aber nicht, weil styled-jsx-Stile auf die aktuelle Komponente beschränkt sind und nicht in Kindkomponenten durchsickern. Eine Möglichkeit, dies zu umgehen, war die Verwendung der :global-Methode, die das Präfix vom p-Tag entfernt. Dies führt jedoch zu einem neuen Problem, nämlich dass Stile seitenübergreifend durchsickern.

In styled-jsx 3 wurde dieses Problem durch eine neue API, css.resolve, gelöst, die den className und die <style>-Tags (die styles-Eigenschaft) für den gegebenen styled-jsx-String generiert:

import css from 'styled-jsx/css';
 
const ChildComponent = ({ className }) => (
  <div>
    <p className={className}>some text</p>
  </div>
);
 
const { className, styles } = css.resolve`
  p {
    color: black;
  }
`;
 
export default function Index() {
  return (
    <div>
      <ChildComponent className={className} />
      {styles}
    </div>
  );
}

Diese neue API ermöglicht die transparente Weitergabe von benutzerdefiniertem Styling an Kindkomponenten.

Da dies ein Major-Release für styled-jsx ist, gibt es eine Breaking Change, die die Bundle-Größen verbessert, wenn Sie styles-jsx/css verwenden. In styled-jsx 2 haben wir eine "scoped" und eine "global" Version von externen Stilen generiert, selbst wenn nur die "scoped" Version verwendet wurde, haben wir trotzdem die "global" Version dieser externen Stile eingebunden.

Mit styled-jsx 3 müssen globale Stile mit css.global statt mit css markiert werden, damit styled-jsx die Bundle-Größe optimieren kann.

Für alle Änderungen lesen Sie bitte die Release Notes.

React Context mit SSR zwischen App und Seiten

Ab Next.js 7 unterstützen wir jetzt die neue React Context-API zwischen pages/_app.js und Seitenkomponenten.

Bisher war es nicht möglich, React Context zwischen Seiten auf der Serverseite zu verwenden. Der Grund dafür war, dass webpack einen internen Modulcache anstelle von require.cache verwendet. Wir haben ein benutzerdefiniertes webpack-Plugin geschrieben, das dieses Verhalten ändert, um Modulinstanzen zwischen Seiten zu teilen.

Dadurch ermöglichen wir nicht nur die Verwendung des neuen React Context, sondern reduzieren auch den Speicherverbrauch von Next.js, wenn Code zwischen Seiten geteilt wird.

nextjs.org

Gemeinsam mit dem Release von Next.js 7 starten wir eine komplett neu gestaltete Version von nextjs.org.

Blog

Der Blogpost, den Sie gerade lesen, ist bereits Teil des neuen Blog-Bereichs auf nextjs.org. Dieser Blog wird die neue Heimat für Kommunikation rund um Next.js sein, zum Beispiel für Ankündigungen neuer Versionen.

Die neue nextjs.org

Inspiration finden

Da die Anzahl der Apps, die Next.js verwenden, ständig wächst, benötigten wir eine Möglichkeit, all diese beeindruckenden Anwendungen in einer Übersicht zu präsentieren. Lernen Sie die neue /showcase-Seite kennen:

Lassen Sie sich auf nextjs.org/showcase inspirieren

Diese neue Showcase ermöglicht es uns, kontinuierlich neue mit Next.js erstellte Apps hinzuzufügen.

Wir laden Sie ein, /showcase zu besuchen, um sich inspirieren zu lassen, oder Ihre eigene Next.js-App einzureichen!

Community

Seit seiner ersten Veröffentlichung wird Next.js in allem eingesetzt – von Fortune-500-Unternehmen bis hin zu persönlichen Blogs. Wir freuen uns sehr über die wachsende Verbreitung von Next.js.

• Derzeit gibt es über 12.500 öffentlich indexierte Domains, die Next.js nutzen.
• Über 500 Mitwirkende haben mindestens einen Commit beigesteuert.
• Auf GitHub wurde das Projekt mehr als 29.000 Mal mit einem Stern versehen.
• Seit der ersten Veröffentlichung wurden fast 2200 Pull Requests eingereicht.

Die Next.js-Community zählt fast 2000 Mitglieder. Machen Sie mit!