[TOC] ----- ## Vue是渐进式框架 Vue.js是一套构建用户界面的 **渐进式框架**。 ![](https://box.kancloud.cn/593319bbbd88ba78969cb93ed7832d8a_550x131.jpg) Vue从设计角度来讲, 虽然能够涵盖这张图上所有的东西,但是你并不需要一上手就把所有东西全用上 ,因为没有必要。无论从学习角度,还是实际情况,这都是可选的。**声明式渲染**和**组件系统**是Vue的核心库所包含内容,而**客户端路由**、**状态管理**、**构建工具**都有专门解决方案。这些解决方案相互独立,你可以在核心的基础上任意选用其他的部件,不一定要全部整合在一起。 ###声明式渲染 现在基本所有的框架都已经认同这个看法——DOM应尽可能是一个函数式到状态的映射。状态即是唯一的真相,而DOM状态只是数据状态的一个映射。如下图所示,所有的逻辑尽可能在状态的层面去进行,当状态改变的时候,View应该是在框架帮助下自动更新到合理的状态,而不是说当你观测到数据变化之后手动选择一个元素,再命令式地去改动它的属性。 ![](https://box.kancloud.cn/0db2c5568d34ec4e8916790862013241_550x332.png) 在Vue2.0中,渲染层的实现做了根本性改动,那就是引入了虚拟DOM。 ![](https://box.kancloud.cn/2365fae987847c0540d2a598b661422d_550x461.png) Vue的编译器在编译模板之后,会把这些模板编译成一个渲染函数 。 而函数被调用的时候就会渲染并且返回一个 **虚拟DOM的树 **。 这个树非常轻量,它的职责就是描述当前界面所应处的状态。当我们 有了这个虚拟的树之后,再交给一个patch函数,负责把这些虚拟DOM真正施加到真实的DOM上 。在这个过程中,Vue有自身的响应式系统来侦测在渲染过程中所依赖到的数据来源。在渲染过程中,侦测到的数据来源之后,之后就可以精确感知数据源的变动。到时候就可以根据需要重新进行渲染。当重新进行渲染之后,会生成一个新的树,将新树与旧树进行对比,就可以最终得出应施加到真实DOM上的改动。最后再通过patch函数施加改动。 这样做的主要原因是, 在浏览器当中,JavaScript的运算在现代的引擎中非常快,但DOM本身是非常缓慢的东西 。当你调用原生DOM API的时候,浏览器需要在JavaScript引擎的语境下去接触原生的DOM的实现,这个过程有相当的性能损耗。所以,本质的考量是,要把耗费时间的操作尽量放在纯粹的计算中去做,保证最后计算出来的需要实际接触真实DOM的操作是最少的。 下面看 **渲染函数** 如下图所示,在Vue2.0当中,可以看到就是说当比如左侧的模板,经过Vue的编译之后就会变成右侧的东西。 ![](https://box.kancloud.cn/f9ae2d9048b38bac0397ee4ec6359a06_550x180.png) 这个函数类似于创建一个虚拟元素的函数,我们可以给它一个名字,给它描述应该有的属性特性和可能其他的数据。然后后面这个最后这个参数是个数组,包含了该虚拟元素的子元素。总的来说2.0的编译器做的就是这个活。 同时,在Vue2.0里,用户可以选择直接跳过模板这一层去手写渲染函数,同时也有可选JSX支持。从开发者的偏好以及开发者的效益的角度来考量,模板和JSX是各有利弊的东西。模板更贴近我们的HTML,可以让我们更直观地思考语义结构,更好地结合CSS的书写。JSX和直接渲染函数,因为是真正的JavaScript,拥有这个语言本身的所有的能力,可以进行复杂的逻辑判断,进行选择性的返回最终要返回的DOM结构,能够实现一些在模板的语法限制下,很难做到的一些事情。 ![](https://box.kancloud.cn/a81707294d285fc384242c61f1eb4f27_550x280.png) 所以在Vue2.0里,两个都是可以选择的。在绝大部分情况下使用模板,但是在需要复杂逻辑的情况下,使用渲染函数。 在Vue2.0的路由和内部的一些实践上,都大量地应用渲染函数做复杂的抽象组件 ,比如过渡动画组件以及路由里面的link组件,都是用渲染函数实现的,同时还保留了它本身的依赖追踪系统。 如下图所示,Vue的依赖追踪通过ES5的 Object.defineProperty 方法实现。比如,我们给它一个原生对象,Vue会遍历这个数据对象的属性,然后进行属性转换。每一个属性会被转换为一个 getter 和一个 setter。同时每个组件会有一个对应的 watcher 对象,这个对象的职责就是在当前组件被渲染的时候,记录数据上面的哪些属性被用到了。 例如,在渲染函数里面用到A.B的时候,这个就会触发对应的 getter。整个渲染流程具体要点如下: - 当某个数据属性被用到时,触发 getter,这个属性就会被作为依赖被 watcher 记录下来。 - 整个函数被渲染完的时候,每一个被用到的数据属性都会被记录。 - 相应的数据变动时,例如给它一个新的值,就会触发 setter,通知数据对象对应数据有变化。 - 此时会通知对应的组件,其数据依赖有所改动,需要重新渲染。 - 对应的组件再次调动渲染函数,生成 Virtual DOM,实现 DOM 更新。 如下图所示,在Vue里面由于依赖追踪系统的存在,当任意数据变动的时,Vue的每一个组件都精确地知道自己是否需要重绘,所以并不需要手动优化。用Vue渲染这些组件的时候,数据变了,对应的组件基本上去除了手动优化的必要性。 ![](https://box.kancloud.cn/ac3f3266e2defd64bc06f7cffe22ca4c_550x413.png) ### 组件系统 相信基本上所有的现代框架都已经走向了组件化道路,Web Components 从规范层面做这个实践。主流框架都有各有不同的封装,但 核心思想都是一样,把UI结构映射到恰当的组件树 ,如下图所示。 ![](https://box.kancloud.cn/231be042ac8bc2b218aca49a47777345_550x257.png) 在Vue中,父子组件之间的通信是通过 props 传递。从父向子单向传递;而如果子组件想要在父组件作用里面产生副作用,就需要去派发事件。这样就形成一个基本的父子通信模式,在涉及大规模状态管理的时候会有额外的方案,这个后面会提到。 ![](https://box.kancloud.cn/388063c43adb69814e09d3228f28b8bc_550x413.png) Vue的组件引入构建工具之后有一个 单文件组件概念 ,如下图所示,就是这个Vue文件。在同一个Vue文件里,可以同时写 template, script 和 style,三个东西放在一个里面。同时,Vue的单文件组件和 Web Components 有一个本质不同,它是基于构建工具实现。这样的好处是有了一个构建的机会,可以对这些单文件组件做更多的分析处,在每一个语言块里可以单独使用不同的处理器,这点后面还会讲到。 ![](https://box.kancloud.cn/261c0947292898a52a0096a2df905038_550x413.png) ### 客户端路由 在做一个界面复杂度非常的高应用时,它会有很多的状态,这样的应用显然不可能在每做一次操作后都刷新一个页面作为用户反馈。这就要这个应用有多个复杂的状态,同时这些状态还要对应到URL。有一个重要的功能叫做 deep-linking,也就是当用户浏览到一个URL,然后把它传给另外的人或者复制重新打开,应用需要直接渲染出这个URL对应的状态。这就意味着应用的URL和组件树的状态之间有一个映射关系,客户端路由的职责就是让这个映射关系声明式地对应起来。 ![](https://box.kancloud.cn/b725d7dbfd442e705cd595833d216b6b_550x325.png) 若要自己实现一个这样的路由,看上去倒是很简单,用hash去模拟一下,就可以自己很快地做出很简单的路由。但事实上,客户端路由涉及很多更复杂的问题,如下图所示。 ![](https://box.kancloud.cn/d96ff8d0ffe940243c4a7c0f087c4566_550x242.png) 可能同一层的路由有多个不同的出口,还有着复杂的URL匹配规则,等等。这些问题如果都由自己去一一实现,那么复杂度是非常高的。而Vue基本都有对应的解决方案(router.vuejs.org)。配合Webpack还可以实现基于路由的懒加载,一条路径所对应的组件在打包的时候,会分离成另外一块,只有当该路由被访问的时候,才会被加载出来。这有相应的解决方案,同时也有实例。 ### 状态管理 说到状态管理,本质上就是把整个应用抽象为下图中的循环。脸书最早提出 Flux 这个概念的时,也是一个很松散的概念,而且官方的实现本身做得很难用。所以,社区就做了各种各样的探索。图中的这三个东西是一个单向数据流,State 驱动 View 的渲染,而用户对 View 进行操作产生 Action,会使State产生变化,从而导致 View 重新渲染。 ![](https://box.kancloud.cn/99689404eacea99ec01a1cf828d81e21_550x375.png) 一个单独的Vue的组件,其实就已经是这样的结构。但是当多个这样的组件来配套的时候,就会遇到一个问题。每个组件都有它自己的状态,但整个应用的状态,跟组件之间并不一定存在一一对应的关系。这个状态可能是一个全局状态。那么状态到底放在哪里?大部分解决方案是把这个状态从组件树中提取出来,放在一个全局的 Store 里面。Vuex 也是这样做的,但是它是针对 Vue 做了特化。我们看到最左边就是Vue的组件,这些组件在大部分情况下,就不再有私有的状态,而是从全局的 Store 里面获取状态。Actions 和 Mutations 比较难用一两句话说清楚,大致就是当应用状态进行改变的时候,需要通过 Mutations 去显式地触发,而 Actions 则是负责异步和其他副作用。由于 Mutations 会被记录下来,我们可以把这些记录发到工具里面去做分析,甚至进行回滚。当发现bug的时候,这使得我们可以更好地理解大型应用中的状态变化。更多的细节,还请看官方文档(vuex.vuejs.org)。 ![](https://box.kancloud.cn/6e8858819226340a00d666a2bf8d8994_550x413.png) ### 构建工具 构建工具方面,Vue有一个官方的,全局安装的 vue-cli。这里有一个笔误。全局安装之后,我们就可以用 vue 命令创建一个新的项目,Vue 的 CLI 跟其他 CLI 不同之处在于,有多个可选模板,有简单的也有复杂的。极简的配置,更快的安装,可以更快的上手。它也有一个更完整的模板,包括单元测试在内的各种内容都涵盖,但是,它的复杂度也更高,这又涉及到根据用例来选择恰当复杂度的问题。所有的模板在创建之后,构建脚本都是通过 npm 脚本来执行,在国内安装 npm 依赖的时候有点卡,可以用 yarn 或者推荐用淘宝的 npm 镜象源,可以很大地提升安装速度。 ![](https://box.kancloud.cn/6a0fbd975c48a0fd562767b6a0565b36_550x353.png) 之前提到了单文件组件,如下图所示,支持任意的处理器,开箱即用的热重载,所以组件都支持热重载 (hot-reload)。当你做了修改,不会刷新页面,只是对组件本身进行立刻重载,不会影响整个应用当前的状态。CSS也支持热重载。我们看下左下角,在使用这个预处理器的同时,我们只需要添加一个 scoped 特性,Vue 会通过对模板和CSS代码的解析改写,来模拟CSS的效果。同时单文件组件也支持懒加载,一个懒加载的组件和它的依赖会被打包成一个额外的包,只有被用到的时候才加载,这对首屏的加载速度也是很有帮助的。 ![](https://box.kancloud.cn/529c5e3e7badf82c70632882ebde9b02_550x413.png) 如下图所示,这个开发者工具本身也是用Vue写的。 ![](https://box.kancloud.cn/30de9428eacef65408e0771821efb2d4_550x413.png) 使用它的话可以看到我们当前应用的组件树结构。 ![](https://box.kancloud.cn/41b4efbd4f5cf0dbb94692fc51f9264d_550x413.png) 点击组件,就可以观察这个组件当前的状态。也可以把这个组件发送到控制台里。同时这个开发者工具还有一个 Vuex 面板,如果你用了 Vuex,那么每次操作都会被记录下来,记录下来的状态之间可以进行跳转。除此之外,还支持把当前应用的状态快照发送给另外一个人,这个人可以在他的控制台里导入你发送的状态,就可以立刻跳转到你之前所在的状态。这对于重现一些 bug,或要描述当前状态都很有帮助。 ![](https://box.kancloud.cn/e6c281dd8f3d8bc756ac2f357c69d681_550x413.png) ### 总结 我们可能在任何情况下都需要 **声明式的渲染功能** ,并希望尽可能避免手动操作,或者说是可变的 **命令式操作** ,希望尽可能地让DOM的更新操作是自动的,状态变化的时候它就应该自动更新到正确的状态;我们需要 **组件系统** ,将一个大型的界面切分成一个一个更小的可控单元; **客户端路由**——这是针对单页应用而言,不做就不需要,如果需要做单页应用,那么就需要有一个URL对应到一个应用的状态,就需要有路由解决方案; **大规模的状态管理** ——当应用简单的时候,可能一个很基础的状态和界面映射可以解决问题,但是当应用变得很大,涉及多人协作的时候,就会涉及多个组件之间的共享、多个组件需要去改动同一份状态,以及如何使得这样大规模应用依然能够高效运行,这就涉及大规模状态管理的问题,当然也涉及到可维护性,还有 **构建工具**。现在,如果放眼前端的未来,当HTTP2普及后,可能会带来构建工具的一次革命。但就目前而言,尤其是在中国的网络环境下,打包和工程构建依然是非常重要且不可避免的一个环节。