Est-il nécessaire d'utiliser le rendu côté serveur pour comprendre javascript ?

La colonne

Tutoriel d'apprentissage Javascript indique s'il faut utiliser le rendu côté serveur.

Avant-propos

Il y a quelque temps, il y avait un projet de rendu côté serveur React. Dois-je. utiliser ça ? Cela dépend principalement de la scène.

Il est plus adapté au référencement et au rendu sur premier écran, qui sont souvent mentionnés par tout le monde, et est généralement nécessaire pour les affaires de toc.

Isomorphisme

Il existe de nombreuses différences entre le rendu côté serveur des frameworks modernes et jsp et php. Parce que nextjs et nuxtjs ne sont pas seulement un rendu côté serveur, ce sont également des frameworks isomorphes.

Qu'est-ce que l'isomorphisme ? Autrement dit, un morceau de code peut s’exécuter côté navigateur ou côté serveur. Cela est dû à la popularité de NodeJS côté serveur.

Les frameworks de rendu traditionnels côté serveur tels que jsp, php et django renvoient tous des chaînes HTML, similaires au mode multipage MPA traditionnel. Par conséquent, lors du changement de page, la page sera actualisée et les fichiers CSS et JS seront à nouveau demandés, ce qui entraînera une mauvaise expérience utilisateur.

Le modèle de développement frontal populaire actuel est la page unique SPA, basée sur l'historique H5 pour changer de page sans actualisation, ce qui peut apporter une meilleure expérience utilisateur.

Ainsi, nextjs et nuxtjs prennent non seulement en charge le rendu côté serveur, mais prennent également en charge SPA. Le rendu côté serveur est couramment utilisé pour la page d'accueil, et d'autres pages conservent toujours le mode d'accès sans actualisation de SPA.

Nous avons des pages écrites avec Django, ce qui est très pénible à maintenir. Parce qu’il est impossible de dire clairement lesquels sont responsables du front-end et lesquels sont responsables du back-end. Ainsi, pour maintenir cela, le front-end et le back-end doivent apprendre Python et Django, ce qui augmente considérablement les coûts de maintenance.

En termes de scénarios d'application réels, nous avons plusieurs scénarios plus adaptés au rendu côté serveur.

Demandes de publication de support

L'une est une page h5 reconstruite. Le projet a été précédemment écrit par une équipe singapourienne utilisant Python + Django, donc là. sont quelques pages Il est ouvert par un site Web tiers Post formulaire de soumission.

Nos pages H5 reconstruites sont toutes accrochées sur Tencent Cloud CDN et ne peuvent pas être ouvertes avec Post. Pourquoi ne pas le remplacer par Get ? Parce qu’il s’agit d’un accord qu’ils avaient conclu auparavant, et que les banques sont toutes des pères, donc elles ne modifieront pas l’accord dans notre intérêt.

Les fonctions de la page sont relativement simples, donc afin de rattraper le temps de reconstruction, l'ami à côté de moi à l'époque a implémenté une version utilisant Express + EJS, qui ne supportait que la syntaxe ES5.

Les exigences ultérieures ont changé plusieurs fois et il est difficile d'ajouter des fonctions à la page d'origine. Par exemple, si je souhaite implémenter JS Bridge, je ne peux utiliser que le microbundle pour regrouper le package npm existant dans un fichier umd, puis l'importer à l'aide de la balise script.

Rendu dynamique des titres

J'ai rencontré une autre exigence il y a quelque temps, je dois implémenter la même page H5 pour plusieurs banques. c'est fondamentalement qu'ils sont tous identiques, mais l'en-tête de l'application doit afficher les noms des différentes banques.

Dans notre application AirPay, lorsque le client ouvre la vue Web, il lira le titre dans notre HTML et le définira comme titre de l'en-tête natif.

Si j'utilise document.title pour le définir dynamiquement dans le code, cela ne prendra pas effet, je ne peux définir dynamiquement l'en-tête que via JS Bridge.

Mais cette page ne sera pas seulement utilisée par AirPay, mais également fournie par Shopee. Elle doit être compatible avec deux ensembles de JS Bridge, ce qui dépasse un peu le gain.

Mais si vous utilisez la méthode d'exportation directe côté serveur, vous pouvez déterminer directement le titre qui doit être rendu côté serveur et le définir dans le titre HTML. Il s’agit d’un autre scénario commercial approprié.

Ainsi, sur la base du projet précédent, la fonction de rendu côté serveur React a été ajoutée pour prendre en charge le développement d'applications isomorphes avec React. Next n'est pas utilisé ici, juste un ensemble d'isomorphismes implémentés par moi-même.

L'idée générale d'implémentation est d'utiliser isomorphic-style-loader et universal-router pour gérer l'isomorphisme des styles et des routes. Une fois que le serveur a obtenu les données, il les envoie à window._INITIAL_STATE__ et le navigateur les obtient. ces données d'initialisation pour la mise en œuvre. Les données sont homogènes.

Dans le même temps, le modèle EJS original est conservé, qui est distribué sur la base du routage Express. Il peut être rendu à l'aide d'EJS ou directement exporté depuis le serveur React.

Cette page dans la première phase est accrochée sur Tencent Cloud CDN. Dans la deuxième phase, le rendu côté serveur est utilisé. Vous pouvez évidemment sentir que la vitesse de chargement est beaucoup plus rapide. Après tout, une image de chargement sera utilisée. toujours être affiché auparavant.

En termes de tutelle des processus, l'ensemble des services Node du département sont effectués à l'aide du Node Agent écrit par le patron, et il a résisté à l'épreuve de diverses promotions majeures.

Inconvénients

Bien sûr, il ne faut pas abuser du rendu côté serveur.

Par exemple, notre système de gestion backend interne est alimenté par Nuxt. Désormais, chaque build local prend 10 minutes, ce qui affecte grandement l'efficacité du développement.

Nuxt possède des fonctions très puissantes, telles que le fractionnement dynamique des fichiers de build en fonction du routage, le préchargement des fichiers JS lorsque la souris est placée sur le composant de routage Nuxt-link, etc.

Mais le bénéfice réel est presque nul, car nous n’avons pas besoin de référencement, et nous n’avons pas besoin d’améliorer la vitesse de chargement du premier écran.

Presque tout le monde dans l'équipe a essayé différents moyens pour optimiser la construction, mais l'effet n'est pas très évident. Ce n'est que récemment que nous avons commencé à diviser les micro-interfaces que nous avons résolu ce problème.

De plus, le rendu côté serveur est également écrit différemment du rendu côté client, ce qui peut facilement conduire à des bugs.

Par exemple, le code suivant dans le fichier d'état Vuex :

const date = moment().format('YYYY-MM-DD')
export default () => ({  
date
})

Lorsque la page est ouverte, l'heure doit être affichée aujourd'hui. Même si la page est placée dans le ciel, elle devrait toujours être le même jour lorsque vous l'ouvrez et l'actualisez.

Mais dans Nuxt, la date affichée est la date de démarrage de votre service. Peu importe la façon dont vous l'actualisez, elle ne changera jamais.

Parce que Nuxt stockera ces données dans le magasin lors de son initialisation, quelle que soit la manière dont il sera actualisé ultérieurement, ce fichier ne sera pas rechargé sur le serveur car le module sera mis en cache par Node, donc la date sera. ne pas être mis à jour.

Mais dans le rendu côté client, puisque le rafraîchissement de la page entraînera le rechargement du fichier JS par le navigateur, cette date sera également recalculée.

Recommandé (gratuit) : Tutoriel d'apprentissage Javascript

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!