Mécanismes de cache dans Next.js

Next.js améliore les performances de votre application et réduit les coûts en mettant en cache le rendu et les requêtes de données. Cette page fournit une analyse approfondie des mécanismes de cache de Next.js, des API que vous pouvez utiliser pour les configurer et de leur interaction entre eux.

Bon à savoir : Cette page vous aide à comprendre le fonctionnement interne de Next.js mais n'est pas une connaissance essentielle pour être productif avec Next.js. La plupart des heuristiques de cache de Next.js sont déterminées par votre utilisation des API et ont des valeurs par défaut pour les meilleures performances avec une configuration nulle ou minimale. Si vous préférez passer directement aux exemples, commencez ici.

Aperçu

Voici un aperçu général des différents mécanismes de cache et leur objectif :

Par défaut, Next.js mettra en cache autant que possible pour améliorer les performances et réduire les coûts. Cela signifie que les routes sont rendues statiquement et les requêtes de données sont mises en cache sauf si vous choisissez de ne pas le faire. Le diagramme ci-dessous montre le comportement de cache par défaut : lorsqu'une route est rendue statiquement au moment de la construction et lorsqu'une route statique est visitée pour la première fois.

Le comportement de cache change selon que la route est rendue statiquement ou dynamiquement, que les données sont mises en cache ou non, et si une requête fait partie d'une première visite ou d'une navigation ultérieure. Selon votre cas d'utilisation, vous pouvez configurer le comportement de cache pour des routes et des requêtes de données individuelles.

Mémorisation des requêtes

Next.js étend l'API fetch pour mémoriser automatiquement les requêtes ayant la même URL et les mêmes options. Cela signifie que vous pouvez appeler une fonction fetch pour les mêmes données à plusieurs endroits dans un arbre de composants React tout en ne l'exécutant qu'une seule fois.

Par exemple, si vous avez besoin d'utiliser les mêmes données dans une route (par exemple dans un Layout, une Page et plusieurs composants), vous n'avez pas besoin de récupérer les données en haut de l'arbre et de les transmettre entre les composants. Au lieu de cela, vous pouvez récupérer les données dans les composants qui en ont besoin sans vous soucier des implications sur les performances de faire plusieurs requêtes réseau pour les mêmes données.

async function getItem() {
  // La fonction `fetch` est automatiquement mémorisée et le résultat
  // est mis en cache
  const res = await fetch('https://.../item/1')
  return res.json()
}

// Cette fonction est appelée deux fois, mais n'est exécutée que la première fois
const item = await getItem() // cache MISS

// Le deuxième appel peut être n'importe où dans votre route
const item = await getItem() // cache HIT

Fonctionnement de la mémorisation des requêtes

• Pendant le rendu d'une route, la première fois qu'une requête particulière est appelée, son résultat ne sera pas en mémoire et ce sera un cache MISS.
• Par conséquent, la fonction sera exécutée, les données seront récupérées depuis la source externe, et le résultat sera stocké en mémoire.
• Les appels ultérieurs de la fonction pour la même requête dans le même passage de rendu seront un cache HIT, et les données seront retournées depuis la mémoire sans exécuter la fonction.
• Une fois que la route a été rendue et que le passage de rendu est terminé, la mémoire est "réinitialisée" et toutes les entrées de mémorisation des requêtes sont effacées.

Bon à savoir :

• La mémorisation des requêtes est une fonctionnalité de React, pas de Next.js. Elle est incluse ici pour montrer comment elle interagit avec les autres mécanismes de cache.
• La mémorisation ne s'applique qu'à la méthode GET dans les requêtes fetch.
• La mémorisation ne s'applique qu'à l'arbre de composants React, ce qui signifie :
  • Elle s'applique aux requêtes fetch dans generateMetadata, generateStaticParams, Layouts, Pages et autres Server Components.
  • Elle ne s'applique pas aux requêtes fetch dans les Route Handlers car ils ne font pas partie de l'arbre de composants React.
