Comprendre React : Rendu côté serveur vs Composants serveur
Quelle est la différence, dans React, entre le rendu côté serveur (le “SSR”) et les composants serveur ?
Pendant un certain temps, j’arrivais pas à bien identifier la différence entre les deux. La question arrêtait pas de me trotter en tête.
À première vue, les deux semblent très similaires. Ils se déroulent tous deux sur le serveur. Ils sont tous deux destinés à accélérer le rendu du contenu.
Mais la documentation relative aux composants serveur explique que ces technologies servent des objectifs différents et opèrent à des niveaux différents. Les deux concepts sont indépendants. Vous pouvez avoir un rendu côté serveur (ou SSR) sans composants serveur et des composants serveur sans SSR. (Et, bien sûr, vous pouvez avoir les deux ou aucun des deux).
Alors, comment comprendre la différence entre les deux ?
Le jour où j'ai compris la différence entre les deux, c'est lorsque je me suis concentré sur ce qui est différent dans les deux noms, et non sur ce qui est similaire. Cela peut sembler évident au point d’être débile, mais croyez-moi, c'est logique. Laissez-moi vous expliquer.
Nous allons voir ça à l'aide d'un exemple pratique. Supposons que nous ayons une application ToDo. Nous avons une page simple avec un en-tête, la photo de profil de l'utilisateur en haut à droite, un menu latéral, un pied de page et la todo list dans le panneau principal.
En termes React, il s'agit d'une arborescence de composants : le composant principal (pour cet exemple) est la page, qui contient les composants de l'en-tête, du menu, du pied de page et du volet principal. L'en-tête contient le composant photo de profil, et la fenêtre principale contient le composant liste de tâches, qui contient chaque composant élément de tâche.
Qu'est-ce que le rendu côté serveur (SSR) ?
Lorsque Next JS faisait du Server Side Rendering (avant Next JS 13), il exécutait une version complète de React côté client sur le serveur. Cependant, il avait un point d'entrée très spécifique : le composant principal de page.
Ainsi, dans notre exemple d'app todo, toute l'arborescence des composants est rendue en HTML sur le serveur avant d'être envoyée au navigateur du client. Cela présente plusieurs avantages : Le chargement initial est plus rapideparce que les clients reçoivent l'intégralité du code HTML, ce qui leur permet de voir une page entièrement rendue plus rapidement. Il facilite le référencement : Les moteurs de recherche peuvent facilement explorer les pages SSR, ce qui améliore le référencement du site. **La charge côté client est réduite ** : Le serveur fait le gros du travail, ce qui réduit la charge de travail du JavaScript côté client pour le rendu de la page.
Cependant, il y a toujours des inconvénients. Vous dépendez toujours du JavaScript côté client si vous voulez que la page soit interactive après le rendu initial. C'est là que les composants serveur entrent en jeu.
Qu'est-ce qu'un composant serveur ?
Vous voyez... Ce qui est nouveau dans les composants serveur, ce n'est pas la partie "serveur". C'est la partie composant.
Le rendu côté serveur de NextJS prendrait toute la page, toute l'arborescence des composants, et la rendrait en HTML. Il convient donc principalement au chargement initial de la page. Mais il l'est moins pour les mises à jour ultérieures de la même page.
Les Composants du serveur peuvent être rendus individuellement.
Il convient de noter qu'ils ne produisent pas de code HTML, du moins pas par défaut. Nous reviendrons sur cette question plus tard.
Tout d'abord, pourquoi le "composant" est-il la partie opérationnelle et importante du nom ? Pourquoi est-ce important ?
Comme l'explique le modèle Astro des "îlots d'interactivité", dans de nombreux cas d'utilisation, une grande partie de l'application web est statique ou ne fait l'objet que de mises à jour minimes.
Si l'on se penche sur l'exemple de l'application Todo, l'en-tête, la barre de navigation latérale et le pied de page sont statiques, après le chargement initial. La seule partie dynamique est le volet central contenant les tâches à accomplir.
Les composants serveur React signifient que nous pouvons ajouter ou supprimer un élément Todo et ne mettre à jour que la partie de l'arborescence des composants qui a changé.
Les composants serveur permettent aux développeurs de rendre des parties spécifiques de l'interface utilisateur sur le serveur, puis de ne mettre à jour que ces parties en fonction des besoins. Cela a un certain nombre d'implications intéressantes. Cela signifie que :
-
Vous pouvez effectuer des mises à jour fines**avec moins de données transférées car seuls les composants qui doivent être modifiés sont mis à jour.
-
Il y a moins de code côté client** puisque les composants qui ne fonctionnent que sur le serveur n'ont pas besoin de code côté client.
-
La recherche de données est plus simple et, si j'ose dire, plus rationnelle, puisque les composants du serveur sont chargés de rechercher leurs propres données. Avant les composants serveur, je devais récupérer toutes les données dans le composant page via la fonction
getServersideProps, puis les transmettre à tous les composants via les props.
Si on prend un peu de recul, le SSR concerne le rendu de la page initiale, tandis que les composants serveur concernent la mise à jour dynamique de parties spécifiques de l'interface utilisateur sans recharger la page entière.
Maintenant, si on prend le temps d'y réfléchir, il manque encore une pièce au puzzle. Si on ne rend le HTML de la page sur le serveur, comment le navigateur peut-il savoir qu'il doit mettre à jour uniquement le HTML du composant ?
Vous vous souvenez que j'ai dit que les composants serveur ne produisent pas de HTML par défaut ?
Le format que les composants serveur React produisent en sortie est un format de texte streamable qui ressemble à des bouts de JSON. (Pour ceux qui se demandent pourquoi ils n'ont pas simplement utilisé JSON, ce serait beaucoup plus difficile à streamer).
Cela signifie qu'un JavaScript quelque part dé-sérialise le format spécial en HTML. Mais ce JavaScript est ... générique, il n'est pas spécifique à un composant donné.
Comparé à l'hydratation que Next JS ferait avant les composants serveur, c'est beaucoup plus léger et ciblé. Les composants serveur React nous permettent de mettre à jour des sections d'interface ciblées sans sacrifier la vitesse ou la sécurité.
Parce que le mot intéressant dans composants serveur React, c'est "composants".
Voilà, j'espère que c'est aussi clair pour vous que pour moi. Si vous avez encore des questions, n'hésitez pas à m'en faire part dans les commentaires, et en attendant... je vous donne rendez-vous dans la prochaine vidéo !
