t4模板VUE_t4灯管更换「t4灯管怎么更换」

　　“

　　框架是什么？为什么要有框架？在浩繁的框架之中，Vue独具魅力之处在那边呢？其背后的核心头脑是什么？Vue毕竟火到什么程度？近来发布的Vue2.0又做了哪些改进呢？Vue和Weex又是怎样的一种相助？

　　本文根据尤雨溪在2016QCon环球软件开辟大会（上海）上的讲演整理而成。

　　Tips：本日文章头图来自于两位迷妹的对峙，有颜有才，如许的程序员请再来一打！

　　作者简介

　　尤雨溪，VueTechnologyLLC首创人，Vue.js作者，计划师，开辟者，开源爱好者，前端框架Vue.js的作者。

　　曾就职于GoogleCreativeLab，参加多个实行项目标界面原型研发，后参加Meteor，参加Meteor框架本身的维护和MeteorGalaxy平台的交互计划与前端开辟。现全职投入Vue.js的开辟与维护，发愤将Vue.js打造成与Angular/React不相上下的天下顶级框架。

为什么要有框架

　　1、框架的存在是为了资助我们应对复杂度

　　前端框架特别多，那么为什么要有框架呢？我个人的见解是，框架的存在是为了资助我们应对复杂度。当我们必要办理一些前端上工程题目的时间，这些题目会有差别的复杂度。

　　假如你用太大略的工具应对非常复杂的需求，就会极大地影响你的生产力。以是，框架本身是帮我们把一些重复的而且已担当过验证的模式，抽象到一个已经帮你计划好的API封装当中，资助我们去应对这些复杂的题目。

　　2、框架自身也有复杂度

　　但是，框架本身也会带来复杂度。信托各人在调研各种框架或学习各种框架时，会碰到学习曲线题目——有些框架会让人一时不知怎样上手。这里就抽象出一个题目，就是要做的应用的复杂度与所利用的框架的复杂度的对比。进一步说，是所要办理的题目的内涵复杂度，与所利用的工具的复杂度举行对比。

　　3、工具复杂度是为了处理惩罚内涵复杂度所做的投资

　　工具的复杂度是可以明白为是我们为了处理惩罚题目内涵复杂度所做的投资。为什么叫投资？那是由于假如投的太少，就起不到规模的效应，不会有公道的回报。这就像创业公司拿风投，投多少是很紧张的题目。假如要办理的题目本身黑白常复杂的，那么你用一个过于大略的工具应付它，就会碰到工具太弱而使得生产力受影响的题目。

　　反之，是假如所要办理的题目并不复杂，但你却用了很复杂的框架，那么就相称于杀鸡用牛刀，会碰到工具复杂度所带来的副作用，不但会失去工具本身所带来上风，还会增长各种题目，比方培训本钱、上手本钱，以及实际开辟服从等。

　　4、Picktherighttoolforthejob

　　“Picktherighttoolforthejob”——在国外，跟开辟者讨论一些框架选型题目时，各人都会说这句话——统统都要看场景。由于，前端开辟原生开辟大概桌面开辟模式相比，有本身的独特之处，它跟着实并不那么固定。在Web上面，应用可以有非常多的形态，差别形态的Web应用大概有完全差别程度的复杂度。这也是为什么我要谈工具复杂度和所要做的应用复杂度的题目。

　　5、怎么看前端框架的复杂度

　　如今的前端开辟已经越来越工程化，而我们必要办理的实际题目也是差别的。如下图所示，我们大概在任何环境下都必要声明式的渲染功能，并盼望尽大概克制手动操纵，大概说是可变的下令式操纵，盼望尽大概地让DOM的更新操纵是主动的，状态变革的时间它就应该主动更新到精确的状态；

　　我们必要组件体系，将一个大型的界面切分成一个一个更小的可控单位；客户端路由——这是针对单页应用而言，不做就不必要，假如必要做单页应用，那么就必要有一个URL对应到一个应用的状态，就必要有路由办理方案；

