Sous le capot
du site.
Vous aussi, vous regardez comment c’est construit ? On devrait bien s’entendre. Voici quelques choix que j’ai faits pour ce site vitrine, avec leurs raisons et leurs limites.
Le contenu arrive dans le HTML
Les pages éditoriales utilisent les Server Components de Next.js. Cette page est générée au build : son texte et ses liens sont lisibles sans attendre l’exécution du JavaScript dans le navigateur.
Les interactions comme le menu mobile et le bouton de thème utilisent des composants client. Le contenu reste accessible si JavaScript est désactivé.
Du contenu typé, dans le dépôt
Les articles du Journal sont des objets TypeScript ; les textes des pages sont écrits dans les composants React. Chaque modification peut donc être relue avec le code dans une pull request.
Ce fonctionnement convient à mon rythme de publication. Il demande de modifier le dépôt et de reconstruire le site pour publier un changement.
Deux thèmes avec les mêmes composants
Les couleurs sont centralisées dans des variables CSS. La préférence système détermine le thème initial ; le bouton permet de le choisir et de le mémoriser dans le navigateur.
Si le stockage est indisponible, le bouton reste utilisable pendant la visite. La mise en page s’adapte à la largeur disponible avec des requêtes de conteneur CSS.
Des vérifications sur les comportements
Les tests Node.js vérifient notamment les filtres et la pagination du Journal, l’exclusion des brouillons et les relations entre les données structurées. Le lint et le build complètent ces contrôles.
Ces vérifications ne remplacent pas une relecture du contenu ni un contrôle du rendu sur mobile, au clavier et dans les deux thèmes.