Maîtrise les composants serveur React grâce à notre guide complet

React a complètement transformé la façon dont on crée les interfaces utilisateur en introduisant une conception basée sur les composants qui favorise l’efficacité et la réutilisabilité. Sa méthode déclarative et sa structure basée sur les composants ont gagné en popularité auprès des développeurs. Mais à mesure que tes projets gagnent en complexité, tu pourrais rencontrer des problèmes de performances liés aux méthodes de rendu et de récupération des données.

Avec les méthodes traditionnelles de rendu côté client, tu comptes sur le navigateur pour exécuter du JavaScript afin d’afficher l’interface utilisateur initiale. Ça peut entraîner des retards de chargement sur les appareils aux ressources limitées. La récupération de données via une interface de programmation d’application (API) ajoute une charge supplémentaire à ces appareils, ce qui peut causer un décalage dans l’affichage du contenu et nuire à l’expérience utilisateur.

Les composants serveur offrent une solution à ces obstacles en permettant le rendu des composants sur le serveur. Ça permet au serveur de diffuser les composants vers le côté client, ce qui améliore les performances et les processus de récupération des données, puisque tout le traitement se fait sur le serveur et non sur les appareils des utilisateurs.

Dans cet article, tu découvriras comment les méthodes de rendu de React ont évolué au fil du temps, ainsi que les inconvénients liés à l’utilisation de React Suspense et du rendu côté serveur (SSR). Tu en apprendras également davantage sur les composants serveur React (RSC) et sur la manière dont ils résolvent ces problèmes.

Comprendre les stratégies de rendu traditionnelles de React

Avant d’aborder les RSC, il est utile de comprendre les stratégies de rendu antérieures, telles que React Suspense et le SSR.

React Suspense

React Suspense a été introduit pour gérer le rendu asynchrone dans les applications React. Il permet aux composants de « suspendre » leur rendu jusqu’à ce que certaines conditions soient remplies, comme la récupération de données ou le fractionnement de code. Voici quelques-uns des avantages de Suspense :

• Une meilleure expérience utilisateur. Suspense te permet d’utiliser des espaces réservés pour tes composants, ce qui facilite l’affichage d’indicateurs de chargement pendant la récupération des données. Ça évite ainsi que le contenu de l’écran de l’utilisateur n’apparaisse vide.
• Rendu des composants. Lorsque tes composants récupèrent des données depuis une API, Suspense met le rendu du composant en pause jusqu’à ce que les données soient disponibles. Ça évite les pages partiellement chargées et contribue à offrir une meilleure expérience aux utilisateurs.
• Fractionnement de code. Suspense s’associe à des fonctionnalités comme React.lazy pour permettre le fractionnement de code et améliorer les performances en ne chargeant les composants que lorsqu’ils sont nécessaires.

Mais React Suspense présente certaines limites dont il faut tenir compte lorsque tu fais évoluer ton application :

• Prise en charge incomplète de la récupération de données côté serveur. Suspense facilite le chargement des données côté client, mais il ne prend pas en charge la récupération de données côté serveur. Pour gérer la récupération de données côté serveur, tu dois utiliser des outils tels que React Query. Par exemple, avec Suspense, tu dois toujours gérer des tâches comme la mise en cache côté serveur et effectuer des requêtes API côté client pour récupérer les données, ce qui peut ajouter de la complexité au SSR.
• Complexité accrue avec les composants imbriqués. Travailler avec Suspense dans des composants imbriqués peut parfois s’avérer assez complexe. Par exemple, lorsque tu développes une page produit qui affiche des avis, des recommandations et des informations sur les stocks, la coordination entre le chargement des données de ces composants imbriqués et les limites de Suspense peut entraîner des temps de chargement plus longs. Cela peut compliquer le code, car il faut gérer les dépendances de données et les états de chargement de chaque composant.
• Surcoût lié au code standard. Suspense nécessite souvent du code supplémentaire pour gérer les états de chargement, les erreurs et les solutions de repli. Par exemple, dans une grosse appli, tu risques de devoir encapsuler de nombreux composants dans Suspense et ErrorBoundary, ce qui ajoute du code répétitif et rend plus difficile de garantir la cohérence et la maintenabilité de l’ensemble à mesure que ton appli se développe.

Rendu côté serveur

Avec le SSR, les composants React sont rendus sur le serveur, puis le code HTML entièrement généré est envoyé au client pour être affiché. À l’inverse, avec le RSC, les composants individuels sont rendus dès qu’ils sont prêts, au lieu d’attendre que toute l’application se charge, comme c’est le cas avec le SSR. Cette approche présente plusieurs avantages :

• Des temps de chargement initiaux améliorés. En pré-renduant le code HTML sur le serveur, tu permets au navigateur d’afficher le contenu bien plus rapidement. Par exemple, si tu développes un site de e-commerce, les utilisateurs peuvent voir immédiatement les détails des produits pendant que le reste de ton JavaScript se charge en arrière-plan. Ça rend ton application plus rapide, surtout si les utilisateurs ont une connexion ou un appareil lent.
• Avantages en matière de référencement (SEO). Les moteurs de recherche peuvent facilement indexer le code HTML rendu de ton site web, ce qui améliore sa visibilité dans les résultats de recherche. Par exemple, si tu as un blog ou un site web riche en contenu, l’utilisation du SSR permet de garantir que les moteurs de recherche accèdent rapidement à tes articles et les évaluent sans attendre le chargement du JavaScript. Dans ce cas, le SSR te permet d’obtenir un meilleur classement SEO.

Le SSR présente également des limites à prendre en compte :

• Surcharge liée à l’hydratation. Une fois que le serveur a envoyé le code HTML initial, le navigateur doit l’« hydrater » en y associant des écouteurs d’événements et en rendant la page interactive. Ça peut entraîner des problèmes de performances, car le navigateur doit afficher la page deux fois : une fois pour le contenu statique, puis une autre pour les parties interactives. Par exemple, si tes applications comportent des fonctionnalités comme des tableaux de bord analytiques avec des graphiques et des champs de saisie, ce double affichage des différents composants peut causer des ralentissements pour les utilisateurs.
• Des charges utiles plus volumineuses. Avec le SSR, tu dois envoyer l’intégralité du bundle JavaScript au client, ce qui peut augmenter la taille de la charge utile. Par exemple, lorsque tu développes une grosse application avec de nombreuses fonctionnalités, la quantité de JavaScript envoyée au navigateur peut augmenter considérablement, ce qui peut ralentir le temps de chargement des pages, surtout sur des connexions lentes.
• Consommation importante de ressources. Le SSR doit générer du code HTML pour chaque requête qui lui est adressée, ce qui entraîne des besoins de traitement accrus et une augmentation des coûts liés au serveur. Par exemple, si ton application est confrontée à un pic de trafic, tu devras peut-être augmenter les ressources serveur, ce qui complique la gestion de l’infrastructure et en augmente le coût.

Composants serveur React

Les RSC sont un nouveau type de composants dans React qui fonctionnent côté serveur, contrairement aux composants traditionnels qui fonctionnent côté client. Ils permettent de résoudre les problèmes liés à Suspense et au SSR classique en permettant aux composants d’être traités et diffusés sous forme de code HTML depuis le serveur vers le client. Les RSC gèrent également la récupération des données côté serveur, garantissant ainsi que les informations confidentielles, telles que les clés API, ne soient pas divulguées au client.

Les RSC offrent des avantages significatifs :

• Des performances optimisées. Avec les RSC, tu transfères le travail de rendu vers le serveur, ce qui réduit la quantité de JavaScript que les navigateurs de tes utilisateurs doivent exécuter. Par exemple, si tu développes un blog, le contenu HTML peut être diffusé directement, ce qui permet aux articles d’apparaître presque immédiatement sans attendre le traitement JavaScript.
• Récupération sécurisée des données. Les RSC récupèrent les données côté serveur, ce qui améliore à la fois la vitesse et la sécurité. Par exemple, dans une application de e-commerce, le serveur récupère les données sur les produits, tout en gardant les clés API cachées du client.
• Réduction de l’exécution de JavaScript côté client. En transférant le rendu vers le serveur, on réduit l’exécution de JavaScript sur les appareils des utilisateurs, ce qui améliore les performances, surtout sur les appareils moins puissants. Dans un tableau de bord, par exemple, le serveur traite les composants riches en données, ce qui limite au minimum le JavaScript nécessaire côté client.
• Chargement initial des pages plus rapide. Comme les RSC diffusent du HTML pré-rendu, le contenu se charge rapidement pour les utilisateurs. Sur un site d’actualités, les articles et les images s’affichent instantanément, ce qui évite les écrans vides pendant le chargement du JavaScript.

