关于React.js的状态同步问题

[lr5420511]

最近没有做.net，因为项目组要使用React.js前端框架，但是现在的人手里面又没有一个了解的。所以就安排我学习这个前端框架，大致看了一下中文文档。因为React.js被FB号称为现在最好的前端MVVM框架，我从开始就带着崇敬的心态去学习，但是看到如何处理模型和视图之间数据同步的问题时，我开始了自己的担忧，并做了几个实验印证了我的这些担忧其实并不是空穴来风。

如图：




注意图2的描述，对于ViewModel状态改变后，框架内部会调用组件的render方法，意味着每一次的状态变化都会在内存中构建一次组件的虚拟Dom结构，通过实验我发现，当新的组件Dom结构和以前的结构不一致时，框架会把该组件完全刷掉。当一致时，会对比每一个状态点的值是否改变，以此作为同步的基础。但无论如何，状态改变后，为了同步到视图都会生成一次虚拟组件Dom结构和使用两次的组件对比更新状态点。 那如果我们的模型只有一个属性的状态改变了（他可能还有其他的属性），有没有必要大动肝火的去又在内存中重新生成一次该组件的虚拟Dom结构，然后逐一对比两次的组件的状态点的不一致，然后进行同步。这个过程中做了多少吃力不讨好的工作？其实完全可以做到哪个属性的状态改变了，我们就只去刷新对应的那个点就好了，就像微软长期以来做的那样。

以上我的一些粗浅的认识，有一些东西还没有深入研究，如果有错误还请各位网友海涵，希望大家一起交流共同进步。

[以专业开发人员为伍]

我在2015年底、2016年前几个月接触 React，最终确定它是个伪 mvvm。它不过是 mvc 框架，说它是 mvvm 框架是言过其实了，它离 mvvm 差的是十万八千里。 当然我接触它，那个时候是因为它号称直接操作 mongodb 数据库并且自动获得数据改变通知，我打算就好像是 winform 初学者刚学 c/s 程序那样可以让一些程序员用最最低级的入门手段就能写前端应用。后来发现这个也是大坑，不能这样来开发，还是要回到真正的 c/s（有自己的服务器端框架）的方向上来。 不过就你的问题来说，在前端弄一个 mvc 刷新模式并非不可以。因为毕竟是在内存中——没有跨网线，而且有许多优化判断措施 ，速度还是差别不大。问题是这种模式太简单了，不能满足基本的 mvvm 需求。 比如说你用 ko 框架写一个 pureComputed 计算属性，或者哪怕是一个简单的 function，当你计算中用到了某些 observable 对象时，你根本不用关心何时需要 render 的问题。当有其中一个你在计算中引用的对象改变了，那么这个 pureComputed 或者 function 所绑定的 DOM 就会自动改变绑定的多种特性（而不是重建！），你根本不用指定说某个数据需要绑定某个组件，你也根本不可能指定何时 render。而且当这个 pureComputed 或者 function 根本没有绑定 DOM 的时候，它又智能地不去冗余进行计算。 React 是个有些粗制滥造的庞大的框架，根本不是像 ko 那样精巧而又高效的框架。编程工作量上，是5:1 的工作量。当然关键还是看什么人来推广。曾经我知道有些教师每月领4、5万块钱，跑到各大互联网公司去求人家某个项目组的人试用一下 React。然后就会发现铺天盖地地广告，说国内某某互联网巨头的产品是用React 来开发的，这种宣传伎俩。

[lr5420511]

引用 4 楼 sp1234 的回复:

我在2015年底、2016年前几个月接触 React，最终确定它是个伪 mvvm。它不过是 mvc 框架，说它是 mvvm 框架是言过其实了，它离 mvvm 差的是十万八千里。

当然我接触它，那个时候是因为它号称直接操作 mongodb 数据库并且自动获得数据改变通知，我打算就好像是 winform 初学者刚学 c/s 程序那样可以让一些程序员用最最低级的入门手段就能写前端应用。后来发现这个也是大坑，不能这样来开发，还是要回到真正的 c/s（有自己的服务器端框架）的方向上来。

不过就你的问题来说，在前端弄一个 mvc 刷新模式并非不可以。因为毕竟是在内存中——没有跨网线，而且有许多优化判断措施 ，速度还是差别不大。问题是这种模式太简单了，不能满足基本的 mvvm 需求。

比如说你用 ko 框架写一个 pureComputed 计算属性，或者哪怕是一个简单的 function，当你计算中用到了某些 observable 对象时，你根本不用关心何时需要 render 的问题。当有其中一个你在计算中引用的对象改变了，那么这个 pureComputed 或者 function 所绑定的 DOM 就会自动改变绑定的多种特性（而不是重建！），你根本不用指定说某个数据需要绑定某个组件，你也根本不可能指定何时 render。而且当这个 pureComputed 或者 function 根本没有绑定 DOM 的时候，它又智能地不去冗余进行计算。

React 是个有些粗制滥造的庞大的框架，根本不是像 ko 那样精巧而又高效的框架。编程工作量上，是5:1 的工作量。当然关键还是看什么人来推广。曾经我知道有些教师每月领4、5万块钱，跑到各大互联网公司去求人家某个项目组的人试用一下 React。然后就会发现铺天盖地地广告，说国内某某互联网巨头的产品是用React 来开发的，这种宣传伎俩。

谢谢您的回复，其实之前我也已经初步实现出了同步代码，所有的代码加起来也没有100行。就如您所说，当没有绑定Dom时也不会去做多余的运算。每一次状态变化都只去刷新绑定规则列表中的有的规则，按照这个规则的描述来进行状态同步。
如图中这个就是他的调用过程

每一次的状态变化，都会根据绑定规则列表中的规则来做指定的同步操作。由于内部实现实在太简单，被项目组否定掉了，没办法又重新学习其他的框架。

[li905663280]

this.setState 让状态发生变化，可以在特殊方法中让用户自己决定是否重新render，这样就让用户可以自行减少render的次数，达到优化的效果

[lr5420511]

引用 1 楼 li905663280 的回复:

this.setState 让状态发生变化，可以在特殊方法中让用户自己决定是否重新render，这样就让用户可以自行减少render的次数，达到优化的效果

谢谢您的回复，那如果ViewModel状态改变了，我们又不去render，是否有其他的方法可以实现状态的同步？

[lr5420511]

引用 1 楼 li905663280 的回复:

this.setState 让状态发生变化，可以在特殊方法中让用户自己决定是否重新render，这样就让用户可以自行减少render的次数，达到优化的效果

是使用shouldComponentUpdate返回false来让框架不调用render吗？感觉这样子处理并没有从根本上解决问题

[li905663280]

引用 3 楼 lr5420511 的回复:

[quote=引用 1 楼 li905663280 的回复:] this.setState 让状态发生变化，可以在特殊方法中让用户自己决定是否重新render，这样就让用户可以自行减少render的次数，达到优化的效果

是使用shouldComponentUpdate返回false来让框架不调用render吗？感觉这样子处理并没有从根本上解决问题[/quote] 正常的处理是这样的。