fetch

Next.js erweitert die Web fetch() API, um für jede Anfrage auf dem Server eigene persistente Caching- und Revalidierungssemantiken 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 Fetch-Anfrage auf Serverseite mit dem persistenten Datencache des Frameworks interagiert.

Sie können fetch direkt mit async und await in Server-Komponenten 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 nativen Optionen verwenden.

options.cache

Konfigurieren Sie, wie die Anfrage mit dem Next.js Datencache interagieren soll.

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

• no-store (Standard): Next.js ruft die Ressource bei jeder Anfrage vom Remote-Server ab, ohne den Cache zu konsultieren, und aktualisiert den Cache nicht mit der heruntergeladenen Ressource.
• force-cache: Next.js sucht nach einer übereinstimmenden Anfrage in seinem Datencache.
  • Wenn eine Übereinstimmung vorliegt und diese aktuell ist, wird sie aus dem Cache zurückgegeben.
  • Wenn keine Übereinstimmung oder eine veraltete Übereinstimmung vorliegt, ruft Next.js die Ressource vom Remote-Server ab und aktualisiert den Cache mit der heruntergeladenen Ressource.

options.next.revalidate

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

Legen Sie die Cachedauer einer Ressource (in Sekunden) fest.

• false - Speichert die Ressource unbegrenzt. Semantisch äquivalent zu revalidate: Infinity. Der HTTP-Cache kann ältere Ressourcen im Laufe der Zeit entfernen.
• 0 - Verhindert das Caching der Ressource.
• number - (in Sekunden) Gibt an, dass die Ressource eine Cachedauer von höchstens n Sekunden haben soll.

Hinweis:

• Wenn eine einzelne fetch()-Anfrage eine revalidate-Zahl festlegt, die niedriger als der Standard-revalidate einer Route ist, wird das Revalidierungsintervall der gesamten 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 wird.
• Widersprüchliche Optionen wie { revalidate: 3600, cache: 'no-store' } führen zu einem Fehler.

options.next.tags

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

Legen Sie die Cache-Tags einer Ressource fest. Die Daten können dann bei Bedarf mithilfe von revalidateTag neu validiert werden. Die maximale Länge für ein benutzerdefiniertes Tag beträgt 256 Zeichen, und die maximale Anzahl von Tag-Elementen ist 64.

Fehlerbehebung

Fetch cache: 'no-store' zeigt keine aktuellen Daten in der Entwicklung

Next.js speichert fetch-Antworten in Server-Komponenten während Hot Module Replacement (HMR) in der lokalen Entwicklung, um schnellere Antworten zu erhalten und die Kosten für kostenpflichtige API-Aufrufe zu reduzieren.

Standardmäßig gilt der HMR-Cache für alle Fetch-Anfragen, einschließlich derjenigen mit der Option cache: 'no-store'. Das bedeutet, dass nicht zwischengespeicherte Anfragen keine aktuellen Daten zwischen HMR-Aktualisierungen zeigen. Der Cache wird jedoch bei Navigation oder vollständigem Seitenneuladen gelöscht.

Weitere Informationen finden Sie in der Dokumentation zu serverComponentsHmrCache.

Versionshistorie