Next.js: `nächster Export` (statische Builds)

Wie wäre es, wenn wir getInitialProps für den statischen Build ignorieren.
Das ignorieren wir einfach.

Könnten wir das in Betracht ziehen?

Bestimmt. Client-only getInitialProps ist eine Möglichkeit.

@rauchg @arunoda Würde das Ignorieren getInitialProps nicht den Zweck einer statischen Site zunichte machen? Es wäre immer noch ein Server erforderlich, um diese anfänglichen Requisiten richtig hinzubekommen? Oder habe ich vielleicht etwas in der vorherigen Diskussion übersehen?

Es gibt zwei Arten von statischen Sites. Diejenige, bei der die Daten zu 100 % statisch sind, und diejenige, bei der dies nicht der Fall ist. Und es gibt einen Hybrid, bei dem Sie mit jeder Seite vorberechnete Requisiten versenden und Daten weiterhin dynamisch abgerufen werden können

@rauchg React erlaubt von Natur aus die Hybridform durch seinen componendDidMount Hook. Ich würde gerne die next export -Funktion sehen, um eine wirklich statische Seite zu generieren, ansonsten muss ich eine weitere Feature-Anfrage öffnen, sobald sie fertig ist ;)

Es gibt zwei Arten von statischen Sites. Diejenige, bei der die Daten zu 100 % statisch sind, und diejenige, bei der dies nicht der Fall ist. Und es gibt einen Hybrid, bei dem Sie mit jeder Seite vorberechnete Requisiten versenden und Daten weiterhin dynamisch abgerufen werden können

Welche Art von statischer Site plant dieser Befehl zu exportieren?

Lassen Sie uns sie vielleicht folgendermaßen definieren:

• statische Seiten, die kein clientseitiges Rendering erfordern (sie können ohne Javascript funktionieren)
• Statische Websites, bei denen bestimmte Seiten oder Funktionen clientseitig gerendert werden müssen (wobei etwas Javascript erforderlich ist)
• statische Websites, bei denen jede Seite dann durch clientseitiges Rendering unterstützt wird (was etwas Javascript erfordert) - z. B. Single-Page-Web-Apps

Und was genau ist der Vorteil von zeit:next beim Exportieren einer statischen Site?

Nach meinem Verständnis wird zeit:now immer noch statische Sites in eine node.js-App (zeit:serve) einschließen - und zeit:now übertrumpft sogar die meisten statischen Bereitstellungsoptionen sowieso.

Und was genau ist der Vorteil von zeit:next beim Exportieren einer statischen Site?

@balupton Ermöglicht das Hosten auf Github-Seiten, aws s3 usw.

Alternativ habe ich versucht, den statischen Inhalt mit wget abzurufen. Obwohl es mit anderen meiner Projekte funktioniert (ohne next zu verwenden), funktioniert es hier mit next nicht gut.

@jferrettiboke @stretchkennedy Wo interne Links zur "Build-Zeit" unbekannt sind, funktioniert der vom Static-Site-Generator-Webpack-Plugin verwendete Ansatz, bei dem Sie einfach alle URLs auflisten, die zum Rendern an einem Ort benötigt werden, meiner Meinung nach recht gut.

Natürlich möchten Sie dies nicht von Hand tun - ich habe ein Skript, das dies basierend auf übereinstimmenden Dateinamen innerhalb eines Verzeichnisses tut: find-posts

( Fortsetzung des Gesprächs hier ab Nr. 604 )

@balupton Ermöglicht das Hosten auf Github-Seiten, aws s3 usw.

Aber der einzige Grund, warum ich mir vorstellen kann, warum Leute sie bereitstellen möchten, ist, dass sie kostenlos und schnell gehostet werden – aber zeit:now + cloudflare erreicht dasselbe – mit viel mehr Coolness

@balupton Nicht wirklich, wenn Sie eine statische Site haben, die die App nicht rendern oder Daten im Backend abrufen muss, bevor sie an den Server gesendet werden, können Sie viel Geschwindigkeit gewinnen. Das ist der Hauptgrund, warum ich statische Web-Apps mache.

