我还是举一个例子吧,比如我们有这么一类 form 控件
props: { target: Object, name: String, ... }
computed: { value: { get() { return this.target[this.name] }, set ... } }
父控件把 data 中的对象和名称传给子控件,<child :target="foo" name="bar" />,子控件使用 v-model="value",然后在 set 里做比较,决定要不要放入待传回的数据中。上周同事问了我一个问题,为什么明明我在父控件里 this.foo.bar = baz,结果这个字段却没出现?他期待子控件 computed.value.set 会被调用……
如果用 react,父控件不得不再传一个调用 setState 的方法进去,更新之后的 target 也是一个全新的对象,你觉得还能问出来这种问题么?
react 故意设计成所有的对象都应该 immutable,想有属性变化就得重新生成一个,这样你不得不去关注数据的流向。vue 的做法的确是 gc 压力小了,上 proxy 之后效率比生成新对象高更多了。但是双向数据绑定的弊病也出来了:多个源都可以去更新同一个对象,数据的流向变得难以追踪。
还是老话,对于使用者来说,并不在意内部实现是怎样的。vue 比 react 加载快了多少,内存少占用多少,复杂的页面能多画几帧,并不是那么重要。跟正确性相比,代码写得更费劲、效率低了,都不是大的问题。java 跟 c++ 比起来,不光跑得慢,还更啰嗦(不造轮子的话),但是人家不容易啰嗦错啊。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我觉得咱俩说的东西本质是一样的。
: react为什么走functional单向数据流路线?不是因为它的props和state技术上无法被直接赋值修改,本质原因是因为它的reactivity机制是检测不到直接赋值的,所以必须走setState()之类的显式触发,整体重新生成vdom然后diff。
: vue的data为什么不需要setData()?因为用了proxy/setter呗,所以也就没有必要非要使用单项数据流了。
: ...................
--
修改:eGust FROM 125.238.192.*
FROM 125.238.192.*