　　大规模的状态管理——当应用简单的时间，大概一个很底子的状态和界面映射可以办理题目，但是当应用变得很大，涉及多人协作的时间，就会涉及多个组件之间的共享、多个组件必要去改动同一份状态，以及怎样使得如许大规模应用依然可以或许高效运行，这就涉及大规模状态管理的题目，固然也涉及到可维护性，尚有构建工具。

　　如今，假如放面前端的将来，当HTTP2遍及后，大概会带来构建工具的一次革命。但就如今而言，尤其是在中国的网络环境下，打包和工程构建依然黑白常紧张且不可克制的一个环节。

主流框架分析

　　我们看一下现有的一些主流框架从少到多所办理的题目。这个多少并不是来评价框架的优劣，而是从计划的角度出发看它涵盖多少内容。

纯模板引擎：最少的就是纯模板引擎，只管状态到界面的映射。

React和Vue：着实这两者都黑白常专注的只做状态到界面映射，以及组件。

Backbone：它会给你多一些架构上引导，比如它会让你分层。

Angular：它做的事变就更多，它有本身的路由，这些都会包罗在内里。

Ember：相比Angular，Ember做得就更加彻底，Ember信奉的是约定优于设置，它会将统统都帮你计划好打包好，你就开箱用就可以了。

Meteor：Meteor只是一个极度，它是从前到后全都包罗，从前端到数据层到数据库，全都帮你打包好。

　　通过简单的分析，我们可以感受到，做得少的框架不肯定就不如做得多的框架，这表现出一种弃取。也就是说，做得少的框架可以给你更多的机动性，但你必要做更多的选择；做得多的框架有更强的侵入性，学习本钱更高，机动性更低。一旦选择了一个侵入性强的框架，那么一些小的部分你就没有机遇去切换成其他你更想用的方案。

　　以是，React和Vue有一个共同特点，它们都有各自的配套工具，核心固然只办理一个很小的题目，但它们有生态圈及配套的可选工具，当你把他们一个一个加进来的时间，就可以组合成非常强大的栈，就可以涵盖其他的这些更完备的框架所涵盖的题目。

　　如许的一个设置方案，使得在你构建技能栈的时间有可弹性伸缩的工具复杂度：当所要办理的题目内涵复杂度很低的时间，可以只用核心的这些很简单的功能；当必要做一个更复杂的应用时，再增加相应的工具。

　　比方做一个单页应用的时间才必要用路由；做一个相称巨大的应用，涉及到多组件状态共享以及多个开辟者共同协作时，才大概必要大规模状态管理方案。

　　一个纯粹的复杂的单页应用，和只是在后端渲染的静态页面上嵌入交互内容所必要选择的工程栈着实是有相称大区别的。这就是为什么我以为，核心+生态的栈会是一个在团体选型更为机动的栈。

　　React和Vue都选择这个模式。Facebook团队只是专注做React本身，但React社区非常活泼，贡献了大量的第三方办理方案。不可否认，React社区是当前最活泼的社区，很多良好的想法和思绪，包罗状态管理方案最早都是从React社区萌发出来。但是社区的这种活泼也带来肯定程度的副作用，那就是期间变革太快，三天出一个新版本，同一个题目曾经存在几十种差别的办理方案。

　　这就使得我们在去搭建本身的栈时，必要花很多的时间去辨别所选择的部件。同时，由于整个生态圈的这些库并不是由一个同一的团队去规划和计划的，以是很难思量到差别的库之间的协作，这就会导致磨合题目。

　　同时，这也使得很多开辟者抱怨有一个“JavaFatigue”，说JS生态圈东西太多了，为了跟上潮流，必要不绝学习最新的东西，以为很累。固然，有很多人以为这是生态圈繁荣的表现，但它确实使得各人面对了选择困难症的题目。

　　DanAbramov是之前React社区非常活泼的开辟者，已经参加了React团队。有一天他在推特上说，非常的模块化使得他非常难去构建一个同一的体验。这句话指的就是，React生态圈整个栈的每一个部分来自差别开辟者，想全部整合到一起的时就有很多琐屑的题目。

