Next.js: Statische Generierung / SSG-Verbesserungen

Erstellt am 25. Nov. 2019  ┬Ě  250Kommentare  ┬Ě  Quelle: vercel/next.js

Zusammenfassung

Erm├Âglichen Sie, dass Next.js vollst├Ąndig hybrid wird, indem Sie Methoden f├╝r die statische Generierung und das serverseitige Rendering auf Seitenbasis bereitstellen.

  • Zwei neue Methoden zum Abrufen von Daten pro Seite

    • getStaticProps - Melden Sie sich zum Zeitpunkt next build f├╝r die statische Generierung (SSG) an.

    • getServerSideProps - Aktivieren Sie das serverseitige Rendering (SSR), das bei Bedarf rendert.

  • Eine neue Methode zur statischen Generierung (SSG) einer Reihe von Routen aus dynamischen Quellen

    • getStaticPaths - Liste der Parameter f├╝r dynamische Routen zur├╝ckgeben, um statische Generierung (SSG) durchzuf├╝hren

Dieser RFC behandelt ausschlie├člich API-Erg├Ąnzungen. Alle neuen Funktionen sind vollst├Ąndig abw├Ąrtskompatibel und k├Ânnen schrittweise ├╝bernommen werden. Dieser RFC f├╝hrt keine veralteten Versionen ein.

Hintergrund

Beim Erstellen von Websites oder Webanwendungen m├╝ssen Sie im Allgemeinen zwischen 2 Strategien w├Ąhlen: Statische Generierung (SSG) oder serverseitiges Rendering (SSR).

Mit Next.js k├Ânnen Sie stattdessen Hybridanwendungen erstellen, mit denen Sie pro Seite ausw├Ąhlen k├Ânnen, welche Strategie verwendet wird. Ab Next.js 9 werden Seiten ohne getInitialProps statisch optimiert und nach next build als .html Dateien ausgegeben.

M├Âglicherweise m├Âchten Sie jedoch Daten abrufen, w├Ąhrend Sie statische Seiten f├╝r Ihren speziellen Anwendungsfall generieren.

Zum Beispiel, um statisch Marketingseiten aus einem CMS oder einem Blogbereich der Website zu generieren.

Die Verwendung von getInitialProps w├╝rde Sie in diesem Fall f├╝r SSR entscheiden.

Next.js verf├╝gt derzeit ├╝ber einen next export Befehl, der die Anwendung vollst├Ąndig SSG macht und den hybriden Charakter von Next.js verliert.

Wenn Sie next export mit getInitialProps ein weiteres Problem auf. getInitialProps wird zur Build-Zeit aufgerufen (was gro├čartig ist), aber wenn Sie dann next/link , um zwischen den Seiten zu wechseln, wird getInitialProps clientseitig aufgerufen, anstatt next export Ergebnis.

Dies bedeutet auch, dass die Datenquelle (CMS / API-Endpunkt) bei clientseitigen ├ťberg├Ąngen direkt aufgerufen wird. Wenn Ihre Datenquelle ausgefallen ist, werden clientseitige ├ťberg├Ąnge beim Wechsel zwischen den Seiten unterbrochen.

Wir haben mit Vielnutzern von SSG und next export in Next.js wie HashiCorp (danke @jescalan) zusammengearbeitet und ausf├╝hrlich die richtigen Einschr├Ąnkungen f├╝r die Einf├╝hrung zweier neuer Datenabrufmethoden untersucht: getStaticProps und getServerSideProps . Aber auch eine M├Âglichkeit, Parameter zum statischen Generieren statischer Seiten f├╝r dynamische Routen bereitzustellen: getStaticPaths (Ersatz f├╝r exportPathMap pro Seite).

Diese neuen Methoden haben viele Vorteile gegen├╝ber dem getInitialProps Modell, da es einen klaren Unterschied zwischen SSG und SSR gibt.

  • getStaticProps markiert die Seite als statisch zur Erstellungszeit zu generieren (bei Ausf├╝hrung von next build )
  • getStaticPaths erm├Âglicht die R├╝ckgabe einer Liste von Parametern, die zur Erstellungszeit f├╝r dynamische Routen generiert werden sollen
  • getServerSideProps markiert die Seite, die bei jeder Anfrage serverseitig gerendert wird, und ist dem aktuellen getInitialProps Verhalten bei Verwendung eines Servers am ├Ąhnlichsten.

Durch die Trennung dieser Methoden k├Ânnen wir auch das richtige Kontextobjekt bereitstellen, das mit TypeScript eingegeben werden kann. Wenn Sie sich f├╝r eine bestimmte Rendering-Strategie entscheiden, erhalten Sie die richtigen Werte, derzeit mit getInitialProps Sie erraten, was auf SSG vs. SSR bei Verwendung von TypeScript verf├╝gbar ist.

Dar├╝ber hinaus k├Ânnen wir die verschiedenen Kompromisse klarer dokumentieren, indem wir diese Methoden explizit machen.

Implementierung

Beachten Sie, dass sich alle diese Methoden auf der obersten Ebene der Seitenkomponentendatei befinden und nicht verschachtelt werden k├Ânnen, ├Ąhnlich wie getInitialProps .

getStaticProps

Die Verwendung von getStaticProps bedeutet, dass die Seite zur Build-Zeit (SSG) statisch gerendert wird.

Mit dieser neuen Methode k├Ânnen Sie Daten f├╝r eine Seite abrufen, die zum Zeitpunkt next build statisch in eine .html Datei generiert wird.

Next.js generiert au├čerdem automatisch eine JSON-Datei, die das Ergebnis von getStaticProps next build Zeitpunkt

Beim clientseitigen Routing ├╝ber next/link oder next/router ruft Next.js diese JSON-Datei ab, um die zum Rendern der Seite clientseitig erforderlichen Requisiten abzurufen.

Eigenschaften werden unter einem props Schl├╝ssel zur├╝ckgegeben, damit in Zukunft andere Optionen eingef├╝hrt werden k├Ânnen.

// pages/index.js

// getStaticProps is only called server-side
// In theory you could do direct database queries
export async function getStaticProps(context) {
  return {
    // Unlike `getInitialProps` the props are returned under a props key
    // The reasoning behind this is that there's potentially more options
    // that will be introduced in the future.
    // For example to allow you to further control behavior per-page.
    props: {}
  };
}

Das context enth├Ąlt:

  • params - Die Parameter auf einer dynamischen Route.

getStaticPaths

Dies ist eine Erweiterung der getStaticProps Nutzung f├╝r dynamische Routen.

getStaticPaths ersetzt die Notwendigkeit eines exportPathMap und funktioniert pro Seite.

Da Sie vielleicht statisch eine Liste von URLs generieren m├Âchten, die einen dynamischen Parameter haben, wie im Beispiel unten a slug . Next.js stellt eine getStaticPaths Methode bereit, die es erm├Âglicht, eine Liste von URLs zur├╝ckzugeben. Da es sich um eine async Methode handelt, k├Ânnen Sie diese Liste auch aus einer Datenquelle wie Ihrem CMS abrufen.

// pages/blog/[slug].js

// `getStaticProps` gets a `params` object holding the dynamic parameters
// For `/blog/hello-world` it would look like `{ slug: 'hello-world }`
export async function getStaticProps({ params }) {
  return {
    props: {}
  };
}

// `getStaticPaths` allows the user to return a list of parameters to
// render to HTML at build time.
export async function getStaticPaths() {
  return {
    paths: [
      // This renders /blog/hello-world to HTML at build time
      { params: { slug: "hello-world" } }
    ]
  };
}

Zur├╝ckfallen

In vielen F├Ąllen m├Âchten Sie m├Âglicherweise nicht jede m├Âgliche Route in Ihrer Anwendung zur Erstellungszeit vorrendern (z. B. wenn Sie Millionen von Produkten haben). Aus diesem Grund generiert Next.js automatisch eine fallback Seite, die ein Rendering der Seite ohne Daten ist (damit ein Ladezustand angezeigt werden kann), wenn die Seite noch nicht generiert wurde.

Das genaue Verhalten beim Servieren wird sein:

  • Eingehende Anfrage

    • Next.js pr├╝ft, ob der Pfad zur Build-Zeit generiert wurde

    • Wenn der Pfad generiert wurde



      • direkt servieren



    • Wenn der Pfad nicht generiert wurde



      • Dienen Sie den Fallback


      • Next.js rendert die Seite (mit Daten) im Hintergrund und f├╝gt sie der Liste der generierten Seiten hinzu


      • Eine nachfolgende Anfrage an denselben Pfad liefert die generierte Seite


      • Dies stellt sicher, dass Benutzer immer eine schnelle Erfahrung haben und nie langsame TTFB vom Server-Rendering haben, w├Ąhrend schnelle Builds und statische Generierungseigenschaften erhalten bleiben



Falls Sie m├Âchten, dass Pfade, die nicht zur Build-Zeit generiert wurden, zu einem 404 f├╝hren, ist dies auch m├Âglich, indem Sie fallback: false von getStaticPaths

// `getStaticPaths` allows the user to return a list of parameters to
// render to HTML at build time.
export async function getStaticPaths() {
  return {
    // Opt-out of the described fallback behavior
    fallback: false,
    paths: [
      // This renders /blog/hello-world to HTML at build time
      { params: { slug: "hello-world" } }
    ]
  };
}

getServerSideProps

Bei Verwendung von getServerSideProps wird die Seite nicht statisch generiert (SSG), sondern bei jeder Anfrage an den Server (SSR) bei Bedarf gerendert.

Next.js macht auch automatisch einen API-Endpunkt verf├╝gbar, der das Ergebnis des Aufrufs von getServerSideProps zur├╝ckgibt. Dies wird f├╝r das clientseitige Routing verwendet.

Beim clientseitigen Routing ├╝ber next/link oder next/router ruft Next.js diesen exponierten API-Endpunkt ab, um die JSON-Daten abzurufen, die in die Requisiten umgewandelt werden, die zum Rendern der Seite clientseitig erforderlich sind.

Diese Methode ist der aktuellen getInitialProps am ├Ąhnlichsten, mit dem Hauptunterschied, dass getServerSideProps immer serverseitig und nicht im Browser ausgef├╝hrt wird. Entweder beim serverseitigen Rendering oder beim API-Abruf beim clientseitigen Routing.

Ähnlich wie bei getStaticProps die Eigenschaften unter einem props Schlüssel zurückgegeben.

// pages/index.js

// getServerSideProps is only called server-side
// In theory you could do direct database queries
export async function getServerSideProps(context) {
  return {
    // Unlike `getInitialProps` the props are returned under a props key
    // The reasoning behind this is that there's potentially more options
    // that will be introduced in the future.
    // For example to allow you to further control behavior per-page.
    props: {}
  };
}

Das context enth├Ąlt:

  • params - Die Parameter einer dynamischen Route
  • req - Das HTTP-Request-Objekt
  • res - Das HTTP-Antwortobjekt
  • query - Die Abfragezeichenfolge (nicht ganz sicher, aber wahrscheinlich erforderlich)

Verfasst von @timneutkens , @Timer , @ijjk , @fades. In Zusammenarbeit mit @rauchg , @jescalan und anderen ­čÜÇ

Hilfreichster Kommentar

Die Unterst├╝tzung f├╝r die Static Site Generation (SSG) der n├Ąchsten Generation wurde in Next.js 9.3 als stabil ver├Âffentlicht!

Diese Version enth├Ąlt auch Unterst├╝tzung f├╝r den "Vorschaumodus" oder die M├Âglichkeit, die statisch vorgerenderte Seite zu umgehen und die Seite bei Bedarf f├╝r autorisierte Benutzer zu rendern .

Mehr dazu k├Ânnen Sie in unserem Blogbeitrag lesen . Wenn Sie mehr praktische Erfahrung haben , springen Sie direkt in unsere

Alle 250 Kommentare

export async function getStaticProps(context) {
  return {
    // Unlike `getInitialProps` the props are returned under a props key
    // The reasoning behind this is that there's potentially more options
    // that will be introduced in the future.
    // For example to allow you to further control behavior per-page.
    props: {}
  };
}

Ich bin daran interessiert zu sehen, unter welchen Umst├Ąnden wir zus├Ątzliche Daten zur├╝ckgeben m├╝ssen, die nicht in props . Ich fand die Inline-Erkl├Ąrung "um das Verhalten pro Seite weiter zu steuern" etwas vage.

Sieht sehr interessant aus! W├Ąre er ein Ersatz f├╝r getInitialProps oder daneben? F├╝r unseren Anwendungsfall ist die Datenabruf-API beispielsweise ein ├Âffentlicher Dienst. Bei der clientseitigen Navigation erwarten wir also, dass der Client die API-Schicht direkt aufruft, w├Ąhrend bei SSR der Server sie aufruft. W├╝rde dieser Anwendungsfall in Zukunft weiterhin mit der vorherigen Methode gel├Âst werden?

Ich bin daran interessiert zu sehen, unter welchen Umst├Ąnden wir zus├Ątzliche Daten zur├╝ckgeben m├╝ssen, die nicht in props . Ich fand die Inline-Erkl├Ąrung "um das Verhalten pro Seite weiter zu steuern" etwas vage.

Es geht vielmehr darum, die Methode zukunftssicher zu machen, damit wir sie sp├Ąter bei Bedarf erweitern k├Ânnen.

Sieht sehr interessant aus! W├Ąre er ein Ersatz f├╝r getInitialProps oder daneben? F├╝r unseren Anwendungsfall ist die Datenabruf-API beispielsweise ein ├Âffentlicher Dienst. Bei der clientseitigen Navigation erwarten wir also, dass der Client die API-Schicht direkt aufruft, w├Ąhrend bei SSR der Server sie aufruft. W├╝rde dieser Anwendungsfall in Zukunft weiterhin mit der vorherigen Methode gel├Âst werden?

Im Allgemeinen hat dieses Verhalten einige Nachteile, zum Beispiel das Abrufen von Wasserfallen, die aus bestimmten Gebieten der Welt langsam sein k├Ânnen. Der getServerProps Ansatz erm├Âglicht ein effizienteres Caching der Antwort.

Das sieht wirklich interessant aus! Tolle Idee!

Ich habe jedoch Bedenken bez├╝glich der Bereitstellung...

Stellen wir uns vor, ich hoste auf Now.
Bei der ersten Bereitstellung ist es offensichtlich, dass die gesamte Anwendung auf der Bereitstellung aufbaut.

Dann ├Ąndere ich einige Inhalte im CMS und m├Âchte nur den Neuaufbau von SSG-Seiten ausl├Âsen, aber der Anwendungscode hat sich nicht ge├Ąndert.

Sofort ert├Ânt der Alarm, dass es in diesem Fall, wenn ich den Build ausl├Âse, zwei m├Âgliche L├Âsungen gibt:

1) Nichts wird neu erstellt, da alles zwischengespeichert wird - kein Code hat sich ge├Ąndert und blabla.
2) Ich --force es, und jetzt wird "alles" neu erstellt, aber ich habe nur die SSG-Seiten neu erstellt.

_Dies sind nur Hypothesen, da das von den Build-Systemen selbst abh├Ąngt - wie bewusst sind sie von Next_

Dies w├╝rde wahrscheinlich jede andere Hosting-L├Âsung betreffen.

Next selbst hat ein .next/cache ... wie w├╝rde das damit umgehen?

