几年前在版上吹 react 的时候，我表达过我的意思，oo 是工程师搞出来的东西，而 fp 是学院派出身，是有理论背景的。ng1 就算是工程师搞出来的最高成就了，而 react 一出则是彻底革了 ui 技术的命。

前面我说 react 用了俩 fp 概念其实不准确，实际上只有 pure function 一个核心概念，而 immutable 是由于 js 语言本身没带这能力才引入的。由于纯函数是个特别强的约束，表达能力反倒是极其有限的。而且正是由于这个特性，导致不得不对 side effect 进行特殊的考虑。这两天还看到 reddit 上有人问，为啥 random 是 side effect，其实答案也很简单，因为它不是 pure function 了。要对 random 进行特殊处理是违反直觉的，但正是因为有了纯函数的约束，才简化了问题。如果状态错了，那么只要改 reducer 就可以了，反之那就是 jsx 映射错东西了。这样的好处就是，state 的转换过程可以单独测试，ui 也可以单独测试，解耦了业务逻辑和 ui。而业务逻辑中，纯函数的部分可以单独测试，副作用的部分需要单独考虑，但不影响纯函数的正确性。要么纯函数写错了，要么副作用处理错了，界限也非常清晰。

useEffect、useMemo、useReducer 等很多 api 都是先有了第三方库的生态，得到了社区的公认，react 又反过来引入的。比如复杂的状态管理也是经历了从 flux 到 redux 的过程，而 redux 为了解决 side effect 又引入了其它第三方的扩展。同理 redux-thunk 是工程师搞出来的东西，而 redux-saga 是以论文为基础搞出来的学院派的东西。特点也是一样的，thunk 看起来很简单好用，saga 则又引入了一堆的概念，学起来特别晦涩。但两者相比我自然还是推崇 saga，因为从理论上已经证明了有效性，工程师搞出来的东西就是摸着石头过河，你不知道什么时候会出问题。

回过头来看 vue，并不是说 react 的实践就不适用，就像很多人学了 rust 之后反过来也影响了写 c++ 或者其它语言代码，自然而然的就意识到潜在的问题。vue 里也可以尽量写纯函数，遇到 side effect 的时候多留点儿心，也一样可以写出容易测试的代码。但这个就是写代码的人的造化了，代码质量可能会参差不齐。而 react 那边是有个底线在的，不排除有复制粘贴凑合把代码跑通的可能性，但总体上只要有搞懂了的人把关，那项目的质量是差不到哪里去的。

比如我们的 vue 项目，一开始我是企图学 redux connect 解耦控件本身和 vuex 的。但别人不遵守，再加上赶进度，很快就变成想测试控件就不得不带上 vuex 了。你可以说是我们的工程质量问题，人员水平问题，我不反对。但如果上了 react + redux，那是几乎不可能开这个口子的。当然话说回来，由于除了我以外的人都是现学的，上了 react 的话也几乎不可能用相同的速度上线的。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 应该是看懂了。说说我的理解哈。
: 你最后提到的useReduce应该和咱们的话题没有太多直接关系，不涉及react和vue的能力对比问题。我理解useReduce就是把原本分散在各处的setState(v=>foo(v))逻辑都起了个名儿，集中在了一起，方便管理。
: 关键问题在于对e2这种逻辑的表达能力：
: ...................
--
FROM 101.98.83.*