Le paradigme des composants du serveur React

Les composants serveur sont des composants React réservés au serveur qui peuvent générer le code HTML à partir d’un composant individuel, pas nécessairement de l’application entière. Obtenez un bref historique et comment les autres frameworks le gèrent.

Historique de génération HTML du serveur

Perl

Certains des premiers grands sites Web comme Amazon, eBay et Yahoo utilisaient le langage de programmation Perl pour générer du HTML sur le serveur. Les sites Web statiques étaient excellents, mais les données étaient souvent dynamiques et devaient être mises à jour à la volée.

Lorsque les sites Web sont devenus suffisamment grands, les bases de données texte ont été migrées vers MySQL. Les données ont pu être chargées dynamiquement à partir du serveur. Vous pouvez mettre à jour un prix, créer une nouvelle publication ou ajouter un nouveau produit sans reconstruire l’intégralité de votre site.

Cependant, il était difficile de connecter les modèles HTML et la syntaxe Perl pour une meilleure expérience de développement malgré des outils de création de modèles tels que boîte à outils de modèles.

PHP

PHP a facilité la création de modèles à la fin des années 90 et au début des années 2000. Je détestais PHP parce que je pensais que HTML ne devait pas être mélangé à un langage de programmation. Cela créait de nombreux problèmes potentiels et était plus difficile à déboguer. Cependant, la syntaxe, la vitesse et la popularité de PHP ont augmenté de façon exponentielle depuis que WordPress l’a adopté pour construire un empire multimilliardaire. 70 % des sites Web côté serveur l’utilisent encore aujourd’hui.

JavaScript asynchrone

Quelque chose a changé avec jQuery. Bien que jQuery ait fait disparaître facilement les problèmes de compatibilité des navigateurs, il a été Ajax (JavaScript asynchrone et XML) qui a changé la donne. Ajax vous a permis de récupérer des données HTML à partir du serveur (techniquement XML) et d’actualiser des parties de votre page avec du JavaScript pur. Cela signifiait qu’aucune image n’était nécessaire et que votre expérience utilisateur était meilleure. Finalement, nous l’avons remplacé par fetch.

RPC, SOAP et REST

L’idée de Appel de procédure à distance (RPC) existe depuis les années 70. Il s’agit essentiellement d’un moyen permettant à un client de communiquer avec un serveur comme s’il s’agissait d’une fonction locale. Il en existe aujourd’hui de nombreuses formes différentes.

Lorsque XML était encore populaire, les gens utilisaient Protocole d’accès aux objets simples (SOAP) pour communiquer avec leurs backends.

À un moment donné, les programmeurs ont réalisé que renvoyer JSON au lieu de XML était plus facile et plus rapide. REPOS (Representational State Transfer) est devenu le protocole incontournable. Il est encore utilisé aujourd’hui sur les serveurs Node.

Il convient également de mentionner GraphQL: bien que la partie communication fonctionne de manière similaire à REST, elle est plus précisément décrite comme un langage de requête et un environnement d’exécution d’API. Pour moi, c’est juste un autre protocole.

Demande d’une seule page

Avant Angular 1 et React, la plupart des sites Web dynamiques utilisaient principalement le serveur pour générer le HTML. Cependant, l’avènement de l’application monopage (SPA) a montré une bien meilleure expérience utilisateur par rapport à l’application multipage (MPA).

Cela signifie essentiellement que vous chargez votre JavaScript une fois et que l’ensemble de votre site Web est chargé. Il n’y a pas de temps d’attente entre le chargement des pages. Vous cliquez simplement et c’est là.

Au début, il n’y avait que des applications côté client. Les packages côté client pourraient rapidement devenir volumineux et les moteurs de recherche ne peuvent pas lire JavaScript.

Rendu côté serveur

À peu près à la même époque, en 2009, Node.js a été créé en même temps que le rendu côté serveur.

Vous pouvez restituer l’intégralité de votre application JavaScript sur le serveur et la charger dans le client en hydratant les données du serveur vers le client. Il s’agit simplement d’injecter l’état de l’application dans le JavaScript et de le charger. Plus votre site Web est grand, plus vous deviez apprendre à charger paresseusement les parties associées (ou simplement fetch eux) afin que votre package côté client ne soit pas extrêmement volumineux.