　　这是他刚开始做React如今的官方的CLI的时间发出的感慨，他在试图整合社区的各种东西放到一个架子内里，于是碰到了很多如许的题目。我这里完全没有否认React生态圈繁荣的意思，我只是以为可以有别的一种选择，那就是我们可以做一个渐进式框架，这就是Vue选择的方向。

渐进式框架Vue.js

　　1、Vue.js近况

　　以下数据可以表现出Vue.js的近况。

前一段时间突破了三万星，总下载量过百万。

官网上每个月的用户量为26万，这个应该是不包罗中国区数据。官方开辟者插件的周活泼用户数在5万5左右。这个数据是我以为最有说服力的数据。安装而且利用开辟者插件的Vue用户，应该会在实际生产中真正频仍利用Vue。

　　Google搜刮趋势的相干数据如下图所示。图中，绿色的是Backbone的数据，黄色是Ember，赤色是React，蓝色是Vue。可以看出React和Vue近两年发展势头都比力迅猛。

　　可以看出，Vue的曲线开始的是很早，2013年已经开始，但是有很长一段时间的增长是比力低的。由于在那一段时间我还在谷歌工作，Vue根本上是作为个人项目在运营。在已往一两年中，Vue得到了非常大的突破性发展。这个图里没有Angular，由于Angular的量还是非常大的，假如放进去就破表了。

　　这些数据并不能绝对地代表框架当前的热度，但有肯定的参考代价。可以看到React的势头很足。而由Vue的曲线还可以看出它的增长速率还在不绝上扬。

　　2、Vue的定位

　　我在做Vue的过程中也在不绝地思考它的定位，如今，我以为它与其他框架的区别就是渐进式的想法，也就是“Progressive”——这个词在英文中界说是渐进，一步一步，不是说你必须一竿子把全部的东西都用上。

　　3、Vue的计划

　　接下来我们回到之前看的图：

　　Vue从计划角度来讲，固然可以或许涵盖这张图上全部的东西，但是你并不必要一上手就把全部东西全用上，由于没有须要。无论从学习角度，还是实际环境，这都是可选的。声明式渲染和组建体系是Vue的核心库所包罗内容，而客户端路由、状态管理、构建工具都有专门办理方案。这些办理方案相互独立，你可以在核心的底子上恣意选用其他的部件，不肯定要全部整合在一起。

　　4、Vue的实现

　　接下来深入讲一讲这些具体的概念以及Vue在这些概念上具体是做怎样的实现。

　　（1）声明式渲染

　　如今根本全部的框架都已经认同这个见解——DOM应尽大概是一个函数式到状态的映射。状态便是唯一的原形，而DOM状态只是数据状态的一个映射。全部的逻辑尽大概在状态的层面去举行，当状态改变的时间，View应该是在框架资助下主动更新到公道的状态，而不是说当你观测到数据变革之后手动选择一个元素，再下令式地去改动它的属性。

　　下图是Vue的一个模板示例，假如没有效过Vue的话，可以大概感觉到这是一个怎样的概念。

　　着实，在模板语法上，Vue跟Angular是比力相似。在Vue1.0内里，模板实现跟Angular雷同，如下图所示，把模板直接做成在欣赏器内里parse成DOM树，然后去遍历这个树，提取此中的各种绑定。

　　在Vue2.0中，渲染层的实现做了根天性改动，那就是引入了假造DOM。

　　从架构来讲，Vue2.0依然是写一样的模板（Vue2.0于前段时间发布，具体报道拜见

　　https://t.cn/RVC0foZ）。在最左边，Vue2.0跟1.0的模板语法绝大部分是兼容的。Vue的编译器在编译模板之后，会把这些模板编译成一个渲染函数。而函数被调用的时间就会渲染而且返回一个假造DOM的树。这个树非常轻量，它的职责就是形貌当前界面所应处的状态。当我们有了这个假造的树之后，再交给一个patch函数，负责把这些假造DOM真正施加到真实的DOM上。