Les RSC par rapport aux composants React traditionnels

Par rapport aux composants côté client, les RSC gèrent l’exécution, la gestion des données et les performances différemment.

Les composants traditionnels s’exécutent dans le navigateur (côté client), où du JavaScript est nécessaire pour afficher l’interface utilisateur (UI). Les RSC s’exécutent sur le serveur en envoyant du code HTML pré-rendu à l’appareil du client au lieu de tout traiter localement. Cette approche allège la charge de travail sur l’appareil de l’utilisateur et améliore la vitesse de chargement. Gérer les mises en page et le contenu statique côté serveur est également idéal pour les composants non interactifs ou basés sur des données. Les composants côté client peuvent être imbriqués dans des RSC là où l’interactivité est nécessaire, comme pour les boutons ou les formulaires, tout en préservant la sécurité des données sensibles sur le serveur.

Les composants traditionnels peuvent augmenter la taille du bundle JavaScript côté client, ce qui peut ralentir les performances de l’appli. Les RSC n’augmentent pas la taille du package côté client puisqu’ils fonctionnent côté serveur, ce qui réduit les téléchargements et accélère le chargement des pages. Tu peux aussi utiliser les RSC pour améliorer la mise en cache. Le contenu rendu côté serveur est plus facile à mettre en cache, ce qui accélère les réponses pour les données fréquemment consultées, comme les produits populaires d’une boutique en ligne, sans avoir à interroger la base de données à plusieurs reprises.

Comment mettre en œuvre les RSC

La façon la plus simple d’utiliser les RSC en pratique, c’est via le Next.js App Router, qui prend en charge nativement les composants serveur React sans nécessiter de configuration manuelle de Webpack ou de Babel.

Note que les exemples de code de cette section utilisent Next.js 15 avec React 19.

Configuration du projet

Assure-toi d’avoir installé Node.js 22 (version LTS actuelle), puis crée un nouveau projet Next.js :

npx create-next-app@latest your-app
cd [your-app]

Quand on te le demande, sélectionne l’option « App Router ». C’est important, car les RSC ne sont disponibles qu’avec l’App Router, et non avec l’ancien Pages Router.

Création de tes composants

Dans l’App Router de Next.js, chaque composant est par défaut un composant serveur. Crée un fichier à l’emplacement app/components/UserList.jsx :

// app/components/UserList.jsx
// This is a server component by default - no directive needed


async function UserList() {
  // Data fetching happens on the server
  // API keys and sensitive data never reach the client
  const users = [
    { id: 1, name: "John Doe" },
    { id: 2, name: "Jane Smith" },
    { id: 3, name: "Alice Johnson" },
  ];


  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}


export default UserList;

Pour ajouter de l’interactivité côté client, tu dois explicitement marquer un composant avec la directive « use client ». Crée un fichier dans app/components/Counter.jsx :

// app/components/Counter.jsx
"use client"; // This directive marks it as a client component


import { useState } from "react";


function Counter({ initialCount }) {
  const [count, setCount] = useState(initialCount);


  return (
    <div>
      <button onClick={() => setCount((prev) => prev + 1)}>
        Increment
      </button>
      <p>Count: {count}</p>
    </div>
  );
}


export default Counter;

Maintenant, mets à jour le fichier app/page.jsx pour combiner les deux composants :

// app/page.jsx
// This is a server component - it can import both server and client components


import UserList from "./components/UserList";
import Counter from "./components/Counter";


export default function Page() {
  return (
    <div>
      <h1>Users</h1>
      <UserList />        {/* Rendered on the server */}
      <Counter initialCount={50} />  {/* Interactive, runs on the client */}
    </div>
  );
}

Lance et teste le code

Lance le serveur de développement :

npm run dev

Ton application sera accessible à l'adresse http://localhost:3000. Le composant UserList s'affiche sur le serveur et transmet le code HTML au client, tandis que le composant Counter s'hydrate dans le navigateur et gère l'interactivité localement.

