介绍
Nuxt.js是一个基于Vue.js的通用应用框架。
Nuxt.js是使用Webpack和Node.js进行封装的基于Vue的SSR框架,使用它,你可以不需要自己搭建一套SSR程序,而是通过其约定好的文件结构和API就可以实现一个首屏渲染的Web应用。
首先,Nuxt.js是一个Node程序,就像上面说的,我们是要把Vue跑在服务端,所以必须使用Node环境。我们对Nuxt.js应用的访问,实际上是在访问这个Node.js程序的路由,程序输出首屏渲染内容+用以重新渲染的SPA的脚本代码,而路由是由Nuxt.js约定好的pages文件夹生成的。所以整体上,Nuxt.js通过各个文件夹和配置文件的约束管理我们的程序,而不失扩展性,其有自己的插件机制。
作为框架,Nuxt.js为客户端/服务端这种典型的应用架构模式提供了许多有用的特性,例如异步数据加载、中间件支持、布局支持等。
Nuxt.js框架是如何运作的?
Nuxt.js集成了以下组件/框架,用于开发完整而强大的Web应用:Vue2、Vue-Router、Vuex、Vue-Meta,另外Nuxt.js使用Webpack和vue-loader、babel-loader来处理代码的自动化构建工作(如打包、代码分层、压缩等等)。
特性
- 基于Vue.js
- 自动代码分层
- 服务端渲染
- 强大的路由功能,支持异步数据
- 静态文件服务
- ES6/ES7语法支持
- 打包和压缩JS和CSS
- HTML头部标签管理
- 本地开发支持热加载
- 集成ESLint
- 支持各种样式预处理器:SASS、LESS、Stylus等等
- 支持HTTP/2推送
静态化(预渲染)
支持Vue.js应用的静态化算是Nuxt.js的一个创新点,通过nuxt generate命令实现。
该命令依据应用的路由配置将每一个路由静态化成为对应的HTML文件。
静态化可以让你在任何一个静态站点服务商托管你的Web应用。
我们不希望每次更新部署docs仓库的时候都要手工执行nuxt generate命令生成静态文件,它会触发Netlify的钩子应用:
1.克隆nuxtjs.org repository
2.使用npm install命令安装依赖
3.运行npm run generate
4.生成dist目录
我们现在就有了一个无服务端的自动静态化的Web应用
。
我们进一步考虑下电商应用的场景,利用nuxt generate,是不是可以将应用静态化后部署在CDN服务器上,每当一个商品的库存发生变化时,就重新静态化,更新下商品的库存。但是如果用户访问的时候恰巧更新了呢?我们可以通过调用电商的API,保证用户访问的是最新的数据。这样相对于传统的电商应用来说,这种静态化的方案可以大大节省服务器的资源。
Nuxt.js主要是用来解决首屏问题和浏览器seo问题
问题:哪一些配置属于服务端渲染
注释(1)Vue-Meta:
在Vue SPA(单页面应用)中,如果想要修改HTML头部标签,比如修改页面标题、在头部中引入外部js文件或许会在代码中这么写:
// 修改title
document.title = '海康电商'
// 引入外部js
let s = document.createElement('script')
s.setAttribute('src', './vConsole.js')
document.head.appendChild('s')
....
上面的代码都是用来修改HTML头部,我们感觉代码会有点麻烦,所以引入Vue-Meta来管理头部代码会更加方便。
参考文章:https://segmentfault.com/a/1190000012849210
注释(2)SSR(服务端渲染):
简单理解是将组件或页面通过服务器生成html字符串,再发送到浏览器结合css显示页面,最后将静态标记"混合"为客户端上完全交互的应用程序。
SSR的优势和劣势:
优势
1.更利于首屏渲染
首屏的渲染是node
发送过来的html字符串,并不依赖于js文件,这就会使用户更快的看到页面的内容。
2.时间耗时更少
由于是服务端请求首屏数据,而不是客户端请求首屏数据,这是快的一个主要原因。客户端渲染是等浏览器加载js代码、css、图片等文件,解析完成后再请求数据渲染,等待的时间比较长,用户体验不好。服务端渲染是先向后端服务器请求数据,将数据和 HTML 融合后返回给浏览器,之后结合css显示页面,不需要等待js代码下载完成并请求数据,就可以返回一个已有完整数据的首屏页面。
3.更利于SEO(搜索引擎优化)
SEO:搜索引擎优化,它是指通过各种技术(手段)来确保你的Web内容被搜索引擎最大化被爬取,最大化提高权重,带来更多流量。流量是变现的快车道,SEO是低成本获取流量的最佳方法。目前大部分的搜索引擎仅能抓取URI直接输出的数据资源,对于Ajax类的异步请求的数据无法爬取,Google除外,它有自己的技术支持。
使用MVVM框架之后,页面大多数DOM元素都是在客户端根据js动态生成,可供爬虫抓取分析的内容大大减少,另外浏览器爬虫不会等到我们的数据完成之后再去抓取我们的页面数据。服务端渲染返回给客户端的是已经获取了异步数据并执行js脚本的最终HTML,网络爬虫就可以抓取到完整页面的信息。
劣势
1.服务端压力较大
本来是通过客户端完成渲染,现在统一到服务端node服务去做。尤其是高并发访问的情况,会大量占用服务端CPU资源。
2.开发条件受限
在服务端渲染中,只会执行到componentDidMount之前的生命周期钩子,因此项目引用的第三方的库也不可用其它生命周期钩子,这对引用库的选择产生了很大的限制。
3.学习成本相对较高
除了对webpack、React要熟悉,还需要掌握node、Koa2等相关技术。相对于客户端渲染,项目构建、部署过程更加复杂。
注意:上面提到只有首屏用了服务器端渲染,后面的页面还是异步数据渲染逻辑。
参考文章:https://www.jianshu.com/p/10b6074d772c
注释(3)热刷新和热加载:
热刷新:文件内部改动后,整个页面刷新,不保留任何状态(比如输入过内容的input表单),相当于webpack帮你摁了F5刷新。
热加载:文件内部改动后,以最小的代价改变被改变的区域。尽可能保留改动文件前的状态。
注释(4)自动代码分层:
分层思想是应用系统最常见的一种架构模式,我们会将系统横向切割,根据业务职责划分,比如MVC分成模型层、视图层、控制层。将页面和业务逻辑分离,提高应用的可扩展性以及可维护性。
注释(5)搜索引擎:
注释(6)搜索引擎和SPA、SSR:
搜索引擎的基础爬虫的原理就是抓取你的url,然后获取你的html源代码并解析。而你的页面通常用了vue等js的数据绑定机制来展示页面数据,爬虫获取到的html是你的模型页面而不是最终数据的渲染页面,所以说用js来渲染数据对seo并不友好。https://segmentfault.com/q/1010000009369779
参考文章:https://juejin.im/post/58ff960ba22b9d0065b722cd
https://www.jianshu.com/p/6516f2a3ce36