React Server Components : L’Avenir du Développement React

React est une force dominante pour la création d’applications web au cours des dix dernières années.

Nous avons tous vu son évolution, passant de ces composants de classe encombrants à l’élégance des hooks.

Mais les composants de serveur React (RSCs) ?

Nous ne pensons pas que quelqu’un s’attendait à un changement aussi radical dans le fonctionnement de React.

Alors, que sont exactement les composants serveur React ? Comment fonctionnent-ils ? Et que font-ils différemment que React ne pouvait pas déjà faire ?

Pour répondre à toutes ces questions, nous allons rapidement passer en revue les fondamentaux. Si tu as besoin de te remettre à niveau, jette un coup d’œil à ce guide pour apprendre React en tant que débutant.

Dans cet article, nous allons t’expliquer pourquoi nous avions besoin des composants serveur React, comment ils fonctionnent, et quelques-uns des principaux avantages des RSCs.

Commencez maintenant!

Quels Sont Les Composants Serveur React ?

Pense à React Server Components comme une nouvelle manière de construire des applications React. Au lieu de s’exécuter dans le navigateur comme les composants React typiques, les RSCs s’exécutent directement sur ton serveur.

« Je pense que les RSC sont conçus pour être la “composantisation” du backend, c’est-à-dire l’équivalent backend de ce que SPA React a fait pour le frontend. En théorie, ils pourraient largement éliminer le besoin de choses comme REST et GraphQL, conduisant à une intégration beaucoup plus serrée entre le serveur et le client puisqu’un composant pourrait traverser toute la pile. » — ExternalBison54 sur Reddit

Puisque les RSC s’exécutent directement sur le serveur, ils peuvent accéder de manière efficace aux ressources backend telles que les bases de données et les APIs sans une couche supplémentaire de récupération de données.

Mais pourquoi avions-nous besoin des RSC de toute façon ?

Pour répondre à cette question, revenons un peu en arrière.

React Traditionnel : Rendu Côté Client (CSR)

React a toujours été une bibliothèque d’interface utilisateur côté client.

L’idée principale derrière React est de diviser ton design entier en unités plus petites et indépendantes que nous appelons composants. Ces composants peuvent gérer leurs propres données privées (état) et se transmettre des données entre eux (props).

Pense à ces composants comme à des fonctions JavaScript qui se téléchargent et s’exécutent directement dans le navigateur de l’utilisateur. Lorsque quelqu’un visite ton application, son navigateur télécharge tout le code des composants, et React intervient pour tout rendre :

• Le navigateur télécharge le HTML, JavaScript, CSS, et autres ressources.
• React analyse le HTML, configure les écouteurs d’événements pour les interactions utilisateur, et récupère toutes les données nécessaires.
• Le site web se transforme en une application React entièrement fonctionnelle sous tes yeux et tout est réalisé par ton navigateur et ton ordinateur.

Bien que ce processus fonctionne, il présente certains inconvénients :

• Temps de chargement lents : Les temps de chargement peuvent être lents, en particulier pour les applications complexes comportant de nombreux composants, car l’utilisateur doit maintenant attendre que tout soit téléchargé en premier.
• Mauvais pour l’optimisation pour les moteurs de recherche (SEO) : Le HTML initial est souvent très simple — juste suffisant pour télécharger le JavaScript qui rend ensuite le reste du code. Cela rend difficile pour les moteurs de recherche de comprendre de quoi parle la page.
• Deviens plus lent à mesure que les applications grandissent : Le traitement côté client du JavaScript peut solliciter les ressources, conduisant à une expérience utilisateur plus difficile, surtout lorsque vous ajoutez plus de fonctionnalités.

La Prochaine Itération : Le Rendu Côté Serveur (SSR)

Pour résoudre les problèmes causés par le rendu côté client, la communauté React a adopté le rendu côté serveur (SSR).

Avec le SSR, le serveur gère le rendu du code en HTML avant de l’envoyer.

Ce HTML complet et rendu est ensuite transféré à ton navigateur/mobile, prêt à être consulté — l’application n’a pas besoin d’être compilée pendant l’exécution comme elle le serait sans SSR.

