Composition, mise en cache et architecture dans Next.js moderne

Aurora présente les modèles de composition, de mise en cache et d'architecture pour l'évolutivité et la performance dans Next.js moderne. Elle rafraîchit les concepts de rendu statique et dynamique, expliquant que le statique offre rapidité, mise en cache globale, réduction de la charge serveur et meilleur SEO (ex: site Next.js Conf). Le dynamique permet des données en temps réel, du contenu personnalisé (ex: tableau de bord Vercel) et l'accès à des informations connues uniquement à la requête. Cette section pose les bases essentielles pour comprendre les défis et les solutions abordées par la suite. Des API comme `params`, `search params`, la lecture des cookies et en-têtes, ou `fetch` avec `no store` peuvent forcer un rendu dynamique.

Auparavant, une page était soit entièrement statique, soit entièrement dynamique, une seule API dynamique basculant toute la page en dynamique. L'utilisation de React Server Components avec `Suspense` permet de diffuser du contenu dynamique, mais l'ajout de plusieurs composants asynchrones sur une page dynamique entraînait un travail supplémentaire pour la diffusion et la gestion des `fallbacks` (squelettes, décalage de mise en page). Ce segment met en évidence les inefficiences et les compromis auxquels les développeurs étaient confrontés, justifiant l'introduction de nouvelles solutions. Les applications e-commerce, qui mélangent souvent contenu statique et dynamique, souffraient particulièrement de cette contrainte, entraînant un traitement serveur redondant et une performance sous-optimale.

La directive `use cache`, annoncée à la Next.js Conf et disponible dans Next.js 16, révolutionne le rendu en permettant aux pages d'être à la fois statiques et dynamiques. Next.js n'a plus à deviner la nature d'une page ; tout est dynamique par défaut, et `use cache` permet d'opter explicitement pour la mise en cache. Cette fonctionnalité est la pierre angulaire des améliorations de performance et d'architecture présentées dans la démonstration. `use cache` permet une mise en cache composable, où une page, un composant React ou une fonction peut être marqué comme cacheable. Par exemple, un composant de produits vedettes peut être mis en cache, pré-rendu et inclus dans le 'shell' statique via le pré-rendu partiel.

La démonstration utilise une application e-commerce simple pour illustrer des problèmes courants : le 'prop drilling' profond, le JavaScript côté client redondant, les composants volumineux avec de multiples responsabilités, et le manque de rendu statique. L'application inclut des pages d'accueil, de navigation, de produit, 'À propos', et un tableau de bord utilisateur personnalisé, présentant un mélange de contenu statique et dynamique. Cette section prépare le terrain pour les solutions pratiques en montrant une base de code réelle avec des défauts typiques. L'objectif est d'améliorer l'application avec des modèles de composition, de mise en cache et d'architecture pour la rendre plus rapide, évolutive et facile à maintenir, en dépit d'un ralentissement délibéré des requêtes pour la démonstration.

Le problème du 'prop drilling' est illustré par une variable `logged in` passée à travers plusieurs composants, rendant la réutilisation difficile. La solution consiste à pousser la récupération de données vers les composants qui les utilisent et à résoudre les promesses plus profondément dans l'arbre, en utilisant `fetch` ou `React cache`. Un `AuthProvider` est créé dans le `root layout` pour envelopper l'application et passer la promesse d'authentification. Ce modèle améliore la réutilisabilité et la maintenabilité des composants, un aspect crucial pour les applications complexes. Le composant `CustomBanner` utilise `useAuth` et `use` pour lire localement la valeur d'authentification, et est enveloppé de `Suspense` pour éviter de bloquer le chargement de la page, rendant la bannière composable et réutilisable sans dépendances externes.

Le 'donut pattern' est introduit pour résoudre le problème des composants serveur convertis en client à cause d'une petite logique interactive. La `WelcomeBanner`, initialement un composant client à cause d'un simple état `dismissed`, est refactorisée : la logique interactive est extraite dans un `BannerContainer` côté client qui prend des `children` (le contenu serveur). Ce modèle est essentiel pour maximiser le rendu côté serveur et minimiser la charge de JavaScript sur le client, améliorant ainsi les performances. La `WelcomeBanner` redevient un composant serveur asynchrone, récupérant directement les données côté serveur avec sécurité de type. Le même modèle est appliqué pour les animations `Motion` et les catégories du pied de page avec un composant `ShowMore`, démontrant la polyvalence du 'donut pattern'.

L'application souffre d'un rendu entièrement dynamique, entraînant des coûts serveur et des performances dégradées, souvent à cause d'une API dynamique dans le `root layout` (ex: `UserProfile` utilisant des cookies). Les solutions traditionnelles (groupes de routes, 'precompute pattern') sont jugées complexes. Next.js 16 active les composants de cache, rendant les appels asynchrones dynamiques par défaut et introduisant la directive `use cache`. Cette section montre comment `use cache` simplifie l'optimisation du rendu en évitant les solutions de contournement complexes. En appliquant `use cache` à des composants comme `Hero`, `FeaturedCategories` et `FeaturedProducts` sur la page d'accueil, qui ne dépendent pas d'API dynamiques, ils sont pré-rendus statiquement et inclus dans le 'shell' statique via le pré-rendu partiel, réduisant la complexité et améliorant la vitesse de chargement.

La page 'Parcourir tout' présentait une route bloquante due à la récupération des catégories au niveau supérieur sans `Suspense`, causant une mauvaise UX. L'activation des composants de cache aide à identifier ces problèmes. La solution consiste à déplacer la récupération des données des catégories dans le composant `ResponsiveCategoryFilters` et à y appliquer `use cache`, l'incluant dans le 'static shell'. Cette partie illustre comment une meilleure architecture de composants est encouragée par les nouvelles fonctionnalités de Next.js. Les `search params`, étant une API dynamique, ne peuvent pas être mis en cache directement. Ils sont passés comme une promesse au composant `ProductList` et résolus plus profondément, permettant à la majeure partie de la page d'être pré-rendue statiquement tandis que la liste des produits reste dynamique pour la recherche.

La page produit, cruciale et complexe, est optimisée en appliquant `use cache` au produit et aux détails du produit. Le 'donut pattern' est réutilisé pour encapsuler des segments dynamiques (ex: bouton 'Enregistrer le produit') dans des segments cacheables, permettant une UI presque entièrement disponible instantanément. `generate static params` est utilisé pour pré-rendre certaines pages produit et mettre en cache les autres à la volée. Cette section conclut la démonstration en montrant l'efficacité combinée de tous les modèles appris. La démonstration finale de l'application déployée sur Vercel montre des chargements instantanés et un score Lighthouse de 100 sur les pages importantes. Les trois modèles clés sont résumés : affiner l'architecture, composer les composants serveur/client avec le 'donut pattern', et mettre en cache/pré-rendre avec `use cache` et `Suspense` pour le contenu dynamique.