单向数据绑定和双向数据绑定的优缺点,适合什么场景?

经常看见在vue或者angular的介绍里说自己的特色是双向数据绑定,而在看react的介绍中,说自己的优势和特色是单向数据绑定。 这两个截然不同的机制,为什么又都能自圆其说呢?在同一个时代里怎么建立统一的理解?还是说两种机制有各自适合的最佳场景?
关注者
286
被浏览
14068

6 个回答

对于非UI控件来说,不存在双向,只有单向。只有UI控件才有双向的问题。


单向绑定使得数据流也是单向的,对于复杂应用来说这是实施统一的状态管理(如redux)的前提。

双向绑定在一些需要实时反应用户输入的场合会非常方便(比如多级联动菜单)。但通常认为复杂应用中这种便利比不上引入状态管理带来的优势。

注意,Vue 虽然通过 v-model 支持双向绑定,但是如果引入了类似redux的vuex,就无法同时使用 v-model。参见 github.com/vuejs/vuex/b
先描述一下 ng 跟 vue 中使用双向绑定的场景。

如贺老 @贺师俊 所言,只有 UI控件 才存在双向,非 UI控件 只有单向。
但是就 angular1.x 和 vue1.x 而言,贺老漏掉了一个场景,就是在给自定义组件传递数据的时候,也有双向绑定的情况。在 ng 跟 vue 中分别是这样的:
// angular1.5+
<component counter="parentCounter"></component>

angular.module('xx', [])
  .component('component', {
    bindings: { counter: '=' },
    template: '<button ng-click="counter = counter + 1">{{counter}}</button>'
  })

// vue1.x
<component :counter.sync="parentCounter"></component>

Vue.component('component', {
  props: ['counter'],
  template: '<button @click="counter = counter + 1">{{counter}}</button>'
})
当 component 组件里的 button 被点击时,counter 的变化会同步给 parentCounter 导致父 scope 的数据被改变。(ps:angular1.5 之后组件语法加入了 '<' 用于单向绑定,vue2 则直接移除了 .sync 语法)

另外一个就是 UI控件 的场景,对应 ng 里的 ng-model 跟 vue 里的 v-model。

自定义组件的双向绑定其实是框架在 compile 时识别到相应的语法,然后给相应的 watcher 添加一个 sync flag 及 父级数据索引,好在下次 digest 时同步更新对应父级数据。
UI控件 里的实现就更简单了,其实就是 one-way binding + auto event binding 的语法糖。比如我们可以用单向绑定实现 ng-model 和 v-model 的同等功能:
// ng-model (ps: ng-input 并不是 ng 内置指令,假设它是一个监听 input 事件的指令)
<input type="text" ng-value="msg" ng-input="msg = $event.target.value">


// v-model
<input type="text" v-bind:value="msg" v-on:input="msg = $event.target.value">

搞清楚双向绑定的实现原理之后,可以看到双绑跟单向绑定之间的差异只在于,双向绑定把数据变更的操作隐藏在框架内部,调用者并不会直接感知。

单向绑定相应地使得数据流也是单向的,而在践行单向数据流的 flux 系的实现中,其实不过是在全局搞了一个单例的事件分发器 (dispatcher),开发者必须显式地通过这个统一的事件机制做数据变更通知。其实这种方式跟框架对 UI控件 上实现双向绑定的方式是一样的。底层都是事件机制。
试想一下,假设在双向绑定的应用中,我们有办法 hack 进框架对 UI控件 自动绑定的事件 listener 或 数据 watcher,然后加上类似 dispatcher 的逻辑,双向绑定背后的状态变化我们一样可以管理起来,一样可以享用单向数据流才有的收益。对应的,在 react 里同样可以实现双向绑定,比如官方的 LinkedStateMixin,只不过它从出生至今就是 deprecated 的。

再来看 flux 的这张图
如果我们做进一步封装,把 action 跟 dispatcher 都隐藏在框架内部,最后图就变成这样了
如果再进一步,把相互手动通知的机制再隐藏起来,变成这样了
这个不就是 mvvm 里面的双向绑定么(手动尴尬)。。。

所以在我看来,双向和单向只不过是框架封装程度上的差异,本质上两者是可以相互转换的。

回到问题上,单向数据绑定和双向数据绑定的优缺点,适合什么场景?

答:
单向绑定的优点是相应的可以带来单向数据流,这样做的好处是所有状态变化都可以被记录、跟踪,状态变化通过手动调用通知,源头易追溯,没有“暗箱操作”。同时组件数据只有唯一的入口和出口,使得程序更直观更容易理解,有利于应用的可维护性。缺点则是代码量会相应的上升,数据的流转过程变长,从而出现很多类似的样板代码。同时由于对应用状态独立管理的严格要求(单一的全局store),在处理局部状态较多的场景时(如用户输入交互较多的“富表单型”应用),会显得啰嗦及繁琐。
基本上双向绑定的优缺点就是单向绑定的镜像了。优点是在表单交互较多的场景下,会简化大量业务无关的代码。缺点就是由于都是“暗箱操作”,我们无法追踪局部状态的变化(虽然大部分情况下我们并不关心),潜在的行为太多也增加了出错时 debug 的难度。同时由于组件数据变化来源入口变得可能不止一个,新手玩家很容易将数据流转方向弄得紊乱,如果再缺乏一些“管制”手段,最后就很容易因为一处错误操作造成应用雪崩。

这样来看,单向绑定跟双向绑定在功能上基本上是互补的,所以我们可以在合适的场景下使用合适的手段。比如在 UI控件 中(通常是类表单操作),我会使用双向的方式绑定数据;而其他场景则统一采用 单向 + inline event ( <component msg="msg" on-update="updateMsg(msg)"></component> ) 的方式构建应用。
为什么?