　　在这个过程中，Vue有自身的相应式体系来侦测在渲染过程中所依靠到的数据泉源。在渲染过程中，侦测到的数据泉源之后，之后就可以正确感知数据源的变动。到时间就可以根据必要重新举行渲染。当重新举行渲染之后，会天生一个新的树，将新树与旧树举行对比，就可以终极得出应施加到真实DOM上的改动。末了再通过patch函数施加改动。

　　如许做的重要缘故起因是，在欣赏器当中，Java的运算在当代的引擎中非常快，但DOM本身黑白常迟钝的东西。当你调用原生DOMAPI的时间，欣赏器必要在Java引擎的语境下去打仗原生的DOM的实现，这个过程有相称的性能斲丧。以是，本质的考量是，要把淹灭时间的操纵只管放在纯粹的盘算中去做，包管末了盘算出来的必要实际打仗真实DOM的操纵是最少的。

　　下面看渲染函数。用过React的开辟者大概知道，React是没有模板的，直接就是一个渲染函数，它中心返回的就是一个假造DOM树。JSX实际就是一套用于让我们更简单地去形貌树状布局的语法糖。

　　如下图所示，在Vue2.0当中，可以看到就是说当比如左侧的模板，颠末Vue的编译之后就会变成右侧的东西。

　　这个函数雷同于创建一个假造元素的函数，我们可以给它一个名字，给它形貌应该有的属性特性和大概其他的数据。然后背面这个末了这个参数是个数组，包罗了该假造元素的子元素。总的来说2.0的编译器做的就是这个活。

　　同时，在Vue2.0里，用户可以选择直接跳过模板这一层去手写渲染函数，同时也有可选JSX支持。从开辟者的偏好以及开辟者的效益的角度来考量，模板和JSX是各有利弊的东西。模板更贴近我们的HTML，可以让我们更直观地思考语义布局，更好地连合CSS的誊写。

　　JSX和直接渲染函数，由于是真正的Java，拥有这个语言本身的全部的本领，可以举行复杂的逻辑判定，举行选择性的返回终极要返回的DOM布局，可以或许实现一些在模板的语法限定下，很难做到的一些事变。

　　以是在Vue2.0里，两个都是可以选择的。在绝大部分环境下利用模板，但是在必要复杂逻辑的环境下，利用渲染函数。在Vue2.0的路由和内部的一些实践上，都大量地应用渲染函数做复杂的抽象组件，比如过渡动画组件以及路由内里的link组件，都是用渲染函数实现的，同时还保存了它本身的依靠追踪体系。

　　如下图所示，Vue的依靠追踪通过ES5的Object.defineProperty方法实现。比如，我们给它一个原生对象，Vue会遍历这个数据对象的属性，然后举行属性转换。每一个属性会被转换为一个getter和一个setter。同时每个组件会有一个对应的watcher对象，这个对象的职责就是在当前组件被渲染的时间，记录数据上面的哪些属性被用到了。

　　比方，在渲染函数内里用到A.B的时间，这个就会触发对应的getter。整个渲染流程具体要点如下：

当某个数据属性被用到时，触发getter，这个属性就会被作为依靠被watcher记录下来。

整个函数被渲染完的时间，每一个被用到的数据属性都会被记录。

相应的数据变动时，比方给它一个新的值，就会触发setter，关照数据对象对应数据有变革。

此时会关照对应的组件，其数据依靠有所改动，必要重新渲染。

对应的组件再次变更渲染函数，天生VirtualDOM，实现DOM更新。

　　如许一个流程跟主流的一些框架，比方React是有较大区别的。在React中，当组件复杂的时间必要用shouldComponentUpdate做优化。但是，它也有本身的各种坑，比如要确保该组件下面的组件不依靠外部的状态。虽说这在大部分环境下是够用的，但碰到极大复杂度的应用，碰到性能瓶颈的时间，这个流程优化起来也是相称复杂的一个话题。

　　如下图所示，在Vue内里由于依靠追踪体系的存在，当恣意数据变动的时，Vue的每一个组件都正确地知道本身是否必要重绘，以是并不必要手动优化。用Vue渲染这些组件的时间，数据变了，对应的组件根本上去除了手动优化的须要性。

　　（2）组件体系

