react 其实只用了俩核心 fp 概念，一个是 pure function，另外一个是 immutable。延伸出来就是数据的单向流动，hooks 的 getter/setter 设计跟 input/select 完全是一样的。这种设计的结果就是，react 里的 state 就是 single source of truth。而每次由当前的 state 和一个参数（action）生成一个新的 state 的过程也非常简单，由于是纯函数，给定确定的 state 和 action 每次都能保证产生相同的结果。这其实也是 fp 的优势，非常容易写 unittest。

ng1/vue 的双向数据绑定表面上看起来非常直观，vue 的 data 看起来也是跟 state 一样的概念。但这种设计却不得不引入 watch，而它又其实引发了许多问题。首先 watcher 里面可能会再更新 data，而又可能触发其它的 watcher，这就导致了数据的更新流程非常复杂，不像 newState = reduce(oldState, action)  那么简单。其次，多个 watchers 监视同一个数据的变动也是很难避免的，那么它们触发的顺序就变成了一件非常微妙的事情，很可能由于触发顺序的不同而产生不同的结果。另外，watcher 里面依赖了哪些外部的变量也是非常难预测的，导致的结果就完全相同 data 初始结果，同样的事件可能导致不同的最终值。所以如果没设计好的话，很容易把 unittest 的依赖关系搞的非常复杂，很难实现。

总体上，我是更倾向 react + hooks 的，因为 fp 的条条框框在那里绕不过去，迫使项目的设计差不了，用起来是个先苦后甜的过程。vue 容易上手，副作用就是项目上设计起来非常容易放飞自我，最后的坑不比 jquery 的项目少。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: class组件，和hooks组件，各有各的复杂，都很麻烦。本质上是因为react采取了一个奇葩的响应式方案，就是对状态根对象做简单的引用比较。为了这个，弄出一堆fp不可变的东西来，不管咋弄心智负担都不小。
: 这方面我还是觉得vue mobx这种proxy式的响应式方案比较靠谱，也切合现在业务逻辑一般都用class oop来写的实际情况。proxy式的响应方案，虽然也要注意不能丢失引用，但是规则还是比较简单的，只要记住永远要用a.b就可以，不能没有中间那个点。
: 前面有人提到被toRef toRaw这些搞晕了，其实这些都是处理特殊情况的边缘api。正常只要记住上面的规则，会用ref reactive，知道computed返回的是个ref，就可以干活了。
: ...................
--
FROM 115.188.133.*