RSC, SSR et RSE—OMG !

Comprenez clairement la signification de ces termes et leurs relations : composants serveur React (RSC), rendu côté client (CSR) et rendu côté serveur (SSR).

Remarque : une grande partie de ce contenu a été empruntée à une conférence conjointe Alyssa Nicoll et moi avons récemment donné un ouvrage intitulé A Tale of Two Servers : SSR in Angular and React. Si vous recherchez du contenu plus génial sur la RSS du côté d’Angular, vous voudrez certainement jeter un œil à son travail !

La technologie a toujours eu un problème d’acronyme, mais c’est n’a jamais été aussi aigu qu’il ne l’est actuellement dans le monde de React. Avec la popularité croissante des composants React Server (RSC), de nombreux développeurs React qui n’avaient auparavant écrit que des composants pour le rendu côté client (CSR) découvrent soudainement qu’ils doivent parfaire leurs connaissances en matière de rendu côté serveur (SSR). ouf. Si tout cela vous semble étranger, gardez à l’esprit les conseils utiles du Guide de l’auto-stoppeur : prenez votre serviette et ne paniquez pas. Nous sommes Je vais examiner de manière approfondie ce que chacune de ces choses signifie et comment elles (pourraient) avoir un impact sur votre travail quotidien.

Commençons par ce qui est familier : la RSE

La RSE (ou rendu côté client) est ce que la plupart des développeurs React connaissent le mieux, car c’est ainsi que nous avons procédé. écrire des composants dans React depuis des années. «Côté client» ici, il s’agit du navigateur de l’utilisateur. Lorsque les sites Web sont chargés, le navigateur récupère le code du site à partir d’un serveur. Cependant, les navigateurs ne peuvent lire que HTML, CSS et JS (plus quelques autres éléments spéciaux, comme XML … mais cela n’a pas de rapport avec ce dont nous discutons en ce moment).

La différence entre CSR et SSR réside dans l’endroit où ce contenu est rendu ; dans ce cas, cela signifie « traduit » ; de ce que nous avons écrit dans React dans ces formats HTML, CSS et JS lisibles par le navigateur. Le SSR se produit (vous l’avez deviné) côté serveur, de sorte que le HTML, CSS et JS déjà traduits sont récupérés par le navigateur. La RSE se produit du côté client (ou utilisateur), ce qui signifie que les éléments React sont récupérés et que la partie traduction s’effectue dans le navigateur. Cependant, la démarche RSE présente à la fois des avantages et des inconvénients.

Ce qui fonctionne bien

L’un des principaux avantages est que la RSE fonctionne très bien pour le contenu dynamique : le contenu avec état qui doit répondre rapidement aux entrées des utilisateurs. Cela constitue un élément crucial des applications Web modernes, ce qui explique en partie pourquoi la RSE est l’approche privilégiée depuis plusieurs années. En fait, c’est en grande partie pourquoi les applications à page unique (SPA) sont si populaires : nous pouvons réécrire dynamiquement la page actuelle au lieu d’avoir à récupérer et charger de nouvelles pages à chaque clic. Il a le potentiel de rendre les applications Web ultra rapides et réactives, ce qui est formidable.

Ce qui ne fonctionne pas bien

Malheureusement, cette sensation vive et instantanée ne s’appliquait vraiment que si vous faisiez partie de ces personnes assez chanceuses pour disposer d’une connexion Internet solide et fiable. Pour tous ceux qui ne se trouvaient pas dans ce scénario idéal, tout ce que le navigateur devait faire pour le rendu signifiait que le temps de chargement initial pouvait être difficile – les choses devenaient assez lentes. Et pour les gens qui n’ont jamais sauté dans le train de l’Internet rapide, comme les gens des zones rurales ou ceux qui ne pouvaient pas se permettre une connexion sophistiquée à très haut débit… eh bien, ils ont juste été en quelque sorte laissés pour compte. Pendant ce temps, les applications Web elles-mêmes sont devenues plus grandes … et plus gros … et plus grand.

