Comprendre la RSE dans Next.js : explication du rendu côté client

CSR (Client-Side Rendering) est une méthode de rendu d'une page côté client, ce qui signifie qu'elle ne s'exécute pas sur le serveur. La RSE est essentiellement la même que la SPA (Single Page Application), donc si vous savez ce qu'est une SPA et comment elle fonctionne, vous comprenez déjà la RSE. Mais si vous n'êtes pas sûr de ce qu'est le SPA ou de son fonctionnement, je vais vous l'expliquer ci-dessous.

Dans cet article, je vais décrire ce qu'est le SPA et comment il fonctionne. Après cela, je le comparerai à la RSE dans Next.js et vous montrerai comment mettre en œuvre la RSE dans votre projet Next.js.

Qu’est-ce que le SPA ?

Une SPA (Single Page Application) consiste en une seule page HTML qui réécrit dynamiquement le contenu selon les besoins, au lieu de charger une nouvelle page HTML pour chaque interaction.

Comment fonctionne l'AMP ?

Avant de comprendre le SPA, vous devez d'abord connaître le MPA. Apprenons-en :

Avant que les SPA ne deviennent populaires, les sites Web étaient créés en utilisant l'approche des applications multipages (MPA). Alors, comment fonctionnaient les AMP ? Imaginez que vous, en tant que développeur, souhaitiez créer un site Web comportant deux pages : la page d'accueil ("/") et une page à propos ("/about"). Pour construire ceci en utilisant la méthode multipage, vous devrez créer deux fichiers HTML distincts pour chaque itinéraire : main.html pour "/" et about.html pour "/about".

Dans chaque fichier HTML, vous devrez écrire du code HTML, CSS et JavaScript spécifique pour cette page. Cependant, certaines parties du code, comme l’en-tête et le pied de page, sont les mêmes sur les deux pages. Même si l'en-tête et le pied de page sont identiques, vous, en tant que développeur, devrez les répéter dans chaque fichier HTML.

Lorsque le projet est terminé et déployé sur un serveur, le serveur envoie la page HTML complète ainsi que toutes les ressources demandées à l'utilisateur. Par exemple, lorsqu'un utilisateur visite la page d'accueil pour la première fois, le serveur envoie le fichier main.html prêt et l'utilisateur peut voir le contenu immédiatement après une courte attente. Cette méthode est bonne pour le référencement car lorsqu'un robot de moteur de recherche visite votre site Web, il peut voir tout le contenu du fichier HTML, car il est entièrement rendu au préalable.

Cependant, lorsque l'utilisateur accède à une autre page, comme "/about", le processus recommence. Le serveur envoie le fichier about.html ainsi que toutes ses ressources (CSS, JS, etc.). L'utilisateur doit attendre une nouvelle fois que la page se charge, et si sa connexion Internet est lente, l'attente est plus longue. Ce qui est encore plus inefficace, c'est que l'utilisateur doit télécharger à nouveau le même code pour l'en-tête et le pied de page, même s'ils n'ont pas changé. Cette répétition de code (comme l’en-tête et le pied de page) est inutile et inefficace dans les pratiques de développement Web actuelles.

Comment fonctionne le SPA ?

Maintenant que vous comprenez le fonctionnement de MPA (Multi-Page Application), voyons comment fonctionne un SPA.

En raison du retard de chargement des pages à chaque requête, de la répétition du code et de la nécessité de reconstruire l'intégralité du DOM à chaque fois, des SPA ont été introduits pour résoudre ces problèmes.

Imaginez que vous êtes un développeur créant un site Web avec deux itinéraires : "/" et "/about". Dans un framework SPA, vous n'avez qu'un seul fichier HTML appelé index.html. Au lieu de créer des fichiers HTML distincts pour chaque itinéraire, vous créez des composants pour chaque page et les chargez dynamiquement. Par exemple, vous créeriez trois composants, un pour chaque itinéraire et les importeriez dans votre index.html.

