Configuration des segments de route

Les options décrites sur cette page sont désactivées si le drapeau dynamicIO est activé, et seront finalement dépréciées à l'avenir.

Les options de segment de route vous permettent de configurer le comportement d'une Page, d'un Layout ou d'un Gestionnaire de route en exportant directement les variables suivantes :

Options

experimental_ppr

Active le Prérendu partiel (PPR) pour un layout ou une page.

export const experimental_ppr = true
// true | false

dynamic

Modifie le comportement dynamique d'un layout ou d'une page pour les rendre entièrement statiques ou entièrement dynamiques.

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

Bon à savoir : Le nouveau modèle dans le répertoire app favorise un contrôle granulaire du cache au niveau des requêtes fetch plutôt que le modèle binaire tout ou rien de getServerSideProps et getStaticProps au niveau de la page dans le répertoire pages. L'option dynamic est un moyen de revenir à l'ancien modèle pour faciliter la migration.

• 'auto' (par défaut) : L'option par défaut qui met en cache autant que possible sans empêcher les composants d'opter pour un comportement dynamique.
• 'force-dynamic' : Force le rendu dynamique, ce qui entraînera le rendu des routes pour chaque utilisateur au moment de la requête. Cette option est équivalente à :
  • Définir l'option de chaque requête fetch() dans un layout ou une page à { cache: 'no-store', next: { revalidate: 0 } }.
  • Définir la configuration du segment à export const fetchCache = 'force-no-store'.
• 'error' : Force le rendu statique et met en cache les données d'un layout ou d'une page en provoquant une erreur si des composants utilisent des API dynamiques ou des données non mises en cache. Cette option est équivalente à :
  • getStaticProps() dans le répertoire pages.
  • Définir l'option de chaque requête fetch() dans un layout ou une page à { cache: 'force-cache' }.
  • Définir la configuration du segment à fetchCache = 'only-cache', dynamicParams = false.
  • dynamic = 'error' change la valeur par défaut de dynamicParams de true à false. Vous pouvez revenir au rendu dynamique des pages pour les paramètres dynamiques non générés par generateStaticParams en définissant manuellement dynamicParams = true.
• 'force-static' : Force le rendu statique et met en cache les données d'un layout ou d'une page en forçant cookies, headers() et useSearchParams() à retourner des valeurs vides. Il est possible d'utiliser revalidate, revalidatePath ou revalidateTag dans les pages ou layouts rendus avec force-static.

Bon à savoir :

• Des instructions sur comment migrer depuis getServerSideProps et getStaticProps vers dynamic: 'force-dynamic' et dynamic: 'error' peuvent être trouvées dans le guide de mise à niveau.

dynamicParams

Contrôle ce qui se passe lorsqu'un segment dynamique est visité et qu'il n'a pas été généré avec generateStaticParams.

export const dynamicParams = true // true | false,

• true (par défaut) : Les segments dynamiques non inclus dans generateStaticParams sont générés à la demande.
• false : Les segments dynamiques non inclus dans generateStaticParams retourneront une erreur 404.

Bon à savoir :

• Cette option remplace l'option fallback: true | false | blocking de getStaticPaths dans le répertoire pages.
• Pour rendre statiquement tous les chemins la première fois qu'ils sont visités, vous devrez retourner un tableau vide dans generateStaticParams ou utiliser export const dynamic = 'force-static'.
• Lorsque dynamicParams = true, le segment utilise le Rendu côté serveur en streaming.

revalidate

Définit le temps de revalidation par défaut pour un layout ou une page. Cette option ne remplace pas la valeur revalidate définie par des requêtes fetch individuelles.

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

• false (par défaut) : L'heuristique par défaut pour mettre en cache toutes les requêtes fetch qui définissent leur option cache à 'force-cache' ou qui sont découvertes avant qu'une API dynamique ne soit utilisée. Sémantiquement équivalent à revalidate: Infinity, ce qui signifie que la ressource devrait être mise en cache indéfiniment. Il est toujours possible pour des requêtes fetch individuelles d'utiliser cache: 'no-store' ou revalidate: 0 pour éviter d'être mises en cache et rendre la route dynamiquement. Ou définir revalidate à un nombre positif inférieur à la valeur par défaut de la route pour augmenter la fréquence de revalidation d'une route.
• 0 : Garantit qu'un layout ou une page est toujours rendu dynamiquement même si aucune API dynamique ou requête de données non mise en cache n'est découverte. Cette option change la valeur par défaut des requêtes fetch qui ne définissent pas d'option cache à 'no-store' mais laisse les requêtes fetch qui optent pour 'force-cache' ou utilisent un revalidate positif telles quelles.
• number : (en secondes) Définit la fréquence de revalidation par défaut d'un layout ou d'une page à n secondes.

Bon à savoir :

• La valeur de revalidation doit être statiquement analysable. Par exemple, revalidate = 600 est valide, mais revalidate = 60 * 10 ne l'est pas.
• La valeur de revalidation n'est pas disponible lorsque runtime = 'edge' est utilisé.
• En développement, les pages sont toujours rendues à la demande et ne sont jamais mises en cache. Cela vous permet de voir les changements immédiatement sans attendre qu'une période de revalidation passe.

Fréquence de revalidation

• La valeur revalidate la plus basse parmi chaque layout et page d'une seule route déterminera la fréquence de revalidation de la route entière. Cela garantit que les pages enfants sont revalidées aussi fréquemment que leurs layouts parents.
• Les requêtes fetch individuelles peuvent définir une valeur revalidate inférieure à la valeur par défaut de la route pour augmenter la fréquence de revalidation de la route entière. Cela vous permet d'opter dynamiquement pour une revalidation plus fréquente pour certaines routes en fonction de certains critères.

fetchCache

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

runtime

Nous recommandons d'utiliser le runtime Node.js pour le rendu de votre application, et le runtime Edge pour le middleware.

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

• 'nodejs' (par défaut)
• 'edge'

preferredRegion

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

La prise en charge de preferredRegion, et des régions supportées, dépend de votre plateforme de déploiement.

Bon à savoir :

• Si une preferredRegion n'est pas spécifiée, elle héritera de l'option du layout parent le plus proche.
• Le layout racine est par défaut défini à toutes les régions.

maxDuration

Par défaut, Next.js ne limite pas l'exécution de la logique côté serveur (rendu d'une page ou gestion d'une API). Les plateformes de déploiement peuvent utiliser maxDuration depuis la sortie de build Next.js pour ajouter des limites d'exécution spécifiques.

Note : Ce paramètre nécessite Next.js 13.4.10 ou supérieur.

export const maxDuration = 5

Bon à savoir :

• Si vous utilisez des Actions serveur, définissez maxDuration au niveau de la page pour changer le délai d'expiration par défaut de toutes les Actions serveur utilisées sur la page.

generateStaticParams

La fonction generateStaticParams peut être utilisée en combinaison avec des segments de route dynamiques pour définir la liste des paramètres de segment de route qui seront générés statiquement au moment du build plutôt qu'à la demande au moment de la requête.

Voir la référence API pour plus de détails.

Historique des versions