• Pour les cas où fetch n'est pas adapté (par exemple certains clients de base de données, CMS ou GraphQL), vous pouvez utiliser la fonction React cache pour mémoriser les fonctions.

Durée

Le cache dure le temps de vie d'une requête serveur jusqu'à ce que l'arbre de composants React ait fini de rendre.

Revalidation

Comme la mémorisation n'est pas partagée entre les requêtes serveur et ne s'applique que pendant le rendu, il n'est pas nécessaire de la revalider.

Désactivation

La mémorisation ne s'applique qu'à la méthode GET dans les requêtes fetch, les autres méthodes comme POST et DELETE ne sont pas mémorisées. Ce comportement par défaut est une optimisation de React et nous ne recommandons pas de le désactiver.

Pour gérer des requêtes individuelles, vous pouvez utiliser la propriété signal de AbortController. Cependant, cela ne désactivera pas la mémorisation des requêtes, mais annulera plutôt les requêtes en cours.

const { signal } = new AbortController()
fetch(url, { signal })

Cache de données

Next.js a un cache de données intégré qui persiste le résultat des récupérations de données entre les requêtes serveur entrantes et les déploiements. Ceci est possible car Next.js étend l'API native fetch pour permettre à chaque requête sur le serveur de définir sa propre sémantique de cache persistante.

Bon à savoir : Dans le navigateur, l'option cache de fetch indique comment une requête interagit avec le cache HTTP du navigateur, dans Next.js, l'option cache indique comment une requête côté serveur interagit avec le cache de données du serveur.

Vous pouvez utiliser les options cache et next.revalidate de fetch pour configurer le comportement de mise en cache.

Fonctionnement du cache de données

• La première fois qu'une requête fetch avec l'option 'force-cache' est appelée pendant le rendu, Next.js vérifie le cache de données pour une réponse mise en cache.
• Si une réponse mise en cache est trouvée, elle est retournée immédiatement et mémorisée.
• Si aucune réponse mise en cache n'est trouvée, la requête est faite vers la source de données, le résultat est stocké dans le cache de données et mémorisé.
• Pour les données non mises en cache (par exemple aucune option cache définie ou utilisant { cache: 'no-store' }), le résultat est toujours récupéré depuis la source de données et mémorisé.
• Que les données soient mises en cache ou non, les requêtes sont toujours mémorisées pour éviter de faire des requêtes en double pour les mêmes données pendant un passage de rendu React.

Différences entre le cache de données et la mémorisation des requêtes

Bien que les deux mécanismes de cache aident à améliorer les performances en réutilisant les données mises en cache, le cache de données est persistant entre les requêtes entrantes et les déploiements, tandis que la mémorisation ne dure que le temps de vie d'une requête.

Durée

Le cache de données est persistant entre les requêtes entrantes et les déploiements, sauf si vous le revalidez ou le désactivez.

Revalidation

Les données mises en cache peuvent être revalidées de deux manières, avec :

• Revalidation basée sur le temps : Revalider les données après un certain temps écoulé et une nouvelle requête effectuée. Ceci est utile pour les données qui changent rarement et où la fraîcheur n'est pas aussi critique.
• Revalidation à la demande : Revalider les données en fonction d'un événement (par exemple une soumission de formulaire). La revalidation à la demande peut utiliser une approche basée sur des tags ou des chemins pour revalider des groupes de données à la fois. Ceci est utile lorsque vous voulez vous assurer que les données les plus récentes sont affichées dès que possible (par exemple lorsque le contenu de votre CMS headless est mis à jour).

Revalidation basée sur le temps

Pour revalider les données à intervalles réguliers, vous pouvez utiliser l'option next.revalidate de fetch pour définir la durée de vie du cache d'une ressource (en secondes).

// Revalider au maximum toutes les heures
fetch('https://...', { next: { revalidate: 3600 } })