Dans les SPA, vous pouvez également séparer les sections réutilisables de votre site (comme l'en-tête et le pied de page) en leurs propres composants. Au lieu d'écrire le même code d'en-tête et de pied de page pour chaque page, vous importez simplement ces composants là où cela est nécessaire, de la même manière que fonctionnent les fonctions. Cela réduit les répétitions et facilite le développement.

Lorsque votre projet SPA est déployé sur un serveur, le serveur ne restitue plus le contenu de la page. Au lieu de cela, il sert le fichier index.html ainsi que les bundles JavaScript qui contiennent vos composants. Le rendu s'effectue côté client, dans le navigateur.

Lorsqu'un utilisateur visite votre site pour la première fois, le serveur envoie le fichier index.html ainsi que les fichiers JavaScript nécessaires. Cela peut entraîner un temps d'attente plus long par rapport à un MPA, car l'intégralité du DOM est construit une fois le JavaScript entièrement téléchargé, analysé et exécuté.

Cependant, une fois la page initiale chargée, la navigation entre les pages est beaucoup plus rapide dans un SPA. Par exemple, si l'utilisateur navigue de / vers /about, le navigateur n'a pas besoin de recharger la page entière. Étant donné que les éléments communs tels que l'en-tête et le pied de page sont déjà chargés, le navigateur récupère uniquement le code JavaScript pour le contenu spécifique qui change (par exemple, le contenu de la page /about). Le DOM est mis à jour dynamiquement sans actualisation complète de la page, ce qui donne à l'utilisateur l'impression d'interagir avec une application plutôt qu'avec un site Web traditionnel. Cela offre une expérience plus fluide et plus « semblable à une application ».

Cependant, les SPA présentent un inconvénient, surtout en matière de référencement. Étant donné que le fichier index.html initial contient un contenu minimal (la plupart des données étant chargées via JavaScript), les robots des moteurs de recherche peuvent voir une page vide et avoir des difficultés à indexer le contenu. C'est pourquoi le référencement dans les SPA peut être difficile par rapport aux MPA traditionnels.

La RSE est-elle la même que la méthode SPA ?

Oui, le CSR (Client-Side Rendering) est une méthode de rendu, c'est-à-dire le processus de conversion de composants dans un format pouvant être affiché dans le navigateur, permettant à l'utilisateur de voir la page. L’essentiel à comprendre est que la RSE se déroule entièrement dans le navigateur. Pour React et Next.js, CSR fonctionne de la même manière, il n'y a aucune différence entre les deux en ce qui concerne le rendu côté client.

Par exemple, en CSR, lorsque vous visitez un site Web pour la première fois, le serveur envoie un fichier index.html avec un contenu minimal. Mais voici le problème : ce fichier n’a pas encore tout le contenu. Le contenu réel est rendu dans le navigateur une fois que tous les fichiers de composants nécessaires (JavaScript, CSS, etc.) ont été téléchargés. Ensuite, React construit l'arborescence DOM (Document Object Model), puis crée un DOM virtuel, qui est comme une copie légère du vrai DOM.

Une fois le DOM et le DOM virtuel configurés, l'utilisateur peut voir la page. Ce processus de rendu se produit dans le navigateur, convertissant tous les composants en une page affichable.

Désormais, lorsque l'utilisateur navigue d'une page à une autre (disons de / vers /about), React crée un nouveau DOM virtuel pour la nouvelle page. Il compare l'ancien DOM virtuel avec le nouveau, trouve les différences et applique ces modifications au DOM réel. Ce processus de comparaison et de mise à jour du DOM se déroule efficacement et tout se déroule dans le navigateur.

Donc, pour résumer, la RSE fonctionne de la même manière dans React et Next.js. Le rendu s'effectue dans le navigateur et React gère efficacement les mises à jour du DOM à l'aide du DOM virtuel, rendant l'expérience utilisateur fluide et rapide.

Comment mettre en œuvre la RSE dans Next.js ?

Si vous utilisez des méthodes côté client comme useEffect dans votre composant, au lieu de méthodes côté serveur telles que getStaticProps ou getServerSideProps, votre page sera rendue sur le client, suivant la méthode CSR (Client-Side Rendering). Cela signifie que le navigateur gère le rendu après le chargement du code HTML initial.

De plus, l'utilisation de bibliothèques telles que SWR ou TanStack Query active également la RSE, car ces bibliothèques gèrent la récupération des données dans le client après le chargement de la page. De cette façon, votre composant est affiché dans le navigateur et toute mise à jour des données s'effectue de manière transparente côté client, sans implication côté serveur.

Conclusion

CSR est une méthode de rendu de notre projet dans le client, et c'est essentiellement la même que la définition SPA (Single Page Application). React utilise CSR pour le rendu, et c'est l'une des principales différences entre MPA (Multi-Page Applications) et SPA. Next.js utilise également CSR car il est basé sur React, mais pour améliorer le référencement et l'expérience utilisateur, Next.js a ajouté SSG, ISR et SSR. Vous pouvez en savoir plus sur SSR, ISR et SSG. Si vous souhaitez rester informé de mes derniers articles, suivez mon site Web à l'adresse https://saeed-niyabati.ir . Merci d'avoir lu ! Au revoir pour l'instant !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!