　　信托根本上全部的当代框架都已经走向了组件化蹊径，WebComponents从规范层面做这个实践。主流框架都有各有差别的封装，但核心头脑都是一样，把UI布局映射到得当的组件树。

　　在Vue中，父子组件之间的通讯是通过props转达。从父向子单向转达；而假如子组件想要在父组件作用内里产生副作用，就必要去派发变乱。如许就形成一个根本的父子通讯模式，在涉及大规模状态管理的时间会有额外的方案，这个背面会提到。

　　Vue的组件引入构建工具之后有一个单文件组件概念，如下图所示，就是这个Vue文件。在同一个Vue文件里，可以同时写template、和style，三个东西放在一个内里。

　　同时，Vue的单文件组件和WebComponents有一个本质差别，它是基于构建工具实现。如许的长处是有了一个构建的机遇，可以对这些单文件组件做更多的分析处，在每一个语言块里可以单独利用差别的处理惩罚器，这点背面还会讲到。

　　（3）客户端路由

　　在做一个界面复杂度非常的高应用时，它会有很多的状态，如许的应用显然不大概在每做一次操纵后都革新一个页面作为用户反馈。这就要这个应用有多个复杂的状态，同时这些状态还要对应到URL。

　　有一个紧张的功能叫做deep-linking，也就是当用户欣赏到一个URL，然后把它传给别的的人大概复制重新打开，应用必要直接渲染出这个URL对应的状态。这就意味着应用的URL和组件树的状态之间有一个映射关系，客户端路由的职责就是让这个映射关系声明式地对应起来。

　　若要本身实现一个如许的路由，看上去倒是很简单，用hash去模仿一下，就可以本身很快地做出很简单的路由。但究竟上，客户端路由涉及很多更复杂的题目，如下图所示。

　　大概同一层的路由有多个差别的出口，尚有着复杂的URL匹配规则，等等。这些题目假如都由本身去逐一实现，那么复杂度黑白常高的。而Vue根本都有对应的办理方案（router.vuejs.org）。共同Webpack还可以实现基于路由的懒加载，一条路径所对应的组件在打包的时间，会分离成别的一块，只有当该路由被访问的时间，才会被加载出来。这有相应的办理方案，同时也有实例。

　　（4）状态管理

　　说到状态管理，本质上就是把整个应用抽象为下图中的循环。脸书最早提出Flux这个概念的时，也是一个很疏松的概念，而且官方的实现本身做得很难用。以是，社区就做了各种各样的探索。图中的这三个东西是一个单向数据流，State驱动View的渲染，而用户对View举行操纵产生Action，会使State产生变革，从而导致View重新渲染。

　　一个单独的Vue的组件，着实就已经是如许的布局。但是当多个如许的组件来配套的时间，就会碰到一个题目。每个组件都有它本身的状态，但整个应用的状态，跟组件之间并不肯定存在逐一对应的关系。这个状态大概是一个全局状态。那么状态到底放在那边？大部分办理方案是把这个状态从组件树中提取出来，放在一个全局的Store内里。Vuex也是如许做的，但是它是针对Vue做了特化。

　　我们看到最左边就是Vue的组件，这些组件在大部分环境下，就不再有私有的状态，而是从全局的Store内里获取状态。Actions和Mutations比力难用一两句话说清楚，大抵就是当应用状态举行改变的时间，必要通过Mutations去显式地触发，而Actions则是负责异步和其他副作用。

　　由于Mutations会被记录下来，我们可以把这些记录发到工具内里去做分析，乃至举行回滚。当发现bug的时间，这使得我们可以更好地明白大型应用中的状态变革。更多的细节，还请看官方文档（vuex.vuejs.org）。

　　（5）构建工具

　　构建工具方面，Vue有一个官方的，全局安装的vue-cli。这里有一个笔误。全局安装之后，我们就可以用vue下令创建一个新的项目，Vue的CLI跟其他CLI差别之处在于，有多个可选模板，有简单的也有复杂的。极简的设置，更快的安装，可以更快的上手。