Alternativement, vous pouvez utiliser les options de configuration de segment de route pour configurer toutes les requêtes fetch dans un segment ou pour les cas où vous ne pouvez pas utiliser fetch.

Fonctionnement de la revalidation basée sur le temps

• La première fois qu'une requête fetch avec revalidate est appelée, les données seront récupérées depuis la source de données externe et stockées dans le cache de données.
• Toutes les requêtes appelées dans la période spécifiée (par exemple 60 secondes) retourneront les données mises en cache.
• Après cette période, la prochaine requête retournera toujours les données mises en cache (maintenant périmées).
  • Next.js déclenchera une revalidation des données en arrière-plan.
  • Une fois les données récupérées avec succès, Next.js mettra à jour le cache de données avec les nouvelles données.
  • Si la revalidation en arrière-plan échoue, les données précédentes seront conservées inchangées.

Ce comportement est similaire à stale-while-revalidate.

Revalidation à la demande

Les données peuvent être revalidées à la demande par chemin (revalidatePath) ou par tag de cache (revalidateTag).

Fonctionnement de la revalidation à la demande

• La première fois qu'une requête fetch est appelée, les données seront récupérées depuis la source de données externe et stockées dans le cache de données.
• Lorsqu'une revalidation à la demande est déclenchée, les entrées de cache appropriées seront purgées du cache.
  • Ceci est différent de la revalidation basée sur le temps, qui conserve les données périmées dans le cache jusqu'à ce que les nouvelles données soient récupérées.
• La prochaine fois qu'une requête est faite, ce sera à nouveau un cache MISS, et les données seront récupérées depuis la source de données externe et stockées dans le cache de données.

Désactivation

Si vous ne voulez pas mettre en cache la réponse de fetch, vous pouvez faire ce qui suit :

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

Cache complet de route

Termes associés :

Vous pouvez voir les termes Optimisation statique automatique, Génération de site statique ou Rendu statique utilisés de manière interchangeable pour désigner le processus de rendu et de mise en cache des routes de votre application au moment de la construction.

Next.js rend et met en cache automatiquement les routes au moment de la construction. Ceci est une optimisation qui vous permet de servir la route mise en cache au lieu de la rendre sur le serveur pour chaque requête, ce qui entraîne des chargements de page plus rapides.

Pour comprendre comment fonctionne le cache complet de route, il est utile de regarder comment React gère le rendu et comment Next.js met en cache le résultat :

1. Rendu React sur le serveur

Sur le serveur, Next.js utilise les API de React pour orchestrer le rendu. Le travail de rendu est divisé en morceaux : par segments de route individuels et par limites Suspense.

Chaque morceau est rendu en deux étapes :

1. React rend les Server Components dans un format de données spécial, optimisé pour le streaming, appelé React Server Component Payload.
2. Next.js utilise le React Server Component Payload et les instructions JavaScript des Client Components pour rendre le HTML sur le serveur.

Cela signifie que nous n'avons pas besoin d'attendre que tout soit rendu avant de mettre en cache le travail ou d'envoyer une réponse. Au lieu de cela, nous pouvons diffuser une réponse au fur et à mesure que le travail est terminé.

Qu'est-ce que le React Server Component Payload ?

Le React Server Component Payload est une représentation binaire compacte de l'arbre des Server Components rendus. Il est utilisé par React côté client pour mettre à jour le DOM du navigateur. Le React Server Component Payload contient :

• Le résultat rendu des Server Components
• Des espaces réservés pour les Client Components qui doivent être rendus et des références à leurs fichiers JavaScript
• Toutes les props passées d'un Server Component à un Client Component

Pour en savoir plus, consultez la documentation des Server Components.

2. Mise en cache par Next.js sur le serveur (Cache complet de route)

Le comportement par défaut de Next.js est de mettre en cache le résultat rendu (React Server Component Payload et HTML) d'une route sur le serveur. Ceci s'applique aux routes rendues statiquement au moment de la construction ou pendant la revalidation.

