Konfiguration von Routensegmenten

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

OptionTypStandardwert
dynamic'auto' | 'force-dynamic' | 'error' | 'force-static''auto'
dynamicParamsbooleantrue
revalidatefalse | 0 | numberfalse
fetchCache'auto' | 'default-cache' | 'only-cache' | 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store''auto'
runtime'nodejs' | 'edge''nodejs'
preferredRegion'auto' | 'global' | 'home' | string | string[]'auto'
maxDurationnumberWird vom Deployment festgelegt
export const dynamic = 'auto'
export const dynamicParams = true
export const revalidate = false
export const fetchCache = 'auto'
export const runtime = 'nodejs'
export const preferredRegion = 'auto'
export const maxDuration = 5

export default function MyComponent() {}
export const dynamic = 'auto'
export const dynamicParams = true
export const revalidate = false
export const fetchCache = 'auto'
export const runtime = 'nodejs'
export const preferredRegion = 'auto'
export const maxDuration = 5

export default function MyComponent() {}

Wichtig zu wissen:

  • Die Werte der Konfigurationsoptionen müssen derzeit statisch analysierbar sein. Beispielsweise ist revalidate = 600 gültig, aber revalidate = 60 * 10 nicht.

Optionen

dynamic

Ändert 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'

Wichtig zu wissen: Das neue Modell im app-Verzeichnis bevorzugt eine granulare Cache-Kontrolle auf Ebene der fetch-Anfragen gegenüber dem binären Alles-oder-Nichts-Modell von getServerSideProps und getStaticProps auf Seitenebene im pages-Verzeichnis. Die dynamic-Option ermöglicht es, zum vorherigen Modell zurückzukehren und erleichtert die Migration.

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

  • 'force-dynamic': Erzwingt dynamisches Rendering, wodurch Routen bei jeder Anfrage für jeden Benutzer gerendert werden. Diese Option entspricht getServerSideProps() im pages-Verzeichnis.

  • 'error': Erzwingt statisches Rendering und cacht die Daten eines Layouts oder einer Seite, indem ein Fehler ausgelöst wird, wenn Komponenten dynamische Funktionen oder ungecachte Daten verwenden. Diese Option entspricht:

    • 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 Standardwert von dynamicParams von true zu false. Sie können dynamisches Rendering für dynamische Parameter, die nicht von generateStaticParams generiert wurden, durch manuelles Setzen von dynamicParams = true wieder aktivieren.
  • 'force-static': Erzwingt statisches Rendering und cacht die Daten eines Layouts oder einer Seite, indem cookies(), headers() und useSearchParams() gezwungen werden, leere Werte zurückzugeben.

Wichtig zu wissen:

  • Anleitungen zur Migration von getServerSideProps und getStaticProps zu dynamic: 'force-dynamic' und dynamic: 'error' finden Sie im Upgrade-Guide.

dynamicParams

Steuert, was passiert, wenn ein dynamisches Segment aufgerufen 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.

Wichtig zu wissen:

  • Diese Option ersetzt die fallback: true | false | blocking-Option von getStaticPaths im pages-Verzeichnis.
  • Wenn dynamicParams = true ist, verwendet das Segment Streaming Server Rendering.
  • Wenn dynamic = 'error' und dynamic = 'force-static' verwendet werden, wird der Standardwert von dynamicParams auf false geändert.

revalidate

Legt 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 Standardheuristik, um alle fetch-Anfragen zu cachen, die ihre cache-Option auf 'force-cache' setzen oder vor der Verwendung einer dynamischen Funktion entdeckt werden. Semantisch äquivalent zu revalidate: Infinity, was bedeutet, dass die Ressource unbegrenzt gecacht werden sollte. Einzelne fetch-Anfragen können weiterhin cache: 'no-store' oder revalidate: 0 verwenden, um das Caching zu vermeiden und die Route dynamisch rendern zu lassen. Oder setzen Sie revalidate auf eine positive Zahl, die niedriger ist als der Standardwert der Route, um die Revalidierungsfrequenz zu erhöhen.
  • 0: Stellt sicher, dass ein Layout oder eine Seite immer dynamisch gerendert wird, auch wenn keine dynamischen Funktionen oder ungecachte Datenabfragen entdeckt werden. Diese Option ändert den Standardwert von fetch-Anfragen, die keine cache-Option angeben, auf 'no-store', lässt aber fetch-Anfragen, die 'force-cache' oder eine positive revalidate verwenden, unverändert.
  • number: (in Sekunden) Legt die standardmäßige Revalidierungsfrequenz eines Layouts oder einer Seite auf n Sekunden fest.

Wichtig zu wissen: Die revalidate-Option ist nur verfügbar, wenn die Node.js Runtime verwendet wird. Das bedeutet, dass die Verwendung der revalidate-Option mit runtime = 'edge' nicht funktioniert.

Revalidierungsfrequenz

  • Der niedrigste revalidate-Wert über alle Layouts und Seiten einer einzelnen Route bestimmt die Revalidierungsfrequenz der gesamten Route. Dadurch wird sichergestellt, dass untergeordnete Seiten so häufig revalidiert werden wie ihre übergeordneten Layouts.
  • Einzelne fetch-Anfragen können einen niedrigeren revalidate-Wert als den Standardwert der Route setzen, um die Revalidierungsfrequenz der gesamten Route zu erhöhen. Dies ermöglicht es Ihnen, basierend auf bestimmten Kriterien dynamisch eine häufigere Revalidierung für bestimmte Routen zu aktivieren.

