- 主题:对比 vue，reactjs 就是个笑话！
所以说SwiftUI到现在为止还极不成熟
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: UI复杂程度高于操作系统。
: 如果不高于，那是UI开发程度还不够。请考虑：是否允许影音交互？是否允许3d交互？是否允许残障人士交互？
--
FROM 111.166.7.*
ms office 365 的 ui 用的就是 react
你说为什么 office 要搞那么复杂？
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 我想起那句话， java 善于解决 java 发明的问题
: 要切图仔理解这些高深名词，真是太难了
: 问题来了，为什么前端要搞那么复杂
: ...................
--
FROM 101.98.83.*
我觉得前端这玩意确实是在本质上就是复杂的
而且很可能在100年内都会越来越复杂
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 我想起那句话， java 善于解决 java 发明的问题
: 要切图仔理解这些高深名词，真是太难了
: 问题来了，为什么前端要搞那么复杂
: ...................
--
FROM 43.243.12.*
而且我觉得GUI变复杂的速度经常会超出人的估计
刚开始的时候，GUI经常是一个切图仔一周就能做的很不错的状态
但是很快就会变得越来越复杂
【 在 adoal (阿豆) 的大作中提到: 】
: GUI开发本来就是复杂的，你看看Windows GUI程序的开发，
: 从裸写SDK到MFC，.NET下从WinForm到WPF，里面的方法论
: 演变都是通过引入复杂的设计来解决现实中项目做大了一定
: ...................
--
FROM 43.243.12.*
useState的具体实现，充分利用了闭包，而且又巧妙地隐藏了闭包的外表
【 在 tgfbeta (右旋肉碱) 的大作中提到: 】
: 这个只是react自己架构的一个construct，算不得js的工作原理
--
FROM 123.120.168.*
【 在 eGust (十年) 的大作中提到: 】
: 标 题: Re: 对比 vue，reactjs 就是个笑话！
: 发信站: 水木社区 (Wed Jun 30 09:19:44 2021), 站内
:
下面这一段，watcher的复杂性，和useEffect有何不同呢？useEffect如何解决“触发顺序”之类的问题呢？
: 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，就可以干活了。
: : ...................
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 115.188.133.*]
--
FROM 123.120.168.*
因为现在前端越来越重了，前端项目越来越大了
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 我想起那句话， java 善于解决 java 发明的问题
: 要切图仔理解这些高深名词，真是太难了
: 问题来了，为什么前端要搞那么复杂
: ...................
--
FROM 123.120.168.*
这是实现细节，不重要
正所谓闭包是穷人的对象，对象是穷人的闭包
Closures are poor man's objects. Objects are poor man's closures.
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: useState的具体实现，充分利用了闭包，而且又巧妙地隐藏了闭包的外表
--
FROM 111.166.7.*
重点并不在 watch 上，declarative ui 是 model -> view 的映射。理论上只要给定了一个确定的状态，state 也好 data 也好，都能生成一个确定的 ui。
react 里面 newState = reduce(oldState, action)，这是一个非常确定的状态。举一个不太恰当的例子：
import { reactive, watch, toRef } from "vue";
export const counter = reactive({
value: 1,
step: 1
});
const step = toRef(counter, "step");
watch(step, () => {
console.debug("watcher A", { ...counter });
counter.value += Number(counter.step);
});
watch(step, () => {
console.debug("watcher B", { ...counter });
counter.value += Number(counter.step);
});
如果 step 的值改变了：1 -> 2，那么你会看到的输出是
watcher A { value: 1, step: 2 }
watcher B { value: 3, step: 2 }
如果把这个实现换成 react 的话，由于 value 是从
const [{ value, step }, setCounter] = useState(counter);
里取出来的，所以不管有几个 useEffect，调用了几次 setCounter，在所有的 effect 函数里面，value 的值都会是 1。
这个例子本身很不好，实际中的情况是，多个 watchers 监听各自的 props/computed，但它们都会根据变化来和 data 本身的值来更新 data，于是就产生了不确定性。但是一时间不太容易构造一个合适的例子，临时只能想出这个示意一下，不知道解释明白了没……
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 下面这一段，watcher的复杂性，和useEffect有何不同呢？useEffect如何解决“触发顺序”之类的问题呢？
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*
学习了
ng2和react比较呢？
【 在 eGust 的大作中提到: 】
: 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 的项目少。
: ...................
--
FROM 223.104.38.*