Next.js 9.2

Wir freuen uns, heute Next.js 9.2 mit folgenden Neuerungen vorstellen zu können:

• Native CSS-Unterstützung für globale Stylesheets: Anwendungen können nun direkt .css-Dateien als globale Stylesheets importieren.
• Native CSS-Modul-Unterstützung für komponentenspezifische Styles: Mit der .module.css-Konvention können lokal begrenzte CSS-Dateien importiert und überall in der Anwendung verwendet werden.
• Verbesserte Code-Splitting-Strategie: Das Google Chrome Team hat die Code-Splitting-Strategie von Next.js stark optimiert, was zu deutlich kleineren Client-seitigen Bundles führt. Zudem wurde die HTTP/2-Nutzung maximiert, um die Ladegeschwindigkeit zu verbessern, ohne die HTTP/1.1-Performance zu beeinträchtigen.
• Catch-All Dynamic Routes: Die Dynamic Routes von Next.js unterstützen nun Catch-All-Routen, was neue Anwendungsfälle ermöglicht, z.B. für CMS-gesteuerte Websites.

Alle diese Verbesserungen sind abwärtskompatibel und brechen nichts. Für das Update müssen Sie lediglich folgendes ausführen:

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

Native CSS-Unterstützung für globale Stylesheets

Next.js 5 führte die Unterstützung für CSS-Imports über ein benutzerdefiniertes Plugin namens next-css ein, das das Verhalten von Next.js erweiterte.

Im Laufe der Zeit erhielten wir von Unternehmen und Nutzern von Next.js konsistentes Feedback, dass sie next-css oft zu ihrer Anwendung hinzufügen.

Darüber hinaus hatte next-css einige fehlende Einschränkungen beim Import von CSS. Beispielsweise konnte man eine CSS-Datei in jeder Datei des Projekts importieren, aber diese importierte CSS-Datei war global für die gesamte Anwendung.

Um die Developer Experience zu verbessern und diese Inkonsistenzen zu beheben, begannen wir damit, die CSS-Import-Unterstützung standardmäßig in Next.js zu integrieren.

Wir freuen uns, bekannt geben zu können, dass Next.js nun native Unterstützung für den Import von Stylesheets in Ihre Anwendung bietet.

Um CSS-Imports in Ihrer Anwendung zu nutzen, importieren Sie die CSS-Datei in pages/_app.js.

Beispielsweise betrachten wir das folgende Stylesheet namens styles.css im Stammverzeichnis Ihres Projekts:

body {
  padding: 20px 20px 60px;
  margin: 0;
}

Erstellen Sie eine pages/_app.js-Datei, falls noch nicht vorhanden.

Importieren Sie dann die styles.css-Datei:

import '../styles.css';
 
// Dieser Standardexport ist in einer neuen `pages/_app.js`-Datei erforderlich.
export default function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

Da Stylesheets von Natur aus global sind, müssen sie in der benutzerdefinierten <App>-Komponente importiert werden. Dies ist notwendig, um Konflikte bei Klassennamen und der Reihenfolge für globale Styles zu vermeiden.

In der Entwicklung ermöglicht diese Art der Stylesheet-Definition, dass Ihre Styles automatisch auf der Seite aktualisiert werden, während Sie sie bearbeiten.

In der Produktion werden alle CSS-Dateien automatisch zu einer einzigen minifizierten .css-Datei zusammengeführt. Diese CSS-Datei wird über ein <link>-Tag geladen und automatisch in das standardmäßige HTML-Markup eingefügt, das Next.js generiert.

Diese neue Funktion ist vollständig abwärtskompatibel. Falls Sie @zeit/next-css oder andere CSS-bezogene Plugins verwenden, ist die Funktion deaktiviert, um Konflikte zu vermeiden.

Wenn Sie derzeit @zeit/next-css verwenden, empfehlen wir, das Plugin aus Ihrer next.config.js und package.json zu entfernen und nach dem Upgrade auf die native CSS-Unterstützung umzusteigen.

Native CSS-Modul-Unterstützung für komponentenspezifische Styles

Next.js unterstützt nun CSS-Module mit der Dateinamenskonvention [name].module.css.

Anders als die in Next.js 5 mit next-css verfügbare Unterstützung können nun globale CSS und CSS-Module koexistieren — next-css erforderte, dass alle .css-Dateien in Ihrer Anwendung entweder als global oder lokal behandelt werden, aber nicht beides.