Voici comment fonctionne le SSR :

• Le serveur génère le HTML initial pour chaque requête.
• Le client reçoit une structure HTML complètement formée, permettant des chargements de page initiaux plus rapides.
• Le client télécharge ensuite React et le code de votre application, un processus appelé « hydration », qui rend la page interactive.

La structure HTML rendue sur le serveur n’a pas encore de fonctionnalité. 

React ajoute des écouteurs d’événements, configure la gestion de l’état interne et ajoute d’autres fonctionnalités au HTML après son téléchargement sur ton appareil. Ce processus d’ajout de « vie » à la page est connu sous le nom d’hydratation.

Pourquoi SSR fonctionne-t-il si bien ?

1. Temps de Chargement Initial Plus Rapide : Les utilisateurs voient le contenu presque instantanément car le navigateur reçoit un HTML complètement formé, éliminant le temps nécessaire pour que le JavaScript se charge et s’exécute.
2. Amélioration du SEO : Les moteurs de recherche parcourent et indexent facilement l’HTML rendu par le serveur. Cet accès direct se traduit par une meilleure optimisation pour les moteurs de recherche de votre application.
3. Performance Améliorée Sur Les Appareils Plus Lents : Le SSR allège la charge sur l’appareil de l’utilisateur. Le serveur prend en charge le travail, rendant votre application plus accessible et performante, même avec des connexions plus lentes.

SSR, cependant, a engendré un certain nombre de problèmes supplémentaires, nécessitant une solution encore meilleure :

• Temps Lent Jusqu’à l’Interactivité (TTI) : Le rendu côté serveur et l’hydratation retardent la capacité de l’utilisateur à voir et interagir avec l’appli jusqu’à ce que tout le processus soit terminé.
• Charge du serveur : Le serveur doit fournir plus d’efforts, ralentissant ainsi davantage les temps de réponse pour applications complexes, surtout lorsqu’il y a de nombreux utilisateurs en simultané.
• Complexité de configuration : Configurer et maintenir peut être plus complexe, surtout pour les grandes applications.

Enfin, les Composants Serveur React

En décembre 2020, l’équipe React a introduit les « Composants Serveur React de Taille de Bundle Nulle » ou RSCs.

Cela a changé non seulement notre façon de penser la construction des applications React, mais aussi le fonctionnement des applications React en backend. Les RSC ont résolu de nombreux problèmes que nous avions avec les CSR et les SSR.

« Avec les RSC, React devient à la fois un framework entièrement côté serveur et un framework entièrement côté client, ce que nous n’avions jamais eu auparavant. Et cela permet une intégration beaucoup plus étroite entre le code serveur et le code client qu’il n’était jamais possible auparavant. » — ExternalBison54 sur Reddit

Examinons maintenant les avantages que les RSC apportent :

1. Taille de Bundle Zéro

Les RSC sont rendus entièrement sur le serveur, éliminant le besoin d’envoyer du code JavaScript au client. Cela entraîne :

• Tailles de bundles JavaScript considérablement réduites.
• Chargements de page plus rapides, particulièrement sur des réseaux plus lents.
• Performances améliorées sur des appareils moins puissants.

Contrairement au SSR, où l’ensemble de l’arborescence des composants React est envoyé au client pour l’hydratation, les RSC gardent le code exclusivement serveur sur le serveur. Cela conduit à ces paquets côté client nettement plus petits dont nous avons parlé, rendant vos applications plus légères et plus réactives.

2. Accès Direct Au Backend

Les RSC peuvent interagir directement avec les bases de données et les systèmes de fichiers sans nécessiter une couche API.

Comme tu peux le voir dans le code ci-dessous, la variable courses est récupérée directement de la base de données, et l’interface utilisateur affiche une liste des course.id et course.name à partir du courses.map :