De manière générale, l’intégralité de votre code est exécutée deux fois (client et serveur), sauf si vous séparez les données spécifiques de votre serveur en points de terminaison. C’est ainsi qu’Angular avec Angular Universal fonctionne encore aujourd’hui, même si je soupçonne qu’Angular 17 va changer cela.

Routage basé sur des fichiers

De nombreux frameworks de base n’ont pas du tout de système de routage. Ce sont les méta-frameworks (Next.js, Nuxt, Remix, SvelteKit, etc.) qui disposent d’un routeur. Le routage basé sur des fichiers vous permet de créer des dossiers dans votre environnement de développement qui correspondent à des itinéraires spécifiques dans votre application. Un petit nombre de personnes sont contre, mais je trouve cela incroyablement utile.

Le routage basé sur les fichiers est important car les frameworks modernes vous permettent d’avoir un itinéraire différent pour les composants serveur et client. Cela signifie que vous pouvez créer une route serveur qui charge les données, puis les injecte dans une page HTML sur le client.

Ceci est accompli en utilisant des fonctions JavaScript pures comme load ou getServerSidePropsou vous pouvez émuler cela dans Angular avec resolvers. Vous aurez donc un fichier qui charge les données sur le serveur et un autre fichier qui place les données dans le fichier HTML. Il est important de noter que le HTML réel est rendu sur le serveur et que les données sont hydratées sur le client. Le routage basé sur des fichiers facilite simplement les choses.

Merci pour la leçon d’histoire, Nerd. Et le RSC ???

C’est exactement ce que font les composants du serveur React. Il s’agit de composants React réservés au serveur qui peuvent générer le code HTML à partir d’un composant individuel, pas nécessairement de l’application entière, en renvoyant jsx. Vous pouvez avoir des composants serveur dans des composants clients et vice versa. Logiquement, cela a du sens, mais en pratique, il faut réfléchir au modèle mental.

Tous les composants sont des composants serveur par défaut, sauf si vous utilisez 'use client' dans cette partie de votre fonction. Vous n’utiliserez même pas RSC à moins que vous ne disposiez d’un méta-framework qui gère bien le rendu du serveur et du client. À partir d’aujourd’hui, Next.js est l’adoptant.

Imaginez que votre application soit un composant serveur géant. Vous utilisez JSX (ou TSX si vous êtes intelligent) pour créer et construire du HTML. Il s’agit essentiellement d’utiliser votre serveur Node.js pour générer du HTML pour vous. Semble familier? RSC est juste PHP ???

Les composants React Server (RSC) ont souvent été comparés à PHP en raison de la raison pour laquelle PHP est encore utilisé à ce jour. La plupart des personnes qui utilisent Node.js l’utilisent en combinaison avec un framework JavaScript. La boucle est peut-être bouclée, mais nous ne nous débarrassons certainement pas du code côté client.

https://twitter.com/housecor/status/1602673489013575681?lang=fr

Mais le HTML est déjà généré sur le serveur ?

Pas exactement, mais oui. Si vous générez du HTML sur le serveur et l’affichez sur le client, il n’est pas réactif dans les composants serveur, ni en PHP. Cela signifie que vous ne pouvez pas utiliser useState, useEffect ou tout autre package de gestion d’état pour modifier dynamiquement vos données après leur chargement.

Autrefois, si l’on voulait avoir de l’interactivité, il fallait charger le JavaScript dans l’en-tête, que le client utiliserait une fois la page chargée. Les frameworks ont rendu cela facile en injectant le script tags pour nous, et le données dans le HTML page au format JSON. Mais tout n’est pas interactif.

Arborescence des serveurs

Dans React, vous avez votre arborescence de composants React qui est chargée dans le navigateur. Cela signifie que tout peut être interactif par défaut. Selon Dan Abramovmembre principal de l’équipe React, vous ajoutez simplement la possibilité de créer un arborescence du serveur côté serveur différent de l’arborescence client. Vous n’avez pas besoin d’accéder à l’arborescence du serveur sur le client car elle n’est pas interactive. Il détaille la compréhension de base de RSC à partir de zéro.

Rich Harris est contre

Le créateur de Svelte est contre les composants serveur, même si je ne suis qu’en partie d’accord avec lui.

https://youtu.be/uXCipjbcQfM?t=1568

1. Pics de latence

