Gestion du rendu et des données

1. Contexte : le triptyque SSG/SSR/ISR

Next.js offre aux développeurs plusieurs stratégies de rendu, adaptées aux différents besoins d’une application moderne. Deux approches principales dominent : le Static Site Generation (SSG) et le Server-Side Rendering (SSR).

Ces deux modèles ne sont pas exclusifs : Next.js permet de les combiner au sein d’une même application. Ainsi, un site peut parfaitement reposer sur des pages statiques pour son contenu éditorial, tout en proposant des sections dynamiques rendues côté serveur, comme un tableau de bord utilisateur ou une page de profil. En d’autres termes, le choix entre SSG et SSR n’est pas binaire, mais doit se faire page par page, selon la nature du contenu et les besoins métier.

2. Static Site Generation (SSG)

Le Static Site Generation repose sur une idée simple : générer les pages de l’application au moment du build, c’est-à-dire lors de l’exécution de la commande next build. Le rendu final produit alors des fichiers HTML statiques, déjà prêts à être servis. Ces fichiers peuvent être placés derrière un CDN et mis en cache, ce qui garantit une distribution extrêmement rapide et peu coûteuse en ressources serveur.

Ce mode de rendu est particulièrement adapté aux contenus qui ne changent pas ou peu dans le temps. Une fois compilée, la page reste identique pour tous les utilisateurs jusqu’à ce qu’un nouveau build soit lancé.

1. Définition et objectif

L’Incremental Static Regeneration désigne un mode de rendu propre à Next.js qui combine la rapidité du rendu statique avec la souplesse du rendu côté serveur. Une page est d’abord générée de façon statique et servie via le cache d’un CDN. Ensuite, elle peut être régénérée en arrière-plan à intervalles définis, sans nécessiter de rebuild global de l’application. Lorsqu’une nouvelle version est prête, elle remplace automatiquement l’ancienne et sera servie dès la requête suivante. Cette mécanique permet de conserver les avantages du statique tout en assurant un contenu actualisé de manière progressive.

L’ISR a pour finalité de trouver un équilibre entre les deux approches classiques que sont le rendu statique (SSG) et le rendu côté serveur (SSR). Le SSG garantit une vitesse optimale, mais fige le contenu jusqu’à un nouveau build. Le SSR, à l’inverse, permet d’obtenir des données toujours à jour, mais au prix d’une exécution plus lente et d’une sollicitation continue du serveur.

L’ISR s’inscrit comme une solution intermédiaire. Il sert immédiatement une page statique issue du cache, ce qui assure rapidité et scalabilité. En parallèle, il déclenche une régénération en arrière-plan après un délai configurable afin de rafraîchir le contenu sans interrompre l’expérience de navigation. Une fois cette mise à jour effectuée, la nouvelle version remplace la précédente et devient la référence pour les prochaines requêtes.

Ce fonctionnement permet de combiner la réactivité d’un site statique avec la fraîcheur d’un rendu dynamique, tout en maîtrisant la charge serveur. L’ISR apporte ainsi un compromis efficace entre performance, évolutivité et actualisation des données, ce qui en fait une option particulièrement adaptée aux projets nécessitant à la fois stabilité et renouvellement du contenu.

2. Fonctionnement avec...

1. Contexte historique : de getStaticProps à fetch()

Avant l’App Router, le Pages Router structurait la récupération de données autour de fonctions dédiées, liées à la stratégie de rendu choisie. Chaque page exportait l’une de ces fonctions, que Next.js appelait à un moment précis du cycle de vie pour produire le HTML.

Cette approche a bien servi l’écosystème, mais elle dispersait la logique de données dans des fonctions « magiques » et imposait un modèle mental différent selon SSG ou SSR.

Avec Next.js 13+ et l’App Router (recommandé), ce modèle évolue en profondeur. Les fonctions historiques disparaissent au profit d’une écriture directement dans les composants, en particulier les server components : le fetch est natif, l’async/await s’écrit au plus près du rendu, et la stratégie de cache (SSG, SSR, ISR) se déclare par de simples indicateurs (revalidate, dynamic, options de fetch). En pratique, on gagne en lisibilité, en composabilité et en précision sur le comportement de chaque segment de l’interface.

