SSR avec `getServerSideProps`

1. Qu'est-ce que le Rendu Côté Serveur (SSR) ?

Pour commencer, rafraîchissons-nous la mémoire sur la différence fondamentale entre le rendu côté client (CSR) et le rendu côté serveur (SSR).

• CSR (Client-Side Rendering) : Le modèle par défaut des applications React pures. Le serveur envoie une coquille HTML vide, et c'est le JavaScript exécuté dans le navigateur du client qui construit la page. C'est flexible, mais lent pour le premier affichage et difficile à référencer pour les moteurs de recherche.
• SSR (Server-Side Rendering) : Le serveur génère la page HTML complète, avec tout le contenu, avant de l'envoyer au navigateur.

Les avantages sont clairs :

1. SEO optimal : Les robots d'indexation reçoivent une page HTML complète et peuvent en comprendre le contenu sans avoir à exécuter de JavaScript.
2. Performance perçue améliorée : L'utilisateur voit le contenu de la page (le "First Contentful Paint") beaucoup plus rapidement, même si l'interactivité prend quelques millisecondes de plus à arriver.

Pour mieux saisir les nuances entre les différentes stratégies de rendu et le rôle de l'hydratation (le processus qui rend la page interactive côté client), la vidéo suivante offre une excellente synthèse.

2. Implémenter le SSR dans Next.js

Maintenant, comment met-on en œuvre le SSR ? Historiquement, dans l'écosystème Next.js, cela se faisait via une fonction exportée nommée getServerSideProps. Vous la rencontrerez très probablement dans des tutoriels ou des projets existants. Elle s'exécute sur le serveur à chaque requête et passe les données à la page en tant que props.

Avec l'App Router, que nous utilisons, ce processus est encore plus intuitif et intégré directement dans les composants React.

La méthode moderne avec l'App Router

Dans un projet Next.js avec l'App Router, tous les composants sont par défaut des "Server Components" (composants serveur). Cela signifie qu'ils s'exécutent côté serveur. Pour implémenter le SSR, il suffit de deux choses :

1. Rendre le composant de votre page async.
2. Utiliser la fonction fetch pour récupérer vos données, en spécifiant une option pour désactiver la mise en cache.

C'est l'option { cache: 'no-store' } qui indique à Next.js de ne pas mettre en cache le résultat de la requête et de la ré-exécuter à chaque demande de page. C'est l'équivalent direct du comportement de getServerSideProps.

Exercice pratique : Créer une page produit dynamique

Mettons cela en pratique. Nous allons créer une page qui affiche les détails d'un produit en fonction de son ID dans l'URL (par exemple, /products/1). Nous utiliserons l'API publique dummyjson.com pour simuler notre backend.

1. Créez le fichier de la page

Dans votre projet, créez la structure de dossiers et le fichier suivants : app/products/[id]/page.tsx. La notation [id] indique à Next.js qu'il s'agit d'une route dynamique.

2. Écrivez le code de la page

Ouvrez app/products/[id]/page.tsx et collez-y le code suivant :

// app/products/[id]/page.tsx

// Définissons un type pour les données de notre produit pour plus de sécurité avec TypeScript
interface Product {
  id: number;
  title: string;
  description: string;
  price: number;
  brand: string;
  thumbnail: string;
}

// Une fonction helper pour récupérer les données du produit.
// Elle s'exécute côté serveur.
async function getProduct(id: string): Promise<Product> {
    // On fetch les données depuis l'API externe
    const res = await fetch(`https://dummyjson.com/products/${id}`, {
        cache: 'no-store' // C'est la clé du SSR ! On force un nouvel appel à chaque requête.
    });

    // Bonne pratique : gérer le cas où la requête échoue
    if (!res.ok) {
        // Cette erreur activera la page d'erreur la plus proche dans l'arborescence
        throw new Error('Failed to fetch product');
    }

    return res.json();
}

// Le composant de notre page est une fonction `async`
export default async function ProductPage({ params }: { params: { id: string } }) {
    // `params.id` contient la valeur du segment dynamique de l'URL
    const product = await getProduct(params.id);

    return (
        <main className="p-8">
            <h1 className="text-4xl font-bold mb-4">{product.title}</h1>
            
            {/* Note: Dans un vrai projet, utilisez le composant <Image> de Next.js pour l'optimisation */}
            <img src={product.thumbnail} alt={product.title} width={500} className="rounded-lg shadow-lg mb-4" />
            
            <p className="text-lg mb-4">{product.description}</p>
            <p className="text-2xl font-semibold mb-2">Prix : {product.price} $</p>
            <p className="text-md text-gray-600">Marque : {product.brand}</p>
        </main>
    );
}

3. Analysez le code

• async function ProductPage : La page elle-même est une fonction asynchrone.
• { params } : Le composant reçoit params en prop, qui est un objet contenant les segments dynamiques de l'URL. Ici, params.id sera '1', '2', etc.
• getProduct(params.id) : Nous appelons notre fonction de récupération de données directement dans le composant.
• fetch(..., { cache: 'no-store' }) : C'est l'instruction cruciale qui transforme cette page en une page rendue dynamiquement côté serveur. À chaque fois qu'un utilisateur visitera /products/5, le serveur Next.js exécutera cette requête fetch avant de construire et d'envoyer le HTML.

4. Testez et vérifiez

Lancez votre serveur de développement avec npm run dev.

Maintenant, visitez http://localhost:3000/products/1, puis http://localhost:3000/products/2. Vous devriez voir les détails de différents produits.

La preuve ultime du SSR ? Faites un clic droit sur la page et sélectionnez "Afficher le code source de la page". Dans le code HTML brut, vous verrez le titre du produit, sa description, etc. Le contenu est bien là, pré-rendu par le serveur !

3. Quand choisir le SSR ?

Le SSR est extrêmement puissant, mais il implique que votre serveur travaille à chaque requête. Il est donc idéal pour des pages dont le contenu est :

• Hautement dynamique : Les données changent fréquemment (ex: un tableau de bord utilisateur, le fil d'actualité d'un réseau social).
• Critique pour le SEO : Le contenu doit être immédiatement disponible pour les moteurs de recherche.

Pour approfondir les cas d'usage, l'article suivant, bien qu'utilisant la syntaxe getServerSideProps, donne d'excellents exemples.

Conclusion

Vous maîtrisez maintenant l'une des techniques les plus importantes de Next.js pour construire des applications web modernes, performantes et optimisées pour le SEO.

Points clés à retenir :

• Le SSR génère le HTML d'une page sur le serveur à chaque requête, garantissant des données toujours à jour et un SEO optimal.
• Dans l'App Router, le SSR est implémenté en rendant un composant de page async et en utilisant fetch avec l'option { cache: 'no-store' }.
• Cette approche est idéale pour les pages dont le contenu change souvent, comme un profil utilisateur, une liste de résultats de recherche ou un tableau de bord.
• Le HTML pré-rendu est immédiatement disponible pour le navigateur et les moteurs de recherche, ce qui est excellent pour les Core Web Vitals (notamment le LCP) et le référencement.

Prochaine étape :

Le SSR est parfait pour le contenu très dynamique, mais que faire pour le contenu qui ne change pas à chaque seconde, comme un article de blog ou une page de documentation ? Effectuer une requête à la base de données à chaque visite serait inefficace. Pour ces cas, Next.js propose une stratégie encore plus performante : la Génération de Site Statique (SSG). Dans la prochaine leçon, nous apprendrons à utiliser getStaticProps (ou son équivalent moderne dans l'App Router) pour pré-rendre les pages au moment du build, offrant une vitesse de chargement quasi instantanée.