3. Hydratation et réconciliation React côté client

Au moment de la requête, côté client :

1. Le HTML est utilisé pour afficher immédiatement un aperçu initial rapide et non interactif des Client et Server Components.
2. Le React Server Components Payload est utilisé pour réconcilier les arbres des Client et Server Components rendus et mettre à jour le DOM.
3. Les instructions JavaScript sont utilisées pour hydrater les Client Components et rendre l'application interactive.

4. Mise en cache par Next.js côté client (Cache du routeur)

Le React Server Component Payload est stocké dans le cache du routeur côté client - un cache en mémoire séparé, divisé par segments de route individuels. Ce cache du routeur est utilisé pour améliorer l'expérience de navigation en stockant les routes précédemment visitées et en préchargeant les routes futures.

5. Navigations ultérieures

Lors des navigations ultérieures ou pendant le préchargement, Next.js vérifiera si le React Server Components Payload est stocké dans le cache du routeur. Si c'est le cas, il évitera d'envoyer une nouvelle requête au serveur.

Si les segments de route ne sont pas dans le cache, Next.js récupérera le React Server Components Payload depuis le serveur et peuplera le cache du routeur côté client.

Rendu statique et dynamique

Le fait qu'une route soit mise en cache ou non au moment de la construction dépend du fait qu'elle soit rendue de manière statique ou dynamique. Les routes statiques sont mises en cache par défaut, tandis que les routes dynamiques sont rendues au moment de la requête et ne sont pas mises en cache.

Ce diagramme illustre la différence entre les routes rendues statiquement et dynamiquement, avec des données mises en cache ou non :

En savoir plus sur le rendu statique et dynamique.

Durée

Par défaut, le cache complet de la route est persistant. Cela signifie que le résultat du rendu est mis en cache entre les requêtes des utilisateurs.

Invalidation

Il existe deux façons d'invalider le cache complet de la route :

• Revalidation des données : Revalider le cache de données invalidera également le cache du routeur en re-rendant les composants sur le serveur et en mettant en cache le nouveau résultat de rendu.
• Redéploiement : Contrairement au cache de données, qui persiste entre les déploiements, le cache complet de la route est effacé lors de nouveaux déploiements.

Désactivation

Vous pouvez désactiver le cache complet de la route, ou en d'autres termes, rendre dynamiquement les composants pour chaque requête entrante, en :

• Utilisant une API dynamique : Cela exclura la route du cache complet de la route et la rendra dynamiquement au moment de la requête. Le cache de données peut toujours être utilisé.
• Utilisant les options de configuration de segment de route dynamic = 'force-dynamic' ou revalidate = 0 : Cela ignorera le cache complet de la route et le cache de données. Les composants seront rendus et les données récupérées à chaque requête entrante vers le serveur. Le cache du routeur s'appliquera toujours car il s'agit d'un cache côté client.
• Désactivant le cache de données : Si une route a une requête fetch qui n'est pas mise en cache, cela exclura la route du cache complet de la route. Les données pour la requête fetch spécifique seront récupérées pour chaque requête entrante. Les autres requêtes fetch qui ne désactivent pas la mise en cache seront toujours mises en cache dans le cache de données. Cela permet un mélange de données mises en cache et non mises en cache.

Cache côté client du routeur

Next.js dispose d'un cache de routeur côté client en mémoire qui stocke la charge utile RSC des segments de route, divisés par les mises en page, les états de chargement et les pages.

Lorsqu'un utilisateur navigue entre les routes, Next.js met en cache les segments de route visités et précharge les routes vers lesquelles l'utilisateur est susceptible de naviguer. Cela permet une navigation instantanée en arrière/avant, aucun rechargement complet de page entre les navigations, et la préservation de l'état React et de l'état du navigateur.

Avec le cache du routeur :