2. Refonte du modèle avec l’App Router

Avec l’App Router (Next.js 13+), la récupération de données se fait au plus près du rendu, directement dans les composants. Les server components peuvent être async et exécuter des requêtes côté serveur sans surcoût conceptuel : plus besoin de fonctions dédiées comme getStaticProps ou getServerSideProps. La stratégie (SSG/SSR/ISR) se déclare par quelques indicateurs explicites au niveau...

1. Pourquoi combiner SSR et TanStack Query ?

Le modèle de rendu côté serveur proposé par l’App Router de Next.js offre une base solide pour générer des pages rapides, optimisées pour le référencement et capables d’intégrer des données fraîches dès le premier chargement. Toutefois, ce rendu initial n’est qu’une partie de l’équation. Une fois la page servie au navigateur, l’utilisateur attend généralement une expérience beaucoup plus dynamique : formulaires interactifs, données rafraîchies sans rechargement complet, listes paginées ou filtrées, voire contenus mis à jour en temps réel.

C’est dans ce contexte que React Query, désormais connu sous le nom de TanStack Query, apporte une valeur décisive. Cette bibliothèque ne se limite pas à exécuter des appels réseau : elle met en place un système complet de cache côté client, de synchronisation et de revalidation automatique des données distantes. Concrètement, elle simplifie la gestion des états asynchrones en offrant une API claire pour suivre l’évolution des requêtes (chargement, succès, erreur) et en intégrant des mécanismes avancés comme le prefetch ou l’optimistic update.

L’intérêt de la combinaison entre SSR et TanStack Query est donc double : d’un côté, Next.js assure un affichage initial rapide et optimisé grâce au rendu serveur ; de l’autre, TanStack Query prend le relais côté client pour maintenir les données à jour, répondre aux interactions en temps réel et garantir une expérience utilisateur fluide. Ensemble, ces deux briques permettent de construire des applications modernes qui allient performance, fiabilité et interactivité.

2. Installation et configuration initiale

Avant de pouvoir exploiter les fonctionnalités de TanStack Query dans un projet Next.js basé sur l’App Router, il faut commencer par installer la bibliothèque. L’opération est simple :

npm install @tanstack/react-query...

1. Contexte : avant les Server Actions

Avant l’introduction des Server Actions, la communication entre le client et le serveur dans une application Next.js reposait principalement sur les API routes. Pour envoyer des données, par exemple, soumettre un formulaire de contact ou enregistrer une modification dans une base, le développeur devait définir une route dédiée dans /api/..., puis appeler cette route côté client à l’aide de fetch() ou d’une bibliothèque comme axios.

Cette approche fonctionnait, mais elle introduisait une couche intermédiaire artificielle entre la logique de l’interface et celle du serveur. On se retrouvait souvent avec du code dupliqué, notamment pour gérer les schémas de validation, les erreurs ou les types. De plus, la logique se retrouvait dispersée entre plusieurs fichiers, les composants côté client, les routes API côté serveur, et parfois des fonctions utilitaires partagées.

Ce modèle, hérité du paradigme classique client/serveur, était robuste, mais manquait de fluidité. Dans la pratique, il ajoutait une complexité inutile pour des actions pourtant simples, comme l’ajout d’un commentaire ou l’envoi d’un message. C’est pour répondre à cette problématique que Next.js a introduit une nouvelle abstraction : les Server Actions.

2. Qu’est-ce qu’une Server Action ?

Les Server Actions représentent une évolution majeure dans la manière d’écrire du code côté serveur dans Next.js. Concrètement, il s’agit de fonctions définies dans des server components qui peuvent être appelées directement depuis le client, sans passer par une route API explicite.

Une Server Action peut être liée à un formulaire HTML natif (via l’attribut action) ou invoquée de manière programmatique. Lorsqu’elle est exécutée, la logique s’exécute exclusivement sur le serveur, avec toutes les garanties de sécurité et de sérialisation assurées par Next.js. Cela permet, par exemple, d’écrire directement en base de données, d’envoyer des e-mails...