React Server Components vs SSR : Où se situe réellement la frontière_

React Server Components et le rendu côté serveur se mélangent facilement car ils sont souvent utilisés dans la même application.

Ils sont liés. Ils ne sont pas la même chose.

Si vous les considérez comme interchangeables, vous finissez par avoir des décisions architecturales confuses et une base de code qui envoie plus de JavaScript client qu'il n'en a besoin.

## SSR Résout le Rendu Initial

Le SSR traditionnel génère du HTML sur le serveur afin que le navigateur puisse afficher quelque chose d'utile avant que l'application cliente ne se hydrate complètement.

Cela est précieux pour :

- le premier rendu
- l'indexabilité
- la performance perçue

Mais le SSR ne supprime pas le besoin de JavaScript client. Si la page est interactive, le navigateur a toujours besoin du code nécessaire pour hydrater cette interface utilisateur.

C'est là le point clé que de nombreuses équipes manquent : le HTML rendu par le serveur n'est pas la même chose que l'exécution de composants uniquement sur le serveur.

## Les Composants Serveurs Résolvent le Placement des Bundles

Les React Server Components changent l'endroit où certaines logiques de composants peuvent résider.

Un Composant Serveur s'exécute sur le serveur, peut accéder directement aux ressources côté serveur, et ne livre pas sa propre implémentation au navigateur.

Cela le rend utile pour :

- l'assemblage d'interfaces utilisateur soutenues par une base de données
- la transformation de contenu coûteuse
- garder les dépendances uniquement serveur hors du bundle client

Un exemple simple :

```tsx
import { db } from "@/lib/db";
import MarkdownIt from "markdown-it";

const md = new MarkdownIt();

export default async function PostBody({ slug }: { slug: string }) {
  const post = await db.post.findUniqueOrThrow({ where: { slug } });
  const html = md.render(post.body);

  return <article dangerouslySetInnerHTML={{ __html: html }} />;
}

Si cela reste un Composant Serveur, le navigateur n'a pas besoin du client de base de données ou du parseur Markdown juste pour rendre le reste de la page interactif.

L'Hydratation Existe Toujours

Les Composants Serveurs n'éliminent pas les composants clients. Ils permettent de les utiliser de manière plus intentionnelle.

Au moment où vous avez besoin des API du navigateur, de l'état local ou des gestionnaires d'événements, vous entrez dans le territoire client :

"use client";

import { useState } from "react";

export function LikeButton() {
  const [liked, setLiked] = useState(false);

  return (
    <button onClick={() => setLiked((value) => !value)}>
      {liked ? "Aimé" : "Aimer"}
    </button>
  );
}

Ce composant s'hydrate toujours côté client. L'objectif n'est pas "zéro JavaScript partout". L'objectif est de livrer du JavaScript uniquement là où le navigateur en a réellement besoin.

La Décision Architecturale

La question pratique n'est pas "devons-nous utiliser SSR ou RSC ?" Dans les applications modernes Next.js, vous utilisez souvent les deux.

La meilleure question est :

"Quelles parties de cet arbre doivent s'exécuter dans le navigateur ?"

Si la réponse est "très peu", les Composants Serveurs peuvent réduire de manière significative la taille des bundles et l'éparpillement des dépendances.

Si la majorité de la page est très interactive, les Composants Serveurs aident toujours avec l'accès aux données et la composition, mais ils ne transforment pas magiquement un tableau de bord interactif en une page uniquement serveur.

Ce Qui Va Mal dans les Réelles Bases de Code

Les modes d'échec courants sont prévisibles :

• marquer des itinéraires entiers avec "use client" parce qu'une feuille a besoin d'interactivité
• passer de grands objets sérialisés à travers la limite serveur/client
• importer accidentellement des modules réservés au serveur dans le code client
• supposer que les Composants Serveurs remplacent toutes les frontières API

La discipline consiste à garder la frontière étroite.

Utilisez les Composants Serveurs pour :

• la récupération de données
• les bibliothèques uniquement serveur
• l'assemblage de contenu non interactif

Utilisez les Composants Clients pour :

• les gestionnaires d'événements
• les API uniquement navigateur
• l'état d'interaction local

Cette répartition n'est pas idéologique. C'est juste plus facile à échelle.

Lectures Complémentaires

• React : Server Components
• Next.js : Server and Client Components
• Next.js : Server Components