Lorsque l'on développe une application NextJS il est fréquent de vouloir définir des mises en pages communes entre nos différentes pages.
Se pose alors le problème de la réutilisation. La documentation officielle nous propose une approche certes pratique mais un peu sommaire de comment gérer ses mises en page.
Elle se décompose en 3 choses :
Commençons par le fichier de définitions de types, ici on a CodingSparkAppProps qui sont nos propriétés qui seront utilisées dans pages/_app.tsx puis on définit CodingSparkPageLayoutProps qui surcharge un type assez générique LayoutArgs avec les layouts qui sont disponibles pour notre application.
On étends bien évidemment les types par défaut de NextJS : NextPage.
Dans le fichier qui suit on notera que par défaut on gère un layout « none » ce qui signifie qu'il n'y a pas de mise en page. C'est utile dans le cas où vous n'avez pas encore migré l'intégralité de vos pages vers ce système de layout.
Ici car on en a peu, on part sur un switch/case mais on pourrait bien utiliser une table de correspondance comme une Map ou un objet. C'est d'ailleurs ce que je vous invite à faire si vous commencez à avoir beaucoup de layouts.
À noter qu'on utilise next/dynamic pour ne charger les layouts que lorsqu'ils sont utilisés afin de d'optimiser les premiers chargements de l'application avec du chunking.
Enfin très simplement on va aller « Taguer » notre page avec les meta-données que l'ont a définies plus haut dans le fichier d'interfaces.
And voilà, rien de bien compliqué on profite même de l'auto-complétion !
La dernière chose qu'il nous reste à faire et brancher nos layouts avec notre application, pour se faire on procède de la sorte dans le fichier page/_app.tsx.
Il ne reste plus qu'à savourer le doux parfum de la réussite… 😌