Vue开发介绍（一）

我们为什么需要Vue

考虑以下代码：

0

当点击按钮时，span标签的内容会+1；当输入颜色的时候，span的颜色会改变。这在组件较少时，我们将状态封装在监听函数中，然后操纵DOM，更新展示，是没有什么问题的。但是随着组件的增多，如果我们还将状态分散在各个函数中，则会导致维护成本的急剧上升，尤其是各个状态之间还相互依赖时，更是一团乱麻。如下图：

这时，我们容易想到将组件中的状态提取出来，专门做一个数据层，用来表示状态（对，这就是MVC的基本思想），那么应用的整体结构就变为如下图所示：

将维护在监听函数中的状态抽取出来，从而实现了Action与View之间的解耦。

如果用jQuery实现的话，我们很容易写出以下代码：

0

虽然我们将数据从函数中提取了出来，但是根据数据来对View进行更新的操作并没有减少，我们还是需要手动进行对于DOM的操作。这里简单说一下Backbone，Backbone实现了对于数据层的监听，成功的将接受Action的监听函数，与View页面的更新函数分离开来。监听函数直接改变表示状态的数据层中的数据，之后监听到数据变化的页面更新函数会被加以调用，用来更新View层，可以说很成功的实现了MVC架构。而Vue、React之类的框架，相比于此的不同点，则在于将View层的更新逻辑进行了封装，从而避免了需要手工写更新函数的步骤，使得只需要对状态数据进行操作，即可在页面上进行更新。
其中，React和Vue1.0的更新过程又有所差异，可以用以下代码简单表示React的更新逻辑：

0

React是一种全量更新的思维，当状态变化时，就调用updateUI()，有枣没枣打三竿子。剩下的就是如何优化updateUI()函数的事情了。来看下一段代码：

2

    
hello
    
world

我们很容易看出，上述的updateUI()，对于需要更新的DOM结构是紧耦合的，而且对于数据的要求也有着很强的限定性，这样就无法实现对View层操作进行自动化的要求了。对此问题，我们首先想到的是利用模板，将不变化的DOM结构部分提取出来，代码如下：

我们只需要使用某种模板解析的类库，将模板的结构进行解析，然后将state的状态填入，就可以动态生成需要更新的DOM结构，从而实现封装View层页面更新函数的DOM操作的目的。但是，这又随之引入另一个问题，那就是当state数据变的庞大的时候，如果仅仅只有一部分数据发生了变化的话，若将state整个更新的话，性能代价是相当大的，而整体更新又是React封装DOM操作的基本前提，那么如何处理这对矛盾呢？于是，React便引入了VirtualDOM来解决这个问题。每次数据变化，不会再操作整个DOM结构的更新，而是先生成VirtualDOM对象，之后，在通过Diff算法，找出实际需要进行DOM更新的部分。事情的发展是有着先后顺序的，而这先后顺序，也反映出了框架构建者处理问题时的思路。React之所以采用VirtualDOM，并不是一开始就计划好的，而是因为自己封装DOM操作的前提假设就是全部更新的逻辑，所以不得已才采用VirtualDOM来作为一层缓冲，如果更新的逻辑一开始就不是全部更新，那么其实是没必要引入VirtualDOM的，比如Vue1.x，其更新的逻辑就是通过创建DocumentFragment来进行局部更新，所以并没有引入VirtualDOM，而是引入了v-bind、v-if、v-for等一些列指令。

最后，我们总结一下，为了解决Action与View之间的强耦合，我们采用了MVC架构，引入了Model层，来表示组件的状态，Action与View之间不直接相互操作，而是通过Model层联系在一起；为了统一封装View层更新函数中的DOM操作，我们采用了不同的思路，React采用全部更新的方法，于是不得不引入VirtualDOM，Vue1.x则采用局部更新的方法，根据不同指令，将不同的DOM的操作封装在了Vue实例的directive对象中。由此，我们可以看出，采用React、Vue开发的关键就在于如何组织数据流的更新，而从数据渲染到页面的过程，框架已经帮我们做了。