React & Next.js : Server et Client Components

Toute la série jusqu'ici parlait de React côté navigateur : le state, les effets, les événements s'exécutent chez l'utilisateur. L'App Router de Next.js ajoute un axe nouveau et puissant : où un composant s'exécute - sur le serveur ou dans le navigateur. C'est la dernière pièce, et elle boucle avec les trois modes de rendu vus en introduction.

# Les Server Components (le défaut)

Dans l'App Router, un composant est un Server Component par défaut. Il s'exécute uniquement sur le serveur, au build ou à la requête - jamais dans le navigateur.

Conséquence directe : il peut être async et aller chercher ses données directement (base de données, API), sans passer par un useEffect :

// Server Component - aucune directive, c'est le défaut
async function ListeProjets() {
  const projets = await getProjets(); // accès direct à la BDD / une API

  return (
    <ul>
      {projets.map((p) => <li key={p.id}>{p.titre}</li>)}
    </ul>
  );
}

// Server Component - aucune directive, c'est le défaut

async function ListeProjets() {

  const projets = await getProjets(); // accès direct à la BDD / une API

  return (

    <ul>

      {projets.map((p) => <li key={p.id}>{p.titre}</li>)}

    </ul>

  );

}

Ce qu'un Server Component ne peut pas faire : useState, useEffect, les gestionnaires d'événements, les API du navigateur. Il est rendu une fois, en HTML, côté serveur.

Son gros avantage : son code JavaScript n'est jamais envoyé au navigateur. Moins de JS à télécharger = page plus légère et plus rapide.

# Les Client Components

Pour l'interactivité, on bascule un composant côté navigateur avec la directive "use client" en tout début de fichier :

"use client";

import { useState } from "react";

function Compteur() {
  const [n, setN] = useState(0);
  return <button onClick={() => setN(n + 1)}>{n}</button>;
}

"use client";

import { useState } from "react";

function Compteur() {

  const [n, setN] = useState(0);

  return <button onClick={() => setN(n + 1)}>{n}</button>;

}

Un Client Component peut tout faire ce qu'on a vu dans la série : state, hooks, effets, événements. Il est pré-rendu en HTML sur le serveur (pour un affichage initial rapide), puis « hydraté » dans le navigateur - React y rattache l'interactivité.

# Server vs Client, en un tableau

La règle mentale : serveur par défaut, client seulement quand il y a de l'interactivité réelle.

# Comment les deux cohabitent

Une page est un arbre majoritairement serveur, dans lequel on insère des îlots clients là où c'est nécessaire. Un Server Component peut rendre un Client Component :

// Server Component
async function Page() {
  const projets = await getProjets();
  return (
    <section>
      <ListeProjets projets={projets} /> {/* serveur */}
      <Compteur />                       {/* client, îlot interactif */}
    </section>
  );
}

// Server Component

async function Page() {

  const projets = await getProjets();

  return (

    <section>

      <ListeProjets projets={projets} /> {/* serveur */}

      <Compteur />                       {/* client, îlot interactif */}

    </section>

  );

}

Deux règles de la frontière :

• "use client" marque une limite : tout ce que ce composant importe bascule aussi côté client. On place donc la directive le plus bas possible dans l'arbre.
• Les props passées d'un serveur à un client doivent être sérialisables (des données : chaînes, nombres, objets simples) - pas de fonctions, car elles traversent la frontière réseau.

# Retour aux modes de rendu

Cet axe serveur/client se combine avec les modes vus en introduction :

• Server Components + génération statique = SSG : le HTML est produit au build, servi instantanément (le cas de ce portfolio).
• Server Components rendus à chaque requête = SSR : pour du contenu qui change souvent.
• Les Client Components apportent la couche interactive par-dessus, quel que soit le mode.

Autrement dit : Next.js te laisse choisir, par composant et par page, où et quand le rendu se fait.

# À retenir

• Dans l'App Router, un composant est Server par défaut : il s'exécute sur le serveur, peut être async, et n'envoie pas son JS au navigateur.
• "use client" bascule un composant côté navigateur : state, effets, événements - l'interactivité.
• On compose un arbre serveur avec des îlots clients ; la directive se place le plus bas possible, et les props serveur → client doivent être sérialisables.
• Cet axe se combine avec SSG / SSR : le vrai pouvoir de Next.js, c'est de choisir le rendu page par page.

Cette note clôt la série React / Next.js. Tu as maintenant le fil complet : des composants et du state jusqu'au rendu côté serveur. La suite, c'est de la pratique - et ce portfolio est lui-même un terrain de jeu grandeur nature.