CSS-Module begrenzen CSS lokal, indem sie automatisch eindeutige Klassennamen erstellen. Dies ermöglicht es Ihnen, denselben CSS-Klassennamen in verschiedenen Dateien zu verwenden, ohne sich über Kollisionen Gedanken machen zu müssen.

Dieses Verhalten macht CSS-Module zur idealen Wahl für komponentenspezifisches CSS. CSS-Modul-Dateien können überall in Ihrer Anwendung importiert werden.

Betrachten Sie beispielsweise eine wiederverwendbare Button-Komponente im Ordner components/:

Erstellen Sie zunächst components/Button.module.css mit folgendem Inhalt:

/*
Sie müssen sich keine Sorgen machen, dass .error {} mit anderen `.css`- oder
`.module.css`-Dateien kollidiert!
*/
.error {
  color: white;
  background-color: red;
}

Erstellen Sie dann components/Button.js, importieren Sie die obige CSS-Datei und verwenden Sie sie:

import styles from './Button.module.css';
 
export function Button() {
  return (
    <button
      type="button"
      // Beachten Sie, wie die "error"-Klasse als Eigenschaft des importierten
      // `styles`-Objekts zugreifbar ist.
      className={styles.error}
    >
      Destroy
    </button>
  );
}

CSS-Module sind eine optionale Funktion und werden nur für Dateien mit der Erweiterung .module.css aktiviert. Reguläre <link>-Stylesheets und globale CSS-Dateien werden weiterhin unterstützt.

In der Produktion werden alle CSS-Modul-Dateien automatisch zu vielen minifizierten und code-gesplitteten .css-Dateien zusammengeführt. Diese .css-Dateien repräsentieren häufig genutzte Pfade in Ihrer Anwendung und stellen sicher, dass die minimale Menge an CSS pro Seite geladen wird, damit Ihre Anwendung gerendert werden kann.

Wie oben erwähnt, ist diese neue Funktion vollständig abwärtskompatibel. Falls Sie @zeit/next-css oder andere CSS-bezogene Plugins verwenden, ist die Funktion deaktiviert, um Konflikte zu vermeiden.

Wenn Sie derzeit @zeit/next-css verwenden, empfehlen wir, das Plugin aus Ihrer next.config.js und package.json zu entfernen und auf die native CSS-Unterstützung umzusteigen.

Verbesserte Code-Splitting-Strategie

Next.js-Versionen vor 9.2 hatten einen festen Satz von JavaScript-Bundles, die zum Laden und Interaktiv-Machen einer Seite erforderlich waren:

• Die JavaScript-Datei der Seite
• Eine Datei mit gemeinsamen JavaScript
• Next.js Client-seitiges Runtime-Bundle
• Webpack Client-seitiges Runtime-Bundle
• Dynamische Imports (hinzugefügt über next/dynamic, falls verwendet)

Damit die Seite interaktiv wird, müssen alle diese Bundles geladen werden, da sie voneinander abhängen, um React im Browser zu starten.

Da alle diese Bundles erforderlich sind, damit die Anwendung interaktiv wird, ist es wichtig, dass sie so optimiert wie möglich sind. In der Praxis bedeutet dies, nicht zu viel Code aus anderen Teilen der Anwendung herunterzuladen.

Aus diesem Grund verwendete Next.js ein commons-Bundle, das gemeinsames JavaScript zwischen Seiten enthielt. Die Berechnung der alten Bundle-Splitting-Strategie zur Generierung von commons basierte auf einer Nutzungsraten-Heuristik. Wenn ein Modul in mehr als 50% aller Seiten verwendet wurde, wurde es als gemeinsames Modul markiert. Andernfalls wurde es in die JavaScript-Datei der Seite gebündelt.

Allerdings können Anwendungen aus vielen verschiedenen Seitentypen bestehen. Zum Beispiel Marketing-Seiten, ein Blog und ein Dashboard. Wenn es eine große Anzahl von Marketing-Seiten im Vergleich zu anderen Seitentypen gab, führte die Commons-Berechnung zu Optimierungen, die stark auf die Marketing-Seiten fokussiert waren.

Unser Ziel ist es, alle Seitentypen in einer Anwendung zu optimieren.