La principale différence par rapport à React traditionnel, c’est que UserList n’envoie pas de JavaScript au navigateur — seulement du HTML. Ça réduit la taille de ton bundle côté client et améliore automatiquement les performances de chargement.

Bonnes pratiques pour l’utilisation des RSC

Comme les RSC gèrent la majeure partie du rendu côté serveur, transférer autant que possible le rendu de ton application vers le serveur peut améliorer considérablement les performances tout en conservant les fonctionnalités interactives là où c’est nécessaire. Voici quelques bonnes pratiques qui peuvent t’aider à y parvenir et à améliorer la vitesse, la flexibilité et la facilité de gestion de ton application grâce aux RSC.

Tout d’abord, utilise les RSC pour récupérer des données depuis des API ou des bases de données. Si tu as déjà récupéré des données côté serveur, ne les récupère pas à nouveau côté client. Par exemple, si tu charges des données utilisateur côté serveur et que tu les transmets au client, il n’y a pas besoin d’un deuxième appel d’API côté client, sauf si les données changent.

Décomposer le code en petits morceaux et charger de manière sélective les scripts nécessaires à l’aide d’outils tels que Vite ou webpack peut contribuer à améliorer les temps de chargement. Crée des composants réutilisables dans toute ton application. Par exemple, si plusieurs pages doivent afficher une liste d’utilisateurs, crée un composant « UserList » qui fonctionne partout.

Enfin, veille à ce que les composants serveur restent légers en les consacrant exclusivement au rendu des données, puisqu’ils n’ont pas besoin de gérer l’état comme le font les composants client. Concentre-toi sur leur légèreté et sur leur rôle exclusif de rendu des données. N’hydrate que les parties d’une page qui doivent être interactives. Par exemple, si la page est principalement statique mais comporte un formulaire ou un bouton interactif, n’hydrate que ces composants.

Défis et limites des RSC

Même si les RSC présentent des avantages, il est aussi important de comprendre les obstacles et les limites liés à leur intégration dans ton projet.

Gestion de l’état

Les composants côté serveur ne peuvent pas interagir avec les méthodes de cycle de vie telles que `useEffect` ou `useState`. Ça veut dire que tu ne peux pas gérer l’interactivité côté client au sein des composants côté serveur. Par exemple, si un formulaire est affiché côté serveur, tu auras besoin d’un composant côté client pour gérer les modifications en temps réel des données saisies.

Lorsque tu utilises à la fois des composants côté client et côté serveur dans tes projets, il est important de gérer l’interaction entre ces deux types de composants dans toute ton application pour éviter tout problème. Par exemple, si ton application récupère des données depuis le serveur et permet aux utilisateurs de modifier ces données localement sur leurs appareils, tu risques de rencontrer des problèmes pour maintenir la cohérence des données entre le serveur et les composants côté client.

Code non sérialisable

Les composants côté serveur ne peuvent utiliser que des props sérialisables, ce qui signifie que tu ne peux pas passer de fonctions, de symboles ou d’objets complexes qui ne peuvent pas être sérialisés. Par exemple, envoyer une fonction de rappel d’un composant côté serveur vers un composant côté client entraînera un message d’erreur. Les composants côté serveur n’ont pas accès aux API du navigateur telles que window, document ou localStorage. Si tu as besoin d’interagir avec le DOM, cela doit se faire dans un composant côté client.

Incohérences d'hydratation

Si le code HTML affiché par le serveur ne correspond pas à ce qu’attend le JavaScript côté client, ça peut poser des problèmes pendant le processus d’hydratation. Par exemple, des différences dans le formatage des dates entre le serveur et le client peuvent entraîner de légers décalages. Les décalages d’hydratation peuvent être difficiles à déboguer, car la cause première n’est pas toujours évidente.

Compatibilité avec les bibliothèques tierces

Certaines bibliothèques tierces peuvent ne pas fonctionner correctement avec les RSC, en particulier celles qui dépendent fortement des techniques de rendu côté client ou d’API spécifiques aux navigateurs. Par exemple, des bibliothèques telles que react-router-dom nécessitent un rendu côté client. Tu devras peut-être remplacer ou adapter certaines bibliothèques pour qu’elles fonctionnent avec les RSC.