• Les mises en page sont mises en cache et réutilisées lors de la navigation (rendu partiel).
• Les états de chargement sont mis en cache et réutilisés lors de la navigation pour une navigation instantanée.
• Les pages ne sont pas mises en cache par défaut, mais sont réutilisées lors de la navigation en arrière et en avant dans le navigateur. Vous pouvez activer la mise en cache pour les segments de page en utilisant l'option de configuration expérimentale staleTimes.

Bon à savoir : Ce cache s'applique spécifiquement à Next.js et aux composants serveur, et est différent du bfcache du navigateur, bien qu'il ait un résultat similaire.

Durée

Le cache est stocké dans la mémoire temporaire du navigateur. Deux facteurs déterminent la durée de vie du cache du routeur :

• Session : Le cache persiste entre les navigations. Cependant, il est effacé lors du rafraîchissement de la page.
• Période d'invalidation automatique : Le cache des mises en page et des états de chargement est automatiquement invalidé après un certain temps. La durée dépend de la façon dont la ressource a été préchargée, et si la ressource a été générée statiquement :
  • Préchargement par défaut (prefetch={null} ou non spécifié) : non mis en cache pour les pages dynamiques, 5 minutes pour les pages statiques.
  • Préchargement complet (prefetch={true} ou router.prefetch) : 5 minutes pour les pages statiques et dynamiques.

Bien qu'un rafraîchissement de page efface tous les segments mis en cache, la période d'invalidation automatique n'affecte que le segment individuel à partir du moment où il a été préchargé.

Bon à savoir : L'option de configuration expérimentale staleTimes peut être utilisée pour ajuster les temps d'invalidation automatique mentionnés ci-dessus.

Invalidation

Il existe deux façons d'invalider le cache du routeur :