async function CourseList() {
  const db = await connectToDatabase();
  const courses = await db.query('SELECT * FROM courses');

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

Ceci est plus simple en contraste avec le SSR traditionnel où tu devrais configurer des routes API séparées pour récupérer des morceaux de données individuels.

3. Fractionnement Automatique du Code

Avec les RSCs, tu obtiens également un fractionnement du code plus granulaire et une meilleure organisation du code.

React conserve le code exclusivement serveur sur le serveur et assure qu’il ne soit jamais envoyé au client. Les composants client sont automatiquement identifiés et envoyés au client pour l’hydratation.

Et l’ensemble global devient extrêmement optimisé puisque le client reçoit maintenant exactement ce qui est nécessaire pour une application pleinement fonctionnelle.

D’un autre côté, SSR nécessite un fractionnement manuel soigné du code pour optimiser les performances pour chaque page supplémentaire.

4. Effet Cascade Réduit et Rendu en Streaming

Les composants serveur React combinent le rendu en flux continu et la récupération de données en parallèle. Cette combinaison puissante réduit considérablement l’effet “cascade” souvent observé dans le rendu côté serveur traditionnel.

Effet Cascade

L’« effet cascade » ralentit le développement web. En gros, il oblige les opérations à se suivre les unes les autres comme si une cascade coulait sur une série de rochers.

Chaque étape doit attendre que la précédente soit terminée. Cette “attente” est particulièrement perceptible lors de la récupération des données. Un appel API doit être terminé avant que le suivant ne commence, ce qui ralentit les temps de chargement des pages.

Rendu en Streaming

Le rendu en streaming offre une solution. Au lieu d’attendre que la page entière soit rendue sur le serveur, le serveur peut envoyer des morceaux de l’interface utilisateur au client dès qu’ils sont prêts.

Les composants serveur React rendent le rendu et la récupération des données beaucoup plus fluides. Il crée plusieurs composants serveur qui fonctionnent en parallèle pour éviter cet effet cascade.

Le serveur commence à envoyer le HTML au client dès qu’un élément de l’interface utilisateur est prêt.

Alors, comparés au rendu côté serveur, les RSCs :

• Permet à chaque composant de récupérer ses données indépendamment et en parallèle.
• Le serveur peut diffuser un composant dès que ses données sont prêtes, sans attendre que les autres composants soient à jour.
• Les utilisateurs voient le contenu se charger l’un après l’autre, améliorant leur perception de la performance.

5. Interaction Douce Avec Les Composants Client

Maintenant, utiliser des RSCs n’implique pas nécessairement que tu dois éviter d’utiliser des composants côté client. 

Les deux composants peuvent coexister et t’aider à créer une excellente expérience globale de l’application.

Pense à une application e-commerce. Avec SSR, toute l’application doit être rendue côté serveur.

Dans les RSCs, cependant, tu peux choisir quels composants rendre sur le serveur et lesquels rendre du côté client.

Par exemple, tu pourrais utiliser des composants de serveur pour récupérer les données des produits et rendre la page de liste des produits initiale.

Ensuite, les composants client peuvent gérer les interactions utilisateur comme l’ajout d’articles dans un panier d’achat ou la gestion des avis sur les produits.

Devrais-Tu Ajouter L’Implémentation RSC À Ta Feuille De Route ?

Notre verdict ? Les RSC apportent beaucoup de valeur au développement React.

Ils résolvent certains des problèmes les plus urgents avec les approches SSR et CSR : performance, récupération de données, et expérience développeur. Pour les développeurs qui commencent tout juste à coder, cela a rendu la vie plus facile.

Maintenant, devrais-tu ajouter l’implémentation RSC à ton plan de route ? Nous devrons opter pour le redouté — cela dépend.

Ton appli peut fonctionner parfaitement bien sans RSCs. Et dans ce cas, ajouter une autre couche d’abstraction peut ne pas apporter grand-chose. Cependant, si tu prévois de développer l’échelle, et penses que les RSCs peuvent améliorer l’expérience utilisateur pour ton appli, essaie de faire de petits changements et de développer à partir de là.

Et si tu as besoin d’un serveur puissant pour tester des RSCs, lance un DreamHost VPS.

DreamHost propose un service VPS entièrement géré où tu peux déployer tes applications les plus exigeantes sans te soucier de la maintenance du serveur.