Migration des pages Dynamiques

[Fansoa]

Page dynamiques

/

• blog
• contact
• search
• site-map
• toutes-les-news

blog/

• [id]

profil

• [username]

talent

• [slug]

[Fansoa]

En ce qui concerne la page blog/[id], il y a un comportement inattendu: un class tailwind ne semble pas s'appliquer à une des balises html: my-48

Env prod cela fonctionne.
Env dev, et builder cela ne fonctionne pas.

[Fansoa]

En ce qui concerne la page blog/[id], il y a un comportement inattendu: un class tailwind ne semble pas s'appliquer à une des balises html: my-48

Env prod cela fonctionne. Env dev, et builder cela ne fonctionne pas.

resolved

[Fansoa]

Explications sur la migration des pages dynamiques

Récupération des données

Dans le contexte de l'App Router et d'un composant rendu côté serveur (SSR), la récupération des données ne s'effectue plus via getStaticProps, mais directement au sein de la fonction du composant.

Les appels à l'API sont centralisés dans des services, et les fonctions liées à ces appels sont stockées dans services/utils. Par exemple, la fonction convertMarkdownToHtml située dans le fichier services/utils permet de convertir du markdown en HTML.

Génération statique des pages dynamiques

Dans le cadre de l'App Router, la génération statique des pages dynamiques ne passe plus par getStaticPaths, mais par generateStaticParams. L'équipe de Next.js a opté pour un nommage plus explicite. Il est possible de rediriger l'utilisateur vers la page parente not-found la plus proche dans l'arborescence des fichiers si la page demandée n'a pas été générée. Pour cela, il faut exporter une constante dynamicParams assignée à false dynamicParams.

Les Métadonnées

Pour les pages dynamiques, si l'on souhaite disposer de métadonnées variables en fonction de la page, il est nécessaire d'effectuer une requête pour récupérer les données, contrairement au Page Router où les métadonnées sont directement définies dans le composant.

Pas d'inquiétude pour les performances : Next.js met automatiquement en cache les requêtes API effectuées dans ses pages, ce qui évite tout double appel à l'API. D'ailleurs, cela n'aurait pas été problématique dans notre cas, puisque les pages sont générées statiquement, donc l'utilisateur n'aurait pas été impacté.