Génération de site statique avec `getStaticProps`

1. Qu'est-ce que la Génération de Site Statique (SSG) ?

Contrairement au SSR où la page est générée à chaque requête, avec la SSG, la page HTML est générée une seule fois, au moment du build (lorsque vous exécutez npm run build). Le serveur web n'a plus qu'à servir ces fichiers HTML statiques pré-construits.

Pour bien comprendre les avantages et les inconvénients de cette approche, l'article suivant offre une excellente synthèse.

Comme vous l'avez lu, la SSG offre :

• Performance Maximale : Servir un fichier statique est l'opération la plus rapide qu'un serveur puisse faire. Le TTFB (Time To First Byte) est imbattable.
• Fiabilité et Coût : Les pages statiques peuvent être déployées sur des CDN (Content Delivery Networks) globaux pour un coût très faible et une résilience maximale. Il n'y a pas de "serveur d'application" qui puisse tomber en panne lors d'une requête.
• Excellent SEO : Comme avec le SSR, les robots des moteurs de recherche reçoivent une page HTML complète.

Le seul "inconvénient" est que le contenu n'est aussi frais que la dernière fois que le site a été buildé. C'est donc un compromis à faire en fonction de la nature de vos données.

2. Implémenter la SSG avec des données externes

Pour générer une page statiquement tout en y incluant des données provenant d'une API (par exemple, la liste des articles d'un blog), Next.js a historiquement popularisé une fonction spéciale : getStaticProps.

Même si vous utilisez l'App Router qui simplifie ce processus, comprendre le fonctionnement de getStaticProps est fondamental car c'est un concept clé de l'écosystème Next.js que vous rencontrerez dans de nombreux projets et tutoriels.

La vidéo suivante est un excellent guide pratique pour voir getStaticProps en action.

Résumé de l'implémentation (Pattern getStaticProps)

Voici la structure de code que vous venez de voir dans la vidéo. C'est le pattern classique utilisé avec le Pages Router.

// pages/users.js - Syntaxe du Pages Router

// 1. Le composant de la page qui reçoit les données via les props
function UserList({ users }) {
  return (
    <>
      <h1>List of Users</h1>
      {users.map(user => (
        <div key={user.id}>
          <p>{user.name}</p>
        </div>
      ))}
    </>
  );
}

export default UserList;

// 2. La fonction qui s'exécute au build time sur le serveur
export async function getStaticProps() {
  // 3. Récupération des données
  console.log('Generating / Regenerating UserList page'); // Ce log n'apparaît que dans le terminal du build, jamais dans le navigateur !
  const response = await fetch('https://jsonplaceholder.typicode.com/users');
  const data = await response.json();

  // 4. Passage des données à la page via l'objet `props`
  return {
    props: {
      users: data,
    },
  };
}

Le point crucial à retenir est que la fonction getStaticProps s'exécute uniquement côté serveur pendant le build. Le code que vous y écrivez (clés d'API, connexions directes à une base de données) n'est jamais envoyé ni exécuté dans le navigateur du client.

L'approche moderne avec l'App Router

Maintenant, comment cela se traduit-il dans l'App Router que nous utilisons ? La philosophie de Next.js a évolué vers plus de simplicité.

Vous vous souvenez du code de notre page SSR de la leçon précédente ?

// SSR: Exécuté à chaque requête
async function getProduct(id: string) {
    const res = await fetch(`.../${id}`, { cache: 'no-store' }); // L'option 'no-store' force le SSR
    // ...
}

Pour transformer cette page en SSG, il suffit de supprimer l'option { cache: 'no-store' }. Dans l'App Router, fetch met en cache les données par défaut. La première fois que la page est construite, Next.js exécute le fetch, génère le HTML, et met en cache le résultat. Toutes les requêtes suivantes recevront cette version statique.

Voici à quoi ressemblerait notre page de liste d'utilisateurs avec l'App Router :

// app/users/page.tsx - Syntaxe de l'App Router

// Une fonction helper pour récupérer les données.
// Par défaut, Next.js mettra en cache le résultat de ce fetch.
async function getUsers() {
    const res = await fetch('https://jsonplaceholder.typicode.com/users'); // Pas d'option `cache`, donc comportement SSG par défaut.
    
    if (!res.ok) {
        throw new Error('Failed to fetch users');
    }

    return res.json();
}

// Le composant de page est `async` et s'exécute sur le serveur au moment du build.
export default async function UsersPage() {
    const users = await getUsers();

    return (
        <main className="p-8">
            <h1 className="text-4xl font-bold mb-4">Users List (Statically Generated)</h1>
            <div>
                {users.map((user: { id: number; name: string; email: string }) => (
                    <div key={user.id} className="p-2 border-b">
                        <p className="font-semibold">{user.name}</p>
                        <p className="text-gray-600">{user.email}</p>
                    </div>
                ))}
            </div>
        </main>
    );
}

Cette approche est plus intuitive car elle est intégrée au modèle de composant de React, mais elle accomplit exactement le même objectif que getStaticProps.

3. Quand utiliser la SSG ?

La SSG est la stratégie de choix pour tout contenu qui est le même pour tous les utilisateurs et qui ne change pas fréquemment.

Exemples parfaits :

• Un blog : les articles sont écrits et ne changent pas à chaque seconde.
• Un site de documentation : le contenu est statique par nature.
• Un site marketing ou une landing page.
• Une liste de produits sur un site e-commerce : même si les prix peuvent changer, on peut reconstruire le site périodiquement.

Pour les cas où le contenu statique a besoin d'être mis à jour sans pour autant redéployer tout le site, Next.js propose une solution intermédiaire appelée ISR (Incremental Static Regeneration), qui est une extension de la SSG. Elle permet de régénérer une page statique à un intervalle de temps défini (par exemple, toutes les 60 secondes).

Conclusion

Félicitations ! Vous avez maintenant une vision complète des deux principales stratégies de rendu de Next.js qui sont au cœur de la création d'applications web modernes et performantes.

Points clés à retenir :

• La Génération de Site Statique (SSG) pré-génère les pages en HTML au moment du build pour une performance et une fiabilité maximales.
• Le pattern historique pour l'implémenter est la fonction getStaticProps, qui s'exécute côté serveur pendant le build pour injecter des données dans une page.
• Dans l'App Router, le comportement SSG est obtenu par défaut avec fetch, qui met automatiquement les requêtes en cache. Le SSR est l'exception que l'on active avec { cache: 'no-store' }.
• La SSG est idéale pour les contenus qui changent rarement et qui sont les mêmes pour tous les visiteurs (blogs, documentation, pages marketing).

Prochaine étape :

Nous avons bien couvert les stratégies de rendu fondamentales pour construire un frontend performant et optimisé pour le SEO avec Next.js. Dans le prochain module, nous allons revenir côté backend pour aborder un sujet essentiel au déploiement professionnel : la conteneurisation. Nous commencerons par apprendre à écrire un Dockerfile pour empaqueter notre application Spring Boot, la préparant ainsi pour le déploiement sur n'importe quelle infrastructure cloud.