Les Server Components
Qu’est-ce que les Server Components ?
En React, tout le code s’exécute traditionnellement du côté client (navigateur). Mais avec les Serveur Components (RSC de son p’tit nom doux), une partie du composant peut être exécuté du côté du serveur, ce qui permet d’envoyer au client du HTML pré-rendu avec données. L’avantage dans tout ça, c’est que le client n’a pas besoin ni de télécharger ni d’exécuter le code JavaScript de ces composants.
Ok mais alors, à quoi cela sert ?
Les RSC apportent plusieurs avantages :
- Il y a moins de JavaScript à exécuter côté client. La page sera plus légère, donc plus rapide à afficher
- On peut faire un accès direct à la base de données sans passer par une API Rest par exemple.
Pour être plus précis, sans les RSC, j’aurais besoin d’une API pour accéder à ma database du côté Front. Le back va alors récupérer les datas du côté de la database et les renvoyer au front qui les affichera.
Avec les RSC, le code étant exécuté du côté serveur, l’accès à la database se fait en direct. Plus besoin d’une API pour l’interroger ! Et donc pas de fetch côté front et gain de performance et plus simple. Attention cependant, les RSC ne remplacent pas totalement les API. On en aura souvent besoin. Le but est juste de dire que l’on peut, dans certains cas, simplifier en passant par des RSC. - Top côté SEO ! Vu que les datas sont rendues côté serveur et arrive toutes cuites au front, lors de la lecture de la page, tout est déjà rendu et donc mieux pour le SEO pour nos amis comme Google et compagnie. Vraiment un gros plus pour la team SEO qui se tirera moins les cheveux ensuite :)
- On peut mettre une architecture hybride en place. En d’autres termes, tu peux dire que ton composant RSC à une partie qui doit s’exécuter côté client (« use client »).
Mais c’est génial, je vais en mettre partout !!
Oui mais non en fait :) Il y a tout de même des points de vigilances à noter :
- Si vous avez besoin d’un composant interactif avec un useState ou un onClick, cela doit rester un Client Component.
- La frontière entre Client et Server Component ne sont pas toujours très simples. Prenons l’exemple d’un panier. On pourrait se dire que ce serait cool d’en faire un RSC. Mais on a besoin de le mettre à jour, ajouter un code promo par exemple. Et là bim ! Pas possible, cela doit rester côté client. Cela oblige à bien découper ses composants.
- Aujourd’hui, c’est vraiment avec NextJS que cela peut être utilisé. Sur React « pur », comme l’indique la documentation (https://fr.react.dev/reference/rsc/server-components), les RSC sont encore « expérimental » et comportent souvent des changements. Libre à vous de l’utiliser mais attention tout de même sur des applications à mettre en prod :)
- Les outils de debug sont encore jeunes et parfois le debug peut rendre confuse la résolution :)
- Les RSC sont performants oui mais attention, vous déplacez la charge de client à serveur. Et c’est pas une bonne chose non plus. Et par conséquent, les perfs ne seront pas forcément mieux si on en abuse.
- Enfin le côté hybride côté avantage est aussi un inconvénient. À trop vouloir être modulaire, le code en devenir illisible en mélangeant server et client components.
Vous prendrez bien un p’tit verre ?
Ha non pardon c’est plutôt d’hydratation de datas dont nous allons parler ici ^^
Kezako l’hydratation ?
L’hydratation, c’est le moment ou votre page se reveille côté client. Quand vous faites du pain, votre levure se réveille avec de l’eau. Bah dans notre cas, l’eau c’est les datas reçues et notre levure, c’est notre page côté client (désolé j’ai fais du pain maison hier…)
En gros, le serveur envoi du HTML tout prêt. Le navigateur (notre client) affiche lui une version un peu endormie, sans interactivité de notre page. Le JavaScript se charge et React commence à hydrater notre page avec nos datas. Après cela, nos boutons etc sont enfin vivant :)
Exemple :
// Code avant hydratation
<button>Cliquez-moi</button>
// Code après hydratation
<button onClick={handleClick}>Cliquez-moi</button>
Magnifique n’est-ce pas ?
Quand sont rendus les Server Components ?
Point important à retenir : les RSC ne sont pas rendus « en temps réel » à chaque visite. Il y a deux moments possibles :
Au moment du build (Static) :
– Pour du contenu qui ne change pas souvent (page « À propos », documentation)
– Next.js génère le HTML une seule fois lors de la compilation
– Super performant car le serveur n’a aucun calcul à faire
// Static - rendu au build
export default async function AboutPage() {
return <h1>À propos de nous</h1>; // Pas de données dynamiques
}
À chaque requête (Dynamic) :
– Quand vous avez besoin de données fraîches (posts d’un blog, profil utilisateur)
– Le serveur exécute le composant à chaque visite
– Plus lent qu’en static, mais données toujours à jour
// Dynamic - rendu à chaque requête
export default async function UserProfile({ userId }) {
const user = await getUser(userId); // Requête DB à chaque visite
return <h1>Profil de {user.name}</h1;
}
Comment je met en place un Server Component ?
Bah en fait, un composant avec NextJS, c’est automatiquement un RSC :) Mais attention, si vous tentez par exemple de mettre un onClick ou un useState dans un composant, vous aurez un message d’erreur qui vous indique qu’il manque « use client ». Ce dernier permet de convertir le composant en Client Component et devrait être écrit tout en haut du fichier.
Exemple de Server Component
Pour faire très simple, voici un exemple de RSC qui affichera la date du côté du serveur :
// app/CurrentDate.js (Server Component par défaut)
export default function CurrentDate() {
const date = new Date().toLocaleString("fr-FR", {
dateStyle: "full",
timeStyle: "short",
});
return <p>Date et heure générées côté serveur : {date}</p>;
}
Comme vous pouvez le voir, il n’y a aucun « use client », pas d’interaction côté front que ce soit avec un useState ou un event de type onClick par exemple. Donc nous sommes en présence d’un composant Server Component.
Mais attends, C’est quoi la différence entre du SSR et RSC ?
Beaucoup de développeur mélange le Server Components avec le Server-Side Rendering. Voici les différences :
SSR
- Tout le composant s’exécute côté serveur
- Puis tout le JavaScript est envoyé au client pour l’hydratation (non on parle toujours pas de boire, un peu de sérieux siouplay)
- Enfin le client télécharge tout le code,même les parties statiques
RSC
- Seuls les composants où on a indiqué « use client » sont envoyé au navigateur
- Le reste (Server Components) reste sur le serveur
- Bundle JavaScript du coup plus petit et plus léger.
Conclusion
Comme tout outil, il peut être utile, mais tout dépend de la façon dont vous l’utilisez. Si vous l’utilisez avec intelligence, vous ferez des merveilles. Mais si vos perfs chutent et que vous en abusez, cela se ressentira également. Et on a pour habitude de dire qu’en général, le problème est entre la chaise et l’écran ;)
Si vous débutez avec les Server Components, le plus simple est de tester avec Next.js (App Router) qui est aujourd’hui la référence.
Pour résumer :
- Les Server Components permettent de réduire le JavaScript côté client et d’accéder directement aux données serveur.
- Ils ne remplacent pas les Client Components, mais les complètent.
- Aujourd’hui, leur usage le plus courant est via Next.js (App Router).
- Bien utilisés, ils offrent un gros gain en performance et en simplicité, mais il faut apprendre à jongler entre serveur et client.
Merci les ami.e.s et à bientôt !
Longue vie et Prospérité
Laisser un commentaire