• Dans une action serveur :
  • Revalider les données à la demande par chemin avec (revalidatePath) ou par étiquette de cache avec (revalidateTag)
  • Utiliser cookies.set ou cookies.delete invalide le cache du routeur pour éviter que les routes utilisant des cookies ne deviennent obsolètes (par exemple, l'authentification).
• Appeler router.refresh invalidera le cache du routeur et fera une nouvelle requête au serveur pour la route actuelle.

Désactivation

À partir de Next.js 15, les segments de page sont désactivés par défaut.

Bon à savoir : Vous pouvez également désactiver le préchargement en définissant la prop prefetch du composant <Link> sur false.

Interactions entre les caches

Lors de la configuration des différents mécanismes de cache, il est important de comprendre comment ils interagissent entre eux :

Cache de données et cache complet de la route

• Revalider ou désactiver le cache de données invalidera le cache complet de la route, car le résultat du rendu dépend des données.
• Invalider ou désactiver le cache complet de la route n'affecte pas le cache de données. Vous pouvez rendre dynamiquement une route qui a à la fois des données mises en cache et non mises en cache. Cela est utile lorsque la plupart de votre page utilise des données mises en cache, mais que vous avez quelques composants qui dépendent de données qui doivent être récupérées au moment de la requête. Vous pouvez rendre dynamiquement sans vous soucier de l'impact sur les performances de la récupération de toutes les données.

Cache de données et cache côté client du routeur

• Pour invalider immédiatement le cache de données et le cache du routeur, vous pouvez utiliser revalidatePath ou revalidateTag dans une action serveur.
• Revalider le cache de données dans un gestionnaire de route n'invalidera pas immédiatement le cache du routeur car le gestionnaire de route n'est pas lié à une route spécifique. Cela signifie que le cache du routeur continuera à servir la charge utile précédente jusqu'à un rafraîchissement complet ou jusqu'à l'expiration de la période d'invalidation automatique.

APIs

Le tableau suivant donne un aperçu de la façon dont les différentes APIs Next.js affectent la mise en cache :

<Link>

Par défaut, le composant <Link> précharge automatiquement les routes depuis le cache complet de la route et ajoute la charge utile du composant serveur React au cache du routeur.

Pour désactiver le préchargement, vous pouvez définir la prop prefetch sur false. Mais cela ne désactivera pas le cache de manière permanente, le segment de route sera toujours mis en cache côté client lorsque l'utilisateur visitera la route.

En savoir plus sur le composant <Link>.

router.prefetch

L'option prefetch du hook useRouter peut être utilisée pour précharger manuellement une route. Cela ajoute la charge utile du composant serveur React au cache du routeur.

Voir la référence de l'API du hook useRouter.

router.refresh

L'option refresh du hook useRouter peut être utilisée pour rafraîchir manuellement une route. Cela efface complètement le cache du routeur et fait une nouvelle requête au serveur pour la route actuelle. refresh n'affecte pas le cache de données ou le cache complet de la route.

Le résultat rendu sera réconcilié côté client tout en préservant l'état React et l'état du navigateur.

Voir la référence de l'API du hook useRouter.

fetch

Les données retournées par fetch ne sont pas automatiquement mises en cache dans le cache de données.

Le comportement de mise en cache par défaut de fetch (par exemple, lorsque l'option cache n'est pas spécifiée) est équivalent à définir l'option cache sur no-store :

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

Voir la référence de l'API fetch pour plus d'options.

fetch options.cache

Vous pouvez activer la mise en cache pour une requête fetch individuelle en définissant l'option cache sur force-cache :

// Activer la mise en cache
fetch(`https://...`, { cache: 'force-cache' })

Voir la référence de l'API fetch pour plus d'options.

fetch options.next.revalidate

Vous pouvez utiliser l'option next.revalidate de fetch pour définir la période de revalidation (en secondes) d'une requête fetch individuelle. Cela revalidera le cache de données, ce qui à son tour revalidera le cache complet de la route. Les données fraîches seront récupérées et les composants seront re-rendus sur le serveur.

// Revalider au maximum après 1 heure
fetch(`https://...`, { next: { revalidate: 3600 } })

Voir la référence de l'API fetch pour plus d'options.

fetch options.next.tags et revalidateTag

Next.js dispose d'un système d'étiquetage de cache pour une mise en cache et une revalidation fine des données.

1. Lors de l'utilisation de fetch ou de unstable_cache, vous avez la possibilité d'étiqueter les entrées de cache avec une ou plusieurs étiquettes.
2. Ensuite, vous pouvez appeler revalidateTag pour purger les entrées de cache associées à cette étiquette.

Par exemple, vous pouvez définir une étiquette lors de la récupération des données :

// Mettre en cache les données avec une étiquette
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })

Ensuite, appelez revalidateTag avec une étiquette pour purger l'entrée de cache :

// Revalider les entrées avec une étiquette spécifique
revalidateTag('a')

Il existe deux endroits où vous pouvez utiliser revalidateTag, selon ce que vous essayez d'atteindre :

