Next.js 9.1

Heute freuen wir uns, Next.js 9.1 mit Unterstützung für src- und public-Verzeichnisse anzukündigen.

Neu in dieser Version

• Unterstützung für src-Verzeichnis: Das pages-Verzeichnis kann nun im src-Ordner verschachtelt werden, was eine größere Vielfalt an Anwendungsstrukturen ermöglicht.
• Unterstützung für public-Verzeichnis: Definieren Sie Dateien, die im Stammverzeichnis Ihrer Anwendungs-URL bereitgestellt werden sollen (z.B. favicon.ico).

Vorschau in dieser Version

• Integrierte CSS-Unterstützung: Anwendungen können bald Global CSS importieren und von Hot Reloading in der Entwicklung sowie erweiterten Produktionsoptimierungen, Kompilierung und Polyfilling profitieren.
• Statische Fehlerseiten: Exportieren Sie erwartete Fehlerseiten (wie 404) statisch für bessere Verfügbarkeit (CDN).
• Module / Nomodule: Senden Sie kleinere JavaScript-Bundles an Endnutzer mit modernen Browsern.
• Verbessertes Bundle Splitting: Senden Sie weniger Bytes an Ihre Endnutzer, was die TTI und Seitenübergangsgeschwindigkeit verbessert. Große Bibliothekschunks werden zudem deploymentsübergreifend langfristig gecached.

Wie immer legen wir Wert darauf, dass alle diese Vorteile abwärtskompatibel sind. Um zu aktualisieren, führen Sie einfach folgenden Befehl aus:

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

Falls Ihre Anwendung eine Next.js-Version vor 9 verwendet, können Sie im Upgrade-Guide nachsehen, welche Änderungen erforderlich sind.

Seit unserem letzten Major-Release freuen wir uns, dass Unternehmen wie TikTok, Hilton, Elastic, Realtor und JW Player mit Next.js gestartet sind. Weitere Beispiele finden Sie in der Showcase!

Unterstützung für src-Verzeichnis

Next.js hat ein spezielles pages-Verzeichnis, in dem jede Datei zu einer separaten Route wird. Gemäß dem "Convention over Configuration"-Ansatz muss sich dieses Verzeichnis im Stammverzeichnis einer Next.js-Anwendung befinden.

In Gesprächen mit Unternehmen, die Next.js nutzen, und bei der Inspektion einiger Closed-Source-Codebasen haben wir festgestellt, dass ein gängiges Muster, das Entwickler wünschen, ein src-Verzeichnis für ihren Code ist, mit dem pages-Verzeichnis darin.

Ab Next.js 9.1 ist es nun möglich, ein src/pages-Verzeichnis zu erstellen, anstatt ein pages-Verzeichnis im Stammverzeichnis der Anwendung anzulegen.

Die Verwendung des src-Verzeichnisses ist optional und deckt den Fall ab, in dem Ihr Unternehmen diesen Standard bereits etabliert hat.

Das pages-Verzeichnis im src-Ordner

Unterstützung für public-Verzeichnis

Neben dem pages-Verzeichnis hatte Next.js ein weiteres spezielles Verzeichnis namens static, dessen Dateien der /static-Route zugeordnet wurden.

Beispielsweise würde static/mein-bild.png auf /static/mein-bild.png abgebildet.

Diese Konvention hat seit der ersten Version von Next.js gut funktioniert und weist keine besonderen Probleme auf.

Im Laufe der Zeit haben wir jedoch festgestellt, dass /static nicht alles abdeckt, was in einer Webanwendung benötigt wird. Beispielsweise muss robots.txt vom Stammverzeichnis der Domain aus bereitgestellt werden.

Ab Next.js 9.1 führen wir ein neues Verzeichnis namens public ein.

Alle Dateien im public-Verzeichnis werden auf das Stammverzeichnis der Domain abgebildet.

Beispielsweise wird public/robots.txt auf /robots.txt abgebildet.

Da public auch den Anwendungsfall des static-Verzeichnisses abdeckt, haben wir uns entschieden, das static-Verzeichnis zugunsten eines public/static-Ordners mit der gleichen Funktionalität als veraltet zu markieren.