@joltmode das ist derzeit im Grunde f├╝r jeden statischen Site-Generator der Fall. .next/cache wird zwischen Bereitstellungen auf Now beibehalten und wiederverwendet. Denken Sie daran, dass Sie derzeit wahrscheinlich getInitialProps f├╝r diesen Fall mit Caching (m├Âglicherweise https://zeit.co/blog/serverless-pre-rendering) verwenden, das dynamisch in einer serverlosen Funktion rendert und dann auf unserem CDN zwischenspeichert Verhalten ist immer noch v├Âllig in Ordnung und funktioniert weiterhin, wenn Sie getServerProps .

Wirklich gro├čartig, w├╝rde gut zu unserer Verwendung von Next f├╝r Kundenprojekte passen und w├╝rde einige Boilerplate-Codes entfernen, die wir herumkopieren.

Eine zu ber├╝cksichtigende Sache ist die Benennung von getStaticProps und getServerProps, wenn sie in Zukunft ein { props } und m├Âgliche andere Optionen zur├╝ckgeben, w├Ąren die *Props dann nicht verwirrend? Vielleicht w├Ąren getStaticConfiguration, getStaticSetup, getStaticOptions allgemeiner?

@kibs Die R├╝ckgabewerte beziehen sich immer darauf, wie die Requisiten behandelt werden. Also die Namensgebung ist imo in Ordnung.

Das ist einfach genial! Dies l├Âst jeden Anwendungsfall und jedes Bed├╝rfnis, das ich in letzter Zeit hatte oder an das ich bei der Entwicklung von privaten und professionellen Web-Apps denken konnte. Sie haben mich gerade daran gehindert, meinen eigenen Hybrid-Site-Generator zu starten, danke!

Ich kann mich auch darauf beziehen, dass die neuen Methoden besser sind als die vorherigen getInitialProps() und exportPathMap() , was f├╝r mich zun├Ąchst etwas verwirrend klang, als ich anfing, Next.js zu verwenden und mich mit SSR / SSG besch├Ąftigte. Der pro-Seiten-Ansatz macht f├╝r mich auch mehr Sinn.

Kann es kaum erwarten, das auszuprobieren!

Nur eine Randnotiz: Im letzten Beispiel fehlt meiner Meinung nach getServerProps() ein Parameter context .

Nur eine Randnotiz: Im letzten Beispiel fehlt meiner Meinung nach getServerProps() ein Kontextparameter.

Fest!

Das h├Ârt sich toll an! Ich frage mich nur aus der Perspektive eines TypeScript-Benutzers, ob getStaticProps , getStaticPaths und getServerProps als statische Methoden in der Seitenkomponente (wie derzeit getInitialProps ) w├Ąren einfacher zu tippen / richtig zu verwenden.

const Page: NextPage<Props> = (props) => ...

// Explicit types needed here
export const getStaticPaths: NextGetStaticPaths<Params> = () => ...
export const getStaticProps: NextGetStaticProps<Props, Params> = (context) => ...
export const getServerProps: NextGetServerProps<Props> = (context) => ...

export default Page

// vs.

const Page: NextPage<Props, Params> = (props) => ...

// Static method types come from NextPage<Props, Params>
Page.getStaticPaths = () => ...
Page.getStaticProps = (context) => ...
Page.getServerProps = (context) => ..

export default Page

@herrstucki Das Problem bei diesem Ansatz ist, dass es erheblich schwieriger wird, B├Ąume zu sch├╝tteln (

@timneutkens guter Punkt ÔÇŽ aber w├Ąre dann eine separate Datei nicht noch sinnvoller? Oder ist so etwas _zuverl├Ąssig_ baumsch├╝ttelbar?

// This should all be removed in client-side code ÔÇŽ
import {fetchQuery, queryTag} from 'big-data-fetching-lib';
const query = queryTag`...`
export const getStaticProps = async () => ({ props: await fetchQuery(query) })

// Only this should be included client-side
export default (props) => ...

@herrstucki wir k├Ânnen das zuverl├Ąssig

Sieht sehr interessant aus! W├Ąre er ein Ersatz f├╝r getInitialProps oder daneben? F├╝r unseren Anwendungsfall ist die Datenabruf-API beispielsweise ein ├Âffentlicher Dienst. Bei der clientseitigen Navigation erwarten wir also, dass der Client die API-Schicht direkt aufruft, w├Ąhrend bei SSR der Server sie aufruft. W├╝rde dieser Anwendungsfall in Zukunft weiterhin mit der vorherigen Methode gel├Âst werden?

Im Allgemeinen hat dieses Verhalten einige Nachteile, zum Beispiel das Abrufen von Wasserfallen, die aus bestimmten Gebieten der Welt langsam sein k├Ânnen. Der getServerProps Ansatz erm├Âglicht ein effizienteres Caching der Antwort.

Sicher, aber ich spreche davon, die RTT zum Reaktionsserver ├╝berhaupt zu vermeiden. Betrachten Sie den Fall, in dem die SSR-Ausgabe vom Server beim CDN/Cache-Server-Proxy zwischengespeichert wird. In Verbindung mit dem Datenabruf f├╝r die Client-Navigation, der direkt eine andere API-Schicht aufruft (├╝blich f├╝r Web/Apps/alle Clients), bedeutet dies, dass die Next.js-Serverschicht in einem Szenario mit hohem Datenverkehr nicht so stark skaliert werden muss.

Ich verstehe Ihren Standpunkt zu Wasserfall-Abrufen, aber wenn Sie den Verbrauchern die M├Âglichkeit geben, den Next-Server als SSR-Schicht im Vergleich zu einer Datenquelle zu behandeln, w├╝rden viel bessere Skalierungskonfigurationen erm├Âglicht.

Sieht sehr interessant aus! W├Ąre er ein Ersatz f├╝r getInitialProps oder daneben? F├╝r unseren Anwendungsfall ist die Datenabruf-API beispielsweise ein ├Âffentlicher Dienst. Bei der clientseitigen Navigation erwarten wir also, dass der Client die API-Schicht direkt aufruft, w├Ąhrend bei SSR der Server sie aufruft. W├╝rde dieser Anwendungsfall in Zukunft weiterhin mit der vorherigen Methode gel├Âst werden?

Im Allgemeinen hat dieses Verhalten einige Nachteile, zum Beispiel das Abrufen von Wasserfallen, die aus bestimmten Gebieten der Welt langsam sein k├Ânnen. Der getServerProps Ansatz erm├Âglicht ein effizienteres Caching der Antwort.

Sicher, aber ich spreche davon, die RTT zum Reaktionsserver ├╝berhaupt zu vermeiden. Betrachten Sie den Fall, in dem die SSR-Ausgabe vom Server beim CDN/Cache-Server-Proxy zwischengespeichert wird. In Verbindung mit dem Datenabruf f├╝r die Client-Navigation, der direkt eine andere API-Schicht aufruft (├╝blich f├╝r Web/Apps/alle Clients), bedeutet dies, dass die Next.js-Serverschicht in einem Szenario mit hohem Datenverkehr nicht so stark skaliert werden muss.

Ich verstehe Ihren Standpunkt zu Wasserfall-Abrufen, aber wenn Sie den Verbrauchern die M├Âglichkeit geben, den Next-Server als SSR-Schicht im Vergleich zu einer Datenquelle zu behandeln, w├╝rden viel bessere Skalierungskonfigurationen erm├Âglicht.

Ich glaube, Sie missverstehen, dass dieses neue Verhalten bedeutet, dass Sie tats├Ąchlich die vollst├Ąndigen Ergebnisse auf einem CDN zwischenspeichern k├Ânnen, da das CDN dynamische Antworten unterst├╝tzt. Dies war bisher mit getInitialProps nicht zuverl├Ąssig m├Âglich.

@timneutkens Ich habe mit babel-plugin-preval Code nach getStaticProps zu portieren. Ich habe ein Problem mit fs .

Ich versuche, die .md-Dateien meines ./pages/blog/ Verzeichnisses zu lesen und sie zu durchlaufen, damit ich eine Blog-Indexseite mit all meinen Beitr├Ągen erstellen kann

import React from 'react';
import Link from 'next/link';
import fs from 'fs-extra';

const Index = ({ posts }) => (
  <div>
    Hello World. <Thing msg="hello" />
    <Link href="/thing">
      <a>About</a>
    </Link>
    {posts.map(p => (
      <div key={p.title}>{p.title}</div>
    ))}
  </div>
);

Index.getStaticProps = async () => {
  const items = await fs.readdir('./pages/blog');
  items.forEach(path => /* .... do some stuff ... */ )
  return { props: { posts: items } };
};

export default Index;

Dieser Code f├╝hrt zu diesem Fehler:

Module not found: Can't resolve 'fs' in '/Users/jared/Downloads/nextjs-typescript-template/node_modules/fs-extra/lib'

IIRC von Razzle, dieser Fehler hat mit den Dateisystem-Stubs von Webpack (oder deren Fehlen) zu tun. Ich glaube, ich habe dies einmal mit Razzle behoben, indem ich dies zur Webpack-Konfiguration hinzugef├╝gt habe.

node: {
  fs: "empty";
}

Ich habe diese next.config.js ausprobiert, aber der Fehler verschwindet einfach. Es scheint jedoch, dass fs / fs-extra nicht wirklich funktioniert, oder es funktioniert und m├Âglicherweise Pfade nicht (mir unklar). Irgendwelche Gedanken dazu?

Meine andere Frage im Allgemeinen ist, was Sie sich f├╝r die besten Praktiken f├╝r die Verwendung von import vs. require in getStaticProps vorstellen. Wenn ich mich nicht irre, versucht mein obiges Snippet, fs-extra in React isomorph?? zu importieren. W├Ąre es daher besser, den Import in einen Inline-Requirement wie diesen zu ├Ąndern?

js Index.getStaticProps = async () => { const fs = require('fs-extra'); // only require when needed at SSG const props = await fs.readdir('./pages/blog'); return { props: { posts } }; };

Ich glaube, Sie missverstehen, dass dieses neue Verhalten bedeutet, dass Sie tats├Ąchlich die vollst├Ąndigen Ergebnisse auf einem CDN zwischenspeichern k├Ânnen, da das CDN dynamische Antworten unterst├╝tzt. Dies war bisher mit getInitialProps nicht zuverl├Ąssig m├Âglich.

Ah, ich glaube ich verstehe was du meinst. W├╝rde das bedeuten, dass getServerProps bei der ersten SSR-Generation einen eindeutigen Endpunkt erstellen w├╝rde, in einem inhaltsadressierbaren Hash vielleicht in der URL, die wir dann auf dem CDN zwischenspeichern k├Ânnen? Der einzige Nachteil w├Ąre, dass der Cache nicht zwischen Nicht-Next-Apps (Android / iOS) und Next-Apps geteilt werden kann. Au├čerdem sind bei einer externen Datenquelle die Cache-Steuerungsanweisungen vorgelagert, aber hier, da Next die Verantwortung f├╝r die Bereitstellung der Daten ├╝bernehmen w├╝rde, ben├Âtigen wir APIs oder Requisiten, um diese f├╝r die generierten Datenendpunkte anzugeben.

@jaredpalmer Ich https://github.com/zeit/next.js/issues/9524#issuecomment -558628066 (einschlie├člich meiner Bedenken bez├╝glich zuverl├Ąssiger Baum-Shakeability ) durch eine separate Datei gel├Âst w├╝rde, die vollst├Ąndig getrennt von kompiliert w├╝rde Client-Bundle-Code? Z.B

pages/
    foo.js
    foo.data.js (<- exports getStaticProps etc.)

or:

pages/
    foo.js
pages-data/
    foo.js (<- exports getStaticProps etc.)

@jaredpalmer Tree Shaking wurde auf

Wie immer danke f├╝r alles, was ihr tut. Die Arbeit mit Next.js war eine absolute Freude, und wie ich bereits sagte, k├Ânnen wir mit fast jedem Feature-Release die Gr├Â├če der von mir verwalteten Codebasen _reduzieren_. Es ist wunderbar.

Es ist schwer, diesen RFC kritisch zu sehen, da er, wie geschrieben, f├╝r viele Anwendungen sofort n├╝tzlich ist. Ich m├Âchte jedoch eine Zeile ansprechen, bei der ich nicht sicher bin, ob ich damit einverstanden bin:

" getStaticPaths ersetzt die Notwendigkeit eines exportPathMap und funktioniert pro Seite."

Bei einigen Anwendungen ist es entweder unpraktisch oder unm├Âglich, die Routen zum Zeitpunkt der Erstellung zu kennen. Ein paar Beispiele w├Ąren:

  • Benutzerprofilseiten
  • Produktseiten (f├╝r Unternehmen mit einem sich schnell ├Ąndernden Inventar)
  • Seiten mit Verkaufsauftragsdetails

Routen f├╝r Seiten wie diese haben wahrscheinlich die Form /entity-name/entity-id und die dynamischen Routen von Next funktionieren wirklich sehr gut, da Sie Dinge wie router.push('/customers/[customerId]', '/customers/baer') tun k├Ânnen. Es gibt noch einen Haken. Wenn Sie vorhaben, diese Dateien statisch mit etwas wie Serve, Netlify, NGINX usw. bereitzustellen, m├╝ssen Sie eine Reihe von Weiterleitungen generieren, damit Benutzer beim Seitenaktualisieren keinen 404-Fehler erhalten brauche exportPathMap .

Folgendes wird fast unver├Ąndert aus einer Codebasis kopiert, an der ich regelm├Ą├čig arbeite:

const buildServeConfig = redirects => {
  const config = {
    public: `dist`,
    trailingSlash: true,
    rewrites: redirects
  };

  const outputPath = `${__dirname}/serve.json`;

  fs.writeFile(outputPath, JSON.stringify(config, null, 2), err => {
    if (err) {
      throw err;
    }
    // eslint-disable-next-line no-console
    console.log(`Generated: ${outputPath}`);
  });
};

...

exportPathMap: function(defaultPathMap, { dev, outDir }) {
  const redirects = Object.entries(defaultPathMap)
    // No need to create a redirect rule for `/dirname/` or `/dirname/index.html`
    .filter(([url]) => url !== `/` && url !== `/index`)
    .map(([url, { page }]) => ({
      // Replaces /[customerId] with /:customerId
      source: url.replace(/]/g, ``).replace(/\[/g, `:`),
      destination: `${page}/index.html`
    }));

  // By default, the routes are sorted such that a route like `/order/:orderId`
  // comes before `/order/new`. Since the `:orderId` portion of `/order/:orderId` 
  // is a wildcard, the route `/order/new` will be a match and consider `new` 
  // as a value for `:orderId`. To get past this, we sort the redirects by the 
  // number of parameters in ascending order.
  const sortedRedirects = [...redirects].sort(
    (currentRedirect, nextRedirect) =>
      currentRedirect.source.split(`:`).length >
      nextRedirect.source.split(`:`).length
  );

  buildServeConfig(sortedRedirects);

  return defaultPathMap;
}

Ich verstehe, dass dieser RFC keine APIs veraltet oder entfernt, und ich erkenne auch an, dass es m├Âglich ist, diese Weiterleitungen durch das Durchlaufen des Build-Verzeichnisses zu erstellen. Selbst wenn es veraltet w├Ąre, habe ich eine sch├Âne Fluchtluke. Aber es "beseitigt die Notwendigkeit von getStaticPaths nicht ganz".

Nochmals vielen Dank f├╝r Ihre Aufmerksamkeit bei der Durchf├╝hrung dieses Projekts

Schlie├čen sich getStaticProps / getStaticPaths und getServerProps gegenseitig aus? zB w├Ąre es m├Âglich, einen Teil gleichzeitig vorgerendert und einen Teil dynamisch zu haben?

Ja, sie sind eine statische Generierung und eine serverseitige Rendering.

Dies behebt eines der gro├čen Dinge, die ich von Gatsby vermisse, bevor wir zu Next migriert haben:

Wir haben eine monolithische (100 kbs) JSON-Datei, aus der wir Daten ziehen, um unsere Seiten zu rendern, die sich nie ├Ąndern. In Gatsby haben wir die JSON-Datei in das GraphQL-Schema geladen und danach abgefragt, wobei wir nur die Daten erfasst haben, die wir zum Rendern einer bestimmten Seite ben├Âtigten. Mit Next ist der einfachste/sauberste Weg, dies zu tun, import monolith from './monolith.json' , was erfordert, dass der Benutzer die gesamte JSON-Datei herunterl├Ądt.

Dieser RFC befasst sich zu 100% mit diesem Anwendungsfall und bringt Next einen Schritt n├Ąher an Gatsby in den Bereichen, in denen Gatsby gl├Ąnzt (offensichtlich kann Gatsby kein Runtime-SSR ausf├╝hren, also spreche ich nur von statischen Buildtime-Renderings).

@timneutkens , danke f├╝r den RFC!

Ich habe einen Anwendungsfall f├╝r Next.js, den ich k├╝rzlich mit @rauchg besprochen habe.

Next.js liefert sehr fl├╝ssiges DX und einige vern├╝nftige Standardeinstellungen. Ich bin also daran interessiert, Next.js f├╝r eine clientseitig gerenderte Anwendung zu verwenden, eine Smart-TV-App.

Smart-TV-Apps sind fast klassische Web-Apps, die von der Browser-Engine von TV ausgef├╝hrt werden:

  1. Die App ist in einem Bundle verpackt: Stile, Skripte, Bilder, _index.html_, Zertifikate und TV-Konfigurationsdatei.
  2. Das Bundle wird zur ├ťberpr├╝fung an den App Store der Plattform gesendet.
  3. Das Bundle wird dann als App aus dem Store installiert und vom Benutzer ausgef├╝hrt.

Die Sache ist, dass das Bundle statisch vom TV-Ger├Ąt selbst gehostet und nicht vom Server geladen wird. Daher ist keine SSR-Option m├Âglich (Node.js wird Entwicklern f├╝r diese Zwecke nicht zug├Ąnglich gemacht). Aber die App selbst ist dynamisch (sagen wir Netflix).

Wir m├╝ssen also ein SPA ausf├╝hren, das von einem statischen Webserver gehostet wird.

Wie ich verstehe, wird die vollst├Ąndige Abmeldung von getServerProps (oder getInitialProps ) dazu beitragen, SSR zu vermeiden. Aber was passiert mit dynamischem Rendering auf dem Client? Und wie sieht es in diesem Fall mit dem Routing aus? Laut diesem RFC wurde das Problem noch nicht angegangen. @timneutkens , k├Ânnten Sie bitte den besten Weg vorschlagen, um das clientseitige Rendering in Next.js zu aktivieren? Und ob es ├╝berhaupt zu Next.js passt? Vielen Dank!

PS Ich kann ein Problem f├╝r diesen Anwendungsfall erstellen, wenn Sie der Meinung sind, dass es besser ist, es separat zu besprechen.

@grushetsky k├Ânnen Sie ein anderes Problem erstellen. Das ist eine ganz andere Frage als im RFC diskutiert wird ­čĹŹ

@timneutkens Das Versprechen dieses RFC ist eines der Dinge, die mich auf Next sehr aufgeregt haben! Nur um das klarzustellen, getInitialProps w├╝rde auch noch existieren, oder?

Richtig @outdooricon -- getInitialProps wird es auf absehbare Zeit geben.

Laut RFC:

Dieser RFC behandelt ausschlie├člich API-Erg├Ąnzungen. Alle neuen Funktionen sind vollst├Ąndig abw├Ąrtskompatibel und k├Ânnen schrittweise ├╝bernommen werden. Dieser RFC f├╝hrt keine veralteten Versionen ein.

Toller RFC, super aufgeregt daf├╝r!

Ich habe ├╝ber die getServerProps in Bezug auf einen bestimmten Anwendungsfall nachgedacht und die Ergebnisse in einem Cache abgelegt. Da dies in einen API-Endpunkt umgewandelt und das Ergebnis als Requisiten an die Komponente geliefert wird, gibt es eine vorgeschriebene M├Âglichkeit, das Ergebnis in einen externen Cache wie Redux, GraphQL-Caches usw. usw. clientseitig zu legen?

Wenn ich getInitialProps richtig verstehe, da es statisch und asynchron ist, hat Next die M├Âglichkeit zu warten, bis es abgeschlossen ist, bevor die Komponente zum ersten Mal gerendert wird. Damit k├Ânnen wir dort Dinge in einen externen Cache legen. Dies wird bei getServerProps nicht der Fall sein, da es auf dem Server l├Ąuft und das Ablegen von Dingen in einen Cache im Komponentenlebenszyklus zu bedeuten scheint, dass wir ein Rendering haben m├╝ssen, bei dem die Daten noch nicht im Cache verf├╝gbar sind , auch wenn es in Requisiten verf├╝gbar ist?

Dies kann nat├╝rlich beabsichtigt sein und ich k├Ânnte einen Ansatz ├╝bersehen, aber ich dachte, ich w├╝rde fragen, ob es etwas ist, das in Betracht gezogen wurde?

Bearbeiten: Ich denke, das gilt auch f├╝r getStaticProps . ­čśä

Vielleicht habe ich es irgendwo ├╝bersehen, aber wie gehen wir mit Situationen um, in denen Inhalte zwischengespeichert, aber in der DB aktualisiert oder ein neuer Blogbeitrag erstellt wird? Ist ein automatischer Neubau erforderlich? Ich denke schon.

Zuerst! Toller Vorschlag, es ist eine massive Verbesserung gegen├╝ber exportPathMaps im Anwendungsfall der meisten Leute. Es wird wirklich gesch├Ątzt. Vor diesem Hintergrund f├Ąllt es mir schwer zu verstehen, wie wir es mit der Internationalisierung der Route schaffen k├Ânnen.

Gibt es Vorschl├Ąge zum Umgang mit i18n-pr├Ąfixierten Routen? Mein spezifischer Anwendungsfall erfordert, dass einige Tausend auf Seiten mit unterschiedlichen L├Ąnder-Langpr├Ąfixen und URLs erstellt werden.

/nl/brillen
/gb/glasses
/es/gafas
...

Es scheint, dass getStaticPaths wirklich hilfreich ist, wenn das Pr├Ąfix f├╝r die URL bekannt ist, wie in Ihrem Beispiel (mit /blog/[id].js ). Aber wie sieht Ihrer Meinung nach eine getStaticPaths Implementierung aus, wenn sie Pfade auf Stammebene generieren muss, mit einem dynamischen Pr├Ąfix (Landessprache) und einem dynamischen Pfad?

@reaktivo pages/[lang]/blog/[id].js -> in getStaticPaths alle URLs zum statischen Rendern angeben.

@timneutkens Irgendeine Idee, wann dies verf├╝gbar / testbar sein wird?

Im Allgemeinen geben wir keine ETAs heraus, da wir Funktionen ausgiebig mit Produktions-Apps testen, um sicherzustellen, dass die L├Âsung richtig ist.

Diese Verbesserungen werden mich dazu bringen, mein "nicht so gepflegtes" ph├Ąnomenales Projekt (reagieren Sie ssg, das niemand au├čer mir verwendet) v├Âllig veraltet. Toll zu sehen, dass Next.js diese fehlenden Teile hinzuf├╝gt!

Ich m├Âchte einen Zweifel kl├Ąren. Betrachten Sie die Verwendung eines CMS wie WordPress. Nach meinem Verst├Ąndnis w├╝rde ich mit der getStaticPaths-Methode alle Beitr├Ąge holen und eine Liste ├╝bergeben wie:

export async function getStaticPaths () {
  return [
    // This renders / blog / hello-world to HTML at build time
    {params: {slug: "hello-world"}}
  ];
}

Der Slug jedes Beitrags w├╝rde in der Methode getStaticProps verwendet, um den Inhalt abzurufen.
Dies w├╝rde in npm build passieren.
Meine Frage bezieht sich auf neue Beitr├Ąge, die nach dem Build hinzugef├╝gt werden.
W├╝rde die Methode getStaticProps verwendet werden, um diesen neuen Beitrag per Slug abzurufen?
Wird dieser neue Beitrag eine .html-Datei wie die im vorherigen Build enthalten?
Ich liebe es, mit weiter zu arbeiten und in mehreren Projekten habe ich das sehr gut.

Nichts direkt damit verbunden, aber der Support kann mir keine Antwort geben, die meiner Frage entspricht.

Was Sie hier vorschlagen, k├Ânnte die L├Âsung sein, aber in der Zwischenzeit kann ich nextJS nicht dazu bringen, einen JAMSTACK basierend auf Webhooks-├änderungen zu erstellen.

Wenn ich getInitialProps h├Ątte, werde ich vom Server gerendert.
Wenn ich dies nicht tue, bin ich nur CDNisiert, aber ohne Vorrendern nicht? Und die Seite bleibt ohne Inhalt, solange XHR nicht zur├╝ckgekehrt ist (Bye-Bye SEO)

Haben Sie jetzt ein laufendes Beispiel von Jamstack mit nextJS und wir k├Ânnten es auf netlify tun.

Vielen Dank,
Andr├ęas

Hey @ScreamZ - diese ├änderung ist meiner Meinung nach der Grund daf├╝r, dass mit nextjs eine vollst├Ąndig statische Site erstellt werden kann. Wir konnten eine nextjs Website statisch kompilieren Verwendung von next export f├╝r eine lange Zeit, aber es w├Ąre immer noch Daten auf Client-seitige Strecke ├ťberg├Ąngen holt mit getInitialProps . Mit der M├Âglichkeit, getStaticProps , k├Ânnen Sie clientseitige ├ťberg├Ąnge ausf├╝hren, ohne dass zus├Ątzliche Daten abgerufen werden m├╝ssen ÔÇô alle abgerufenen Daten in getStaticProps einmal zur Build-Zeit abgerufen und nicht auf Ihrem Live-Site, es sei denn, Sie erstellen erneut. Dies ist die klassische Architektur datengesteuerter statischer Sites. Verkn├╝pfen Sie Ihre Datenquelle ├╝ber einen Webhook mit Ihrem Host, und wenn sich die Datenquelle ├Ąndert, weisen Sie den Host an, Ihre Site neu zu erstellen.

Es gibt viele existierende Beispiele f├╝r vollst├Ąndig statische nextjs-Websites, und es ist trivial, eine nextjs-Site auf netlify zu betreiben. Die Website meiner Firma l├Ąuft derzeit auf nextjs und wird von netlify gehostet, hoffentlich dient dies als gutes Beispiel.

Es ist sehr erw├Ąhnenswert, dass auch der Hosting-Service von zeit stark in Betracht gezogen werden sollte. Die Preise sind ziemlich ├Ąhnlich und ihre Integration mit nextjs-Sites ist un├╝bertroffen - Sie m├╝ssen buchst├Ąblich nicht einmal etwas konfigurieren, Sie verkn├╝pfen einfach github und das Hosting von zeit erkennt, dass Sie nextjs ausf├╝hren, und konfigurieren und implementieren automatisch alles.

Dies ist keine Werbung, ich arbeite nicht f├╝r zeit, sondern nur eine echte Empfehlung. Sie k├Ânnen es mit netlify absolut zum Laufen bringen, und ich habe pers├Ânlich f├╝r mehrere Websites als Beweis. Sie m├╝ssen jedoch gr├╝ndlich verstehen, wie nextjs funktioniert, und Sie m├╝ssen sicherstellen, dass alles richtig konfiguriert ist, damit es auf netlify reibungslos l├Ąuft. Wenn Sie nach dem einfachsten und narrensichersten Hosting f├╝r eine nextjs-Site suchen, w├╝rde ich das Hosting von zeit ausprobieren.

@jescalan Danke f├╝r dieses tolle Teilen ­čÖĆ­čĆ╗

Ich habe kein Problem mit NextJS mit netlify, weil Sie Publish directory , um den Ordner out anzugeben. Aber auf zeit Jetzt gibt es keine M├Âglichkeit zu sagen, bitte benutze kein SSR, sondern gehe voll auf statisch mit next export .

@ScreamZ das ist irgendwie wahr, aber es h├Ąngt davon ab, wie genau Sie eine "vollst├Ąndige statische" Site definieren. Wenn Sie getStaticProps f├╝r alle Ihre Seiten mit dem Hosting-Service von zeit verwenden, entspricht das, was Sie erhalten, effektiv einer statischen Site, auch wenn sie nicht next export l├Ąuft, da alle Seiten mit getStaticProps werden nur erstellt, wenn die Site bereitgestellt wird, und werden danach direkt vom CDN bereitgestellt.

Der wesentliche Unterschied besteht darin , dass, soweit ich wei├č , dass es nicht einen Weg gibt , um alle Seiten zu zwingen , statisch auf zeit Hosting (edit zu sein: zeit vor kurzem es so ge├Ąndert , dass jede Seite mit einer Config , die enth├Ąlt exportPathMap laufen eine vollst├Ąndig statische Site, daher ist dies nicht mehr der Fall). Seiten mit getStaticProps verhalten sich genauso wie Seiten, die mit next export generiert wurden ÔÇô eine einzelne statische Kopie der Seite wird bei jedem Treffer direkt vom CDN bereitgestellt. Sie k├Ânnten aber auch einige Seiten mit getServerProps oder getInitialProps ausf├╝hren und sie w├╝rden sich wie vom Server gerenderte Seiten verhalten. Pers├Ânlich sehe ich dies als Vorteil - wenn eine SSR-Route erforderlich ist, k├Ânnen Sie einfach eine andere Datenabrufmethode verwenden, und diese einzelne Route ist jetzt SSR, w├Ąhrend alle Ihre anderen Routen statisch bleiben k├Ânnen.

@jescalan Danke,

Also m├╝ssen Sie nur warten, bis dies implementiert ist, und verwenden Sie in der Zwischenzeit netlify f├╝r statische

Gibt es eine Geschichte rund um die SSG-Konfiguration? Insbesondere m├Âchten wir gemeinsam genutzte Build-Artefakte verwenden, aber next export mit anderen Konfigurationen f├╝r QA/Prod ausf├╝hren. Diese Konfigurationswerte w├╝rden nur in getStaticProps gelesen werden. W├╝rde dies serverRuntimeConfig oder publicRuntimeConfig oder process.env direkt verwenden?

@ScreamZ @jescalan Ich habe heute zusammen mit @Timer Zero-Config next export Support auf Now gelandet (er verdient alle Credits). Du kannst tun:

"build": "next build && next export"

Und es wird automatisch funktionieren.

Lass mich wissen wie es gelaufen ist

Ja, ich war der Typ, der beim Support nachgefragt hat und sie haben mir gesagt, dass dies noch implementiert wurde ­čśů Soweit ich sehen kann, m├╝ssen Sie eine Export-Map in der Konfiguration definieren?

@ScreamZ nein, Sie k├Ânnen einfach next build && next export wie oben gezeigt hinzuf├╝gen und es wird funktionieren.

@timneutkens Wenn ich getInitialProps durch getServerProps ersetze, muss ich dann noch target: 'serverless' zur Konfigurationsdatei hinzuf├╝gen, um Server Pre Rendering zu aktivieren? Vielen Dank.

Wie k├Ânnen wir diese ausprobieren?

Wie k├Ânnen wir diese ausprobieren?

Ich denke, alle diese Methoden ben├Âtigen derzeit das Pr├Ąfix unstable_ , um erkannt zu werden.

zB unstable_getStaticProps

@timneutkens

@ScreamZ @jescalan Ich habe heute zusammen mit @Timer Zero-Config next export Support auf Now gelandet (er verdient alle Credits). Du kannst tun:

"build": "next build && next export"

Und es wird automatisch funktionieren.

Lass mich wissen wie es gelaufen ist

Mein Build-Skript macht ein bisschen mehr Dinge, aber es sieht so aus, als ob es wie ein Zauber funktioniert:

"build": "graphql codegen && next build && npm run export",

Au├čerdem ist es gro├čartig! Es war genau das, was ich gesucht habe ­čśů (Auf Wiedersehen GatsbyJS, mein Lieblingsframework ist jetzt so stark wie du!)

Vielen Dank f├╝r diese Reaktivit├Ąt.

Ich habe auch ein Upgrade auf 9.1.6 und das habe ich ├╝berraschenderweise gesehen
Screenshot 2019-12-21 at 19 25 43

Ich dachte, dieser Thread w├Ąre ein RFC, es sieht so aus, als w├Ąre er bereits f├╝r uns ge├Âffnet, nicht wahr?
Typoskript-Typen sind jedoch in 9.1.6 nicht aktiviert.

Verdammt, darauf bin ich jetzt so gehyped! ­čĄú

Letzte Fragen:

  • Wenn ich es bekomme, wird getInitialProps in Zukunft eingestellt? Oder ist es in manchen F├Ąllen noch relevant? Ein Beispiel?
  • next export kann auch zugunsten von Seiten mit getStaticProps und nur next build ?

Danke f├╝r das tolle Tool ­čÖĆ­čĆ╗

Wenn ich es erhalte, wird getInitialProps in Zukunft veraltet sein? Oder ist es in manchen F├Ąllen noch relevant? Ein Beispiel?

Wie im ersten RFC gesagt:

Dieser RFC behandelt ausschlie├člich API-Erg├Ąnzungen. Alle neuen Funktionen sind vollst├Ąndig abw├Ąrtskompatibel und k├Ânnen schrittweise ├╝bernommen werden. Dieser RFC f├╝hrt keine veralteten Versionen ein.

Ich dachte, dieser Thread w├Ąre ein RFC, es sieht so aus, als w├Ąre er bereits f├╝r uns ge├Âffnet, nicht wahr?

Ist es nicht, wir probieren es auf ZEIT-Anwendungen aus und einige Sichtbarkeitsfl├Ąchen sind bereits gelandet (z. B. der Seitenbaum, den Sie gesehen haben).

next export kann auch zugunsten von Seiten mit getStaticProps und next build nur veraltet sein?

Richtig, im Allgemeinen werden Sie next export einfach nicht verwenden. Es wird aus Gr├╝nden der R├╝ckw├Ąrtskompatibilit├Ąt beibehalten, aber im Allgemeinen sollten Sie eine Hybrid-App erstellen, da Sie alle Vorteile des Exports mit Unterst├╝tzung f├╝r andere Funktionen wie API-Routen und die Option f├╝r serverseitiges Rendering f├╝r einige Seiten erhalten.

Wie k├Ânnen wir diese ausprobieren?

Ich denke, alle diese Methoden ben├Âtigen derzeit das Pr├Ąfix unstable_ , um erkannt zu werden.

zB unstable_getStaticProps

Es wird dringend empfohlen, es noch nicht zu verwenden, es ist experimentell und kann zwischen den Ver├Âffentlichungen unterbrochen werden.

Ich habe also mit dieser Funktion gespielt und festgestellt, dass die JSON-Datei mit den Seitendaten immer nach dem Zugriff auf die SSG-Seite von einer anderen Seite abgerufen wird.

Planen Sie eine Optimierung des Preloads f├╝r die JSON-Datei?
Vielleicht laden Sie es vorab, wenn der Benutzer zu der Seite navigieren m├Âchte (dh: der Benutzer bewegt sich ├╝ber einen SSG-Link) oder das Vorladen, genau wie Sie andere js-Seiten vorab laden, die von einer Link-Komponente referenziert werden.

Ich liebe diese Funktion ├╝brigens!

Planen Sie eine Optimierung des Preloads f├╝r die JSON-Datei?

Jawohl.

F├╝r das, was es wert ist, bin ich eher f├╝r baumsch├╝ttelbare Exporte dieser Funktionen als f├╝r separate Dateien.

Wie ist der Status dieser Funktion? Was sind seine Blocker?

@mikestop setzt fort, dass dieser RFC derzeit intern von unserem Team und einigen ausgew├Ąhlten Partnern intensiv getestet wird. Sie k├Ânnen sich f├╝r das sehr experimentelle Verhalten entscheiden, indem Sie die Pr├Ąfixe unstable_ , wie oben erw├Ąhnt ! ­čśä

Bitte migrieren Sie jedoch keine Produktionsworkloads auf die neuen Methoden, da wir die APIs m├Âglicherweise immer noch auf bahnbrechende Weise aktualisieren.

Pers├Ânlich verwende ich es f├╝r die Generierung von statischen Sites von 8 bis 20K Seiten (mit der M├Âglichkeit, einige dynamische Anfragen auf einigen Seiten zu haben). Es funktioniert sehr gut (mit Ausnahme des 10K-Dateienlimits bei Now), das einzige, was ich schade finde, ist, dass ohne die Methode getStaticPaths getStaticProps bei jedem Neuladen aufgerufen wird. Ein Verhalten, das gut sein k├Ânnte, ist, dass der erste Aufruf die JSON-Datei erstellt und der n├Ąchste verwendet sie.

Sind inkrementelle Builds geplant? Also werden nur neue/ge├Ąnderte Inhalte neu erstellt?

Sie k├Ânnen sich f├╝r das sehr experimentelle Verhalten entscheiden, indem Sie die Pr├Ąfixe unstable_ , wie oben erw├Ąhnt !

Ich m├Âchte die Methode unstable_getServerProps testen, aber es sieht so aus, als ob sie im Moment ignoriert wird und ich sie nirgendwo im zeit/next.js Repository finden kann. Ist es noch nicht implementiert oder mache ich es nur falsch?

Sind inkrementelle Builds geplant? Also werden nur neue/ge├Ąnderte Inhalte neu erstellt?

Die Implementierung wurde im Hinblick auf inkrementelle Neuerstellungen entwickelt, wird jedoch noch nicht unterst├╝tzt (und in diesem RFC auch nicht behandelt).

Seien Sie versichert, die Architektur ist fertig und wir werden dies untersuchen, nachdem diese Funktionen stabil sind.
Aus diesem Grund wird getStaticProps pro Seite definiert und nicht einmal f├╝r die gesamte Anwendung!

Ich w├╝rde gerne die Methode unstable_getServerProps testen, aber es sieht so aus, als ob sie im Moment ignoriert [...]

getServerProps ist noch nicht in der Vorschau verf├╝gbar, tut mir leid!

getServerProps ist noch nicht in der Vorschau verf├╝gbar, tut mir leid!

Danke f├╝r die Warnung. Ich werde mir diesen Thread auf jeden Fall ansehen, denn wenn er landet, habe ich eine Menge Code, der durch Umbenennen einer einzelnen Funktion ersetzt werden kann! ­čśŹ

Bitte kl├Ąren Sie, ich bin mir nicht 100% sicher, ob getServerProps / getStaticProps derzeit verf├╝gbar sind oder nicht.

Basierend auf diesem Thread: Nein

Aber wenn das der Fall ist, frage ich mich, warum mein Terminal darauf angespielt hat, als ich next build wenn sie noch nicht verf├╝gbar sind? Als ich die Nachricht sah, hatte ich zun├Ąchst die Annahme, dass diese Methoden in Produktion waren, und es dauerte eine Weile, bis ich entdeckte, dass dies nicht der Fall war. Ich bin nur neugierig auf die Begr├╝ndung oder ob ich etwas falsch verstehe.

╬╗  (Server)  server-side renders at runtime (uses getInitialProps or getServerProps)
ÔŚő  (Static)  automatically rendered as static HTML (uses no initial props)
ÔŚĆ  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)

(auf n├Ąchster Version 9.1.6)

Vielen Dank

@stevenjchang Sie sind mit der folgenden Syntax in pages/**/*.js verf├╝gbar:

export function unstable_getStaticPaths() {} // return [{params: {...}}, ...]
export function unstable_getStaticProps({params: {...}) {} // return {props: {...}}

Und ich sollte auch hinzuf├╝gen, dass sie wunderbar sind, obwohl sie bei der Verwendung des Dev-Servers immer noch etwas rau sind.

obwohl sie bei der Verwendung des Dev-Servers immer noch etwas rau sind.
@mikestop macht weiter

K├Ânnten Sie das bitte n├Ąher ausf├╝hren? Niemand sonst hat uns negatives Feedback ├╝ber die Erfahrung mit dem Entwicklerserver gegeben, und wir w├╝rden es gerne l├Âsen!

@Timer Ich mag die neue API sehr. Mein Hauptproblem w├Ąhrend der Entwicklung ist, dass der Json bei jedem Ladevorgang erneut angefordert wird. Dies verlangsamt das Testen, stellt aber auch die Erfahrung des Benutzers beim Surfen auf der Website falsch dar.

Meinst du mit "bei jedem Ladevorgang" Seitenladevorg├Ąnge? Oder umbauen? Oder...?

@mmmeff Jedes Mal, wenn Sie zu demselben Pfad navigieren, wird die json erneut angefordert. Wenn Sie also zwischen zwei Seiten hin- und herklicken, verbringen Sie viel Zeit damit, auf Daten zu warten.

@mikestop f├Ąhrt fort, dies ist das beabsichtigte Verhalten, da die aktuellsten Daten in der Entwicklung oft vorzuziehen sind. W├Ąre offen f├╝r eine Diskussion ├╝ber bessere Heuristiken in einer neuen Ausgabe!

@timneutkens Dieser RFC sieht sehr vielversprechend aus. Ich habe ein paar Fragen/Bedenken zum Thema Sicherheit und wie es genau funktioniert.

Nehmen wir einen generischen Business Case, der sowohl auf SSR als auch auf SSG beruht.

Kontext

Wir m├Âchten einige Informationen auf einer Website (AKA "App") anzeigen.
Diese Informationen werden in einem BDD gespeichert, auf das ├╝ber eine GraphQL-API zugegriffen werden kann.
Einige dieser Informationen sind ├Âffentlich, andere privat (zB: Benutzer-E-Mails/Passwort).

Die App verwendet zwei Stufen:

  • Eine ÔÇ×StagingÔÇť-Phase, in der der Kunde ├änderungen in Echtzeit in der Staging-App sehen kann (er aktualisiert diese Informationen ├╝ber ein Back-Office oder ├Ąhnliches).
  • Eine ÔÇ×ProduktionsstufeÔÇť, auf die der Kunde keinen Zugriff hat und nichts selbst aktualisieren kann. Um die Produktions-App zu aktualisieren, muss eine neue Bereitstellung erfolgen. (Sie bitten um eine neue Produktionsbereitstellung von ihrem Back-Office aus)

In diesem Szenario verwenden wir sowohl SSR als auch SSG:

  • Die Staging-App verwendet SSR, da sie die Daten in Echtzeit von der GraphQL-API abruft (beim Erstellen einer Seite).
  • Die Produktions-App verwendet SSG, da sie bei einer neuen Bereitstellung die Daten von der GraphQL-API abruft und daraus statische Seiten generiert (sie sind daher statisch und ├Ąndern sich nicht mehr, es wird keine Abfrage an die GraphQL-API gestellt zur Laufzeit (zumindest nicht beim Laden einer Seite))

Dieses Szenario sollte generisch genug sein und (IMHO) einer der Hauptanwendungsf├Ąlle der SSG-Nutzung sein.
Die Produktions-App ist nichts anderes als eine Momentaufnahme der Staging-App.

Ein paar Fragen:

  1. Ist das mit diesem RFC m├Âglich ? Dass sich dieselbe App basierend auf einer bestimmten "Phase" (Produktion/Inszenierung) unterschiedlich verh├Ąlt
  2. Wie werden die Daten aus der GraphQL-API injiziert?

    • Beim Staging werden sie dynamisch ├╝ber SSR oder CSR abgerufen, w├Ąhrend der Benutzer durch die Seiten navigiert (und sind im Browser verf├╝gbar, wenn sie w├Ąhrend der CSR abgerufen werden).

    • In der Produktion werden sie zur Build-Zeit abgerufen, aber werden sie dann in einer globalen JS-Variablen gespeichert und k├Ânnen somit von jedem gelesen werden? (Sicherheitsbedenken, da wir uns bewusst sein m├╝ssen, keine sensiblen Daten abzurufen, die m├Âglicherweise im Browser verf├╝gbar sind, ├Ąhnlich wie bei der Verwendung von CSR)

  3. H├Ątten Sie Bedenken bez├╝glich dieses Ansatzes mit gemischter SSR/SSG? (Sicherheit, Leistung, Wartbarkeit usw.)

Wann planen Sie die Ver├Âffentlichung? Wird es ein gro├čes Update (v10) oder ein abw├Ąrtskompatibles Update sein?

Hey,

Haben Sie diese L├Âsung mit einem benutzerdefinierten Server ausprobiert und zum Laufen gebracht?

Beispiel:

// server.js

const express = require('express');
const next = require('next');

const port = parseInt(process.env.PORT, 10) || 3000;
const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();

  server.get('/blog/:id', (req, res) => {
    console.log('My params needed be passed to page:', req.params);
    return app.render(req, res, '/blogDetail', { id: req.params.id });
  });

  server.listen(port, err => {
    if (err) throw err;
    console.log(`> Ready on http://localhost:${port}`);
  });
});

// blogDetail.js
export async function unstable_getStaticProps(props) {
  console.log('What is passed', props);

  return {};
}

const BlogPostPage = ({ post }) => {
  return <div>Hey</div>;
}

export default BlogPostPage;
# Terminal output

My params needed be passed to page: { id: 'test' }
What is passed { params: undefined }

Warum kann getStaticProps die Abfragezeichenfolge nicht einschlie├čen? Ich habe derzeit eine Seite, auf der ich einfach SSR verwenden muss, um die Abfrageparameter ohne erneutes Rendern zu erhalten. Die Verwendung des useRouter Hooks f├╝hrt zu mehreren Re-Renderings, da query anf├Ąnglich ein leeres Objekt ist. Dies ist eine Seite, die f├╝r das Conversion-Tracking verwendet wird, also ist das offensichtlich kein Starter.

@pjaws Der RFC erw├Ąhnt ausdr├╝cklich, dass getStaticProps f├╝r die statische Generierung bestimmt ist. Statisches HTML kann keine Abfragezeichenfolge empfangen.

Warum kann es dann dynamische URL-Parameter empfangen? Wie ist das anders?

Am Di, 14. Januar 2020 um 01:30 Uhr Tim Neutkens [email protected]
schrieb:

@pjaws https://github.com/pjaws Der RFC, der ausdr├╝cklich erw├Ąhnt wird
getStaticProps ist f├╝r die statische Generierung. Statisches HTML kann kein a . empfangen
Abfragezeichenfolge.

ÔÇö
Sie erhalten dies, weil Sie erw├Ąhnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=AMVRRIQCKDJNF4MPWSLYNV3Q5WA2NA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBWLOW63LNMVXHJKT
oder abmelden
https://github.com/notifications/unsubscribe-auth/AMVRRIRJXLYC4MC4U7DH7NDQ5WA2NANCNFSM4JRPBELQ
.

Denn in getStaticPaths Sie die Seiten zur├╝ckgeben, die zur Build-Zeit gerendert werden.

Diese ├änderungen sehen sehr vielversprechend aus, tolle Arbeit wie immer! ­čĹŹ

Ich frage mich ├╝ber den Anwendungsfall von getInitialProps in _app.js , um Datenanforderungen zu erf├╝llen, die ├╝ber die Seiten hinweg geteilt werden (zB Einrichten von Kontextanbietern). Verstehe ich richtig, dass es unm├Âglich ist, getStaticProps auf die gleiche Weise zu verwenden? Kann man es nur in einzelnen Seiten definieren?

Ich frage mich ├╝ber den Anwendungsfall von getInitialProps in _app.js, um Datenanforderungen zu erf├╝llen, die ├╝ber die Seiten hinweg geteilt werden (z. B. Einrichten von Kontextanbietern). Verstehe ich richtig, dass es unm├Âglich ist, getStaticProps auf die gleiche Weise zu verwenden? Kann man es nur in einzelnen Seiten definieren?

Richtig, zun├Ąchst nur f├╝r einzelne Seiten. Kann es sp├Ąter noch einmal ├╝berdenken. Die getInitialProps von _app werden beim Exportieren in statisches HTML weiterhin aufgerufen, sodass Sie inkrementell zu getStaticProps wechseln k├Ânnen.

Hallo Leute, eine verwandte Frage - wie werden Verm├Âgenswerte behandelt? weil ich gerade sehe, dass, wenn ich ein Headless-CMS (sogar WordPress oder Graphcms oder was auch immer) verwende, die Asset-URL im statischen HTML verwendet wird.

Hier gibt es zwei Pr├Ąferenzen - dass Asset-Links als solche verwendet werden.
Aber wahrscheinlicher - laden Sie das Asset herunter, erstellen Sie den HTML-Code (lokal verlinken) und legen Sie dann ein CDN vor. Dies ist die weitaus akzeptablere Praxis.

Dies passt auch sehr gut zum Einsatz von Deployment-Systemen wie Netlify ÔÇô die ├╝ber eine weitaus geeignetere global verf├╝gbare Infrastruktur verf├╝gen als etwa DatoCMS oder Graphcms. Wenn ich also Netlify als Bereitstellung verwende, m├Âchte ich, dass alles von der Netlify-Dom├Ąne bereitgestellt wird und es seine Magie wirken l├Ąsst.

@sandys Wenn ich in https://github.com/zeit/next.js/issues/9054#issuecomment -570427085 richtig verstanden habe, solltest du die Assets herunterladen, unter .next/static speichern und einen Link erstellen selbst in getStaticProps .

Es gibt auch die Idee, statische API-Routen zu verwenden, aber ich bin mir nicht sicher, wie Sie das Browser-Caching-Verhalten damit steuern w├╝rden.

@Janpot danke f├╝r die Verlinkung. Die Kommentare dort scheinen darauf hinzudeuten, dass dieses Zeug selbst gerollt werden muss.

Bitte f├╝gen Sie meine Anfrage hinzu, dies integriert zu haben. Vielleicht ist #9054 allgemeiner, aber ich denke aus der Perspektive von SSG und das ist EXTREM wichtig.

Ich habe vergessen zu erw├Ąhnen, aber auch Asset-Hashing wird f├╝r SSG unerl├Ąsslich sein.

@homoky , Laufen bringen, hast du in der Zwischenzeit Fortschritte gemacht?

@homoky , Laufen bringen, hast du in der Zwischenzeit Fortschritte gemacht?

Es ist nicht m├Âglich und auch nicht geplant: #10071

­čśó

@sandys eigentlich ist die L├Âsung viel einfacher, wenn Sie https://github.com/zeit/next.js/issues/9081 verwenden , um ein Rewrite von zB /images zum CMS hinzuzuf├╝gen. ZB auf ZEIT Jetzt w├╝rde es das Ergebnis bereits zwischenspeichern, wenn die richtigen Header hinzugef├╝gt werden, kein zus├Ątzliches Herunterladen erforderlich (massiver Overhead beim Build).

@timneutkens danke f├╝r die Antwort.
Nicht ganz sicher, was du meinst. Wir verwenden also netlify - schlagen Sie vor, dass wir die CMS-URLs als solche beibehalten und eine CDN-Schicht dar├╝ber legen?
Ich bin mir nicht ganz sicher, ob Netlify (Cloudfront, das wir verwenden wollen) mit all diesen Diensten reibungslos funktionieren kann.

Wenn die Images heruntergeladen und Teil der Bereitstellung werden, wird dieses ganze Problem massiv vereinfacht. Weil ich CDN so eingerichtet habe, dass es von der Basis-URL zwischengespeichert wird (die in meinem Fall von s3 bedient wird).

Ich bin mir nicht ganz sicher, ob Ihre L├Âsung davon abh├Ąngt, dass ich Zeit NOW verwende

Wenn die Images heruntergeladen und Teil der Bereitstellung werden, wird dieses ganze Problem massiv vereinfacht. Weil ich CDN so eingerichtet habe, dass es von der Basis-URL zwischengespeichert wird (die in meinem Fall von s3 bedient wird).

Dies macht den Build-Prozess tats├Ąchlich viel komplexer und 10x langsamer, definitiv nicht einfacher.

Ich bin mir nicht ganz sicher, ob Ihre L├Âsung davon abh├Ąngt, dass ich Zeit NOW verwende

Funktioniert mit jedem Proxy der Welt. Inklusive Cloudfront.

@timneutkens Wir sind der Build-Prozesszeit eigentlich agnostisch. egal ob es l├Ąnger dauert. aber aus vielen Gr├╝nden (einschlie├člich aller Assets, die von einer bekannten Basis-URL bereitgestellt werden), w├Ąre es sehr vorzuziehen, diese im Build zu speichern.

Ich bef├╝rworte sicherlich nicht, dass Sie dies f├╝r alle aktivieren. Viele Leute werden gerne Deeplinks zu einem CMS erstellen. Aber wir betreiben eine Website mit hohem Traffic und das ist definitiv etwas, was Websites wie wir brauchen.

Verzeihen Sie mir auch, aber ich habe Ihre L├Âsung nicht verstanden. wie sollen wir das konfigurieren? Ich habe keine Kontrolle dar├╝ber, welche URL ein CMS verwendet. Zum Beispiel beginnt Datocms mit der Bereitstellung von www.datocms-assets.com/ . Wie verwenden wir die L├Âsung in #9081 ?

Wir sind der Build-Prozesszeit eigentlich agnostisch. egal ob es l├Ąnger dauert

Dies mag f├╝r Ihre Anwendung zutreffen, f├╝r die meisten Anwendungen ist dies jedoch nicht der Fall.

aber aus vielen Gr├╝nden (einschlie├člich aller Assets, die von einer bekannten Basis-URL bereitgestellt werden), w├Ąre es sehr vorzuziehen, diese im Build zu speichern.

Es muss wirklich nicht so sein, wie gesagt, Sie k├Ânnen ein Rewrite verwenden, das /images/* an die cms-URL weiterleitet, zum Beispiel www.datocms-asset.com/* oder ├Ąhnliches. Und dann verlinken Sie einfach alle Bilder mit /images .

Beachten Sie, dass dies allm├Ąhlich vom Thema abweicht.

@sandys eigentlich ist die L├Âsung viel einfacher, wenn Sie #9081 verwenden, um ein Rewrite von zB /images zum CMS hinzuzuf├╝gen. ZB auf ZEIT Jetzt w├╝rde es das Ergebnis bereits zwischenspeichern, wenn die richtigen Header hinzugef├╝gt werden, kein zus├Ątzliches Herunterladen erforderlich (massiver Overhead beim Build).

@timneutkens Nur um die Dinge f├╝r mich klar zu machen. Im Idealfall w├╝rden Sie das Bild hashen und f├╝r immer im Browser unter einer eindeutigen URL zwischenspeichern, und Inhaltsersteller k├Ânnen die Datei jederzeit unter demselben Namen im CMS aktualisieren. Das bedeutet also, dass das CMS in dem von Ihnen vorgeschlagenen Setup verantwortlich sein m├╝sste f├╝r:

  1. Optimierung der Bilder
  2. Hashing der Bilder und Bereitstellung unter diesem Hash
  3. Stellen Sie eine Karte von der Bild-URL zur gehashten Bild-URL bereit, die in getStaticProps heruntergeladen werden kann, um die Bild-URLs ihrem unver├Ąnderlichen Gegenst├╝ck auf dem CMS neu zuzuordnen

Was, denke ich, nicht unm├Âglich ist. Ich m├Âchte nur sicherstellen, dass dies das vorgeschlagene Setup ist.

@Janpot CMS-Anbieter handhaben dies bereits, indem sie eine eindeutige URL f├╝r Bilder usw.

Dies mag f├╝r Ihre Anwendung zutreffen, f├╝r die meisten Anwendungen ist dies jedoch nicht der Fall.

Auch hier bin ich nicht allein. Es gibt unz├Ąhlige ├Ąhnliche Anfragen. Ich bitte Sie, dies zu ber├╝cksichtigen.

https://spectrum.chat/next-js/general/how-would-you-handle-importing-remote-images-on-nextjs-static-export~30b2ba84-bc27-4da7-9ec8-21e4d5d287a3

auch auf gatsby-Seite - https://github.com/gatsbyjs/gatsby/issues/14076

https://spectrum.chat/gatsby-js/general/adding-remote-images-during-node-creation~e704e6fb-24b2-46c6-b1fc-93189d2e28a4

https://github.com/njosefbeck/gatsby-source-stripe/#downloading-files

@sandys dies hat nichts mit dem SSG RFC zu tun, also

Wollte jedoch nur erw├Ąhnen, dass dies in all unseren K├Âpfen eng mit SSG verbunden ist. Da dies der Idealfall f├╝r den SSG-Exportbefehl ist. Dies ist in anderen F├Ąllen im Allgemeinen nicht erforderlich.
Im besten Fall ist dies eine optionale Funktion beim n├Ąchsten Export.

Aber wie Sie wollen - respektieren Sie Ihre Entscheidung.

Aber es ist etwas, das next export derzeit nicht einmal tut. Daher ist es eine v├Âllig neue Sache und hat nichts mit diesem RFC zu tun.

Das geht auch nicht mit getServerProps und On-Demand-Rendering.

@Janpot CMS-Anbieter handhaben dies bereits, indem sie eine eindeutige URL f├╝r Bilder usw.

­čĹŹ ja, das macht Sinn. Das bedeutet aber auch, dass Sie zwei M├Âglichkeiten haben, wenn Sie Bilder in Ihrem Projekt verwenden und diese optimieren und zwischenspeichern m├Âchten:

  1. Erstellen Sie ein benutzerdefiniertes Webpack-Setup
  2. ein externes CMS verwenden

bearbeiten:

Und wenn ich richtig verstehe, file-loader ist bereits f├╝r CSS enthalten. Geht es nicht auch darum, es f├╝r JS zu aktivieren?

@Janpot Der von Sandeep erw├Ąhnte spezifische Punkt ist, dass die URLs von einer externen Quelle stammen w├╝rden, nicht vom Projekt selbst. Das standardm├Ą├čige Einschlie├čen des Dateiladers ist eine andere Funktionsanforderung.

Mir ist aufgefallen, dass f├╝r Seiten, die f├╝r ZEIT Now bereitgestellt werden, wenn ich eine Seite mit einer dynamischen URL habe, die die neuen statischen APIs verwendet, f├╝r Seiten, die nicht statisch mit unstable_getStaticPaths generiert wurden, die Funktion unstable_getStaticProps zur Laufzeit auf dem Server ausgef├╝hrt, anstatt 404 zur├╝ckzugeben.

ZB habe ich eine Seite /blog/[slug].js , deren getStaticPaths das Array zur├╝ckgibt:

[{ params: { slug: 'hello' } }]

und mein getStaticProps hat eine Logik, um eine Datei basierend auf dem Slug zu lesen. Wenn ich /blog/hello besuche, wird die Seite wie erwartet vorgerendert, aber wenn ich eine ung├╝ltige Seite wie /blog/doesnt-exist besuche, dann wird getStaticProps zur Laufzeit ausgef├╝hrt und ich erhalte einen Fehler 500, anstatt a 404. Oder wenn ich eine Fehlerbehandlung hinzuf├╝ge, wird die Seite anstelle eines 404 gerendert, obwohl sie nicht in der Ausgabe von getStaticPaths .

Ist diese Logik beabsichtigt?

Dies ist eine gro├če Verbesserung. Wir waren gerade dabei, einige vorgefertigte Skripte zu schreiben, um genau dies zu tun.
Ich habe gerade getestet, eine unserer Sites auf Next 9.2 auf unstable_getStaticPaths und unstable_getStaticProps zu verschieben, und es hat gut funktioniert.

Wir haben eine Regression im Vergleich zu exportPathMap : Wenn Sie einen Pfad mit exportPathMap erstellen, k├Ânnen Sie Folgendes angeben:

{
 "/path/to/page": {page: "/index", query: { pageId: 123 } }
}

und der statische Build wird aufgebaut

/path
   /to
     /page
       index.html

Wenn Sie das Äquivalent von unstable_getStaticPaths in der Vorlage [slug].jsx ,

[{ slug: '/path/to/page' }]

Next 9.2 generiert '%2Fpath%2Fto%2Fpage' anstelle der verschachtelten Verzeichnisse.

/%2Fpath%2Fto%2F
   index.html

Der Aufbau von Verzeichnissen (die dem bestehenden exportPathMap-Verhalten entsprechen) ist wichtig f├╝r den Aufbau von Seiten. Wir verwenden eine einzelne Vorlagendatei, aber der ver├Âffentlichte Pfad kann beliebig verschachtelt sein.

@dpfavand in diesem Fall sollten Sie eine Catch-All-Route verwenden: https://nextjs.org/blog/next-9-2#catch -all-dynamic-routes

M├Âglicherweise k├Ânnen wir warnen, wenn Sie versuchen, einen Pfad mit Schr├Ągstrichen zur├╝ckzugeben, aber das Verhalten ist korrekt, wenn Sie [slug].js , in Ihrem Fall m├Âchten Sie [...slug].js .

Wann soll dieser landen? Wird es ein Patch von 9.2 oder eine eigene Nebenversion sein?

Wir wissen die ganze Aufregung rund um dieses Feature wirklich zu sch├Ątzen. Wie an anderer Stelle erw├Ąhnt, teilen wir im Allgemeinen keine Zeitpl├Ąne f├╝r Funktionen, da wir sicherstellen m├Âchten, dass sie die richtige Entwicklererfahrung, Einschr├Ąnkungen und Zukunftssicherheit aufweisen.

Da es sich um ein neues Feature handelt, wird es nur geringf├╝gig sein.

Ja, das w├╝rde ich normalerweise verstehen, aber der 9.1.7-Blog hat den Eindruck erweckt
es war schon in freier Wildbahn.

Am Fr, 17. Januar 2020 um 17:05 Uhr Tim Neutkens [email protected]
schrieb:

Wir wissen die ganze Aufregung rund um dieses Feature wirklich zu sch├Ątzen. Wie erw├Ąhnt
andernorts teilen wir im Allgemeinen keine Zeitleisten f├╝r Funktionen, wie wir es m├Âchten
Stellen Sie sicher, dass sie die richtige Entwicklererfahrung, Einschr├Ąnkungen und Zukunft haben
Beweiskraft.

ÔÇö
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=ADKINGF724256WCEFHBFIH3Q6ITRXA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT-DN5WWZ
oder abmelden
https://github.com/notifications/unsubscribe-auth/ADKINGBVCG6MFMOG5U2FGMDQ6ITRXANCNFSM4JRPBELQ
.

>

Lassiter Gregg
[email protected] [email protected]
Zelle (832) 495-9903

Gibt es so etwas wie getStaticProps aber nur einmal f├╝r die gesamte App statt pro Seite ausgef├╝hrt wird?

Mein Anwendungsfall ist, dass ich einen React Context ( PricingPlansContext ) habe, der von mehreren Seiten verwendet wird und ich m├Âchte, dass die Daten (Preispl├Ąne) nur einmal von meinem externen Server zur Build-Zeit abgerufen werden ( next export ). Nie zur Laufzeit und ohne die getStaticProps von jeder Seite hinzuf├╝gen zu m├╝ssen.

BEARBEITEN: Oben einen entsprechenden Kommentar gefunden: https://github.com/zeit/next.js/issues/9524#issuecomment -574179540. Hoffentlich wird es ber├╝cksichtigt.

Ich benutze daf├╝r babel plugin-preval`, obwohl ich auch gesehen habe, wie Leute a
json-Datei innerhalb von exportPathMa() mit next.config.js, die sie dann importieren
innerhalb ihres Codes.

Am Ende habe ich eine Json-Datei mit einem npm-Skript geschrieben, aber danke f├╝r den Vorschlag von exportPathMap, vielleicht ist das ein besserer Ort.

@dpfavand in diesem Fall sollten Sie eine Catch-All-Route verwenden: https://nextjs.org/blog/next-9-2#catch -all-dynamic-routes

M├Âglicherweise k├Ânnen wir warnen, wenn Sie versuchen, einen Pfad mit Schr├Ągstrichen zur├╝ckzugeben, aber das Verhalten ist korrekt, wenn Sie [slug].js , in Ihrem Fall m├Âchten Sie [...slug].js .

@timneutkens danke f├╝r das Follow-up. Ich habe zwei Methoden ohne Erfolg ausprobiert. Wenn der Slug-Wert als String in getStaticPaths , wird er grunds├Ątzlich nicht an getStaticProps . Wenn der Slug-Wert als Array zur├╝ckgegeben wird, schl├Ągt der Build fehl, da der Wert ein String sein muss.

Fall 1, Angenommen eine Datei pages/[...slug].jsx , Slug als String:

export async function unstable_getStaticPaths() {
    return [{ params: { slug: 'en/about' } }];
}

export async function unstable_getStaticProps({ params }) {
    console.log('params', params);
    return { slug: params.slug };
}

Im obigen Fall ist params in getStaticProps ein leeres Objekt - kein slug Schl├╝ssel.

Fall 2, pages/[...slug].jsx , Slug als Array,

export async function unstable_getStaticPaths() {
    const allPaths = Object.keys(pathMap).map(slug => ({ params: { slug } }));
    return [{ params: { slug: ['en', 'about'] } }];
}
export async function unstable_getStaticProps({ params }) {
    console.log('params', params);
    return { slug: params.slug };
}

In Fall 2 schl├Ągt der Build fehl mit

> Build error occurred
{ Error: A required parameter (slug) was not provided as a string.
    at _validParamKeys.forEach.validParamKey (/project/node_modules/next/dist/build/utils.js:21:569)
    at Array.forEach (<anonymous>)
    at toPrerender.forEach.entry (/project/node_modules/next/dist/build/utils.js:21:495)
    at Array.forEach (<anonymous>)
    at Object.isPageStatic (/project/node_modules/next/dist/build/utils.js:17:122)
    at process._tickCallback (internal/process/next_tick.js:68:7) type: 'Error' }

Ich sehe nur Pfadparameter in den obigen Beispielen f├╝r getStaticPaths . Wird es m├Âglich sein, SSG-Pfade zu erstellen, die Abfrageparameter enthalten? Zum Beispiel:

/store/widgets/circles-n-squares?sort=price&minWeight=2&color=black

Ich denke insbesondere aus der Perspektive einer E-Commerce-Site, bei der es schwierig w├Ąre, jede einzelne Facette der Produktsuche in den pathname einer URL abzudecken.

Ich habe hier vor kurzem eine Nachricht gepostet und keine Antwort erhalten - im Wesentlichen verh├Ąlt sich getStaticProps wie getServerProps wenn eine Site an ZEIT Now bereitgestellt wird (dh getStaticPaths ignoriert und Anfragen bearbeitet) dynamisch) - Ich denke, das ist ein Fehler?

@dpfavand genau das Starter-Site f├╝r Agilitycms und nextjs mit dynamischem

@timneutkens danke f├╝r das Follow-up. Ich habe zwei Methoden ohne Erfolg ausprobiert. Wenn der Slug-Wert als String in getStaticPaths , wird er grunds├Ątzlich nicht an getStaticProps .

Fall 1, Angenommen eine Datei pages/[...slug].jsx , Slug als String:

export async function unstable_getStaticPaths() {
  return [{ params: { slug: 'en/about' } }];
}

export async function unstable_getStaticProps({ params }) {
  console.log('params', params);
  return { slug: params.slug };
}

Im obigen Fall ist params in getStaticProps ein leeres Objekt - kein slug Schl├╝ssel.

├ťbrigens, kleine Welt! Nochmals vielen Dank, dass Sie bei fastr_conf gesprochen haben.

Hallo @timneutkens ,

Ich bin sehr begeistert von der Idee, dass sich next.js wie ein statischer Site-Generator verh├Ąlt.

Ich m├Âchte fragen, wie die Methoden getStaticProps und getStaticPaths werden k├Ânnen, wenn ein gro├čer Datenblock einmal angefordert und dann zum Generieren verschiedener Seiten verwendet wird.

Ich verwende beispielsweise einen JavaScript-SDK-Client eines API-basierten CMS, der ├╝ber eine Methode zum Abrufen aller verf├╝gbaren Objekte verf├╝gt. Einige dieser Objekte repr├Ąsentieren Site-Seiten.

const entries = await cmsSdkCient.getEntries();

Bisher habe ich die Methode exportPathMap verwendet, um alle Eintr├Ąge aus dem CMS auf einmal abzurufen und eine Karte zwischen den Pfaden dieser Seite und ihren Daten zu erstellen. Die Funktion exportPathMap macht zwei Dinge:

  1. Stellt eine Seitenkarte mit ihren Daten und ssr: true , die von getInitialProps zum Zeitpunkt des Exports verbraucht werden
  2. Schreibt dieselben Daten, diesmal mit ssr: false , in init-props.json Dateien, die in dem Ordner abgelegt werden, der dem Pfad jeder Seite entspricht. Wenn dann getInitialProps vom Client aufgerufen wird, werden die ben├Âtigten Daten von init-props.json der ├╝bereinstimmenden Seite geladen.


next.config.js mit exportPathMap

module.exports = {
  exportTrailingSlash: true,
  exportPathMap: (defaultPathMap, { outDir }) => {
    // load data from CMS
    const objects = await cmsSdkCient.getEntries();

    // create map between page paths and page data
    return objects.reduce((accum, object) => {

      // if the object does not have a slug, it is not a page
      if (!object.slug) return accum;

      const pagePath = '/' + object.slug;
      const ssrQueryData = Object.assign({ ssr: true }, object);
      const clientQueryData = Object.assign({ ssr: false }, object);

      // generate the map for export phase with {ssr: true}
      accum[pagePath] = {
        // using additional fields from the page object,
        // the pageFromPagePath() computes which page file should
        // be used to render the page object
        page: pageFromPagePath(object),
        query: ssrQueryData
      };

      // write json files that will be loaded by client
      if (outDir) {
        const jsonFilePath = path.join(outDir, _.trim(pagePath, '/'), 'init-props.json');
        fse.outputFileSync(jsonFilePath, JSON.stringify(clientQueryData));
      }

      return accum;
    }, {});
  }
}


Seiten/my_page.js mit getInitialProps

Index.getInitialProps = async (context) => {
  const ssr = _.get(context, 'query.ssr', false);
  if (ssr) {
    // we are on server, return the data
    return _.get(context, 'query', {});
  } else {
    // we are on client side, request the data through /init-props.json endpoint
    const url = context.asPath + '/init-props.json';
    return fetch(url).then(response => {
      return response.json();
    });
  }
};

Ich kann den gro├čen Vorteil der Verwendung der Methoden getStaticProps und getStaticPaths , die einen Gro├čteil meines Codes im Zusammenhang mit dem Speichern von JSON-Dateien und dem Laden vom Client reduzieren.

// pages/my_page.js
export async function getStaticProps(context) {
  const objects = await cmsSdkCient.getEntries();
  const props = _.find(object, { type: 'my_page' })
  return { props };
}

// pages/blog/[slug].js
export async function getStaticProps(context) {
  const objects = await cmsSdkCient.getEntries();
  const props = _.find(object, { type: 'post', slug: context.params.slug })
  return { props };
}

export async function getStaticPaths() {
  const objects = await cmsSdkCient.getEntries();
  return objects
    .filter(object => object.type === 'post')
    .map(object => ({ params: { slug: object.slug } }))
}

Was mich besch├Ąftigt, ist die Frage, wie ich den Workflow optimieren kann, um alle Eintr├Ąge einmal zu bringen, anstatt sie jedes Mal abzurufen, wenn getStaticProps oder getStaticPaths aufgerufen werden?

Eine andere Frage hat m├Âglicherweise nicht unbedingt mit diesem Problem zu tun, aber da wir uns in der Welt der SSGs und Remote-Datenquellen befinden, lohnt es sich, sie zu stellen. Angenommen, next.js l├Ąuft im Dev-Modus, wie kann man next.js benachrichtigen, diese Methoden erneut auszuf├╝hren, um die Remote-Daten erneut abzurufen und die Site neu aufzubauen.

@smnh Da es sich um ÔÇ×nur JavaScriptÔÇť handelt, k├Ânnen Sie Ihre Eintr├Ąge einmal

Was Ihre zweite Frage betrifft, geschieht dies automatisch. F├╝hren Sie next dev und Sie k├Ânnen loslegen.

Ich sehe nur Pfadparameter in den obigen Beispielen f├╝r getStaticPaths . Wird es m├Âglich sein, SSG-Pfade zu erstellen, die Abfrageparameter enthalten? Zum Beispiel:

/store/widgets/circles-n-squares?sort=price&minWeight=2&color=black

Ich denke insbesondere aus der Perspektive einer E-Commerce-Site, bei der es schwierig w├Ąre, jede einzelne Facette der Produktsuche in den pathname einer URL abzudecken.

Ich glaube nicht, dass dies im Kontext von ssg sinnvoll ist. SSG gibt f├╝r jeden Eintrag eine Datei aus - Abfrageparameter sind nicht Teil des Dateinamens, daher ben├Âtigen Sie eine Serverschicht, um die Anforderungen in eine tats├Ąchliche Datei umzuschreiben. (Wie w├Ąre Ihr statischer Dateiname im obigen Beispiel?) Ich w├╝rde vorschlagen, die Standardansicht (die Sie erhalten, wenn Sie die Seite ohne Facetten besuchen) vorab zu rendern und auf der Clientseite zu aktualisieren, wenn Abfrageparameter f├╝r die Anfrage vorhanden sind. Aber das wird ein Thema jenseits dieses SSG RFC.

@dpfavand genau das Starter-Site f├╝r Agilitycms und nextjs mit dynamischem

@timneutkens danke f├╝r das Follow-up. Ich habe zwei Methoden ohne Erfolg ausprobiert. Wenn der Slug-Wert als String in getStaticPaths , wird er grunds├Ątzlich nicht an getStaticProps .
Fall 1, Angenommen eine Datei pages/[...slug].jsx , Slug als String:

export async function unstable_getStaticPaths() {
    return [{ params: { slug: 'en/about' } }];
}

export async function unstable_getStaticProps({ params }) {
    console.log('params', params);
    return { slug: params.slug };
}

Im obigen Fall ist params in getStaticProps ein leeres Objekt - kein slug Schl├╝ssel.

├ťbrigens, kleine Welt! Nochmals vielen Dank, dass Sie bei fastr_conf gesprochen haben.

Hey! Das Nextjs-Team hat damit begonnen, sich damit zu befassen, es ist ein Ticket offen, um einige zus├Ątzliche Probleme mit der aktuellen Canary-Implementierung zu l├Âsen: https://github.com/zeit/next.js/issues/10190

@smnh Am Ende habe ich ein Skript, das den freigegebenen Inhalt vorab

F├╝r Rebuilds habe ich Webhooks im CMS eingerichtet, um Netlify-Build-Hooks auszul├Âsen, wenn sich relevante Inhalte ├Ąndern. GetStaticProps kann dann einfach seitenspezifischen Inhalt abrufen.

Danke @zeusdeux
Betreff:

Was Ihre zweite Frage betrifft, geschieht dies automatisch. F├╝hren Sie den n├Ąchsten Entwickler aus und Sie k├Ânnen loslegen.

Wenn ich sie in einem Modul zwischenspeichere und dann die Daten im CMS ├Ąndere, wie der Cache ung├╝ltig gemacht und von dev , jedoch ohne next.js zu stoppen und erneut auszuf├╝hren :)

Wenn ich sie in einem Modul zwischenspeichere und dann die Daten im CMS ├Ąndere, wie der Cache ung├╝ltig gemacht und von dev , jedoch ohne next.js zu stoppen und erneut auszuf├╝hren :)

getStaticPaths wird nur in einem Produktionsbuild aufgerufen, daher k├Ânnen Sie die Abrufmethode nur anweisen, im Modulstatus zwischenzuspeichern, wenn sie von dieser Funktion aufgerufen wird.

Hey, ich habe nicht gesehen, ob jemand das gleiche Problem hat wie ich.

Angenommen, ich habe dieselbe Seite auf mehreren Routen mit unstable_getStaticProps :

1. /providers/[category]/[city] 
2. /providers/[category] 

Der Quellcode ist f├╝r beide Seiten gleich, so dass er nicht dupliziert werden muss. Die erste Datei enth├Ąlt also Quellcode mit Logik, die zweite importiert nur die erste wie export { default } from './[city]'; .

Es wird jedoch ein Fehler ausgegeben, dass die Daten von getStaticProps nicht definiert sind. Wenn ich denselben Code in beide Dateien kopiere, funktioniert es.

@homoky Sie m├╝ssen die Methoden erneut exportieren:

export { default, unstable_getStaticProps } from './[city]';

Ich habe es mit SSG versucht, aber ohne Gl├╝ck.

Sollte der folgende Code mit v9.2.1 zu SSG f├╝hren?

function Page({ stars }) {
  return <div>Next stars: {stars}</div>
}

Page.unstable_getStaticProps = async ctx => {
  return { props: { stars: 5 } }
}

export default Page

Meine Konsolenausgabe von next build zeigt:

Page                                                           Size     First Load
Ôöî ÔŚő /                                                          354 B       72.1 kB
...
╬╗  (Server)  server-side renders at runtime (uses getInitialProps or getServerProps)
ÔŚő  (Static)  automatically rendered as static HTML (uses no initial props)
ÔŚĆ  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)

@joostmeijles unstable_getStaticProps muss exportiert statt an die Seitenkomponente angeh├Ąngt werden, zB

export const unstable_getStaticProps = async () => {
  return {
    props: { stars: 5 }
  }
}

@joostmeijles unstable_getStaticProps muss exportiert statt an die Seitenkomponente angeh├Ąngt werden, zB

export const unstable_getStaticProps = async () => {
  return {
    props: { stars: 5 }
  }
}

Danke, das l├Âst es.

Wenn jemand ein End-to-End-Arbeitsbeispiel daf├╝r sehen m├Âchte, das Erstellen dynamischer Seiten (aus einem CMS) mit einer Catch-All-Route und SSG, besuchen Sie https://github.com/agility/agilitycms-next-starter- ssg.

Ich war ein paar Mal ratlos und dachte, dies k├Ânnte f├╝r andere hilfreich sein.

Wie kann ich w├Ąhrend des Builds mit getStaticProps bei der Bereitstellung auf zeit.co/now auf die n├Ąchsten API-Routen zugreifen? Isomorpher Abruf erfordert eine absolute URL; lokal funktioniert es mit http://localhost :3000 aber nicht mit now Deployment (oder ich habe es falsch gemacht ­čĄĚÔÇŹÔÖé´ŞĆ). Irgendwelche Ideen?

Wenn ich richtig liege, werden die API-Routen als serverlose Funktionen bereitgestellt, und ich vermute, dass sie w├Ąhrend des Build-Prozesses nicht bereit sind?

Sie sollten die Funktion Ihrer API-Route direkt aufrufen, da dies viel weniger Overhead bedeutet, als ├╝ber http zu gehen.

Sie sollten die Funktion Ihrer API-Route direkt aufrufen, da dies viel weniger Overhead bedeutet, als ├╝ber http zu gehen.

Gibt es Ressourcen, die ich in den Dokumenten zu diesem Thema lesen kann? Ich bin mitten in der Migration zu zeit.co/now :)

Ganz w├Ârtlich genommen importieren und rufen Sie die Funktion auf:

import MyFunction from '../lib/somewhere'


export async function /* unstable_ */getStaticProps() {
  const result = await MyFunction()
}

Noch eine Frage: Wird es m├Âglich sein, getStaticProps / getStaticPaths und getServerProps nebeneinander zu verwenden? Wenn ich zum Beispiel einige Seiten mit SSG vorgerendert habe, aber keine im CDN-Cache gefunden wird, wird dann auf SSR zur├╝ckgegriffen, um die Seite bei Bedarf zu generieren?

getStaticProps wird auf SSR zur├╝ckgreifen und das Ergebnis zum Cache hinzuf├╝gen.

getStaticProps wird auf SSR zur├╝ckgreifen und das Ergebnis zum Cache hinzuf├╝gen.

@lfades , wenn ich dich richtig verstehe, dann bin ich super ­čśŹ dar├╝ber, denn so kann ich ein paar der beliebten Seiten vorrendern, anstatt vorher mehrere tausend Seiten nachzuschlagen und zu generieren.

Aber nur um sicher zu gehen, dass ich es verstehe... Nehmen wir an, ich habe eine /products/[productId].js dynamische Pfadseite. Wenn ich ein getStaticProps und eine begrenzte Anzahl von Ergebnissen aus getStaticPaths anliefere, dann sagen Sie, wenn /products/123 nicht im CDN-Cache gefunden wird (weil es nicht t in getStaticPaths ), wird es auf SSR zur├╝ckfallen, getStaticProps ausf├╝hren und das Ergebnis dann als statische Seite zwischenspeichern?

Folgefrage: Funktioniert das auch, wenn ich gar kein getStaticPaths liefere?

@flintinatux Ja und ja

getStaticProps wird auf SSR zur├╝ckgreifen und das Ergebnis zum Cache hinzuf├╝gen

Dies ist ein Problem, da es keine M├Âglichkeit gibt, 404s auszuf├╝hren, da getStaticProps das ├ändern des res -Objekts nicht zul├Ąsst - entweder 200 oder 500, wenn w├Ąhrend des Funktionsaufrufs ein Fehler auftritt.

Ist eine Änderung geplant?

@davidbailey00 beim Erstellen statischer Websites haben 404-Seiten bereits den 404-Statuscode nicht.

Wenn ich einen vollst├Ąndigen statischen Export durchf├╝hre, gibt es nat├╝rlich keine M├Âglichkeit, Statuscodes zu erstellen, da alles nur eine Datei ist. Ich spreche von der Bereitstellung hybrider Sites mit getStaticProps f├╝r ZEIT Now - es scheint, als ob es getStaticPaths respektieren und 404-Seiten bereitstellen sollte, anstatt das Rendern aller Seiten zu erzwingen, die unabh├Ąngig davon einem dynamischen Pfad entsprechen.

So funktioniert es aber nicht nur bei Now, sondern auch bei next start .

Ich wiederhole, wie bereits gesagt: Dies ist experimentell und alles kann sich noch im Verhalten ├Ąndern.

Aber es ist m├Âglich , 404 Seiten mit dienen getServerProps oder getInitialProps - wenn getStaticProps ignoriert getStaticPaths , wenn Antwortcode bedenkt , dann ist es v├Âllig unrentabel f├╝r jede Website , die Sorgen ├╝ber gute SEO.

Wir werden wahrscheinlich weitere M├Âglichkeiten zum Umgang mit Statuscodes einf├╝hren, aber bedenken Sie, dass die meisten statischen Sites (z. B. CRA) /* an index.html weiterleiten, wobei 404 immer noch eine 200 ist.

Hallo Leute, ich habe eine direkte Frage, ich baue eine einfache Website mit dem neuen [unstable_]getStaticProps um einige der Seiten zu SSG. Bisher funktioniert alles einwandfrei, mit Ausnahme des Verst├Ąrkers .

Wenn eine Seite [unstable_]getStaticProps , ist amp deaktiviert. Hier ein einfaches Beispiel f├╝r die Arbeit mit next v9.2.1, wo Sie das ├╝berpr├╝fen k├Ânnen:

import React from "react";
import { useAmp } from "next/amp";

export const config = { amp: `hybrid` };

const AmpExample = ({ date }) => {
  const isAmp = useAmp();
  return (
    <>
      <p>
        Welcome to the {isAmp ? `AMP` : `normal`} version of the Index page!!
      </p>
      <p>date: {date}</p>
    </>
  );
};
/**
 * If I get the dynamic data from getStaticProps,
 * page is SSG render but AMP is disabled when accessing
 * with `/ampExample?amp=1`
 */
export async function unstable_getStaticProps() {
  return {
    props: {
      date: new Date().toISOString(),
    },
  };
}

/**
 * If I get the dynamic data from getInitialProps,
 * page is SSR render but AMP is disabled when accessing
 * with `/ampExample?amp=1`
 */
// AmpExample.getInitialProps = () => {
//   return { date: new Date().toISOString() }
// }
export default AmpExample;

Irgendwelche Hilfe zu verstehen, wie man Seiten SSG mit Daten und amp Laufen bringt?

Hallo, wie w├Ąre es mit getStaticProps f├╝r App Komponente ( _app.tsx ), dh f├╝r F├Ąlle wie das Abrufen gemeinsamer Daten f├╝r alle Seitenkomponenten w├Ąhrend der Build-Phase?

Hallo, wie w├Ąre es mit getStaticProps f├╝r App Komponente ( _app.tsx ), dh f├╝r F├Ąlle wie das Abrufen gemeinsamer Daten f├╝r alle Seitenkomponenten w├Ąhrend der Build-Phase?

@pkral78 Ich kann Ihnen sagen, wie ich mit dem tats├Ąchlichen Entwicklungsstand

Ich habe ein Layout mit dem Ansatz "Layout as a Higher Order Component (HOC)" erstellt (nicht mehr in den Lernunterlagen ­čĄĚÔÇŹÔÖé´ŞĆ).

Wie auch immer, ich habe ein Layout wie das folgende erstellt (nur ein Beispiel):

import React from "react";
import Head from "next/head";

const withSSGLayout = Page => {
  const WithSSGLayout = props => {
    return (
      <>
        <Head>
          <title>My Web Page</title>
          <link rel="icon" href="/favicon.ico" />
          <meta name="viewport" content="width=device-width, initial-scale=1" />
          <link
            href="https://fonts.googleapis.com/css?family=Roboto:400,700&display=swap"
            rel="stylesheet"
          />
        </Head>
        <Page {...props} />
      </>
    );
  };

  WithSSGLayout.unstable_getStaticProps = async () => {
    const pageStaticProps = Page.unstable_getStaticProps
      ? await Page.unstable_getStaticProps()
      : {};

    // Here you can make parent level queries too
    return {
      props: {
        ...pageStaticProps.props,
        parentProp: `dynamic prop-${new Date().toISOString()}`,
      },
    };
  };
  return WithSSGLayout;
};

export default withSSGLayout;

Und dann auf der Seite, auf der Sie diesen Ansatz verwenden m├Âchten, k├Ânnen Sie einfach den HOC hinzuf├╝gen (Sie m├╝ssen die [unstable_]getStaticProps explizit exportieren und der Verst├Ąrker funktioniert nicht zusammen), aber ich habe einen "sch├Ânen Weg" gefunden, um eine Anfrage auf hoher Ebene zu stellen und SSG-Abfragen pro Seite.

import React from "react";
import withSSGLayout from "../hocs/withSSGLayout";

export const config = { amp: `true` };

const Index = props => {
  const { date, parentProp } = props;
  return (
    <div>
      <h1>Example</h1>
      <h3>Local Prop?: {date}</h3>
      <h3>Parent Prop?: {parentProp}</h3>
    </div>
  );
};

// In theory you could do direct database queries
Index.unstable_getStaticProps = async () => {
  // Here you can make page level queries
  return {
    props: {
      date: new Date().toISOString(),
    },
  };
};
const IndexHOC = withSSGLayout(Index);

export const { unstable_getStaticProps } = IndexHOC;
export default IndexHOC;

W├╝rde gerne hinterfragen, wenn es ein guter Ansatz ist. In meinem Fall verwende ich diese Technik, um die Links im ├╝bergeordneten und den Seiteninhalt in den Seiten abzufragen. Ich hoffe, es hilft.

@robertovg Sie m├╝ssen auf

@timneutkens K├Ânnten Sie vielleicht eine bessere L├Âsung f├╝r dieses kleine Beispiel vorschlagen? Ich habe nur versucht, in irgendeiner Weise sowohl "Layout-Level-SSG-Abfrage" als auch "Seiten-Level-SSG-Abfrage" zu haben, und ich dachte ├╝ber diesen HOC-Layout-Ansatz nach.

Die Haupteinschr├Ąnkung f├╝r mich bestand darin, explizit "[unstable_]getStaticProps" zu exportieren, die Sie auf jeder Seite haben m├╝ssen, um sie als SSG-Seite zu markieren.

Ich w├╝rde mich auch sehr ├╝ber weitere Informationen freuen, ob Verst├Ąrker + SSG kompatibel sein werden, habe ich vorhin gefragt.

Danke ­čÖĆ

@robertovg Trennen Sie zuerst das Layout von den Daten, damit Sie f├╝r das freigegebene Layout etwas Einfaches wie

import Layout from '../components/layout'

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

Und dann f├╝r getStaticProps die freigegebenen Daten mit einer Methode aus einem anderen Modul abrufen, sodass das vollst├Ąndige Beispiel so aussehen k├Ânnte:

import fetchSharedData from '../lib/fetch-shared-data'
import Layout from '../components/layout'

export const unstable_getStaticProps = async () => {
  const sharedData = await fetchSharedData()
  const pageProps = {...}

  return {  props: { ...sharedData, ...pageProps } }
}

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

@robertovg Trennen Sie zuerst das Layout von den Daten, damit Sie f├╝r das freigegebene Layout etwas Einfaches wie

import Layout from '../components/layout'

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

Und dann f├╝r getStaticProps die freigegebenen Daten mit einer Methode aus einem anderen Modul abrufen, sodass das vollst├Ąndige Beispiel so aussehen k├Ânnte:

import fetchSharedData from '../lib/fetch-shared-data'
import Layout from '../components/layout'

export const unstable_getStaticProps = async () => {
  const sharedData = await fetchSharedData()
  const pageProps = {...}

  return {  props: { ...sharedData, ...pageProps } }
}

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

Ich sehe und verstehe diese L├Âsung, aber das Problem, das ich zu l├Âsen versuchte, bestand darin, die Nutzung gemeinsamer Daten zu skalieren.
Zum Beispiel, wenn Sie ein <Header /> , das die sharedData , um die Links zu erhalten und diese von einem Headless CMS kommen. Sie m├╝ssen das <Header /> als Kind des <Layout /> mit Requisiten oder einer anderen L├Âsung injizieren. Und Sie m├╝ssen die Injektion von <Header /> in alle Seiten wiederholen, die Sie verwenden m├Âchten.

Beim HOC-Ansatz w├╝rden Sie <Header /> einmal im HOC hinzuf├╝gen.

Aus diesem Grund dachte ich, es sei ein guter Punkt, der von @pkral78 angesprochen wurde, um Codeduplizierung nach M├Âglichkeit zu vermeiden.

Aus diesem Grund dachte ich, es sei ein guter Punkt, der von @pkral78 angesprochen wurde, um Codeduplizierung nach M├Âglichkeit zu vermeiden.

Es war in meinem Kopf. Die _app-Seite sollte ihre getStaticProps , die einmal w├Ąhrend des Renderns der ersten Seite aufgerufen werden und dann gespeicherte props an die n├Ąchsten gerenderten Seiten weitergeben. Aber ich ├╝berlege noch, ob es ├╝berhaupt das richtige Konzept ist.

Ich bin mir nicht sicher, ob so etwas ein beabsichtigter Anwendungsfall ist, aber es scheint nicht zu funktionieren:

// /pages/[...slug].jsx
import ReactDOMServer from "react-dom/server";

export async function unstable_getStaticProps({ params: { slug } }) {
  const filePath = "../content/" + slug.join("/") + ".mdx";
  const { default: Component } = await import(filePath);
  const content = ReactDOMServer.renderToStaticMarkup(<Component />);
  return {
    props: { title: slug.join(" "), content }
  };
}

export default function Page({ title, content }) {
  return (
    <div>
      <h1>{title}</h1>
      <div dangerouslySetInnerHTML={{ __html: content }} />
    </div>
  );
}

Auch wenn es kein beabsichtigter Anwendungsfall ist, protokolliert es einen Fehler, der etwas verd├Ąchtig erscheint:

[ warn ]  ./pages/[...slug].jsx
Critical dependency: the request of a dependency is an expression

Bearbeiten:

Oh, ok, es l├Âst sich auf, wenn ich es tue

const { default: Component } = await import(`../content/${slug.join("/")}.mdx`);

https://codesandbox.io/s/happy-oskar-40bug

Dies beschwert sich dar├╝ber, dass Ihr Importdateipfad dynamisch ist

Am Do, 30. Januar 2020 um 00:29 Uhr schrieb Jan Potoms [email protected] :

Bin mir nicht sicher ob sowas
https://codesandbox.io/s/nifty-cache-jspqr ist ein beabsichtigter Anwendungsfall, aber
es scheint nicht zu funktionieren:

// /pages/[...slug].jsximport ReactDOMServer von "react-dom/server";
asynchrone Funktion exportieren unstable_getStaticProps({ params: { slug } }) {
// Wie sicher ist das ├╝berhaupt?
const filePath = "../content/" + slug.join("/") + ".mdx";
const { default: Component } = wait import(filePath);
const content = ReactDOMServer.renderToStaticMarkup(Komponente);
R├╝ckkehr {
Requisiten: { title: slug.join(" "), content }
};
}
Standardfunktion exportieren Seite({ Titel, Inhalt }) {
R├╝ckkehr (


{Titel}




);
}

Auch wenn es kein beabsichtigter Anwendungsfall ist, protokolliert es einen Fehler, der wie
etwas verd├Ąchtig:

[ warnen ] ./pages/[...slug].jsx
Kritische Abh├Ąngigkeit: Die Anforderung einer Abh├Ąngigkeit ist ein Ausdruck

ÔÇö
Sie erhalten dies, weil Sie erw├Ąhnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=AAADKRKOL34WKTG7J5QFRJ3RAIGPBA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDNPJ
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAADKRIWNA2DSMWFRGD453DRAIGPBANCNFSM4JRPBELQ
.

Aus diesem Grund dachte ich, es sei ein guter Punkt, der von @pkral78 angesprochen wurde, um Codeduplizierung nach M├Âglichkeit zu vermeiden.

Es war in meinem Kopf. Die _app-Seite sollte ihre getStaticProps , die einmal beim Rendern der ersten Seite aufgerufen werden und dann gespeicherte props an die n├Ąchsten gerenderten Seiten weitergeben. Aber ich ├╝berlege noch, ob es ├╝berhaupt ein richtiges Konzept ist.

@pkral78 , Es k├Ânnte daran liegen, dass ich in den meisten SSG-Sites, die ich mir vorstelle, mit Next implementiert zu haben, ein "gemeinsames St├╝ck" (Kopfzeile, Fu├čzeile, Seitenleisten ...) haben m├Âchte. Und warum nicht einfach die Abfrage nach diesem gemeinsamen Teil in der _app machen, wenn Sie es brauchen, und es auf untergeordneten Seiten verf├╝gbar machen, ohne auf jeder Seite manuell arbeiten zu m├╝ssen.

Meine einzige Sorge ist, dass, wenn Sie es in _app.js , wir je nach Seite nicht mehr als ein "gemeinsames St├╝ck" haben k├Ânnen. Mit der Idee, ein Prototyp zu erstellen, wollte ich es im Layout haben, weil es uns erm├Âglicht, mehrere Layouts zu haben, abh├Ąngig von der Art der Seite, die Sie rendern m├Âchten. "Deshalb habe ich withSSGLayout angerufen mein HOC, weil ich plante, nicht nur SSG-Seiten, sondern auch SSR- und vollst├Ąndig Client-basierte Seiten oder sogar mehr als ein SSGLayout zu haben.Ich k├Ânnte dies tun, wenn Layouts auch f├╝r eine ├╝bergeordnete getStaticProps Methode verantwortlich sein k├Ânnte.

Wie auch immer, SSG in Next wird es zum Werkzeug f├╝r jede Art von Website machen ­čÖî

@Janpot bez├╝glich https://github.com/zeit/next.js/issues/9524#issuecomment -580012327

Kann dringend empfehlen, niemals dynamische Pfade in import() . Es b├╝ndelt jede m├Âgliche Datei unter dem Pfad zum JS-Bundle und reduziert dabei die Build-Leistung erheblich.

@timneutkens Klar, macht Sinn. Soll getStaticProps nur externe APIs abfragen, nicht das Dateisystem?

@Janpot Sie k├Ânnen aus dem Dateisystem lesen, oft werden Sie jedoch eine externe API abfragen.

@timneutkens Ok, dann besser @mdx-js/runtime , anstatt sich auf @next/mdx denke ich.

import ReactDOMServer from "react-dom/server";
import { promises as fs } from "fs";
import MDX from "@mdx-js/runtime";

export async function unstable_getStaticProps({ params: { slug } }) {
  const mdxContent = await fs.readFile(`./content/${slug.join('/')}.mdx`, {
    encoding: "utf-8"
  });
  const content = ReactDOMServer.renderToStaticMarkup(<MDX>{mdxContent}</MDX>);
  return {
    props: { title: slug.join(" "), content }
  };
}

export default function Page({ title, content }) {
  return (
    <div>
      <h1>{title}</h1>
      <div dangerouslySetInnerHTML={{ __html: content }} />
    </div>
  );
}

@Janpot ja! Sie k├Ânnten auch einfachen Markdown verwenden, das machen wir f├╝r nextjs.org/docs.

In Bezug auf https://github.com/zeit/next.js/issues/9524#issuecomment -580207073 ist es genau so, wie ich Next mit SSR derzeit verwende. Ich habe eine GraphQL-Anforderung, die auf Layoutebene ausgef├╝hrt wird und deren Inhalt mit den allgemeinen Komponenten der App (Navbar, Fu├čzeile und die dynamischen untergeordneten Elemente) geteilt wird. Dann stellen die dynamischen untergeordneten Elemente normalerweise eine weitere GraphQL-Anfrage f├╝r seitenspezifischen Inhalt.

Daher scheint es wichtig zu sein, dies wiederzuverwenden, und ich m├Âchte nicht auf jeder Seite Code duplizieren m├╝ssen, um diese gemeinsamen Daten abzurufen.

Hey!
ich bin ganz neu hier. Ich habe gerade angefangen, an der Migration der App zu NextJS zu arbeiten.

Es gibt einen grundlegenden Anwendungsfall, der von dieser Funktion stark profitieren w├╝rde ÔÇô mehrere Sprachversionen. Die Web-App, an der ich arbeite, hat ungef├Ąhr 16 Sprachversionen mit 100.000+ Seitenaufrufen pro Tag und die M├Âglichkeit, zum Beispiel eine Landingpage statisch zu generieren, w├Ąre fantastisch, aber das Problem ist das Routing.

Mit serverseitigem Rendering kann ich Anforderungsheader oder Cookies lesen und die richtige Sprachversion rendern, aber ist ohne sie die einzige L├Âsung, um Pfade f├╝r jede Version wie /en, /de, /fr und auf "/" zu erstellen, um NextJS einfach umzuleiten?

Nachdem ich etwas ├╝ber ReactDOMServer.renderToStaticMarkup gelernt hatte, f├╝gte ich es meiner unstable_getStaticProps Funktion hinzu und stellte fest, dass es meinen (mobilen) PageSpeed-Score von 96 auf 100 verbesserte, dank der drastischen Verbesserung der Zeit bis zur Interaktivit├Ąt und des maximalen Potenzials der ersten Eingabeverz├Âgerung .

Ich kann die Seite ohne JavaScript besuchen und sie l├Ądt gut. Es scheint also, dass React trotz der Verwendung von SSG am Seitenladen arbeitet.

Vielleicht ist dies ein Mangel an meinem Verst├Ąndnis von React, aber ich w├╝rde erwarten, dass die Leistung mit und ohne JavaScript gleich ist, und ich w├╝rde nicht erwarten, dass das Vorrendern der Komponenten hilft (ich dachte, das macht SSG).

Ist das Erwartete ein Fehler oder mache ich etwas falsch?

Pre-Commit: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2F5e310826bcf5030008a91209--josephduffynextjs.netlify.com%2Fposts%2Fgathered-1-0-1&tab=mobile
Commit: https://github.com/JosephDuffy/josephduffy.co.uk/pull/54/commits/d23898b874e5088ebcfabf577ee396b476ed97e4
Post-Commit: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2F5e3371beda1b8f0009368ef9--josephduffynextjs.netlify.com%2Fposts%2Fgathered-1-0-1&tab=mobile

@JosephDuffy

es scheint also, dass React trotz der Verwendung von SSG beim Laden der Seite arbeitet.

Es hydratisiert das DOM. Grunds├Ątzlich:

  1. Ihr Browser l├Ądt das SSR-HTML in das Browser-DOM
  2. React baut das gesamte virtuelle DOM neu auf
  3. React durchl├Ąuft diese DOMs und synchronisiert sie (Hydratation)

Wenn Ihr Inhalt wirklich statisch ist, also keine Nebenwirkungen oder Ereignishandler, dann sind Schritt 2. und 3. irgendwie unn├Âtig. Mit Ihrer Methode reduzieren Sie Ihren Komponentenbaum im Grunde auf 1 Komponente mit 1 Attribut, was f├╝r React sehr schnell gerendert und hydratisiert wird. (+ dangerouslySetInnerHTM wird w├Ąhrend der Fl├╝ssigkeitszufuhr ignoriert)

<div dangerouslySetInnerHTML={{ __html: props.htmlContent }} />

Beachten Sie, dass Ereignishandler und Nebenwirkungen mit dieser Methode nicht funktionieren.

Bearbeiten:

Eine Idee k├Ânnte darin bestehen, den Standardexport auf einer Seite wegzulassen, wenn getStaticProps statisches HTML zur├╝ckgibt. dh

export async function unstable_getStaticProps() {
  // ...
  return {
    props: { dangerouslySetInnerHTML: { __html: '<div>static content</div>' } }
  };
}

Da clientseitig nichts gerendert werden muss, kann next.js seine Laufzeit von der Seite ausschlie├čen und einfach den HTML-Code einf├╝gen, der getStaticProps zur├╝ckgegeben hat. Und es w├╝rde genauso funktionieren, als ob dangerouslySetInnerHTML auf dem next.js-Root-Knoten verwendet w├╝rde.
Ich denke, es w├Ąre einfacher zu implementieren als eine teilweise Fl├╝ssigkeitszufuhr, wenn auch weniger stark. Die Wiederverwendung der Terminologie von React selbst k├Ânnte die Verwirrung ├╝ber die Funktionsweise dieser Funktion verringern.

Ich versuche, eine statische Site zu Next.js zu migrieren, und m├Âchte alle .html-Varianten von Blog-Posts auf Versionen umleiten, die nicht auf .html enden. Es scheint, als w├╝rde getStaticProps derzeit keinen Kontext abrufen, sodass ich keine ├ťberpr├╝fung auf eingehenden Slug und keine Umleitung durchf├╝hren kann. Es w├Ąre hilfreich, wenn getStaticProps den vollst├Ąndigen Kontext h├Ątte, damit ich einige bedingte Dinge damit tun k├Ânnte.

@nodabladam es h├Ârt sich so an, als ob Sie nach dem Custom Routes RFC suchen: #9081.

Dieser RFC w├╝rde es Ihnen erm├Âglichen, etwas wie folgt zu definieren:

// next.config.js
module.exports = {
  redirects() {
    return [
      // Redirect from the old HTML version of a blog post
      {
        source: "/blog/:post.html",
        destination: "/blog/:post",
        permanent: true
      }
    ];
  }
};

Sie k├Ânnen diese Funktion derzeit unter der Taste experimental ausprobieren:

// next.config.js
module.exports = {
  experimental: {
    redirects() {
      // ...
    }
  }
};

Ich habe getStaticProps und getStaticPathNames in einem meiner Projekte (ca. 8K Seiten) implementiert.

Ausgabedateien werden jedoch auf die 10┬áKB-Grenze von Dateien pro Bereitstellung angerechnet. Bei 8K-Seiten erhalten Sie 16K Ausgabedateien, da jede Seite auch eine JSON-Datei erh├Ąlt.

Ist eine Erh├Âhung dieser Grenze geplant? Oder kann ich diese Grenze umgehen?

Ich habe das gleiche Problem.
Ich verstehe, dass sie dieses Limit anheben wollen, aber ich wei├č nicht, wann es eingef├╝hrt wird.

Also verwende ich getStaticProps auf allen Seiten und getStaticPaths nur auf einigen von ihnen und es funktioniert (meine Produktseite generiert 70% der Gesamtseiten, also habe ich keine getStaticPaths eingef├╝gt). Ich bleibe unter dem Limit, aber es ist nicht perfekt, der erste Ladevorgang ist ziemlich lang und es ist schwierig, 404-Fehler zu verarbeiten.

Ich habe das gleiche Problem.
Ich verstehe, dass sie dieses Limit anheben wollen, aber ich wei├č nicht, wann es eingef├╝hrt wird.

Also verwende ich getStaticProps auf allen Seiten und getStaticPaths nur auf einigen von ihnen und es funktioniert (meine Produktseite generiert 70% der Gesamtseiten, also habe ich keine getStaticPaths eingef├╝gt). Ich bleibe unter dem Limit, aber es ist nicht perfekt, der erste Ladevorgang ist ziemlich lang und es ist schwierig, 404-Fehler zu verarbeiten.

Ich hoffe, dass sie das Limit bald anheben, aber ich hoffe, es werden nicht 20K sein.. das wird mir auf lange Sicht nicht reichen.

Ich m├Âchte die ersten Ladezeiten mit getStaticPaths vermeiden. Eventuell muss ich neben Zeit Now nach anderen L├Âsungen suchen

Next.js macht auch automatisch einen API-Endpunkt verf├╝gbar, der das Ergebnis des Aufrufs von getServerProps zur├╝ckgibt. [...] Next.js ruft diesen exponierten API-Endpunkt ab, um die JSON-Daten abzurufen, die in die Requisiten umgewandelt werden, die zum Rendern der Seite clientseitig erforderlich sind.

Next.js ruft Daten von diesem Endpunkt ab, bevor die eigentliche Routen├Ąnderung vorgenommen und die Seitenkomponente gerendert wird (zumindest standardm├Ą├čig nicht anders). So kann der Benutzer eine extrem bissige Site erleben, weil bestimmte Seiten statisch generiert werden, aber wenn er auf einen Link zu einer SSR-Seite klickt, "h├Ąngt" die Site pl├Âtzlich, kurz bevor sich die Route ├Ąndert.

Gibt es eine empfohlene M├Âglichkeit, die Komponente _first_ zu laden, damit sie mit Ladeindikatoren, animierten Platzhaltern usw. gef├╝llt werden kann? (Anstatt sie der aktuellen Seite hinzuzuf├╝gen.) Wenn nicht, k├Ânnten sie f├╝r die neu vorgeschlagenen Funktionen relevant sein? Ich habe es mit einer Kombination aus getInitialProps und Hooks innerhalb der Render-Methode erreicht, aber es f├╝hlt sich chaotisch an.

Ich w├╝rde denken, dass dieses UX-Muster (sofortiger Seitenwechsel) von vielen (den meisten?) bevorzugt wird, aber ich habe noch keine Beispiele daf├╝r mit Next.js gesehen. Ich benutze das Framework erst seit ein paar Tagen, also korrigiert mich bitte, wenn ich falsch liege.

Bin echt gespannt auf die neuen Features! Danke f├╝r deine Arbeit.

@nicoqh , Ihre Bedenken bez├╝glich Seiten├╝berg├Ąngen sind nicht spezifisch f├╝r SSG, da das Aufh├Ąngen mit dem aktuellen getInitialProps auftritt. Ich verwende nprogress , um zumindest einen Fortschrittsbalken oben anzuzeigen, w├Ąhrend die n├Ąchste Seite geladen wird, aber ich sehe auch dieses Beispiel f├╝r legitime Seiten├╝berg├Ąnge, die n├Ąher an das klingen, was Sie beschreiben. Ich habe es nicht selbst ausprobiert, aber ich hoffe, es hilft bei dem, was Sie brauchen:
https://github.com/zeit/next.js/tree/canary/examples/with-next-page-transitions

Es sieht so aus, als w├╝rde die zur├╝ckgegebene JSON-Datei /_next/data/BUILD_ID/<file>.json AssetPrefix nicht ber├╝cksichtigen. Dies f├╝hrt dazu, dass die Datei f├╝r mich in meiner Produktionsumgebung zu 404 wird, da ich ein Setup habe, das erwartet, dass alles _next ein Asset ist, das ├╝ber CDN l├Ąuft. Diese JSON-Dateien sollten letztendlich ├╝ber das AssetPrefix (CDN) weitergeleitet werden, oder?

Ich habe das gleiche Problem.
Ich verstehe, dass sie dieses Limit anheben wollen, aber ich wei├č nicht, wann es eingef├╝hrt wird.
Also verwende ich getStaticProps auf allen Seiten und getStaticPaths nur auf einigen von ihnen und es funktioniert (meine Produktseite generiert 70% der Gesamtseiten, also habe ich keine getStaticPaths eingef├╝gt). Ich bleibe unter dem Limit, aber es ist nicht perfekt, der erste Ladevorgang ist ziemlich lang und es ist schwierig, 404-Fehler zu verarbeiten.

Ich hoffe, dass sie das Limit bald anheben, aber ich hoffe, es werden nicht 20K sein.. das wird mir auf lange Sicht nicht reichen.

Ich m├Âchte die ersten Ladezeiten mit getStaticPaths vermeiden. Eventuell muss ich neben Zeit Now nach anderen L├Âsungen suchen

@erhankaradeniz und @ziltosh sollten wir das generell sehr, sehr bald m├Âchten , k├Ânnen Sie mich direkt [email protected] und sie werden sich um Sie

Ich habe das gleiche Problem.
Ich verstehe, dass sie dieses Limit anheben wollen, aber ich wei├č nicht, wann es eingef├╝hrt wird.
Also verwende ich getStaticProps auf allen Seiten und getStaticPaths nur auf einigen von ihnen und es funktioniert (meine Produktseite generiert 70% der Gesamtseiten, also habe ich keine getStaticPaths eingef├╝gt). Ich bleibe unter dem Limit, aber es ist nicht perfekt, der erste Ladevorgang ist ziemlich lang und es ist schwierig, 404-Fehler zu verarbeiten.

Ich hoffe, dass sie das Limit bald anheben, aber ich hoffe, es werden nicht 20K sein.. das wird mir auf lange Sicht nicht reichen.
Ich m├Âchte die ersten Ladezeiten mit getStaticPaths vermeiden. Eventuell muss ich neben Zeit Now nach anderen L├Âsungen suchen

@erhankaradeniz und @Ziltosh sollten wir das generell sehr, sehr bald m├Âchten , k├Ânnen Sie mich direkt [email protected] und sie werden sich um Sie

Danke @kvangundy
Ich habe dich bez├╝glich dieses Problems auf Twitter kontaktiert ;-)