La RSE ne fonctionne pas non plus particulièrement bien avec l’optimisation des moteurs de recherche (SEO). En effet, les moteurs de recherche explorent et indexent les sites Web en examinant leur texte, leurs descriptions d’images, etc. Mais, dans le cas de la RSE, ces éléments n’ont pas encore été rendus. Dans cet espace entre la récupération sur le serveur et le chargement dans le navigateur de l’utilisateur, il s’agit principalement d’un fichier HTML vide et de certains React (pas encore lisibles).

La solution proposée : SSR

Comme mentionné précédemment, SSR (ou rendu côté serveur) signifie que le contenu est rendu sur le serveur avant d’être livré au navigateur au format HTML, CSS et JS. Comme vous vous en doutez, cela présente ses propres avantages et inconvénients.

Ce qui fonctionne bien

La RSS, en général, a de meilleures performances que la RSE. Parce que le HTML et le CSS sont déjà rendus, la sensation de chargement de la page pour la toute première fois est ultra rapide : dites adieu à tous ces spinners et animations de chargement que nous voyons si souvent dans les SPA.

Ce pré-rendu résout également les problèmes de référencement mentionnés précédemment. Encore une fois, étant donné que le code HTML apparaît dans le navigateur et est prêt à l’emploi, les moteurs de recherche peuvent facilement parcourir ces balises d’en-tête et de paragraphe pour comprendre quel contenu se trouve réellement sur le site. Un bon référencement améliore vos notes et votre classement, place votre site plus haut dans les résultats de recherche et génère généralement plus de trafic.

Ce qui ne fonctionne pas bien

La RSS n’est pas la meilleure solution pour réagir aux commentaires des clients. En effet, il doit revenir au serveur chaque fois qu’il doit récupérer du contenu mis à jour. Alors qu’un composant CSR a déjà tout ce dont il a besoin côté client et a juste besoin d’effectuer un nouveau rendu rapide, le composant SSR n’a que le HTML statique. Pour les applications dynamiques et avec état, ce n’était pas idéal.

 Froid. Mais quelle est la place de ce truc RSC ?

RSC (React Server Components) constituent l’approche spécifique à React pour équilibrer SSR et CSR de manière à nous permettre d’avoir le meilleur des deux mondes. Pour de nombreux développeurs React axés sur le frontend, SSR a nécessité une grande courbe d’apprentissage ; il est venu avec beaucoup de nouveaux concepts techniques et terminologie (suspense, hydratation, régénération statique incrémentielle, etc.). Pour certaines personnes, la barrière à l’entrée semblait un peu raide et les avantages ne compensaient pas tout à fait le temps investi dans la mise en œuvre.

Lorsqu’il est combiné avec un framework (comme Next.js ou Waku), les RSC font un excellent travail en gérant les aspects techniques les plus difficiles de la RSS « en coulisses » – ce qui fait que les composants réels que nous écrivons ne semblent pas si différents de ceux que nous utilisons déjà. en tant que développeur React.

L’approche populaire de la RSS aujourd’hui consiste à diviser une application en «îles» d’interaction, ce qui signifie que certaines parties de la page seront statiques tandis que d’autres seront dynamiques. Dans React, cela se produit en choisissant entre les RSC et les composants clients traditionnels. Toute application React utilisant des RSC aurait besoin d’une combinaison de composants serveur et de composants clients afin d’être pleinement réactive aux entrées de l’utilisateur. En règle générale, vous souhaiterez utiliser un composant serveur lorsque vous devez effectuer une récupération de données volumineuse ou gérer de grandes dépendances, puis exploiter les composants clients lorsque vous avez besoin d’une interaction utilisateur et d’une interface utilisateur avec état. Cela ressemble souvent à une relation parent-enfant dans laquelle les RSC sont le parent et les composants clients sont l’enfant.

Vous vous sentez prêt à plonger ?

Même si tous ces acronymes peuvent sembler un peu intimidants au début, ce n’est en fait pas si mal après tout, n’est-ce pas ? De plus, si vous êtes un utilisateur de KendoReact, il est encore plus facile de commencer à implémenter des composants de serveur ; nous sommes fiers d’être les premiers à adopter Composants du serveur React ! Si vous souhaitez en savoir plus sur ce processus et avoir un aperçu de ce à quoi ressemblait notre processus de développement RSC, consultez notre flux récent : Décisions relatives aux données : composants du serveur React et KendoReact !