Wie immer legen wir Wert auf Abwärtskompatibilität, daher wird das static-Verzeichnis mit einer Deprecation-Meldung weiterhin funktionieren.

In Kürze verfügbar

Die folgenden Funktionen befinden sich derzeit unter einer experimentellen Flagge und werden veröffentlicht, sobald die endgültige Implementierung fertig ist.

Integrierte CSS-Unterstützung

Aktuell bietet Next.js eine eingebaute CSS-in-JS-Lösung namens styled-jsx. Diese Lösung eignet sich gut für die Gestaltung einzelner React-Komponenten.

In Gesprächen mit Unternehmen haben wir jedoch festgestellt, dass es einen allgemeinen Bedarf gibt, bestehende Stile oder Design-Systeme auf CSS-Basis wiederzuverwenden.

In der Regel bedeutet dies, das next-css-Plugin hinzuzufügen, um CSS-Imports zu unterstützen.

Wir haben festgestellt, dass etwa 50% aller Next.js-Nutzer dieses Plugin zu ihrer Anwendung hinzufügen.

Aufgrund dieser starken Verbreitung fügen wir nun integrierte Unterstützung für CSS-Imports mit automatischem Neuladen von Styles in der Entwicklung und Produktionsoptimierungen hinzu, die im next-css-Plugin bisher nicht möglich waren.

Die erste Implementierung wird derzeit in produktiven Next.js-Anwendungen getestet.

Zuerst werden globale CSS-Imports eingeführt:

// Globale Styles können aus _app.js importiert werden
import '../styles/global.css';
import App from 'next/app';
 
export default App;

Nach globalen CSS-Imports folgt die Unterstützung für CSS-Module über die .module.css-Erweiterung:

// Bereichsbezogene Styles werden über .module.css importiert
import styles from '../styles/index.module.css';
 
export default function HomePage() {
  return <h1 className={styles.heading}>Hallo Welt</h1>;
}

Dies ermöglicht eine deutlich bessere Developer Experience bei der Verwendung von CSS-Imports.

Mehr über die laufenden Arbeiten erfahren Sie im RFC auf GitHub.

Statische Fehlerseiten

Next.js hat eine spezielle Seite, die bei einem Fehler gerendert wird. Diese Seite wird intern als /_error bezeichnet. Nutzer können diese Seite anpassen, indem sie eine pages/_error.js-Datei erstellen, die eine React-Komponente exportiert.

Die gerenderten Fehler lassen sich grob in zwei Kategorien einteilen: erwartete und unerwartete Fehler.

Erwartete Fehler sind beispielsweise die 404-Seite.

Ein unerwarteter Fehler wäre beispielsweise, wenn in getInitialProps oder beim Rendern des React-Baums ein Fehler auftritt, der einen 500-Fehler erzeugt.

Wir planen, die automatische statische Optimierung für erwartete Fehler hinzuzufügen, da diese im Allgemeinen nicht dynamisch gerendert werden müssen.

Es wird eine Opt-out-Möglichkeit geben, falls ein Nutzer diese Seiten dynamisch rendern möchte, aber standardmäßig wird die 404-Seite statisch sein. Dies verringert die Serverlast bei Verwendung des server-Targets und reduziert Kosten beim serverless-Target.

Ein weiterer Vorteil statischer Seiten ist, dass sie automatisch gecached werden können, wenn eine CDN verwendet wird.

Zusammenarbeit mit Google Chrome

Wie im Next.js 9-Announcement erwähnt, investiert das Google Chrome-Team Ressourcen in die Verbesserung von Next.js und arbeitet an mehreren Initiativen, um groß angelegte Performance-Verbesserungen für alle Next.js-Anwendungen zu erreichen.

Mehr über diese Zusammenarbeit erfahren Sie im Next.js 9-Announcement und in diesem Vortrag von Nicole Sullivan auf der React Rally.

Module / Nomodule

Wenn Sie Code in Next.js schreiben, verwenden Sie im Allgemeinen "modernes" JavaScript. Sie können alle neuesten stabilen Funktionen nutzen, und Next.js stellt sicher, dass diese Funktionen durch Kompilierung des Codes mit Babel transformiert oder polygefilled werden.

