class组件，和hooks组件，各有各的复杂，都很麻烦。本质上是因为react采取了一个奇葩的响应式方案，就是对状态根对象做简单的引用比较。为了这个，弄出一堆fp不可变的东西来，不管咋弄心智负担都不小。

这方面我还是觉得vue mobx这种proxy式的响应式方案比较靠谱，也切合现在业务逻辑一般都用class oop来写的实际情况。proxy式的响应方案，虽然也要注意不能丢失引用，但是规则还是比较简单的，只要记住永远要用a.b就可以，不能没有中间那个点。

前面有人提到被toRef toRaw这些搞晕了，其实这些都是处理特殊情况的边缘api。正常只要记住上面的规则，会用ref reactive，知道computed返回的是个ref，就可以干活了。



今天刚在知乎上写了个相关文章，贴出来吧

https://www.zhihu.com/question/468249924/answer/1968728853

【 在 eGust (十年) 的大作中提到: 】
: react 官方文档 hooks 的介绍部分阐述了引入 hooks api 的理由：
: https://reactjs.org/docs/hooks-intro.html#motivation
: - It’s hard to reuse stateful logic between components
: ...................
--
FROM 123.120.168.*

这个只是react自己架构的一个construct，算不得js的工作原理
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: useState这个hook的原理，真是进阶学习js工作原理的绝好案例。
--
FROM 111.163.120.*

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.*

要吃饭。
如果现在还是jq时代，人均还是六七千的工资。。

让我我也把这东西搞复杂。

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 我想起那句话， java 善于解决 java 发明的问题
: 要切图仔理解这些高深名词，真是太难了
: 问题来了，为什么前端要搞那么复杂
: ...................
--
FROM 220.181.41.*

GUI开发本来就是复杂的，你看看Windows GUI程序的开发，
从裸写SDK到MFC，.NET下从WinForm到WPF，里面的方法论
演变都是通过引入复杂的设计来解决现实中项目做大了一定
会遇到的确实复杂的技术和工程管理问题。
切图仔？只管切图好了，代码总是要码农来写的。


Web前端嘛，历史遗留问题。本来是用来展示一页一页静态
文稿页面的架构，随着Web越来越应用程序化，也遇到了
桌面和移动端GUI开发的工程化问题，确实也是在这么做的。
只不过这个领域由历史演变来的现状就是，构成UI的元素在
用户能直接打开看源码的页面里、切图仔和JS码农之间的
工作内容纠缠不清、编程语言只能用有人爱有人嫌的JS，
等一系列跟桌面和移动端生态不太一样的问题罢了。
并不是要切图仔理解这些技术，而是很多场景下，说话管用
的人并不介意需要理解这些技术的人和切图仔的区别^_^

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 我想起那句话， java 善于解决 java 发明的问题
: 要切图仔理解这些高深名词，真是太难了
: 问题来了，为什么前端要搞那么复杂
: ...................
--
FROM 122.225.220.*