Route-Segment-Konfiguration

Die auf dieser Seite beschriebenen Optionen sind deaktiviert, wenn das dynamicIO-Flag aktiviert ist und werden in Zukunft vollständig veraltet sein.

Die Route-Segment-Optionen ermöglichen es Ihnen, das Verhalten einer Seite, eines Layouts oder eines Route-Handlers zu konfigurieren, indem Sie die folgenden Variablen direkt exportieren:

Optionen

experimental_ppr

Aktivieren Sie Partial Prerendering (PPR) für ein Layout oder eine Seite.

export const experimental_ppr = true
// true | false

dynamic

Ändern Sie das dynamische Verhalten eines Layouts oder einer Seite zu vollständig statisch oder vollständig dynamisch.

export const dynamic = 'auto'
// 'auto' | 'force-dynamic' | 'error' | 'force-static'

export const dynamic = 'auto'
// 'auto' | 'force-dynamic' | 'error' | 'force-static'

Hinweis: Das neue Modell im app-Verzeichnis bevorzugt eine granulare Caching-Kontrolle auf Ebene der fetch-Anfrage gegenüber dem binären Alles-oder-Nichts-Modell von getServerSideProps und getStaticProps auf Seitenebene im pages-Verzeichnis. Die dynamic-Option ist eine Möglichkeit, zurück zum vorherigen Modell zu wechseln und bietet einen einfacheren Migrationspfad.

• 'auto' (Standard): Die Standardoption, um so viel wie möglich zu cachen, ohne dass Komponenten am dynamischen Verhalten gehindert werden.

• 'force-dynamic': Erzwingen Sie dynamisches Rendering, was dazu führt, dass Routen für jeden Benutzer zum Zeitpunkt der Anfrage gerendert werden. Diese Option ist äquivalent zu:

  • getServerSideProps() im pages-Verzeichnis.
  • Setzen der Option jeder fetch()-Anfrage in einem Layout oder einer Seite auf { cache: 'no-store', next: { revalidate: 0 } }.
  • Setzen der Segmentkonfiguration auf export const fetchCache = 'force-no-store'

• 'error': Erzwingen Sie statisches Rendering und Caching der Daten eines Layouts oder einer Seite, indem ein Fehler ausgelöst wird, wenn Komponenten Dynamische APIs oder nicht zwischengespeicherte Daten verwenden. Diese Option ist äquivalent zu:

  • getStaticProps() im pages-Verzeichnis.
  • Setzen der Option jeder fetch()-Anfrage in einem Layout oder einer Seite auf { cache: 'force-cache' }.
  • Setzen der Segmentkonfiguration auf fetchCache = 'only-cache', dynamicParams = false.
  • dynamic = 'error' ändert den Standard von dynamicParams von true zu false. Sie können dynamisch gerenderte Seiten für dynamische Parameter, die nicht von generateStaticParams generiert wurden, wieder aktivieren, indem Sie manuell dynamicParams = true setzen.

• 'force-static': Erzwingen Sie statisches Rendering und Caching der Daten eines Layouts oder einer Seite, indem cookies, headers() und useSearchParams() gezwungen werden, leere Werte zurückzugeben.

Hinweis:

• Anweisungen zum Migrieren von getServerSideProps und getStaticProps zu dynamic: 'force-dynamic' und dynamic: 'error' finden Sie im Upgrade-Leitfaden.

dynamicParams

Steuern Sie, was passiert, wenn ein dynamisches Segment besucht wird, das nicht mit generateStaticParams generiert wurde.

export const dynamicParams = true // true | false,

export const dynamicParams = true // true | false,

• true (Standard): Dynamische Segmente, die nicht in generateStaticParams enthalten sind, werden bei Bedarf generiert.
• false: Dynamische Segmente, die nicht in generateStaticParams enthalten sind, geben einen 404-Fehler zurück.

Hinweis:

• Diese Option ersetzt die fallback: true | false | blocking-Option von getStaticPaths im pages-Verzeichnis.
• Um alle Pfade beim ersten Besuch statisch zu rendern, müssen Sie ein leeres Array in generateStaticParams zurückgeben oder export const dynamic = 'force-static' verwenden.
• Wenn dynamicParams = true ist, verwendet das Segment Streaming-Server-Rendering.
• Wenn dynamic = 'error' und dynamic = 'force-static' verwendet werden, ändert dies den Standard von dynamicParams zu false.

revalidate

Legen Sie die standardmäßige Revalidierungszeit für ein Layout oder eine Seite fest. Diese Option überschreibt nicht den revalidate-Wert einzelner fetch-Anfragen.

export const revalidate = false
// false | 0 | number

export const revalidate = false
// false | 0 | number