@erhankaradeniz K├Ânnen Sie stattdessen eine E-Mail an [email protected] senden ? So landet es korrekt in unserem System.

@flintinatux , danke f├╝r den Tipp. Ich habe das Beispiel gesehen und es hilft nicht beim Laden der Seitenkomponente vor dem Laden der Daten, daher sind Platzhalter auf der Seite usw. nicht m├Âglich. Aber ein interessantes Beispiel, danke!

Ich denke, es wird in dieser Ausgabe nicht behandelt, was bedeutet, dass es nicht zum Thema geh├Ârt, also werde ich woanders suchen, um es zu diskutieren :)

Ich denke, der Ansatz, getInitialProps in getStaticProps & getServerProps aufzuteilen, ist viel sauberer! Ich habe eine Frage dazu, wie sich dies auf unseren Anwendungsfall auswirkt:
Wir m├Âchten zwei separate Builds erstellen: eine statische Version f├╝r unsere Produktseite und eine Version mit SSR f├╝r eine Bearbeitungsumgebung.

Ich dachte, ich k├Ânnte getStaticProps vs getServerProps abh├Ąngig vom Build bedingt als statische Methoden anh├Ąngen (├Ąhnlich wie https://github.com/zeit/next.js/issues/9524#issuecomment- 558617056), aber ich bin mir nicht sicher, ob dies m├Âglich ist, sie so wie sie sind bedingt zu exportieren. Irgendwelche Ideen, ob dies je nach Build m├Âglich sein wird, um dynamisch / statisch zu unterst├╝tzen?

In Bezug auf:

RFC wird sp├Ąter aktualisiert, um ├änderungen widerzuspiegeln, und wird immer noch auf die reale Verwendung in unseren Apps wiederholt.

Ich frage mich, ob es eine M├Âglichkeit gibt, eine Art Wildcard-Route zu verwenden, um Routen abzufangen, die zum Zeitpunkt des Builds unbekannt sind. Es ist gro├čartig, dass ich statische Seiten beispielsweise aus CMS-Daten rendern kann, aber was ist, wenn jemand ein neues Element hinzuf├╝gt? Daf├╝r habe ich keine statische Seite. Dieses Thema kratzt mich schon lange am Kopf.

Ich habe eine dynamische Route eingerichtet, um statische Seiten _pages/[slug].js_ zu rendern. _getStaticPaths_ ruft alle Seiten ab, die ich statisch rendern m├Âchte. Ich habe _getStaticProps_, um die Daten abzufragen und an die Renderfunktion zu ├╝bergeben. Alle in _getStaticPaths_ angegebenen Seiten werden beim Build als HTML-Dateien in _.next/server/static_ gerendert. Gro├č!

Jetzt f├╝hre ich npm run start und diese Seiten so aus, wie sie sollten. Das Anfordern einer fehlenden URL (wie _/foo_) generiert jedoch neue statische HTML- und JSON-Dateien in _.next/server/static_. Das ist nicht gut. Wie kann ich den Server dazu bringen, alle anderen URLs zu _pages/_error.js_ umzuleiten?

https://github.com/zeit/next.js/issues/9524#issuecomment -582777067

Auch das decken wir ab.

Jetzt f├╝hre ich npm run start und diese Seiten so aus, wie sie sollten. Das Anfordern einer fehlenden URL (wie /foo) generiert jedoch neue statische HTML- und JSON-Dateien in .next/server/static. Das ist nicht gut. Wie kann ich den Server dazu bringen, alle anderen URLs auf pages/_error.js umzuleiten?

Dies ist noch w├Ąhrend des Fluges und kein unerwartetes Verhalten im Moment.

Nochmals eine Erinnerung daran, dass Sie eine experimentelle Funktion verwenden und das Verhalten sich jederzeit ├Ąndern kann. Die Dinge werden sich ├Ąndern und m├Âglicherweise zwischen allen Versionen unterbrechen, w├Ąhrend Sie dies verwenden, wenn es nicht stabil ist.

@timneutkens Danke! Ich verstehe die Instabilit├Ąt. Hast du eine Idee, wie man das handhabt? Ging den Code durch und stellte fest, dass das Ausgeben eines Fehlers in _unstable_getStaticProps_ die Fehlerseite rendert. Dies k├Ânnte ein sch├Âner Weg sein. Ich br├Ąuchte nur eine M├Âglichkeit, den Fehler unver├Ąndert an _pages/_error.js_ weiterzuleiten. Ich w├╝rde es gerne 404 senden. Jetzt geht es als 500.

Ich habe dies schon einige Male in anderen Threads gepostet, aber "going to _error" ist ein unerwartetes Verhalten, ab sofort sollte Ihre Seite einen 404-Zustand darstellen. Einfach gesagt if(!data.something) { return <My404Component /> } , und dann sollte My404Component noindex Meta-Tags setzen.

Wirklich? Die Dokumentation weist eindeutig darauf hin, _pages/_error.js_ f├╝r 404s zu verwenden.

Siehe: https://nextjs.org/docs/advanced-features/custom-error-page

@jiv-e das ist f├╝r 404s verursacht durch:

  • Seite nicht gefunden
  • Datei nicht gefunden

Wenn Sie dynamische Routen haben, m├╝ssen Sie den Fall "404" wie gesagt behandeln, z. B. wie https://nextjs.org/docs/advanced-features/custom-error-page#reusing -the-built-in-error- Seite

Ich habs! Vielen Dank!

Ich m├Âchte getStaticProps , um ├ťbersetzungs- / Sprachschl├╝ssel zur Build-Zeit abzurufen, da sie sich h├Âchstwahrscheinlich 1-2 Mal im Monat oder sogar pro Jahr ├Ąndern werden. Sie ben├Âtigen sie auch nicht als JSON / Props innerhalb des DOM. Das Problem ist, dass ich die Schl├╝ssel nicht im Baum an die Komponente weitergeben m├Âchte, in der ich sie tats├Ąchlich verwende. Welche Ans├Ątze eignen sich f├╝r meinen Anwendungsfall?

useTranslation() Hook (oder HOC) mit Kontext?

Es w├Ąre sch├Ân, wenn AppTree Teil des NextGetStaticProps-Kontexts w├Ąre ( getStaticProps({ AppTree }) ). Andernfalls ist es nicht m├Âglich, Dinge wie apollos getDataFromTree auf ssg auszuf├╝hren.

An dieser Stelle planen wir nicht, AppTree-Traversal in getStaticProps zuzulassen, da dies wirklich schlecht f├╝r die Leistung ist (konsistentes Feedback von Unternehmen). Wenn Sie getStaticProps zu einer Seite hinzuf├╝gen, durchl├Ąuft es immer noch getInitialProps von _app, um eine inkrementelle ├ťbernahme zu erm├Âglichen, sodass es immer noch mit Apollo funktionieren w├╝rde.

Es w├Ąre sch├Ân, wenn wir gleichzeitig amp: 'hybrid' und SSG- Funktionalit├Ąt haben k├Ânnten.
Dies k├Ânnte erreicht werden, indem zwei Dateien f├╝r eine Seite wie diese erstellt werden, dh:

  • (SSG) index.html
  • (AMP) index.amp.html

Dies w├╝rde es Proxys erm├Âglichen, basierend auf dem Abfrageparameter ?amp=1 in ein Amp-Dokument aufzul├Âsen.

Es w├Ąre sch├Ân, wenn wir gleichzeitig amp: 'hybrid' und SSG- Funktionalit├Ąt haben k├Ânnten.
Dies k├Ânnte erreicht werden, indem zwei Dateien f├╝r eine Seite wie diese erstellt werden, dh:

  • (SSG) index.html
  • (AMP) index.amp.html

Dies w├╝rde es Proxys erm├Âglichen, basierend auf dem Abfrageparameter ?amp=1 in ein Amp-Dokument aufzul├Âsen.

Genau @Dacturne , das ist der einzige Nachteil, den ich sehe, SSG bereits in Projekten zu verwenden, wie ich vor einiger Zeit in diesem Thread kommentiert habe.

­čĄ×

@jansedlon Ich habe einen Blogbeitrag erstellt, der Ihre Frage beantwortet:

Ich frage mich, ob es eine M├Âglichkeit gibt, eine Art Wildcard-Route zu verwenden, um Routen abzufangen, die zum Zeitpunkt des Builds unbekannt sind. Es ist gro├čartig, dass ich statische Seiten beispielsweise aus CMS-Daten rendern kann, aber was ist, wenn jemand ein neues Element hinzuf├╝gt? Daf├╝r habe ich keine statische Seite. Dieses Thema kratzt mich schon lange am Kopf.

https://paqmind.com/en/blog/ssr-ist-nicht-die-zukunft

(nicht hier posten, weil zu gro├č)

@ivan-kleshnin Ich habe mal kurz nachgeschaut und es sieht super spannend aus! Du h├Ąttest mir vielleicht Hunderte von Stunden erspart! Vielen Dank, ich schaue heute noch genauer darauf zur├╝ck.

https://github.com/zeit/next.js/issues/9524#issuecomment -582799948

@jansedlon wie bereits erw├Ąhnt, arbeiten wir

@timneutkens Lieben Sie die

Wir haben die neuen getStaticProps / getStaticPaths APIs bei unserer Migration von tinacms.org von Gatsby zu Next.js verwendet, und bisher war es gro├čartig!

Ein Stolperstein, den wir hatten, war die Generierung eines RSS-Feeds. Idealerweise m├Âchten wir es statisch generieren, da der Inhalt, auf den es verweist, statisch generiert wird. Ich sehe derzeit keine M├Âglichkeit, dies zu tun, also handhaben wir es stattdessen nur serverseitig, indem wir den Inhalt abfragen und XML in die Antwort schreiben.

Gab es Diskussionen ├╝ber die Unterst├╝tzung der statischen Generierung f├╝r Nicht-HTML-Inhaltstypen?

FYI Wir haben angefangen, getStaticProps auf zeit zu verwenden und Releases mit dem --prod Flag zu verwenden und der Cache wurde f├╝r die Json-Dateien auf neuen Releases nicht geleert. Die Umstellung unserer Produktionsversion auf die Verwendung der Alias-Funktion hat funktioniert und der Cache wurde gel├Âscht.

Wir haben die neuen getStaticProps / getStaticPaths APIs bei unserer Migration von tinacms.org von Gatsby zu Next.js verwendet, und bisher war es gro├čartig!

Ein Stolperstein, den wir hatten, war die Generierung eines RSS-Feeds. Idealerweise m├Âchten wir es statisch generieren, da der Inhalt, auf den es verweist, statisch generiert wird. Ich sehe derzeit keine M├Âglichkeit, dies zu tun, also handhaben wir es stattdessen nur serverseitig, indem wir den Inhalt abfragen und XML in die Antwort schreiben.

Gab es Diskussionen ├╝ber die Unterst├╝tzung der statischen Generierung f├╝r Nicht-HTML-Inhaltstypen?

Ich dachte es f├╝r mich und habe es gerade herausgefunden. Hier meine Skripte:

"scripts": {
    "dev": " next",
    "build": "yarn sitemap && next build",
    "start": "next start",
    "sitemap": "ts-node --project ./cli/tsconfig.spec.json ./cli/generateSitemap.ts"
  },

Bevor next build yarn sitemap , erzeugt dies eine statische Sitemap. Sie k├Ânnen dieselbe Technik verwenden, um beispielsweise alle Daten in json zwischenzuspeichern, die Sie in getStaticProps ben├Âtigen, und Sie k├Ânnen sie auf mehreren Seiten wiederverwenden.

RFC aktualisiert, Verhalten von getStaticPaths etwas ge├Ąndert (Sie m├╝ssen jetzt einen paths Schl├╝ssel zur├╝ckgeben, dies spiegelt getStaticProps wider, wo props m├╝ssen ├änderung ist noch nicht in Next.js gelandet.

Au├čerdem wurde eine Erkl├Ąrung f├╝r das Verhalten von fallback hinzugef├╝gt (bei Bedarf Hintergrundgenerierung von Seiten, die zur Erstellungszeit nicht exportiert wurden).

F├╝hrte ein weiteres Update des RFC durch, f├╝gte eine Erkl├Ąrung f├╝r ├änderungen in der Clientnavigation in Bezug auf einen Loading Zustand hinzu.

Wir m├Âchten m├Âglicherweise eine M├Âglichkeit hinzuf├╝gen, damit Benutzer wissen, ob der Ladezustand ├╝ber einen React-Hook gerendert wird ­čĄö

Tolles Zeug! Ich habe mich nur gefragt, ob es f├╝r statisch generierte Seiten eine M├Âglichkeit geben w├╝rde, Daten zwischen mehreren Routen mithilfe einer einzigen JSON-Datei auszutauschen (wie Code-Splitting, aber f├╝r Daten)?

Ich bin auf den neuesten canary Build gesto├čen und wurde sofort vom neuen Loading Zustand Loading Zust├Ąnde aufzunehmen.

Ich verstehe den Wunsch nach einem schnelleren TTFB, und das k├Ânnte in Zukunft ein Nice-to-have f├╝r meine App sein. Aber w├Ąre es m├Âglich, den Zustand Loading einer Opt-in- oder Opt-out- Funktion zu machen, ├Ąhnlich wie fallback: false f├╝r getStaticPaths ? Vielleicht ein export const enableLoadingState = false auf der Seite oder eine Site-weit im next.config.js .

https://github.com/zeit/next.js/issues/9524#issuecomment -583962425

Nochmals eine Erinnerung daran, dass Sie eine experimentelle Funktion verwenden und dass wir derzeit mit dem Verhalten experimentieren.

Ich habe meine (experimentelle) SSG-Website auf Now bereitgestellt (mit einem Standard-Setup). Es funktioniert gut, aber ich sehe 404-Fehler im Netzwerk-Tab, wenn ich die Site durchsuche. Alle 404-Fehler zeigen auf _next/static/pages/[slug].js .

Ist dies erwartetes Verhalten, w├Ąhrend es experimentell ist? Oder sollte ich einige Einstellungen ├Ąndern?

@joostmeijles es h├Ârt sich so an, als ob Sie nicht die richtigen href und as f├╝r next/link angeben . F├╝r dynamische Seiten muss href die Seite href='/[slug]' und as muss die URL as='/slug-1'

Ich erhalte w├Ąhrend des Builds 3 Protokolle in der Konsole, ist das ein Fehler?

// Page is showing three logs despite static path only having 2 entries and output generating only two files as intended
export default function Page(props){
    console.log("Page - should only show twice", props); 
    return <><h1>Page</h1></>
}

export async function unstable_getStaticProps(props) {
    console.log("unstable_getStaticProps - should only show twice", props);
    return {
      props
    };

}

export async function unstable_getStaticPaths() {
    console.log("show once")
    return {
        paths: [
        { params: { year: "1901" } },
        { params: { year: "1902" } },
        ]
    }
}

Nein, das wird gem├Ą├č fallback im RFC erwartet.

Nein, das wird gem├Ą├č fallback im RFC erwartet.

export async function unstable_getStaticPaths() {
    console.log("show once")
    return {
        fallback: false,
        paths: [
        // This renders /blog/hello-world to HTML at build time
        { params: { year: "1901" } },
        { params: { year: "1902" } },
        ]
    }
}

Ich habe versucht, mich abzumelden, aber ich erhalte diesen Fehler.

Fehler: Zus├Ątzliche Schl├╝ssel, die von unstable_getStaticPaths in /[Jahr] zur├╝ckgegeben wurden (Fallback) Das einzige zul├Ąssige Feld ist derzeit paths

Nochmals eine Erinnerung daran, dass Sie eine experimentelle Funktion verwenden und dass wir derzeit mit dem Verhalten experimentieren und nicht alles implementiert ist.

Wird diese Funktion getStaticProps nur f├╝r Seiten verf├╝gbar sein?
W├Ąre auch f├╝r App/Dokument interessant, zum Beispiel eine globale Konfiguration f├╝r die Anwendung abzurufen?

Ich habe dies "erfolgreich" implementiert und bin mit den bisherigen Ergebnissen zufrieden. Aber ich frage mich, ob es eine M├Âglichkeit gibt, nachfolgende Builds "schneller" zu machen? ├ťberpr├╝fen Sie zum Beispiel, ob sich SSG-generierte Seiten nicht ge├Ąndert haben und generieren Sie diese nicht neu? (Wahrscheinlich Wunschdenken von mir)

@timneutkens Haben Sie Pl├Ąne, einen sitemap.xml-Generator f├╝r SSG-Seiten hinzuzuf├╝gen? Ich spreche nicht einmal von dynamischen Routen, da es meiner Meinung nach einfacher ist, sie vorerst nur f├╝r statische Seiten zu implementieren.

@timneutkens Haben Sie Pl├Ąne, einen sitemap.xml-Generator f├╝r SSG-Seiten hinzuzuf├╝gen? Ich spreche nicht einmal von dynamischen Routen, da es meiner Meinung nach einfacher ist, sie vorerst nur f├╝r statische Seiten zu implementieren.

Ja, das w├Ąre eine tolle Option. Generiere derzeit selbst einen mit SSR. (aber das Laden der sitemap.xml-Datei dauert lange)

https://github.com/zeit/next.js/issues/9524#issuecomment -585293270

Anfangs nur f├╝r Seiten, da nach der Landung andere Arbeiten auf getStaticProps wirken.

https://github.com/zeit/next.js/issues/9524#issuecomment -586957539

Ja, aber nicht als Teil dieses RFC. Es wird ein Follow-up geben, nachdem dies gelandet ist.

@timneutkens Ich denke, die Implementierung f├╝r SSG-Seiten ist einfach, weil Sie jedes Mal, wenn Next eine statische Seite erstellt, einen URI in ein Array schieben und dann, wenn es endet, einfach das Array jedem XML-Tag zuordnen, verbinden und in der Mitte einf├╝gen eines <sitemapindex> Tags. getStaticProps k├Ânnte einen anderen Schl├╝ssel im R├╝ckgabeobjekt namens excludeFromSitemap so dass standardm├Ą├čig alle Seiten in sitemap.xml jedoch mit einer Option zum Opt-out.

Wenn dies der Fall w├Ąre, h├Ątten die Entwickler eine genaue Kontrolle dar├╝ber, welche statische Seite in die Sitemap aufgenommen wird (zum Beispiel: wenn die Funktion getStaticPaths Seite [foo] Pfade mit foo params 'abc' und 'xyz' aber nur die 'abc' Datei sollte in der Sitemap sein, der Entwickler k├Ânnte excludeFromSitemap auf true wenn der Parameter ==='xyz' in getStaticProps .

F├╝r SSR und statische Seiten k├Ânnte es auch m├Âglich sein, eine Konstante (zB export const excludeFromSitemap = true; ) aus der Seitendatei zu exportieren, genau wie getServerProps , getStaticPaths und getStaticProps werden exportiert.

Wenn auf SSG-Seiten eine exportierte excludeFromSitemap Konstante (Seitenstandard) vorhanden ist und sich dieser Schl├╝ssel auch in dem von der getStaticProps Funktion zur├╝ckgegebenen Objekt befindet (pfadspezifisch), sollte der exportierte Wert als Standardwert fungieren Wert f├╝r alle Pfade auf dieser Seite und das pfadspezifische excludeFromSitemap , wenn es im getStaticProps Objekt vorhanden ist, sollte den Standardwert der Seite ├╝berschreiben (so k├Ânnte eine Seite export cosnt excludeFromSitemap = true und f├╝gen Sie dann den Schl├╝ssel excludeFromSitemap zu dem von getStaticProps Objekt mit dem Wert false , um alle Pfade mit Ausnahme dieses bestimmten von der Sitemap auszuschlie├čen).

Der Code zum Anh├Ąngen an das Array w├Ąre ungef├Ąhr so ÔÇőÔÇő(ich habe die Wahrheitstabelle berechnet und den minimalen booleschen Ausdruck mit einer Karnaugh-Map erhalten):

//...somewhere else
const validExcludeFromSitemapTypes = ['boolean','undefined'];

//...for each path
const isSSG = !!getStaticPropsReturnedObj && typeof getStaticPropsReturnedObj === "object";
if(
    validExcludeFromSitemapTypes.indexOf(typeof pageExports.excludeFromSitemap)<0 ||
    (isSSG && validExcludeFromSitemapTypes.indexOf(typeof getStaticPropsReturnedObj.excludeFromSitemap)<0)
) {
    throw new Error("'excludeFromSitemap' can either be ommited (undefined) or be a boolean");
}
const defaultExcludedValue = !!pageExports.excludeFromSitemap;
const hasSpecificExcluded = isSSG && typeof getStaticPropsReturnedObj.excludeFromSitemap !== "undefined";
const specificExcludedValue =  isSSG ? !!getStaticPropsReturnedObj.excludeFromSitemap : false;

if(!specificExcludedValue && (!defaultExcludedValue || hasSpecificExcluded))
    sitemapURIs.push(correctlyEncodedURI);

Das Umwandeln des Arrays in die Sitemap w├Ąre so einfach (vorausgesetzt, die URIs im Array sind bereits codiert und nach !excludeFromSitemap gefiltert):

function createSitemap(sitemapURIs: string[]): string {
    return `<sitemapindex>${sitemapURIs.map(u=>`<sitemap><loc>u/loc></sitemap>`).join('')}</sitemapindex>`;
}

Ich denke, dieses Feature w├╝rde sich gut in Next.JS einf├╝gen, da ein Teil seiner Mission darin besteht, den Benutzern die 100-SEO-Punktzahl zu geben, und ein sitemap.xml w├╝rde sehr helfen! ( robots.txt k├Ânnte m├Âglicherweise auch generiert werden, indem ein else zur Bedingung hinzugef├╝gt wird, die die Pfade zum Sitemap-Array hinzuf├╝gt, um diesen Pfad an ein anderes Array von unzul├Ąssigen Seiten anzuh├Ąngen)

In der aktuellen Release-Version k├Ânnen Sie bei Verwendung der unstable_getStaticPaths zusammen mit der unstable_getStaticProps Funktion keine API-Aufrufe an Funktionen durchf├╝hren, die in /api/ .
Da der Server nicht l├Ąuft, ist es unm├Âglich, auf diese Weise die entsprechenden Anfragen zu stellen und die statischen Requisiten zu generieren.
Sie m├╝ssen entweder die Pfadfunktionen nicht bereitstellen (was dieses SSR im Grunde mit einem Cache ausmacht, was immer noch sch├Ân ist!) oder auf SSR anstelle von SSG setzen.

Vielleicht w├Ąre dies eine gute Erg├Ąnzung f├╝r diese Funktion? Ich bin mir nicht sicher, was der beste Weg hier w├Ąre, ich habe woanders einen Vorschlag gelesen, der vorschlug, die http-Anfrage mit SSR und /api Routen zu verk├╝rzen, dies w├Ąre auch hier praktisch.

Aber all dies w├╝rde nat├╝rlich bedeuten, dass Code in der Build-Umgebung ausgef├╝hrt wird, der Aufrufe zu anderen Diensten / DB-Aufrufen oder ├Ąhnlichem machen w├╝rde. Dies sollte klargestellt werden, wenn dies implementiert wird, aber es w├Ąre eine coole Erg├Ąnzung f├╝r dieses Feature.

@reckter Ja , ich habe gerade selbst etwas ├ähnliches gemacht. Ich musste f├╝r jede einzelne separate Seitenanforderung eine Verbindung zu meiner Datenbank herstellen, w├Ąhrend sie statisch generiert wurde. F├╝hlte sich sehr seltsam an...

Ich hoffe, das ist nicht der letzte Anwendungsfall

Es w├Ąre sch├Ân, eine Art Initialisierungsskript zu haben, das Sie aus der next.config oder so einrichten k├Ânnen ...

@reckter Eine M├Âglichkeit, HTTP-Anfragen mit API-Routen von SSG/SSR zu

Wie auch immer, eine m├Âgliche L├Âsung f├╝r den Zugriff auf API-Routen w├Ąhrend SSG w├Ąre, einen lokalen Server zu haben, der nur die /api Routen ausf├╝hrt, bevor die statischen Seiten kompiliert werden! Die Build-Schritte w├Ąren also:

  1. Starten Sie einen Server (vielleicht "Api-Kompilierungsserver" oder so ├Ąhnlich), der nur die /api Routen bedient
  2. unstable_getStaticPaths
  3. unstable_getStaticProps
  4. Kompilieren Sie die statischen Seiten

@reckter im Grunde m├╝ssen Sie keine API-Routen aufrufen, Sie k├Ânnen die von ihr implementierte Funktion direkt aufrufen. Dies vermeidet auch einen Gro├čteil des Overheads, der ├╝ber http-Ursachen hinausgeht.

Grunds├Ątzlich, wenn Sie derzeit eine API-Route haben, die wie folgt aussieht:

import myDb from 'mydatabaseprovider'
const db = myDb()

export default async (req, res) => {
  cont myData = await db.query('posts')
  res.json(myData)
}

Sie w├╝rden es ├Ąndern in:

import myDb from 'mydatabaseprovider'
const db = myDb()

export async function getData() {
  const myData = await db.query('posts')
  return myData
}

export default (req, res) => {
  const myData = await getData()
  res.json(myData)
}

Und dann auf deiner Seite:

import {getData} from './api/myfunction'

export async function getStaticProps() {
  const myData = await getData()
  return {
    props: {
     myData
   }
  }
}

Es w├Ąre schwierig, dasselbe f├╝r GraphQL-APIs zu tun. Und auch f├╝r die meisten REST.

API-Aufruf != Abrufen von DB (allgemein)
Es gibt fast immer eine gewisse Gesch├Ąftslogik in der API-Schicht wie Feldumbenennung, Datenneuformatierung usw.

Ich bin sicher, Sie haben Gr├╝nde, pages/api Aufrufe zu verbieten... aber die Umgehung einer echten API wird nicht einfach oder billig sein. Und ein paar eingesparte Millisekunden werden die Geb├╝hren f├╝r Extracode/Komplexit├Ąt IMO nicht aufwiegen.

Es f├╝hlt sich auch seltsam an, dass Anfragen an jede API zul├Ąssig sind. Au├čer deinem eigenen

Wenn Sie unstable_getStaticPaths wird die Seite neu geladen und verliert beispielsweise den aktuellen Status in Redux. Wird sich dieses Verhalten in Zukunft ├Ąndern?

Bearbeiten: scheint dieses Verhalten durch Verwendung der Option as in Links oder Routern umgangen werden zu k├Ânnen

<Link
  href='/item/[key]'
  as={`/item/${itemName}`}
>
router.push(
  '/item/[key]',
  `/item/${itemName}`
);

@meesvandongen das war schon immer so. Wenn Ihr <Link> ung├╝ltig ist, gelangen Sie zum Backend-Teil, der im Grunde als <a> . Dynamische Fragmente wie [key] m├╝ssen mit entsprechenden Werten gepaart werden.

@reaktivo pages/[lang]/blog/[id].js -> in getStaticPaths alle URLs zum statischen Rendern angeben.

https://github.com/zeit/next.js/issues/9524#issuecomment -562625858
In diesem Fall m├╝ssen f├╝r jede Seite au├čer index.js die Funktionen getStaticPaths und getStaticProps hinzugef├╝gt werden.
Wenn es einige mdx-Seiten gibt, ist das Projekt schwieriger zu pflegen

Erw├Ągen Sie eine ├änderung oder Kompatibilit├Ąt mit statischen getStaticPaths getStaticProps Methoden. https://github.com/zeit/next.js/issues/9524#issuecomment -558617056
Wenn dies der Fall ist, kann die Seite durch eine Funktion h├Âherer Ordnung oder eine Komponente h├Âherer Ordnung (HOC) umbrochen werden.
Auf diese Weise ist der Code wartungsfreundlicher und f├╝r Typescript bequemer.


Baumsch├╝tteln vs. dynamisch. Was f├╝r ein Kopfschmerz-Trade-off.­čśé

Mit 9.2.3-canary.13 ich versucht, fallback: false in getStaticPaths wie folgt zu verwenden:

  return {
    fallback: false,
    paths: slugs.map(slug => ({params: {slug: slug}}))
  }

aber es schl├Ągt mit folgendem Fehler fehl:

Error: Extra keys returned from unstable_getStaticPaths in /blog/[slug] (fallback) Expected: { paths: [] }

Mit 9.2.3-canary.13 ich versucht, fallback: false in getStaticPaths wie folgt zu verwenden:

  return {
    fallback: false,
    paths: slugs.map(slug => ({params: {slug: slug}}))
  }

aber es schl├Ągt mit folgendem Fehler fehl:

Error: Extra keys returned from unstable_getStaticPaths in /blog/[slug] (fallback) Expected: { paths: [] }

Ich denke, Sie brauchen die Karte eine h├Âhere Ebene, also gibt die Karte das Objekt zur├╝ck, das Sie derzeit haben, jedoch mit einer einzigartigen Schnecke. anstatt in den Pfaden zuzuordnen.

Ich habe meine Version auf nextjs noch nicht aktualisiert, aber es sollte ├Ąhnlich sein:

return data.map(item => {
    return {
      params: {
        slug: item.slug,
      },
    }
  })

@jorngeorg es ist eine offene PR: https://github.com/zeit/next.js/pull/10701

Fantastischer Beitrag! Es verbessert wirklich den statischen Rendering-Prozess.

Ich empfehle, den Dokumenten hinzuzuf├╝gen, dass bei dynamischen Routen der "Fallback" ohne Aufruf von getStaticProps generiert wird - was bedeutet, dass Sie Ihre Komponente codieren m├╝ssen, um den Fall zu ber├╝cksichtigen, dass props leer ist.

Alternativ k├Ânnen Sie beim Erstellen des Fallbacks das Verhalten so ├Ąndern, dass getStaticProps ohne Kontext aufgerufen wird. Dies w├╝rde der aktuellen Funktionsweise von next export (zB /p/[id].js wird nach /p/[id].html exportiert, indem getInitialProps ohne Kontext ausgef├╝hrt wird).

  • getStaticProps - Melden Sie sich zum Zeitpunkt next build f├╝r die statische Generierung (SSG) an.
  • getServerProps - Aktivieren Sie das serverseitige Rendering (SSR), das bei Bedarf rendert.

10722

Benennen Sie getServerProps in getServerSideProps um.

Ich empfehle, den Dokumenten hinzuzuf├╝gen, dass bei dynamischen Routen der "Fallback" ohne Aufruf von getStaticProps generiert wird - was bedeutet, dass Sie Ihre Komponente codieren m├╝ssen, um den Fall zu ber├╝cksichtigen, dass props leer ist.

Guter Punkt, es zu erw├Ąhnen! Ich hatte auch einige Build-/Bereitstellungsfehler, weil ich das ├╝bersehen habe.

RFC aktualisiert, um die Änderungen widerzuspiegeln

@timneutkens

  • Eine nachfolgende Anfrage an denselben Pfad liefert die generierte Seite

Ich gehe davon aus, dass dies bedeutet, dass Next.js die generierte Seite zwischenspeichert? Ist das ein In-Memory-Cache? Ist dieser Cache durch Grenzen begrenzt oder kann dies zu Speicherlecks f├╝hren?

Wenn Sie next start verwenden, wird lru-Cache ├Ąhnlich dem aktuellen Caching-Beispiel verwendet. Derzeit betr├Ągt das Standardlimit 50 MB, wir k├Ânnen es sp├Ąter konfigurierbar machen: https://github.com/zeit/next.js/ blob/canary/packages/next/next-server/server/spr-cache.ts#L90

Wenn Sie auf ZEIT hosten, geschieht die Generierung und das Caching auf dem CDN/Proxy, sodass es etwas anders funktioniert und Sie sich keine Sorgen ├╝ber Speicherlecks oder ├ťberschreitungen des lru-Limits machen m├╝ssen.

­čĹŹ ok, scheint vern├╝nftig. Das hatte ich mir mehr oder weniger als sinnvolles Standardverhalten vorgestellt.

  • getStaticProps - Melden Sie sich zum Zeitpunkt next build f├╝r die statische Generierung (SSG) an.
  • getServerProps - Aktivieren Sie das serverseitige Rendering (SSR), das bei Bedarf rendert.

10722

Benennen Sie getServerProps in getServerSideProps um.

Warum aber die Umbenennung? IMHO getServerProps ist genau genug und k├╝rzer zu tippen, das Hinzuf├╝gen von Side f├╝hlt sich f├╝r mich ├╝berfl├╝ssig an.

Ich habe mich gefragt, ob an der getStaticPaths-Methode Änderungen vorgenommen wurden. Meine dynamischen Seiten werden nicht mehr als statische Seiten generiert, sondern jetzt als Lambda-Funktionen exportiert?

Liege ich richtig, wenn das Standardverhalten jetzt darin besteht, dass die Seiten zuerst als Lambdas gerendert werden und erst nach dem Besuch einer bestimmten Seite die Seite zu einer statischen Seite generiert wird? (wie im Fallback erw├Ąhnt)

@erhankaradeniz Es wurden keine Änderungen an getStaticPaths , die dazu führen würden, dass Ihre Seite(n) Lambdas sind. Dies ist wahrscheinlich ein Fehler in der Verwendung.

K├Ânnen Sie bitte Ihren Code zeigen, damit wir das Problem identifizieren k├Ânnen?

@Timer Ich bin vorerst zu

So habe ich derzeit meine Pfade generiert:

return cityData.map(city => {
    return {
      params: {
        country: city.countrySlug,
        city: city.slug,
      },
    }
  })

und auf einer anderen Seite tue ich:

return cityData.map(city => {
    return {
      params: {
        country: city.countrySlug,
        city: city.slug,
      },
    }
  })

habe es nicht geschafft, es mit den Pfaden auf die neue Canary-Version zu konvertieren. Ich muss etwas falsch machen, denn console.logs werden nicht einmal innerhalb von getStaticPath ausgel├Âst

Ich habe Probleme mit dem Vorrendern von verschachtelten Pfaden und SSG:

// pages/[lang]/[...slugs].js

export async function getStaticPaths() {
  let knex = await import("knex/client").then(m => m.default)
  let pages = await knex("page").select(["lang", "url"])
  return {
    fallback: true,
    paths: pages.map(page => {
      return {
        params: {
          lang: page.lang,
          slugs: page.url == "/" ? [] : page.url.slice(1).split("/"),
        }
      }
    }),
  }
}

f├╝hrt zu

Error occurred prerendering page "/en/". Read more: https://err.sh/next.js/prerender-error:
Error: The provided export path '/en/' doesn't match the '/[lang]/[...slugs]' page.

f├╝r die Startseite. Aus irgendeinem Grund passt NextJS nicht zusammen

{lang: "en", slugs: []}

zu

/[lang]/[...slugs]

Wenn ich {lang: "en", slugs: ["/"]} angebe, wird es erstellt, aber mit einer falschen URL:

Ôöť ÔŚĆ /[lang]/[...slugs]      875 B        204 kB
Ôöť   Ôöť /en/credits
Ôöť   Ôöť /en/%2F

F├╝rs Protokoll, getServerSideProps funktioniert mit einem ├Ąhnlichen Setup gut.

Ich wei├č, es ist experimentell, aber dieser Thread soll Feedback geben, oder?

pages/[lang]/[...slugs].js entspricht /en/abcdef und nicht /en , daf├╝r m├╝ssen Sie derzeit pages/[lang]/index.js erstellen.

Daf├╝r ist ein Feature Request offen: https://github.com/zeit/next.js/issues/10488

Das ist erstmal toll. Ich habe gehofft, so etwas in Next.js zu haben, damit ich endlich von Gatsby.js wegkommen und eine Hybrid-App (statisch + dynamisch) haben kann.

­čÜÇ Ich habe die kanarische und halbgebackene komplexe App-Version ausprobiert, die gut funktioniert hat. Ich gestehe, ich habe nicht alle Kommentare hier gelesen, bin mir aber nicht sicher, ob das Tree-Shaking noch implementiert ist.

­čĄö getStaticPaths f├╝hlt sich viel eher wie setStaticPaths wo wir den statischen Pfad f├╝r das SSG-Verhalten definieren. Das hat mich ein bisschen verwirrt.

­čžÉ Ich frage mich, ob wir die Build-Zeiten verbessern k├Ânnen, indem wir Build-Kategorien haben? Ich wei├č, dass dies die Einrichtung erschweren w├╝rde, aber es wird sich lohnen. Lassen Sie mich erkl├Ąren:

Was ist, wenn wir etwas wie setBuildCategory , das es auf blog oder pages oder was auch immer jemand will 2020-content . Dann sucht der SSG-Builder nach der Kategorie der ge├Ąnderten Seite und versucht nur, diese Kategorie aus einer Kombination aus Cache und neuem Rendering neu zu erstellen. So etwas kann uns helfen, SSG schnell zu machen und riesige Build-Zeiten f├╝r Dinge zu vermeiden, die sich nicht viel ├Ąndern, sich aber dennoch ├Ąndern k├Ânnten und daher nicht archiviert werden k├Ânnen.

Wenn das Sinn macht; Ich freue mich, auf einen Anruf zu springen und dar├╝ber zu plaudern.

Wie handhabe ich getServerSideProps mit einer benutzerdefinierten Serverimplementierung?

if (pathname === '/a') {
  app.render(req, res, '/b', query)
}

Im obigen Beispiel wird beim Aufrufen von /a die Seite pages/b.js . Aber eine clientseitige Umleitung zu /a versucht, eine a.json Datei herunterzuladen, die in diesem Fall nicht existiert.

Sollen wir ├Ąhnliche Bedingungen f├╝r Anfragen an /_next/data/{BUILD_ID}/{PAGE}.json , um verschiedene JSON-Dateien zu rendern?

Wie erhalte ich das req-Objekt, um fallback: true in getStaticPaths zu verwenden? Es scheint derzeit, dass ich nicht kann. Der Grund, warum ich es brauche, ist, einige Cookies aus dem Browser zu holen, um eine Route zu authentifizieren

@tylermcrobert wie schnappen, wenn es ├╝berhaupt keine Anfrage gibt
Routen mit Backend, die von echten Besucheranfragen abh├Ąngen, k├Ânnen nicht durch Definitionen von "statisch" und "dynamisch" statisch gemacht werden. Um nicht zu sagen, dass Sie Static und Authentifizierung nicht kombinieren k├Ânnen ... es ist nur, dass der Authentifizierungsteil zu API- und Client-Code anstelle von Seiten geh├Ârt.

Wie handhabe ich getServerSideProps mit einer benutzerdefinierten Serverimplementierung?

if (pathname === '/a') {
  app.render(req, res, '/b', query)
}

Im obigen Beispiel wird beim Aufrufen von /a die Seite pages/b.js . Aber eine clientseitige Umleitung zu /a versucht, eine a.json Datei herunterzuladen, die in diesem Fall nicht existiert.

Sollen wir ├Ąhnliche Bedingungen f├╝r Anfragen an /_next/data/{BUILD_ID}/{PAGE}.json , um verschiedene JSON-Dateien zu rendern?

Next.js unterst├╝tzt dynamische Routenparameter, sodass eine Neuzuordnung in einem benutzerdefinierten Server selten mehr erforderlich ist: https://nextjs.org/docs/routing/dynamic-routes

Der von Ihnen beschriebene Ansatz funktioniert nicht mit <Link> (w├╝rde einen vollst├Ąndigen Seiten├╝bergang verursachen), also funktioniert getServerSideProps bereits.

@tylermcrobert wie schnappen, wenn es ├╝berhaupt keine Anfrage gibt
Routen mit Backend, die von echten Besucheranfragen abh├Ąngen, k├Ânnen nicht durch Definitionen von "statisch" und "dynamisch" statisch gemacht werden. Um nicht zu sagen, dass Sie Static und Authentifizierung nicht kombinieren k├Ânnen ... es ist nur, dass der Authentifizierungsteil zu API- und Client-Code anstelle von Seiten geh├Ârt.

Vielleicht verstehe ich die Fallback-Option in diesem Fall falsch. Was Sie sagen, macht im Kontext der Build-Zeit absolut Sinn.

Ist fallback: true f├╝r den Fall, dass es keine vordefinierte Route gibt? In diesem Fall w├╝rde ein Fallback vom Browser aus erreicht, nicht wahr?

@tylermcrobert ja fallback: true case hat eine Anfrage, aber die API muss mit dem "kleinsten gemeinsamen Nenner" vereinheitlicht werden. Ich kann mir kein funktionierendes System vorstellen, bei dem alles mit einem Satz von Pr├Ąmissen erstellt und dann schrittweise mit einem v├Âllig anderen Satz von Pr├Ąmissen aktualisiert wird. Es wird eine Katastrophe sein, es zu unterst├╝tzen.

Ich denke, Sie ├╝bersehen den Punkt, dass diese inkrementellen Builds immer noch zwischen Builds zwischengespeichert werden. Die Rolle des ersten Besuchers beeinflusst also das Build-Ergebnis f├╝r alle nachfolgenden Benutzer! Klingt nach einer schlechten Idee.

@ivan-kleshnin Ich verstehe und stimme sicherlich zu. Der Grund, warum ich frage, liegt in meinem speziellen Anwendungsfall.

Ich verwende ein Headless-CMS, das eine Vorschaufunktionalit├Ąt erm├Âglicht, sodass die Seiten, die in der Vorschau angezeigt werden m├╝ssen, zur Build-Zeit nicht enthalten sind (da der in der Vorschau angezeigte Eintrag zu diesem Zeitpunkt noch nicht existiert hat). Ich dachte, dies w├Ąre ein Fall, in dem die Fallback-Option ins Spiel kommen w├╝rde.

Um auf diese Vorschau zuzugreifen, ben├Âtige ich Zugriff auf die API-Vorschaureferenz, die ├╝ber ein Cookie bereitgestellt wird.

Ist das ein Fall, in dem ich useStaticProps einfach komplett verschrotten sollte? Ich w├╝rde es hassen, die Vorteile statischer Builds zu verlieren, weil ich meine Dokumente nicht in der Vorschau anzeigen kann.

Die Attraktivit├Ąt dieses RFC gegen├╝ber etwas wie Gatsby besteht darin, dass es uns eine ÔÇ×hybride KontrolleÔÇť mit statischer Site-Generierung gibt, die die Arbeit mit Headless-CMS erleichtert

Ich verwende ein Headless-CMS, das eine Vorschaufunktionalit├Ąt erm├Âglicht, sodass die Seiten, die in der Vorschau angezeigt werden m├╝ssen, zur Build-Zeit nicht enthalten sind (da der in der Vorschau angezeigte Eintrag zu diesem Zeitpunkt noch nicht existiert hat). Ich dachte, dies w├Ąre ein Fall, in dem die Fallback-Option ins Spiel kommen w├╝rde.

Bleiben Sie dran, bald mehr ­čĽÁ

Wenn ich das richtig verstehe, k├Ânnen wir Fallback true verwenden, wenn sich beispielsweise in meinem Fall ein Benutzer registriert (es wird keine statische Seite generiert, da es sich um eine neue Seite/ein neuer Benutzer handelt), aber wenn das Profil einen Besuch erh├Ąlt, wird es automatisch generiert?

Erhan Karadeniz
http://www.erhankaradeniz.com

Am 4. M├Ąrz 2020 um 20:25 Uhr schrieb Tim Neutkens [email protected] :


Ich verwende ein Headless-CMS, das eine Vorschaufunktionalit├Ąt erm├Âglicht, sodass die Seiten, die in der Vorschau angezeigt werden m├╝ssen, zur Build-Zeit nicht enthalten sind (da der in der Vorschau angezeigte Eintrag zu diesem Zeitpunkt noch nicht existiert hat). Ich dachte, dies w├Ąre ein Fall, in dem die Fallback-Option ins Spiel kommen w├╝rde.

Bleiben Sie dran, bald mehr ­čĽÁ

ÔÇö
Sie erhalten dies, weil Sie erw├Ąhnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab.

Benutzerdaten sind ein schlechtes Beispiel, da Sie diese clientseitig abrufen m├Âchten. Fallback ist f├╝r statisch generierte On-Demand-Seiten gedacht, die zur Erstellungszeit nicht generiert wurden. ZB m├Âchten Sie vielleicht die Top 100 Blogposts zur Erstellungszeit generieren und keine anderen mit weniger Traffic generieren.

Docs werden demn├Ąchst daf├╝r gelandet.

Ja, was ich meinte, war eine Platzhalterseite. Ich w├╝rde tats├Ąchlich Benutzerdaten auf der Clientseite abrufen.

@timneutkens Gibt es eine M├Âglichkeit, bestimmte statisch generierte Seiten zu l├Âschen oder neu zu erstellen?

Hi!!! Klingt nach der optimalen Anwendung. Ich liebe sowohl React als auch Next!!! Machte alles so elegant und einfach f├╝r uns zu bedienen !! Aber das Beispiel enth├Ąlt den Begriff Blog. Ich m├Âchte ein Beispiel f├╝r eine Implementierung bei der Abfrage eines Headless CMS sehen und den Abruf pro Seite/Post als Export als statisches Element durchf├╝hren.

// Prost, da es bald Freitag ist !!!

@timneutkens das ist spannend ­čĹî

Ein Szenario, auf das wir h├Ąufig sto├čen, und ich habe mit next.js oder gatsby noch keine perfekte L├Âsung, au├čer dynamische Routen oder das Generieren von Projekten in einer Schleife:

Aus historischen Gr├╝nden haben wir es mit mehreren Domains zu tun (und das wollen wir nicht ├Ąndern), die die gleichen/genauen Seiten bedienen, mit Ausnahme von Preisen, W├Ąhrung, Support-Telefonnummern und Sprachauswahl. Von Natur aus sind die meisten dieser Marketingseiten ziemlich statisch und es w├╝rde ausreichen, sie t├Ąglich oder w├Âchentlich zu erstellen (statt sie bei jeder Anfrage rendern zu m├╝ssen).

Meine Frage/Mein Gedanke: Sehen Sie eine M├Âglichkeit (in Zukunft?), dass getStaticPaths Seiten basierend auf etwas generieren k├Ânnte, das kein Routenparameter ist, sondern auf Anfrageebene verwendet werden k├Ânnte, um zwischen ihnen zu wechseln (z. B. serverlos Funktion gibt statisches, vorgefertigtes Ergebnis basierend auf locale )

Konkret w├╝rde dies bedeuten, dass https://mysite.com/my-product und https://mysite.co.uk/my-product zwei verschiedene statische Seiten bedienen w├╝rden, aber ohne dass wir unsere n├Ąchste App 50x generieren oder bei jeder Anfrage ein CMS aufrufen m├╝ssten­čśů

Vielen Dank im Voraus und gespannt auf eure Meinung, vor allem wenn das etwas f├╝r die Zukunft ist, das gel├Âst/umgehbar ist ÔŁĄ´ŞĆ

Ich denke ├╝ber einen Anwendungsfall nach, bei dem ich SSG f├╝r stark frequentierte Zielseiten f├╝r SEO und zur Reduzierung der Serverlast verwenden m├Âchte, aber dennoch m├Âchte, dass aktuelle Daten nach der Hydratation und beim clientseitigen Routing zu dieser Seite verwendet werden. W├Ąre das m├Âglich?

Grunds├Ątzlich sollte das Verhalten beim clientseitigen Routing zu dieser Seite wie bei getInitialProps (aktuelle Daten werden abgerufen, bevor die Seite sichtbar wird). Und beim serverseitigen Routing zu dieser Seite sollte der statische HTML-Code bereitgestellt und hydratisiert werden und dann (optional) einige API-Antworten abgerufen werden, um einige Daten auf der Seite zu aktualisieren.

Ich habe gerade mit unstable_getStaticProps , um es auszuprobieren, und bin in einen lustigen Konflikt geraten: Es ist schwierig, API-Routen mit getStaticProps .

Achten Sie nicht auf die Semantik des Codes, sondern nur auf den Datenfluss:

// pages/api/healthcheck.ts
import { NextApiResponse, NextApiRequest } from 'next';

export type ApiHealthCheckResponse = {
  message: 'ok';
};

const healthCheckHandler = (
  req: NextApiRequest,
  res: NextApiResponse<ApiHealthCheckResponse | ''>,
) => {
  if (req.method === 'GET') {
    return res.status(200).json({ message: 'ok' });
  }

  return res.status(405).send('');
};

export default healthCheckHandler;
// pages/index.js
// ...

export async function unstable_getStaticProps() {
  return {
    props: {
      healthcheck: (await fetch('localhost:3000/api/healthcheck').json())
    },
  };
}

Die Seitenerstellung st├╝rzt zur Erstellungszeit ab, da der Server nicht ausgef├╝hrt wird. Ich bin mir nicht sicher, ob dies ein g├╝ltiger Anwendungsfall ist, da getStaticProps nicht mit etwas zu dynamischem verwendet werden sollte, aber ich dachte, es w├Ąre ein interessanter Edgecase zum Teilen (ich kann mir gut vorstellen, dass ein Route-API-Endpunkt daf├╝r verantwortlich ist, Daten von einer anderen API und formatieren Sie sie neu.

@martpie Vielleicht m├Âchten Sie sich diesen Kommentar ansehen: https://github.com/zeit/next.js/issues/9524#issuecomment -589772756

Die Unterst├╝tzung f├╝r die Static Site Generation (SSG) der n├Ąchsten Generation wurde in Next.js 9.3 als stabil ver├Âffentlicht!

Diese Version enth├Ąlt auch Unterst├╝tzung f├╝r den "Vorschaumodus" oder die M├Âglichkeit, die statisch vorgerenderte Seite zu umgehen und die Seite bei Bedarf f├╝r autorisierte Benutzer zu rendern .

Mehr dazu k├Ânnen Sie in unserem Blogbeitrag lesen . Wenn Sie mehr praktische Erfahrung haben , springen Sie direkt in unsere

Bitte posten Sie alle Fragen an die Next.js GitHub-Community !

Das ist so cool! Danke f├╝r die M├╝he!

Dieses neue Feature scheint jetzt nicht mit Saga und Redux zu funktionieren

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen