Maison > interface Web > Questions et réponses frontales > Vue3.0 prend-il en charge le rendu côté serveur ?

Vue3.0 prend-il en charge le rendu côté serveur ?

青灯夜游
Libérer: 2022-12-15 14:47:24
original
2502 Les gens l'ont consulté

vue3.0 prend en charge le rendu côté serveur. Vue prend en charge le rendu des composants directement dans des chaînes HTML côté serveur, les renvoyant au navigateur en tant que réponse côté serveur, et enfin « activant » (hydrate) le code HTML statique côté navigateur dans une application client interactive. Une application Vue rendue par le serveur peut être considérée comme « isomorphe » ou « universelle » car la plupart du code de l'application s'exécute à la fois sur le serveur et sur le client. Avantages de Vue utilisant le rendu côté serveur : chargement plus rapide du premier écran, modèle mental unifié, meilleur. SEO.

Vue3.0 prend-il en charge le rendu côté serveur ?

L'environnement d'exploitation de ce tutoriel : système Windows7, version vue3, ordinateur DELL G3

Vue prend en charge le rendu côté serveur (SSR) est un framework pour créer des applications côté client. Par défaut, la responsabilité des composants Vue est de générer et de manipuler le DOM dans le navigateur. Cependant, Vue prend également en charge le rendu des composants directement dans des chaînes HTML côté serveur. La réponse est renvoyée au navigateur, et finalement le HTML statique est "hydraté". du côté du navigateur dans une application client interactive.

Une application Vue.js rendue par le serveur peut également être considérée comme « isomorphe » (Isomorphique) ou « Universelle » (Universelle), car la plupart du code de l'application s'exécute sur les deux. le serveur et le client.

Pourquoi utiliser le rendu côté serveur (SSR) ?

Rendu simple face avec le client Par rapport au SPA, les principaux avantages du SSR sont :

    premier écran plus rapide. chargement
  •  : Ceci est particulièrement important sur les vitesses de réseau lentes ou sur les appareils lents. Le HTML rendu sur le serveur n'a pas besoin d'attendre que tout le JavaScript soit téléchargé et exécuté avant d'être affiché, afin que vos utilisateurs voient le rendu complet. page plus rapidement et le processus de récupération des données est terminé côté serveur lors de la première visite, par rapport au client Get, peut-être avoir une connexion à la base de données plus rapide, ce qui conduit généralement à des scores de métriques Web de base plus élevés, une meilleure expérience utilisateur et pour. les applications où « la vitesse de chargement du premier écran est directement liée au taux de conversion », cela peut être crucial [Recommandations associées :

    Tutoriel vidéo vuejs, développement web front-end]

  • Modèle mental unifié
  •  : Vous pouvez utiliser le même langage et le même modèle mental déclaratif orienté composants pour développer l'intégralité de l'application sans basculer entre le système de modèles backend et le framework frontend

  • Meilleur référencement
  •  : les robots des moteurs de recherche peuvent voir. la page entièrement rendue directement

    lors de l'utilisation de SSR. Il y a également quelques compromis à prendre en compte :

Les limitations de développement côté navigateur ne peuvent être utilisées que dans certains hooks de cycle de vie ; gestion spéciale à utiliser dans les applications rendues côté serveur.
  • Plus d'exigences liées à la configuration et au déploiement des applications de rendu côté serveur nécessitent un environnement qui permet au serveur Node.js de s'exécuter, contrairement à un SPA complètement statique. qui peut être déployé sur n'importe quel serveur de fichiers statiques.
  • Charge de serveur plus élevée Le rendu d'une application complète dans Node.js nécessite plus de CPU que le simple hébergement de fichiers statiques, donc si vous vous attendez à un trafic élevé, préparez-vous à la charge de serveur correspondante. et adopter une stratégie de mise en cache solide.
Server Side Rendering (SSR) vs. Static Site Generation (SSG)

Static-Site Generation

(Static-Site Generation, en abrégé SSG), également connu sous le nom de

Pré-rendu, est une autre technique populaire pour créer des sites Web rapides. Si les données requises pour afficher une page côté serveur sont les mêmes pour chaque utilisateur, nous pouvons alors les afficher une seule fois et le faire à l'avance pendant le processus de création, au lieu de restituer la page à chaque fois qu'une demande arrive. Les pages pré-rendues sont générées et hébergées sur le serveur sous forme de fichiers HTML statiques. SSG conserve les mêmes performances que les applications SSR : il apporte d'excellentes performances de chargement sur le premier écran. Dans le même temps, il est moins coûteux et plus facile à déployer que les applications SSR car il génère des fichiers HTML et de ressources statiques. Le mot clé ici est statique : SSG ne peut être utilisé que pour les pages qui consomment des données statiques, c'est-à-dire que les données sont connues au moment de la construction et ne changent pas au cours de plusieurs déploiements. Chaque fois que les données changent, elles doivent être redéployées.

Si vous étudiez le SSR uniquement pour optimiser le référencement de quelques pages marketing (telles que /, /about, /contact, etc.), vous aurez peut-être besoin de SSG au lieu de SSR. SSG est également idéal pour créer des sites Web basés sur le contenu, tels que des sites de documentation ou des blogs. En fait, le site Web que vous lisez actuellement a été généré de manière statique à l'aide de VitePress, un générateur de site statique alimenté par Vue.

Bonjour tout le monde

Préparez-vous à découvrir le rendu côté serveur en action. Le rendu côté serveur (c'est-à-dire SSR) semble compliqué, mais un simple script Node peut réaliser cette fonction en seulement 3 étapes :

// 步骤 1:创建一个Vue实例
var Vue = require('vue')
var app = new Vue({
  render: function (h) {
    return h('p', 'hello world')
  }
})

// 步骤 2: 创建一个渲染器
var renderer = require('vue-server-renderer').createRenderer()

// 步骤 3: 将 Vue实例 渲染成 HTML

renderer.renderToString(app, function (error, html) {
  if (error) throw error
  console.log(html)
  // => <p server-rendered="true">hello world</p>
})
Copier après la connexion

Ce n'est pas difficile. Bien sûr, cet exemple est plus simple que la plupart des applications pour explorer le fonctionnement de ces fonctions

Rendu simple côté serveur via le serveur Web Express

Sans serveur Web, il est difficile de dire rendu côté serveur, alors parlons faites-le reconstituer. Nous allons créer une application de rendu côté serveur très simple en utilisant uniquement ES5 et aucune autre étape de construction ni plugin Vue.

Lancez une application qui indique aux utilisateurs combien de temps ils ont passé sur une page.

new Vue({
  template: &#39;<div>你已经在这花了 {{ counter }} 秒。</div>&#39;,
  data: {
    counter: 0
  },
  created: function () {
    var vm = this
    setInterval(function () {
      vm.counter += 1
    }, 1000)
  }
})
Copier après la connexion

Afin de nous adapter au rendu côté serveur, nous devons apporter quelques modifications pour qu'il puisse être rendu dans le navigateur et Node :

  • Dans le navigateur, ajoutez notre instance d'application au contexte global (fenêtre) , nous Il peut être installé.

  • Dans Node, exporter une fonction factory nous permet de créer des instances d'application pour chaque requête.

Un petit modèle est nécessaire pour implémenter cela :

// assets/app.js
(function () { &#39;use strict&#39;
  var createApp = function () {
    // ---------------------
    // 开始常用的应用代码
    // ---------------------

    // 主要的Vue实例必须返回,并且有一个根节点在id "app"上,这样客户端可以加载它。

    return new Vue({
      template: &#39;<div id="app">你已经在这花了 {{ counter }} 秒。</div>&#39;,
      data: {
        counter: 0
      },
      created: function () {
        var vm = this
        setInterval(function () {
          vm.counter += 1
        }, 1000)
      }
    })

    // -------------------
    // 结束常用的应用代码
    // -------------------
  }
  if (typeof module !== &#39;undefined&#39; && module.exports) {
    module.exports = createApp
  } else {
    this.app = createApp()
  }
}).call(this)
Copier après la connexion

Maintenant que nous avons le code de l'application, ajoutons un fichier html.

<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
  <title>My Vue App</title>
  <script src="/assets/vue.js"></script>
</head>
<body>
  <div id="app"></div>
  <script src="/assets/app.js"></script>
  <script>app.$mount(&#39;#app&#39;)</script>
</body>
</html>
Copier après la connexion

Faites principalement référence aux fichiers app.js et vue.js que nous avons créés précédemment dans le dossier Assets. Nous avons une application d'une seule page qui peut s'exécuter

Ensuite, afin d'implémenter le rendu côté serveur, nous devons ajouter un. étape côté serveur.

// server.js
&#39;use strict&#39;

var fs = require(&#39;fs&#39;)
var path = require(&#39;path&#39;)

// 定义全局的Vue为了服务端的app.js
global.Vue = require(&#39;vue&#39;)

// 获取HTML布局
var layout = fs.readFileSync(&#39;./index.html&#39;, &#39;utf8&#39;)

// 创建一个渲染器
var renderer = require(&#39;vue-server-renderer&#39;).createRenderer()

// 创建一个Express服务器
var express = require(&#39;express&#39;)
var server = express()

// 部署静态文件夹为 "assets"文件夹
server.use(&#39;/assets&#39;, express.static(
  path.resolve(__dirname, &#39;assets&#39;)
))

// 处理所有的Get请求
server.get(&#39;*&#39;, function (request, response) {
  // 渲染我们的Vue应用为一个字符串
  renderer.renderToString(
    // 创建一个应用实例
    require(&#39;./assets/app&#39;)(),
    // 处理渲染结果
    function (error, html) {
      // 如果渲染时发生了错误
      if (error) {
        // 打印错误到控制台
        console.error(error)
        // 告诉客户端错误
        return response
          .status(500)
          .send(&#39;Server Error&#39;)
      }
      // 发送布局和HTML文件
      response.send(layout.replace(&#39;<div id="app"></div>&#39;, html))
    }
  )
})

// 监听5000端口
server.listen(5000, function (error) {
  if (error) throw error
  console.log(&#39;Server is running at localhost:5000&#39;)
})
Copier après la connexion

C'est tout. L'exemple complet, clonez-le pour une expérience approfondie. Une fois qu'il est exécuté localement, vous pouvez confirmer que le service sélectionné par Renderer est réellement en cours d'exécution en cliquant avec le bouton droit sur la page et en sélectionnant Ressources de page (ou similaire). Peut être vu dans le corps :

<div id="app" server-rendered="true">You have been here for 0 seconds&period;</div>
Copier après la connexion

au lieu de :

<div id="app"></div>
Copier après la connexion

Réponse en streaming

Vue prend également en charge le rendu en streaming, avec une préférence appliquée aux serveurs Web prenant en charge le streaming. Permet au HTML d'être généré et écrit de manière générale dans le flux correspondant, plutôt que d'être écrit en une seule fois. Le résultat est que les demandes sont traitées plus rapidement, sans aucun inconvénient !

Afin de rendre le code de l'application de la section précédente adapté au rendu en streaming, vous pouvez simplement remplacer server.get('*',...) par le code suivant :

// 拆分布局成两段HTML
var layoutSections = layout.split('<div id="app"></div>')
var preAppHTML = layoutSections[0]
var postAppHTML = layoutSections[1]

// 处理所有的Get请求
server.get('*', function (request, response) {
  // 渲染我们的Vue实例作为流
  var stream = renderer.renderToStream(require('./assets/app')())

  // 将预先的HTML写入响应
  response.write(preAppHTML)

  // 每当新的块被渲染
  stream.on('data', function (chunk) {
    // 将块写入响应
    response.write(chunk)
  })

  // 当所有的块被渲染完成
  stream.on('end', function () {
    // 将post-app HTML写入响应
    response.end(postAppHTML)
  })

  // 当渲染时发生错误
  stream.on('error', function (error) {
    // 打印错误到控制台
    console.error(error)
    // 告诉客服端发生了错误
    return response
      .status(500)
      .send('Server Error')
  })
})
Copier après la connexion

Ce n'est pas plus compliqué que le précédent version, et cela peut même fonctionner pour vous. Ce n'est même pas un nouveau concept. Nous avons fait :

  • Créer le flux

  • Écrire du HTML avant d'appliquer la réponse

  • Écrire le HTML d'application à la réponse lorsqu'il est disponible

  • Écrire du HTML à la fin de la réponse

  • Traitement Toute erreur

Mise en cache des composants

Le rendu côté serveur de Vue est très rapide par défaut, mais vous pouvez encore améliorer les performances en mettant en cache les composants rendus. Ceci est considéré comme une fonctionnalité avancée, cependant, si le mauvais composant est mis en cache (ou si le bon composant a le mauvais contenu), l'application ne s'affichera pas correctement. Remarque spéciale :

Les composants contenant des sous-composants qui dépendent de l'état global (comme l'état de vuex) ne doivent pas être mis en cache. Si vous faites cela, le sous-composant (en fait le sous-arbre entier) sera également mis en cache. Portez donc une attention particulière aux situations impliquant des fragments ou des sous-composants de slots.

Paramètres

En dehors des situations d'avertissement, nous pouvons mettre en cache les composants en utilisant la méthode suivante.

Tout d'abord, vous devez fournir un objet cache au moteur de rendu. Voici un exemple simple utilisant lru-cache

var createRenderer = require(&#39;vue-server-renderer&#39;).createRenderer
var lru = require(&#39;lru-cache&#39;)

var renderer = createRenderer({
  cache: lru(1000)
})
Copier après la connexion

qui mettra en cache jusqu'à 1000 rendus indépendants. Pour une configuration plus approfondie de la mise en cache dans le contenu, voir Paramètres lru-cache

Ensuite, pour les composants que vous souhaitez mettre en cache, vous pouvez leur fournir :

  • un nom unique

  • une fonction serverCacheKey qui renvoie Un unique portée du composant

Exemple :

Vue.component({
  name: &#39;list-item&#39;,
  template: &#39;<li>{{ item.name }}</li>&#39;,
  props: [&#39;item&#39;],
  serverCacheKey: function (props) {
    return props.item.type + &#39;::&#39; + props.item.id
  }
})
Copier après la connexion

Composant idéal pour la mise en cache

Tout composant pur peut être mis en cache en toute sécurité - cela permet de garantir que la transmission des mêmes données à n'importe quel composant produira le même code HTML. Exemples de ces scénarios :

  • Composants statiques (par exemple, essayez toujours le même code HTML pour que la fonction serverCacheKey puisse être renvoyée vraie)

  • Composants de liste (lorsqu'il existe de grandes listes, leur mise en cache peut améliorer les performances)

  • Composants courants de l'interface utilisateur (tels que les boutons, les alertes, etc. - au moins, ils obtiennent des données via des accessoires au lieu de slots ou de sous-composants)

Explication :

Maintenant, vous devez comprendre les concepts de base derrière le côté serveur rendu. Cependant, le processus de construction, le routage et Vuex ont chacun leurs propres considérations.

(Partage de vidéos d'apprentissage : Tutoriel d'introduction à vuejs, Vidéo de programmation de base)

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!

Étiquettes associées:
source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal