V2 700 dynamic page migration

[Fansoa]

Related issue

#700

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é.

[CinquinAndy]

perfeeect

[Fansoa]

b651c19

J'ai apporté des améliorations au code, mais je pense qu'il est encore possible d'optimiser en externalisant certaines logiques dans un hook.

Je vais tester l'impact sur les rerenders si je déplace cette logique dans un hook.
Il est important d'analyser la logique avant et après cette modification.
Initialement, la page Search était en CSR (Client-Side Rendering), mais elle est désormais rendue en SSR (Server-Side Rendering). Les composants NAV et FOOTER sont maintenant générés côté serveur.

La partie CSR est concentrée dans le fichier SearchContainer.

Les données des inputs du formulaire sont remontées au parent via l'objet l'API URLSearchParams. Cela me permet de ne pas utiliser de setState pour propager les données aux enfants, ce qui évite les rerenders inutiles.

De plus, la fonction onSubmit est utilisée pour fetcher les données et interagir avec le useReducer. Ce dernier gère plusieurs états : Idle, Pending, Success, et Error.

Grâce à ces états, l'interface propose quatre affichages distincts :

Lors de l'arrivée sur la page, une phrase invite l'utilisateur à remplir le formulaire.
Pendant la recherche, un loader s'affiche jusqu'à ce que la requête soit résolue.
Une fois la requête terminée, une liste de cartes est affichée.
En cas d'erreur, un message spécifique peut être présenté.
Je constate qu'une fois la liste de maquilleurs affichée, rien ne s'affiche lorsque les résultats sont vides. Il serait pertinent d'ajouter un message CTA (Call to Action) encourageant l'utilisateur à interagir de nouveau avec le formulaire.