@yn5 Ich glaube, er spricht davon, das Caching von Cloudflare zu verwenden.

Für mich selbst möchte ich eine statische Site rendern, um die Angriffsfläche zu verringern und weniger Ressourcen zu verbrauchen. Die Bereitstellung von nodejs erfordert die Aktualisierung von mehr Abhängigkeiten als nur die Bereitstellung von nginx und verschwendet eine vollkommen gute VM, selbst wenn Sie sie hinter Cloudflare platzieren.

@balupton Aber der einzige Grund, warum ich mir vorstellen kann, warum die Leute sie bereitstellen möchten, ist, dass sie kostenlos und schnell gehostet werden - aber zeit: jetzt + cloudflare erreicht dasselbe - mit viel mehr Coolness

Ich stimme den von @stretchkennedy und @yn5 genannten Gründen zu - aber ich füge auch hinzu, dass das übergeordnete Ziel darin bestehen sollte, sich in Richtung mehr Freizügigkeit zu bewegen; anstatt die Möglichkeiten einzuschränken. Wenn eine bestimmte Site wirklich statischer Natur ist, warum sollte man dann die Option ausschließen, von einem statischen Host aus bedienen zu können?

Darüber hinaus ist es ein Gewinn, Zeit mit einem Flow arbeiten zu lassen, in dessen Einrichtung und Optimierung (z. B. in Ihrer CI/CD-Pipeline) bereits Zeit investiert wurde, anstatt einen neuen Flow einrichten zu müssen.

Ich möchte meinen Hut darüber werfen, wie ich denke, dass dies wirklich gut funktionieren könnte:

static getInitialProps ({ build, req }) {
   if (req) {
      // server-side
   } else if (build) { 
      // static build (can contains parameters about the page build)
      // this happens at the time of the build (next export)
   } else {
      // client-side
   }
}

next export generiert HTML- und JSON-Darstellungen jeder Seitenkomponente der obersten Ebene.

• Die HTML-Darstellung wird verwendet, um die anfängliche Anfrage zu bedienen
• Die JSON-Darstellung wird verwendet, um asynchron über <Link href="..."> zu navigieren

Das Coole daran ist, dass Sie Markdown-Dateien und andere Ressourcen (sogar eine Seite vorab rendern) innerhalb dieser build == true -Bedingung abrufen können.

@matthewmueller wäre es möglich, Code aus getInitialProps() beim Build zu entfernen?

Angenommen, Sie verwenden eine API, um Live-Daten während der Entwicklung abzurufen, und Sie möchten sie in einen statischen Build „backen“ (sowohl in der HTML- als auch in der JSON-Darstellung einer Seite), um alle API-Anforderungen in der Produktion zu eliminieren. Dies wäre großartig für einen kollaborativen Workflow.

Um die Ausgabe zu optimieren, würden Sie wahrscheinlich die Abhängigkeit von der API-Bibliothek entfernen, die Sie zum Abrufen von Daten in getInitialProps() während der Entwicklungs-/Buildzeit verwenden, da Sie sie im Grunde einfach durch die API-Antwort ersetzen können.

static async getInitialProps ({ build, req }) {
  if (build) { 
      return myCoolAPILib.fetch('foobar.csv') // Probably load myCoolAPILib through webpack's async import()?
   }
}

wird verwandelt in:

static async getInitialProps () {
  return {
    // Response from myCoolAPILib
  };
}

Wie würden Sie also mit Code-Splitting umgehen? Derzeit fordert Next für dynamisch gerenderte Seiten eine JSON-Datei mit den Komponenten an. Würden diese auch statisch veröffentlicht werden?

@kbingman ja, ich glaube, die JSON-Versionen werden sowieso erstellt und in das Dateisystem geschrieben.

Aus Sicht von Dev-Ops, Skalierung, Geschwindigkeit und Preisgestaltung geht nichts über eine statische Seite auf S3. Diese Funktion ist also eigentlich super wichtig für uns.

@kbingman diese werden in der Tat auch statisch generiert

Arbeitet schon jemand aktiv daran? Wenn nicht, könnte ich es versuchen, da ich sehr an dieser Funktion interessiert bin.

Ich habe in der next.js-Codebasis ein wenig geforscht und einen extrem groben Proof-of-Concept erhalten, indem ich im Grunde genommen einen weiteren Schritt zum Build hinzugefügt habe, indem ich die renderToHTML -Funktion des Servers verwendet habe.

Soweit ich das beurteilen kann, ist es ziemlich einfach. Eine der größeren Herausforderungen wird der Umgang mit dynamischen Routen wie /posts/:id sein, insbesondere wenn sie nicht durch Links im HTML referenziert werden (was sie uncrawlbar machen würde). Daher sollte der Benutzer wahrscheinlich in der Lage sein, eine statische Liste von Routen bereitzustellen.

@herrstucki

Eine der größeren Herausforderungen wird der Umgang mit dynamischen Routen wie /posts/:id sein, insbesondere wenn sie nicht durch Links im HTML referenziert werden

Das ist, wonach ich suche. Ich hoffe, einen Weg zu finden, Seiten aus Markdown-Dateien zu generieren und sie in einer dynamischen Navigation aufzulisten.

@schönwaldnils

Ich stimme dem zu. Wäre toll, einen reaktionsbetriebenen Jekyll-Ersatz zu haben. (Mir ist klar, dass viele dieser Blog-Funktionen außerhalb des Geltungsbereichs liegen). Aber das würde next.js definitiv zu einer soliden Plattform für ein größeres Publikum machen, das vielleicht Dinge auf gh-pages oder S3 werfen möchte.

@kylehotchkiss Absolut! Genau das habe ich aktuell vor.
Das Hauptproblem in meinem/n Fall(en) ist, dass die Seite immer noch vom Marketing-Team über Cloudcannon, prose.io oder ähnliches gewartet werden kann.
Und ich denke, Markdown mit konfigurierbarem Meta ist immer noch der beste Weg, um eine einfache Inhaltsbearbeitung hinzuzufügen.

@herrstucki Ich arbeite ein bisschen daran und freue mich, an einem Zweig mitzuarbeiten. benötige diese Funktion auf jeden Fall auch. Ich denke, das geht komplett über das Plugin-System, dann können wir es später schöner / etwas nativer machen.

@schoenwaldnils Sie könnten diese Art von Funktionalität erreichen, indem Sie während des statischen Build-Schritts einen { build: true } oder einen anderen Indikator an getInitialProps() übergeben.

In Bezug auf das Routing muss meiner Meinung nach zumindest für eine anfängliche Implementierung nur der Entwicklungsserver routenfähig sein, was Sie mit einem benutzerdefinierten Server erreichen können. Wenn Sie nach statisch exportieren, kann ein Dienst wie Cloudfront oder netlify das Routing von dort übernehmen und Sie können <Link href="/post" as="/post/4">...</Link> verwenden, um die dynamischen Sachen zu erledigen.

PR ist gelandet: https://github.com/zeit/next.js/pull/1576 💥

Jetzt haben wir die Unterstützung für den „nächsten Export“ in den Kern eingebaut.
Siehe: https://zeit.co/blog/next3-preview
Danke an alle für die Hilfe.

Toll zu sehen, dass das passiert ist. Erstaunliche Arbeit Jungs!

Hallo, next export erzeugt einen Unterordner namens _next , gibt es eine Möglichkeit, ihn automatisch umzubenennen?

@arunoda

Wie geht ihr mit DOM-Ereignissen mit next export ? Vielen Dank!

[BEARBEITEN] Auf dem Mac muss ich alle src="/_next/xxxx" -Pfade manuell in src="./_next/xxxx" ändern

@arunoda

@juliandavidmr @sbe88
Sie müssen die Variable assetPrefix in der Datei next.config.js setzen.
Sie können diese auch zur besseren Erklärung durchsehen.
https://medium.com/@anotherplanet/git -tips-next-js-github-pages-2dbc9a819cb8
https://medium.com/@adibas03/next -js-github-pages-contd-42a1dd47f6bc