Solutions aux problèmes courants liés au RSC

Il existe des solutions pratiques que tu peux mettre en œuvre pour garantir la cohérence et résoudre les problèmes courants liés au RSC.

Utilise une gestion de l'état cohérente

Utilise des outils de gestion d’état qui fonctionnent à la fois côté serveur et côté client, comme Redux ou Zustand. Ces bibliothèques te permettent de centraliser ton état afin que les composants rendus côté serveur et ceux côté client puissent accéder aux mêmes données. Par exemple, tu pourrais utiliser Redux pour stocker un état global accessible aux deux côtés de l’application.

Veille à maintenir un flux de données entre le serveur et le client en partageant le contexte. Par exemple, lorsque tu transfères des données utilisateur entre les composants serveur et client, assure-toi que les informations sont gérées de manière centralisée pour éviter toute incohérence.

Utilise du code non sérialisable et refactorise les composants

Pense à utiliser des outils de développement ou des linters de code pour identifier les propriétés non sérialisables qui pourraient poser problème avec les RSC. Par exemple, des outils comme ESLint peuvent être configurés pour détecter les props de fonction transmises depuis des composants côté serveur.

Veille à refactoriser les composants pour t'assurer que les props peuvent être sérialisées et éviter tout problème avec le SSR. Une façon d’y parvenir consiste à déplacer certaines opérations, comme les gestionnaires d’événements, vers les composants côté client. Par exemple, lorsque tu transmets une fonction de rappel depuis un composant côté serveur, assure-toi que le code est adapté pour que l’opération se déroule au sein du composant côté client où elle est utilisée.

Gérer les incohérences d’hydratation

Pour résoudre les incohérences d'hydratation, il faut recourir à des techniques de test et de débogage proactives :

• Mode strict. Active le mode strict de React pour détecter les problèmes dès la phase de développement. Le mode strict te signalera les erreurs au fur et à mesure que tu travailles, ce qui te permettra de les corriger avant qu’elles ne deviennent des problèmes dans le produit final.
• Tests approfondis. Assure-toi de mettre en place des plans de test complets pour détecter tout problème lié à l’hydratation. L’automatisation des tests permet de simuler les processus de rendu côté serveur et côté client afin de garantir l’uniformité. Pense à utiliser des outils comme Cypress ou Jest pour vérifier que le résultat affiché est cohérent aussi bien dans l’environnement serveur que dans l’environnement client.

Vérifie la compatibilité des bibliothèques tierces

Si un logiciel tiers ne fonctionne pas avec les composants serveur comme l’exigent les spécifications de ton projet, explore d’autres options compatibles avec le serveur. Si tu utilises une bibliothèque open source pour ton projet, tu pourrais envisager de contribuer à son développement afin d’y inclure également la prise en charge des RSC. En contribuant ainsi, tu peux améliorer ta propre application tout en ayant un impact positif sur la communauté au sens large qui s’appuie sur cette même bibliothèque pour son travail.

En relevant ces défis grâce à des stratégies adaptées, tu pourras contourner efficacement les limites des RSC et créer des applications robustes et performantes.

Conclusion

Dans cet article, on a expliqué les techniques de rendu de React. On a présenté React Suspense et le SSR, et on a proposé un guide plus approfondi sur les RSC. Tu peux utiliser les RSC pour améliorer les performances de ton application en réduisant le traitement JavaScript côté client et en accélérant le chargement initial des pages.

Si tu veux tester les RSC dans tes projets, la première étape consiste à identifier les composants de ton application qui pourraient tirer parti du SSR. Tu pourras ensuite intégrer progressivement les RSC dans ton code.

La gestion de l’infrastructure pour le SSR et les composants serveur peut s’avérer complexe. L’utilisation d’Upsun, une plateforme en tant que service (PaaS), simplifie le déploiement et la mise à l’échelle de tes applications React. Grâce à sa prise en charge intégrée de Node.js et à sa scalabilité automatique, Upsun peut t’aider à gérer en douceur les pics de trafic. Il fournit également des outils de surveillance et de sécurité et te permet de gérer plusieurs applications ou microservices dans différents langages au sein d’un même projet. Ainsi, tu peux te concentrer sur le développement de ton application React tandis qu’Upsun s’occupe de l’infrastructure de base.