Les React Server Components changent totalement le comportement par défaut du rendu dans une application Next.js. Pour bien les comprendre, il faut les comparer aux alternatives : les Client Components, et ce que nous appelons des “Browser Components”.
Il existe trois types de composants dans une application Next.js (utilisant le App Router). Voici comment ils se distinguent :
| Type de composant | Rendu côté serveur | Hydraté | Description |
|---|---|---|---|
| Server Component | Oui | Non | Nouveau comportement par défaut depuis Next 13/React 18 |
| Client Component | Oui | Oui | Pré-rendu sur le serveur |
| ”Browser Component” | Non | Oui | Importé et rendu uniquement dans le navigateur |
Les Server Components sont rendus sur le serveur et ne sont pas hydratés côté client. Ils sont le nouveau comportement par défaut depuis l’introduction du App Router dans Next.js.
Les Client Components sont pré-rendus sur le serveur, puis hydratés côté client pour les rendre interactifs. Avant l’introduction des Server Components, il n’y avait que des Client Components dans React/Next.
Les “Browser Components” sont un concept qui décrit les composants qui sont importés et rendus uniquement dans le navigateur, en contournant entièrement le rendu côté serveur.
Le terme “Browser Component” n’est pas un nom officiel, nous l’avons inventé dans le cadre de nos formations à Next.js pour mieux expliquer ce cas particulier des composants qui ne sont pas pré-rendus côté serveur.
Le concept de Browser Component est utile pour expliquer comment utiliser du code JavaScript uniquement côté client dans Next.js, et pour comprendre en quoi les “Client Components” ont un nom trompeur !
Une différence clé entre une application Next.js et une Single Page Application (SPA) traditionnelle est que Next.js utilise le rendu côté serveur par défaut. Et ce même pour les “Client Components”.
Cela implique que tout le code dans une application Next.js doit être “SSR-friendly”. Vous ne pouvez pas utiliser directement des API ou des objets spécifiques au navigateur comme window dans vos composants.
Dans certains cas, vous pouvez avoir besoin d’utiliser du code ou des librairies spécifiques au navigateur qui ne sont pas compatibles avec le rendu côté serveur. Next.js fournit quelques techniques pour gérer ces situations.
Une approche consiste à rendre conditionnellement du code uniquement côté client en utilisant un hook réutilisable comme useMounted :
import { useEffect, useState } from 'react';
// Un grand classique en React !
export const useMounted = () => {
const [mounted, setMounted] = useState(false);
useEffect(() => {
setMounted(true);
}, []);
return mounted;
};
Ce hook renvoie un booléen indiquant si le component a été monté (“mounted”) côté client. Lorsqu’elle passe à true, on peut utiliser les API spécifiques au navigateur.
Une autre technique consiste à utliser le lazy loading, via next/dynamic :
import dynamic from 'next/dynamic';
const ClientOnlyComponent = dynamic(() => import('./ClientOnlyComponent'), {
ssr: false,
});
Cela garantit que le component est chargé et rendu uniquement côté client, en évitant tout problème de rendu côté serveur.
Vous trouverez un récapitulatif de toutes ces techniques dans notre précédent article Éliminez les erreurs “Window is Not Defined” et “Hydration Mismatch” dans Next.js
Dans Next.js, par défaut, les composants sont rendus sur le serveur. Pour les Server Components, cela s’arrête là, et pour les Client Components, il y a un second rendu côté client, appelé “réhydratation”, afin de rendre le composant interactif.
On peut ajouter à cette liste la notion de “Browser Components”, pour les cas particuliers où le pré-rendu côté serveur ne peut pas fonctionner, c’est-à-dire lorsque l’on veut utiliser du JavaScript spécifique au navigateur.
Vous avez apprécié cette ressource ?
Découvrez toutes nos formations Next.js et Astro en présentiel ou en distanciel