• false (Standard): Die Standard-Heuristik zum Zwischenspeichern von beliebigen fetch-Anfragen, die ihre cache-Option auf 'force-cache' setzen oder vor Verwendung einer Dynamischen API entdeckt werden. Semantisch gleichwertig mit revalidate: Infinity, was effektiv bedeutet, dass die Ressource unbegrenzt zwischengespeichert werden soll. Es ist dennoch möglich, dass einzelne fetch-Anfragen cache: 'no-store' oder revalidate: 0 verwenden, um nicht zwischengespeichert zu werden und die Route dynamisch zu rendern. Oder revalidate auf eine positive Zahl unterhalb des Routen-Standards setzen, um die Revalidierungshäufigkeit einer Route zu erhöhen.
• 0: Sicherstellen, dass ein Layout oder eine Seite immer dynamisch gerendert wird, auch wenn keine Dynamischen APIs oder nicht zwischengespeicherte Datenabrufe entdeckt werden. Diese Option ändert den Standard von fetch-Anfragen, die keine cache-Option setzen, auf 'no-store', lässt aber fetch-Anfragen, die sich für 'force-cache' entscheiden oder eine positive revalidate-Option verwenden, unverändert.
• Zahl: (in Sekunden) Die Standard-Revalidierungshäufigkeit eines Layouts oder einer Seite auf n Sekunden festlegen.

Hinweis:

• Der Revalidierungswert muss statisch analysierbar sein. Beispielsweise ist revalidate = 600 gültig, aber revalidate = 60 * 10 nicht.
• Der Revalidierungswert ist nicht verfügbar bei Verwendung von runtime = 'edge'.
• In der Entwicklung werden Seiten immer bei Bedarf gerendert und niemals zwischengespeichert. Dies ermöglicht es Ihnen, Änderungen sofort zu sehen, ohne auf das Ablaufen einer Revalidierungsperiode warten zu müssen.

Revalidierungshäufigkeit

• Der niedrigste revalidate-Wert über jedes Layout und jede Seite einer einzelnen Route bestimmt die Revalidierungshäufigkeit der gesamten Route. Dies stellt sicher, dass untergeordnete Seiten genauso häufig revalidiert werden wie ihre übergeordneten Layouts.
• Einzelne fetch-Anfragen können einen niedrigeren revalidate-Wert als den Standard-revalidate der Route setzen, um die Revalidierungshäufigkeit der gesamten Route zu erhöhen. Dies ermöglicht es Ihnen, sich dynamisch für eine häufigere Revalidierung bestimmter Routen basierend auf bestimmten Kriterien zu entscheiden.

fetchCache

export const fetchCache = 'auto'
// 'auto' | 'default-cache' | 'only-cache'
// 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store'

export const fetchCache = 'auto'
// 'auto' | 'default-cache' | 'only-cache'
// 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store'

runtime

Wir empfehlen die Verwendung der Node.js-Laufzeit zum Rendern Ihrer Anwendung und der Edge-Laufzeit für Middleware (einzige unterstützte Option).

export const runtime = 'nodejs'
// 'nodejs' | 'edge'

export const runtime = 'nodejs'
// 'nodejs' | 'edge'

• 'nodejs' (Standard)
• 'edge'

Weitere Informationen über die verschiedenen Laufzeiten.

preferredRegion

export const preferredRegion = 'auto'
// 'auto' | 'global' | 'home' | ['iad1', 'sfo1']

export const preferredRegion = 'auto'
// 'auto' | 'global' | 'home' | ['iad1', 'sfo1']

Unterstützung für preferredRegion und unterstützte Regionen hängen von Ihrer Bereitstellungsplattform ab.

Hinweis:

• Wenn keine preferredRegion angegeben wird, erbt sie die Option des nächstgelegenen übergeordneten Layouts.
• Das Root-Layout verwendet standardmäßig alle Regionen.

maxDuration

Standardmäßig begrenzt Next.js die Ausführung von serverseitiger Logik nicht (Rendern einer Seite oder Handhabung einer API). Bereitstellungsplattformen können maxDuration aus der Next.js-Build-Ausgabe verwenden, um spezifische Ausführungsgrenzen hinzuzufügen. Zum Beispiel auf Vercel.

Hinweis: Diese Einstellung erfordert Next.js 13.4.10 oder höher.

export const maxDuration = 5

export const maxDuration = 5

Hinweis:

• Bei Verwendung von Server-Aktionen kann die maxDuration auf Seitenebene festgelegt werden, um das Standardzeitlimit aller auf der Seite verwendeten Server-Aktionen zu ändern.

generateStaticParams

Die generateStaticParams-Funktion kann in Kombination mit dynamischen Routensegmenten verwendet werden, um die Liste der Routensegment-Parameter zu definieren, die zur Bauzeit statisch generiert werden sollen, anstatt bei Bedarf zum Zeitpunkt der Anfrage.

Weitere Details finden Sie in der API-Referenz.

Versionsverlauf