Viele dieser JavaScript-Funktionen werden mittlerweile von der Mehrheit der Browser unterstützt. Allgemein (auch in Next.js) wird Code jedoch als ein einzelnes JavaScript-Bundle ausgeliefert, das in allen Browsern läuft, die Ihre Anwendung unterstützt.

Im Fall von Next.js bedeutet dies, dass modernes JavaScript in ein Format kompiliert wird, das mit Internet Explorer 11 kompatibel ist.

Beispielsweise muss Next.js derzeit Polyfills für die async/await-Syntax bereitstellen, da der Code in Browsern ausgeführt werden könnte, die async/await nicht unterstützen, was zu Fehlern führen würde.

Um ältere Browser nicht zu brechen, während modernes JavaScript an Browser gesendet wird, die neuere Syntax unterstützen, wird Next.js das Module/Nomodule-Muster nutzen. Das Module/Nomodule-Muster bietet einen zuverlässigen Mechanismus, um modernes JavaScript an moderne Browser zu senden, während ältere Browser auf polygefillten ES5-Code zurückgreifen können.

Diese neue Funktion wird derzeit in Produktion von mehreren großen Next.js-Anwendungen getestet, um reale Daten zu sammeln. Die Ergebnisse dieser Tests sind vielversprechend, und weitere Details zu den Performance-Verbesserungen werden bald veröffentlicht.

Verbessertes Bundle Splitting

Next.js lädt derzeit mehrere JavaScript-Bundles, um eine Seite interaktiv zu machen. Die wichtigsten sind:

• Das Seiten-JavaScript-Bundle.
• Eine Datei mit gemeinsamem JavaScript.
• Das Next.js-Clientseitige Runtime-Bundle.
• Dynamische Imports (meist über next/dynamic hinzugefügt).

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

Da diese Bundles benötigt werden, um React zu starten, ist es wichtig, dass sie so optimiert wie möglich sind und nicht zu viel Code aus dem Rest der Anwendung herunterladen.

Aus diesem Grund gibt es ein commons-Bundle, das gemeinsames JavaScript zwischen Seiten enthält. Die Berechnung der aktuellen Bundle-Splitting-Strategie zur Erzeugung von commons basiert auf einem verhältnisbasierten Heuristik: Wenn ein Modul in 50% aller Seiten verwendet wird, wird es als gemeinsames Modul markiert.

Anwendungen können jedoch aus vielen verschiedenen Teilen bestehen. Beispielsweise Marketing-Seiten, ein Blog und ein Dashboard. Wenn es eine große Anzahl von Marketing-Seiten im Vergleich zum Dashboard gäbe, würde die Commons-Berechnung ein optimierteres Ergebnis für die Marketing-Seiten liefern.

Unser Ziel ist es, beide gleichzeitig in einer Anwendung zu optimieren.

Alex Castle hat eine neue Ebene des Chunkings (Erstellung separater JavaScript-Dateien) definiert, die eine optimiertere Commons-Chunking mit mehreren Dateien ermöglicht, insbesondere wenn viele Seiten beteiligt sind.

Ähnlich wie bei der Module/Nomodule-Unterstützung wird das verbesserte Bundle Splitting derzeit in Produktion von mehreren großen Next.js-Anwendungen getestet, um reale Daten zu sammeln. Die Ergebnisse dieser Tests und weitere Details zu den Performance-Verbesserungen werden bald in einem separaten Blog-Post veröffentlicht.

Community

Wir freuen uns auf die bevorstehenden Änderungen, die die Performance aller Next.js-Anwendungen verbessern werden.

Darüber hinaus wächst die Next.js-Community weiter:

• Über 800 Mitwirkende haben mindestens einen Commit beigetragen.
• Auf GitHub wurde das Projekt über 41.350 Mal mit einem Stern versehen.
• Das Beispiele-Verzeichnis enthält über 210 Beispiele.

Die Next.js-Community hat nun über 11.250 Mitglieder. Machen Sie mit!

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