　　它也有一个更完备的模板，包罗单位测试在内的各种内容都涵盖，但是，它的复杂度也更高，这又涉及到根据用例来选择得当复杂度的题目。全部的模板在创建之后，构建脚本都是通过npm脚原来实行，在国内安装npm依靠的时间有点卡，可以用yarn大概保举用淘宝的npm镜象源，可以很大地提拔安装速率。

　　之条件到了单文件组件，如下图所示，支持恣意的处理惩罚器，开箱即用的热重载，以是组件都支持热重载(hot-reload)。当你做了修改，不会革新页面，只是对组件本身举行立即重载，不会影响整个应用当前的状态。CSS也支持热重载。

　　我们看下左下角，在利用这个预处理惩罚器的同时，我们只必要添加一个scoped特性，Vue会通过对模板和CSS代码的分析改写，来模仿CSS的结果。同时单文件组件也支持懒加载，一个懒加载的组件和它的依靠会被打包成一个额外的包，只有被用到的时间才加载，这对首屏的加载速率也是很有资助的。

　　如下图所示，这个开辟者工具本身也是用Vue写的。

　　利用它的话可以看到我们当前应用的组件树布局。

　　点击组件，就可以观察这个组件当前的状态。也可以把这个组件发送到控制台里。同时这个开辟者工具尚有一个Vuex面板，假如你用了Vuex，那么每次操纵都会被记录下来，记录下来的状态之间可以举行跳转。

　　除此之外，还支持把当前应用的状态快照发送给别的一个人，这个人可以在他的控制台里导入你发送的状态，就可以立即跳转到你之前地点的状态。这对于重现一些bug，或要形貌当前状态都很有资助。

Vue2.0

　　Vue2.0在不久之前刚刚发布（具体报道拜见https://t.cn/RVC0foZ），之前一些技能细节在前文中已有所涉及。Vue2.0相对于1.0的改进有以下几点。

　　1、更轻

　　对Vue1.0巨细压缩，Vue2.0它有一个只包罗运行时的版本，全部的模板在编译的时间已经完成了。基于这个版本，下图中Vue、vue-router和vuex三个（都是2.0版本）加一起，跟Vue1.0的核心库巨细一样。

　　2、更快

　　Vue2.0可以说是当前最快的框架之一。这个是基于第三方独立测试的结果。有爱好的话，可以移步链接（https://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html）举行查察。

　　这个测试是一个比力综合的测试，它对于各种操纵，以及在大列表内里更新移除等，都有相称完备的覆盖。可以看出，Vue2.0，不但仅是在Vue1.0的底子上有很大提拔，相比其他框架，也有相称显着的性能上风。

　　3、Vue2.0架构

　　下图是Vue2.0的架构图，这里不深入讲整个架构的实现。

　　Vue2.0同时支持服务端，服务端渲染支持流式渲染。由于HTTP哀求也是流式，Vue的服务端渲染结果可以直接pipe到返回的哀求内里。如许一来，就可以更早地在欣赏器中出现给用户内容，通过公道的缓存战略，可以有效地提拔服务端渲染的性能。

　　下图是Vue2.0以及服务端渲染的相干内容，根本上把全部的功能都整合在了一起，有爱好的同砚可以在这里搜刮2.0，它可以作为参考应用。

　　除了服务端渲染尚有原生渲染，这里的原生渲染是指阿里巴巴的项目Weex。在架构层面，通过编译一个Weex源文件（雷同于Vue单文件组建的格式）然后运行。界面节点的操纵都是抽象的，这些抽象操纵会派发到差别的目标引擎做实际的渲染，同时支持iOS,Android和Web。

　　Vue和Weex如今有一个相助，Vue2.0将会正式成为Weex的Java运行时。如许的相助可以使得符合功能交集的Vue组件可以跨平台利用。

本日荐号：前端之巅

　　这里有深度及时的前端资讯，一线履历免费的分享活动，纯净的前端技能微信群，只待你参加，一起攀缘前端之巅！

本日荐文

点击下方图片即可阅读

微信PaxosStore内存云揭秘：十亿Paxos/分钟的挑衅

喜好我们的会点赞，爱我们的会分享！