L’argument principal de Harris est que lorsque vous avez une connexion instable, comme lorsque vous êtes dans le métro, l’expérience utilisateur ne sera pas aussi bonne lorsque vous utilisez quelque chose comme des composants serveur. Vous ne voulez pas retélécharger votre application juste pour avoir de l’interactivité comme à l’époque PHP.

Je pense qu’il n’a pas compris l’essentiel ici. Si vous concevez votre application de manière à ce que les parties interactives n’aient pas besoin d’être retéléchargées, cela n’aura pas d’importance. Vous pourriez également mal concevoir une application SvelteKit pour charger paresseusement les mauvais éléments, provoquant les mêmes problèmes. RSC vous donne simplement plus de contrôle.

Sommes-nous en train de sur-corriger ? Je dis catégoriquement non.

2. Cartes sources

Les mappages sources facilitent le débogage dans les environnements de production en mappant votre code compilé au code d’origine. Fondamentalement, il n’y aura pas de cartes sources avec RSC, ce qui rendra impossible le débogage de cette partie de l’application. Ironiquement, il a utilisé le Exemple de carte source encore une fois pour illustrer comment la fuite du code du serveur uniquement vers le client peut être un problème. Voulons-nous des cartes des sources du serveur ou non, Rich !?

Bien que je pense que ce soit un argument valable, je pense qu’il est rare que vous ne puissiez pas effectuer les parties importantes du débogage dans un environnement de développement. Cependant, je ne crée pas de cadre, donc je ne peux vraiment pas m’y opposer.

Vitesse RSC

Jack Herrington affirme que l’ancienne méthode de génération de composants de serveur, à l’aide du répertoire d’applications, est plus rapide. D’autres personnes ont effectué son test avec des résultats similaires :

https://youtu.be/3Q2q2gs0nAI

Cependant, comme Théo souligne, ces tests sont effectués sur une machine locale. Cela signifie que vous n’obtenez pas les performances de vitesse que le CDN et la mise en cache vous offriront.

Votre machine locale n’est pas la même chose qu’un environnement de serveur rapide. La question de savoir si vous devez ou non utiliser des composants serveur est en fait assez nuancée. Certaines situations seront plus rapides sans eux.

Cependant, même Herrington pense que la vitesse de RSC s’améliorera avec le temps, dans l’espoir d’être plus rapide que l’ancien répertoire d’applications Next.js dans tous les cas. À déterminer.

Ce que font les autres frameworks

Vue

Nuxt a implémenté sa propre version des composants serveur de Vue.

https://www.youtube.com/watch?v=17zBODTpuoo

Cela semble être dans un état de développement plus lent que RSC, mais l’avenir nous le dira.

Colocation

Cela ne vaut également rien que vous puissiez voir la colocation dans certains frameworks, qui est du code backend dans les fichiers frontend. Le code est écrit de manière à donner l’impression que vous appelez une fonction serveur dans le client, alors qu’en réalité il crée un point de terminaison. La norme semble utiliser server$() pour les créer.

Comme vous pouvez l’imaginer, Rich Harris est également contre cela pour des raisons de sécurité des points finaux, et il invoque également un méta ou un pseudo JavaScript pour les exécuter.

Il mentionne que le problème de sécurité peut être résolu avec Protection CSRF et Primitives CSP tout comme SvelteKit l’utilise, alors pourquoi ne pas simplement demander aux autres frameworks de l’ajouter également (sauf lorsqu’ils veulent des points de terminaison ouverts).

Ma conclusion

Je n’utilise pas React. J’ai moi-même créé des applications complexes pour l’apprendre, mais ce n’est finalement pas pour moi. Cependant, je pense que les composants serveur sont une bonne chose. Gardons simplement le HTML non interactif, chargé une seule fois.

Je pense que le problème de la carte source se résoudra avec le temps, et je pense que le problème de latence est davantage un problème de conception. Il faut savoir quand les utiliser.

Je pense également que la colocation est une excellente idée car elle améliore l’expérience des développeurs. Personnellement, j’utilise SvelteKit, même si je ne suis pas d’accord avec tout ce que dit Rich Harris. L’expérience développeur et l’expérience utilisateur semblent gagnantes dans la plupart des cas.

Les composants serveur ne sont qu’un autre moyen d’optimiser votre code dans React ou dans tout autre framework comme Nuxt. Ce n’est pas aussi compliqué qu’il y paraît, mais ce n’est pas non plus PHP.

J’adore l’idée et je suis prêt à ce que d’autres frameworks voient son potentiel.