fetch

Next.js erweitert die Web fetch() API, um jeder Server-Anfrage zu ermöglichen, ihre eigenen persistenten Caching- und Revalidierungs-Semantiken festzulegen.

Im Browser gibt die cache-Option an, wie eine Fetch-Anfrage mit dem HTTP-Cache des Browsers interagiert. Mit dieser Erweiterung gibt cache an, wie eine serverseitige Fetch-Anfrage mit dem persistenten Data Cache des Frameworks interagiert.

Sie können fetch mit async und await direkt in Server Components aufrufen.

export default async function Page() {
  let data = await fetch('https://api.vercel.app/blog')
  let posts = await data.json()
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

fetch(url, options)

Da Next.js die Web fetch() API erweitert, können Sie alle verfügbaren nativen Optionen verwenden.

options.cache

Konfiguriert, wie die Anfrage mit dem Next.js Data Cache interagieren soll.

fetch(`https://...`, { cache: 'force-cache' | 'no-store' })

• auto no cache (Standard): Next.js holt die Ressource bei jeder Anfrage in der Entwicklung vom Remote-Server, aber wird einmal während next build abrufen, weil die Route statisch vorgerendert wird. Wenn Dynamic APIs in der Route erkannt werden, holt Next.js die Ressource bei jeder Anfrage.
• no-store: Next.js holt die Ressource bei jeder Anfrage vom Remote-Server, auch wenn keine Dynamic APIs in der Route erkannt werden.
• force-cache: Next.js sucht nach einer passenden Anfrage in seinem Data Cache.
  • Wenn es eine Übereinstimmung gibt und diese frisch ist, wird sie aus dem Cache zurückgegeben.
  • Wenn es keine Übereinstimmung oder eine veraltete Übereinstimmung gibt, holt Next.js die Ressource vom Remote-Server und aktualisiert den Cache mit der heruntergeladenen Ressource.

options.next.revalidate

fetch(`https://...`, { next: { revalidate: false | 0 | number } })

Legt die Cache-Lebensdauer einer Ressource (in Sekunden) fest.

• false - Die Ressource wird unbegrenzt im Cache gespeichert. Semantisch äquivalent zu revalidate: Infinity. Der HTTP-Cache kann ältere Ressourcen im Laufe der Zeit entfernen.
• 0 - Verhindert, dass die Ressource im Cache gespeichert wird.
• number - (in Sekunden) Gibt an, dass die Ressource eine maximale Cache-Lebensdauer von n Sekunden haben soll.

Wissenswert:

• Wenn eine einzelne fetch()-Anfrage eine revalidate-Zahl festlegt, die niedriger ist als die Standard-revalidate einer Route, wird das gesamte Revalidierungsintervall der Route verringert.
• Wenn zwei Fetch-Anfragen mit derselben URL in derselben Route unterschiedliche revalidate-Werte haben, wird der niedrigere Wert verwendet.
• Der Einfachheit halber ist es nicht notwendig, die cache-Option zu setzen, wenn revalidate auf eine Zahl gesetzt ist.
• Konfliktierende Optionen wie { revalidate: 3600, cache: 'no-store' } führen zu einem Fehler.

options.next.tags

fetch(`https://...`, { next: { tags: ['collection'] } })

Legt die Cache-Tags einer Ressource fest. Daten können dann bedarfsgesteuert mit revalidateTag revalidiert werden. Die maximale Länge für einen benutzerdefinierten Tag beträgt 256 Zeichen und die maximale Anzahl an Tag-Elementen ist 128.

Problembehandlung

Fetch-Standard auto no store und cache: 'no-store' zeigen in der Entwicklung keine frischen Daten an

Next.js cached fetch-Antworten in Server Components über Hot Module Replacement (HMR) in der lokalen Entwicklung, um schnellere Antworten zu ermöglichen und Kosten für abgerechnete API-Aufrufe zu reduzieren.

Standardmäßig gilt der HMR-Cache für alle Fetch-Anfragen, einschließlich solcher mit der Standardoption auto no cache und cache: 'no-store'. Das bedeutet, dass ungecachte Anfragen zwischen HMR-Aktualisierungen keine frischen Daten anzeigen. Der Cache wird jedoch bei Navigation oder vollständigen Seiten-Neuladungen geleert.

Weitere Informationen finden Sie in der Dokumentation zu serverComponentsHmrCache.

Versionsverlauf