Configuration des segments de route

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

Les options des segments 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

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'

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 des pages 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îne le rendu des routes pour chaque utilisateur au moment de la requête. Cette option équivaut à :
  • 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 APIs dynamiques ou des données non mises en cache. Cette option équivaut à :
  • 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' sont disponibles 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,

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 devez 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 (Streaming Server Rendering).

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 les requêtes fetch individuelles.

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

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 l'utilisation d'une API dynamique. Sémantiquement équivalent à revalidate: Infinity, ce qui signifie que la ressource devrait être mise en cache indéfiniment. Il est toujours possible pour les 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.
• 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 inchangées.
• 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'.
• 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 plus petite valeur revalidate 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 plus basse que 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'

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'

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

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

preferredRegion

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

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 preferredRegion n'est pas spécifié, il héritera de l'option du layout parent le plus proche.
• Le layout racine est défini par défaut sur toutes les régions (all).

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 de 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

export const maxDuration = 5

Bon à savoir :

• Si vous utilisez Actions serveur, définissez maxDuration au niveau de la page pour modifier 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