fetchCache

Dies ist eine erweiterte Option, die nur verwendet werden sollte, wenn Sie das Standardverhalten gezielt überschreiben müssen.

Standardmäßig wird Next.js alle fetch()-Anfragen cachen, die vor der Verwendung von dynamischen Funktionen erreichbar sind, und wird fetch-Anfragen, die nach der Verwendung dynamischer Funktionen entdeckt werden, nicht cachen.

fetchCache ermöglicht es Ihnen, die standardmäßige cache-Option aller fetch-Anfragen in einem Layout oder einer Seite zu überschreiben.

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'
  • 'auto' (Standard): Die Standardoption, um fetch-Anfragen vor dynamischen Funktionen mit der von ihnen bereitgestellten cache-Option zu cachen und fetch-Anfragen nach dynamischen Funktionen nicht zu cachen.
  • 'default-cache': Ermöglicht das Übergeben einer beliebigen cache-Option an fetch, aber wenn keine Option angegeben wird, wird die cache-Option auf 'force-cache' gesetzt. Dies bedeutet, dass sogar fetch-Anfragen nach dynamischen Funktionen als statisch betrachtet werden.
  • 'only-cache': Stellt sicher, dass alle fetch-Anfragen das Caching aktivieren, indem der Standardwert auf cache: 'force-cache' geändert wird, wenn keine Option angegeben ist, und einen Fehler auslöst, wenn eine fetch-Anfrage cache: 'no-store' verwendet.
  • 'force-cache': Stellt sicher, dass alle fetch-Anfragen das Caching aktivieren, indem die cache-Option aller fetch-Anfragen auf 'force-cache' gesetzt wird.
  • 'default-no-store': Ermöglicht das Übergeben einer beliebigen cache-Option an fetch, aber wenn keine Option angegeben wird, wird die cache-Option auf 'no-store' gesetzt. Dies bedeutet, dass sogar fetch-Anfragen vor dynamischen Funktionen als dynamisch betrachtet werden.
  • 'only-no-store': Stellt sicher, dass alle fetch-Anfragen das Caching deaktivieren, indem der Standardwert auf cache: 'no-store' geändert wird, wenn keine Option angegeben ist, und einen Fehler auslöst, wenn eine fetch-Anfrage cache: 'force-cache' verwendet.
  • 'force-no-store': Stellt sicher, dass alle fetch-Anfragen das Caching deaktivieren, indem die cache-Option aller fetch-Anfragen auf 'no-store' gesetzt wird. Dies erzwingt, dass alle fetch-Anfragen bei jeder Anfrage neu abgerufen werden, selbst wenn sie eine 'force-cache'-Option angeben.

Verhalten über Routensegmente hinweg

  • Alle Optionen, die über die Layouts und Seiten einer einzelnen Route hinweg gesetzt werden, müssen miteinander kompatibel sein.
    • Wenn sowohl 'only-cache' als auch 'force-cache' angegeben werden, gewinnt 'force-cache'. Wenn sowohl 'only-no-store' als auch 'force-no-store' angegeben werden, gewinnt 'force-no-store'. Die force-Option ändert das Verhalten über die gesamte Route, sodass ein einzelnes Segment mit 'force-*' alle durch 'only-*' verursachten Fehler verhindert.
    • Die Absicht der 'only-*'- und force-*'-Optionen ist es, sicherzustellen, dass die gesamte Route entweder vollständig statisch oder vollständig dynamisch ist. Das bedeutet:
      • Eine Kombination von 'only-cache' und 'only-no-store' in einer einzelnen Route ist nicht erlaubt.
      • Eine Kombination von 'force-cache' und 'force-no-store' in einer einzelnen Route ist nicht erlaubt.
    • Ein übergeordnetes Element kann nicht 'default-no-store' angeben, wenn ein untergeordnetes Element 'auto' oder '*-cache' angibt, da dies dazu führen könnte, dass dieselbe fetch-Anfrage unterschiedliches Verhalten aufweist.
  • Es wird generell empfohlen, gemeinsame übergeordnete Layouts auf 'auto' zu belassen und die Optionen dort anzupassen, wo untergeordnete Segmente abweichen.

runtime

export const runtime = 'nodejs'
// 'nodejs' | 'edge'
export const runtime = 'nodejs'
// 'nodejs' | 'edge'
  • 'nodejs' (Standard)
  • 'edge'

Erfahren Sie mehr über die Edge- und Node.js-Runtimes.

preferredRegion

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

Die Unterstützung für preferredRegion und die unterstützten Regionen hängt von Ihrer Deployment-Plattform ab.

Wichtig zu wissen:

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

maxDuration

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

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

export const maxDuration = 5
export const maxDuration = 5

Wichtig zu wissen:

  • Wenn Sie Server Actions verwenden, setzen Sie maxDuration auf Seitenebene, um das Standard-Timeout aller auf der Seite verwendeten Server Actions zu ändern.

generateStaticParams

Die Funktion generateStaticParams kann in Kombination mit dynamischen Routensegmenten verwendet werden, um die Liste der Routensegmentparameter zu definieren, die statisch zur Build-Zeit statt bei Bedarf zur Anfragezeit generiert werden.

Weitere Details finden Sie in der API-Referenz.