Alex Castle schlug eine neue Methode des Chunkings (Erstellung separater JavaScript-Dateien) vor, die optimiertes Commons-Chunking mit mehreren Dateien ermöglicht, auch wenn viele Seitentypen beteiligt sind.

Heute freuen wir uns, bekannt geben zu können, dass dieses neue Chunking-Verhalten standardmäßig in Next.js 9.2 aktiviert ist. Wir möchten uns herzlich beim Google Chrome Team und Alex Castle für diesen Beitrag bedanken. Diese Änderung spiegelt die kumulative Anstrengung von Wochen der Forschung, Labortests, Tests in der Praxis und Implementierung wider.

Die neue Chunking-Implementierung nutzt HTTP/2, um eine größere Anzahl kleinerer Chunks zu liefern.

Nach der neuen Heuristik werden Chunks erstellt für:

• Einen minimalen Chunk für jede Seite.
• Einen Framework-Chunk, der React, ReactDOM, Reacts Scheduler usw. enthält.
• Library-Chunks für jede node_module-Abhängigkeit über 160kb (vor Minifizierung/Gzip)
• Einen Commons-Chunk für Code, der über alle Seiten hinweg verwendet wird.
• So viele Shared-Chunks (von 2 oder mehr Seiten verwendet) wie möglich, optimiert für die Gesamtgröße der Anwendung und die anfängliche Ladegeschwindigkeit.
• Next.js' Client-seitige Runtime.
• Webpack-Runtime.

Schauen wir uns an, was dies in einer realen Anwendung bedeutet:

Ein früher übernehmender Industriepartner, Barnebys®, verzeichnete eine 23%ige Verringerung der gesamten Anwendungsgröße.

Darüber hinaus wurde ihr größtes JS-Bundle um 30% reduziert — von 605kB auf 425kB — ohne erforderliche Codeänderungen.

Ein weiterer Industriepartner, SumUp®, verzeichnete eine 70%ige Verringerung ihres größten JS-Bundles — von 395kB auf 122kB — ohne erforderliche Codeänderungen.

Größtes JavaScript-Bundle

Das neue Chunking-Verhalten reduziert nicht nur Ihre Gesamt- und anfängliche Ladegröße, sondern auch nachfolgende Client-seitige Navigationen. Barnebys® verzeichnete eine 87%ige Reduzierung der geladenen JavaScript-Menge nach sechs (6) Seiten-Navigationen:

JavaScript geladen durch mehrere Client-seitige Übergänge

Dieses neue Verhalten ist vollständig abwärtskompatibel. Um diese Leistungsverbesserung zu nutzen, müssen Sie nur auf die neueste Version von Next.js aktualisieren.

Catch-All Dynamic Routes

Mit der Veröffentlichung von Next.js 9 führten wir dynamische Routensegmente ein, mit dem Ziel, dynamische Segmente in Next.js zu vereinfachen, ohne einen benutzerdefinierten Server zu benötigen. Diese Funktion wurde von Next.js-Nutzern stark angenommen.

Es gab jedoch noch einige Fälle, die die dynamischen Routensegmente nicht abdeckten.

Einer dieser Fälle waren Catch-All-Routen. Zum Beispiel das Routing eines Wildcards wie /post/** als Seite. Dies ist besonders nützlich, wenn Sie eine verschachtelte Struktur haben, die von einer Inhaltsquelle wie einem CMS definiert wird.

Sie können nun Catch-All Dynamic Routes mit der [...name]-Syntax erstellen.

Beispielsweise wird pages/post/[...slug].js auf /post/a, /post/a/b, /post/a/b/c usw. zutreffen.

slug wird im Router-Query-Objekt als Array einzelner Pfadteile bereitgestellt. Für den Pfad /post/foo/bar wäre das Query-Objekt also { slug: ['foo', 'bar'] }.

Community

Wir freuen uns sehr über das anhaltende Wachstum der Next.js-Adaption:

• Wir hatten über 880 unabhängige Mitwirkende.
• Auf GitHub wurde das Projekt über 44.000 Mal mit einem Stern versehen.
• Das Beispiele-Verzeichnis enthält über 220 Beispiele.

Die Next.js-Community hat nun über 13.800 Mitglieder. Kommen Sie dazu!

Wir sind unserer Community und all den externen Feedbacks und Beiträgen dankbar, die diese Version mitgestaltet haben.