1. Gestionnaires de route - pour revalider les données en réponse à un événement tiers (par exemple, un webhook). Cela n'invalidera pas immédiatement le cache du routeur car le gestionnaire de route n'est pas lié à une route spécifique.
2. Actions serveur - pour revalider les données après une action utilisateur (par exemple, la soumission d'un formulaire). Cela invalidera le cache du routeur pour la route associée.

revalidatePath

revalidatePath vous permet de revalider manuellement les données et de re-rendre les segments de route sous un chemin spécifique en une seule opération. L'appel de la méthode revalidatePath revalide le cache de données, ce qui à son tour invalide le cache complet de la route.

revalidatePath('/')

Il existe deux endroits où vous pouvez utiliser revalidatePath, selon ce que vous essayez d'atteindre :

1. Gestionnaires de route - pour revalider les données en réponse à un événement tiers (par exemple, un webhook).
2. Actions serveur - pour revalider les données après une interaction utilisateur (par exemple, la soumission d'un formulaire, un clic sur un bouton).

Voir la référence de l'API revalidatePath pour plus d'informations.

revalidatePath vs. router.refresh :

Appeler router.refresh effacera le cache du routeur et re-rendra les segments de route sur le serveur sans invalider le cache de données ou le cache complet de la route.

La différence est que revalidatePath purge le cache de données et le cache complet de la route, tandis que router.refresh() ne modifie pas le cache de données et le cache complet de la route, car il s'agit d'une API côté client.

APIs dynamiques

Les APIs dynamiques comme cookies et headers, ainsi que la prop searchParams dans les pages dépendent des informations de requête entrante en temps réel. Leur utilisation exclura une route du cache complet de la route, en d'autres termes, la route sera rendue dynamiquement.

cookies

L'utilisation de cookies.set ou cookies.delete dans une action serveur invalide le cache du routeur pour éviter que les routes utilisant des cookies ne deviennent obsolètes (par exemple, pour refléter les changements d'authentification).

Voir la référence de l'API cookies.

Options de Configuration des Segments de Route

Les options de configuration des segments de route peuvent être utilisées pour remplacer les valeurs par défaut d'un segment de route ou lorsque vous ne pouvez pas utiliser l'API fetch (par exemple, avec un client de base de données ou des bibliothèques tierces).

Les options de configuration de segment de route suivantes désactiveront le cache complet de route (Full Route Cache) :

• const dynamic = 'force-dynamic'

Cette option de configuration désactivera le cache de données (Data Cache) pour toutes les requêtes (c'est-à-dire no-store) :

• const fetchCache = 'default-no-store'

Consultez fetchCache pour voir des options plus avancées.

Consultez la documentation Configuration des Segments de Route pour plus d'options.

generateStaticParams

Pour les segments dynamiques (par exemple app/blog/[slug]/page.js), les chemins fournis par generateStaticParams sont mis en cache dans le Full Route Cache lors de la construction. Au moment de la requête, Next.js mettra également en cache les chemins qui n'étaient pas connus lors de la construction lors de leur première visite.

Pour rendre statiquement tous les chemins lors de la construction, fournissez la liste complète des chemins à generateStaticParams :

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  return posts.map((post) => ({
    slug: post.slug,
  }))
}

Pour rendre statiquement un sous-ensemble de chemins lors de la construction, et le reste lors de leur première visite au moment de l'exécution, retournez une liste partielle de chemins :

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  // Rend les 10 premiers articles lors de la construction
  return posts.slice(0, 10).map((post) => ({
    slug: post.slug,
  }))
}

Pour rendre statiquement tous les chemins lors de leur première visite, retournez un tableau vide (aucun chemin ne sera rendu lors de la construction) ou utilisez export const dynamic = 'force-static' :

export async function generateStaticParams() {
  return []
}

Bon à savoir : Vous devez retourner un tableau depuis generateStaticParams, même s'il est vide. Sinon, la route sera rendue dynamiquement.

export const dynamic = 'force-static'

Pour désactiver la mise en cache au moment de la requête, ajoutez l'option export const dynamicParams = false dans un segment de route. Lorsque cette option est utilisée, seuls les chemins fournis par generateStaticParams seront servis, et les autres routes renverront une erreur 404 ou correspondront (dans le cas des routes catch-all).

Fonction cache de React

La fonction cache de React permet de mémoïser la valeur de retour d'une fonction, vous permettant d'appeler la même fonction plusieurs fois tout en ne l'exécutant qu'une seule fois.

Comme les requêtes fetch sont automatiquement mémoïsées, vous n'avez pas besoin de les encapsuler dans cache de React. Cependant, vous pouvez utiliser cache pour mémoïser manuellement des requêtes de données dans des cas d'utilisation où l'API fetch n'est pas adaptée. Par exemple, certains clients de base de données, clients CMS ou clients GraphQL.

import { cache } from 'react'
import db from '@/lib/db'

export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})