useState useEffect useMemo 的原理非常重要，不是实现细节。不懂具体怎么实现的，只背api，分分钟掉到沟里，基本没法干活

【 在 tgfbeta (右旋肉碱) 的大作中提到: 】
: 这是实现细节，不重要
: 正所谓闭包是穷人的对象，对象是穷人的闭包
: Closures are poor man's objects. Objects are poor man's closures.
: ...................
--
FROM 123.120.168.*

@eGust 试了一下，有意思。

  const [counter, setCounter] = useState({ value: 1, step: 1 })

  useEffect(() => {
    console.log('A', { ...counter })
    setCounter((old) => {
      console.log('AA', { ...old })
      return { value: old.value + old.step, step: old.step }
    })
  }, [counter.step])

  useEffect(() => {
    console.log('B', { ...counter })
    setCounter((old) => {
      console.log('BB', { ...old })
      return { value: old.value + old.step, step: old.step }
    })
  }, [counter.step])

step 1->2 时，外层 A B 处拿到的两个 counter 是一样的，如你所说。

但是，setCounter内层 AA BB 处拿到的两个 old 是不一样的，反而和 vue 类似，拿到的一个是没加过 step 的，一个是加过的。

所以 react 最终页面效果还是value加了2，和vue的最终效果一样。

看来一个渲染批次之内的多个 setCount 传入多个 old => new 这样的 reducer 函数的时候，是 lazy evaluation，把两个 setCount 压到最后顺序执行了。这个最终效果和你说的有偏差，react 的这种写法，一样有你说的调用顺序的“微妙”问题。也就是说，那两个
setCount，和 vue 的两个 watch 一样，都有先后次序的问题。

想想也应该是这样啊，用户写了对同一个内存对象的两次累加修改，在单线程模式下，最后的本质肯定还是一先一后执行的啊，最终肯定得加两次啊。哪怕并发模式，将来有了
cocurrent，正确的逻辑也得是加锁，最终还是要加两次呀。

只要加两次，就肯定无法避免先后次序问题。咱们这个例子只是加一，顺序无所谓。碰上顺序有关系的，反而是 cocurrent 比较麻烦，vue 和 non-cocurrent react 还好，不管怎么 lazy evalute，最终应该还是按照代码里的真实顺序来调用的，次序虽然不一定直观，但应该是稳定的。


【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 标  题: Re: 对比 vue，reactjs 就是个笑话！
: 发信站: 水木社区 (Wed Jun 30 21:52:25 2021), 站内
:
: 我咋觉得react也一样呢？复刻一下这个例子：
:
: const [{ value, step }, setCounter] = useState(counter);
:
: useEffect(() => {
:   console.debug("watcher A", { ...counter });
:   setCounter(old => ({ value: old.value + old.step, step: old.step })) // 1
: }, [step]);
:
: useEffect(() => {
:   console.debug("watcher B", { ...counter });
:   setCounter(old => ({ value: old.value + old.step, step: old.step })) // 2
: }, [step]);
:
: 跑的时候 1 和 2 两个 setCounter 也是顺序运行的，它们各自取到的 old.value 也不一样吧？
:
: 我个人理解，useState useEffect 本质就是为了造成纯组件函数的“假象”，把生存周期是跨越多次渲染而一直存在的 state 变量、effect 函数，都存到了用户看不见的闭包里，因为 react 函数组件只有一层 render 函数，正常来看的话没有造闭包的地儿：
:
: ...; // state 和 effect 真实创建于框架代码里，也就是组件 render 函数体之外
:
: function Component () {
:   ...; // render 通过 useState useEffect 取出作用域外的闭包变量
: }
:
: 而 vue 是把这种变量显式地放在 setup 函数形成的闭包里。
:
: setup() {
:   ...; // 构造跨多次渲染的闭包变量
:   return () => {
:     // render 直接通过原生js作用域机制获取外面的闭包变量
:   }
: }
:
: 所以本质都是闭包变量，只是闭包的位置不同而已吧？
:
: 除非说 react 内部在上述同一批次内多次调用 setCount 的时候，故意都是传入初始的
: count，而不是前面 setCount 修改过的 count。。。如果真是这样，我觉得反而不符合用户意图啊？
:
: 稍后有空试一下。
:
:
:
:
: 【 在 eGust (十年) 的大作中提到: 】
: : 标  题: Re: 对比 vue，reactjs 就是个笑话！
: : 发信站: 水木社区 (Wed Jun 30 16:51:15 2021), 站内
: :
: : 重点并不在 watch 上，declarative ui 是 model -> view 的映射。理论上只要给定了
: 一个确定的状态，state 也好 data 也好，都能生成一个确定的 ui。
: :
: : react 里面 newState = reduce(oldState, action)，这是一个非常确定的状态。举一个
:   counter.value += Number(counter.step);
: }, [step]);
:
:
: 【 在 eGust (十年) 的大作中提到: 】
: : 标  题: Re: 对比 vue，reactjs 就是个笑话！
: : 发信站: 水木社区 (Wed Jun 30 16:51:15 2021), 站内
: :
: : 重点并不在 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 于 Jun 30 17:00:22 2021 修改本文·[FROM: 101.98.83.*]
: : ※ 来源:·水木社区 mysmth.net·[FROM: 101.98.83.*]
:
:
: --
:
: ※ 修改:·beep 于 Jun 30 22:18:46 2021 修改本文·[FROM: 123.120.168.*]
: ※ 来源:·水木社区 mysmth.net·[FROM: 123.120.168.*]
--
修改:eGust FROM 101.98.83.*
FROM 123.120.168.*

我认为 现在的体系就是往没必要的复杂里搞。
为什么要用函数式呢？
事件响应不就已经很足够了么。
如同 cisc 和 risc 的区别
【 在 adoal (阿豆) 的大作中提到: 】
: GUI开发本来就是复杂的，你看看Windows GUI程序的开发，
: 从裸写SDK到MFC，.NET下从WinForm到WPF，里面的方法论
: 演变都是通过引入复杂的设计来解决现实中项目做大了一定
: ...................
--
FROM 124.240.15.*

因为 vue2 赶上了一个好时代。
vue2 代替了angular ，后面 angular 就没人看了。
就像 laravel 比 zend framework 还重。那样
PHP 不是一种好语言，但是他赶上了个好时代。 laravel 走向了邪路
nodejs 本来可以替代 php 的，可惜就是太做了。一直是歪的
【 在 gang2k (枕头) 的大作中提到: 】
: 为啥国内用angular的这么少？
: 发自「今日水木 on iPhone 12」
--
FROM 124.240.15.*

如果不支持这种功能的语言是怎么解决这些问题的？
抛事件，事件乱飞？
【 在 eGust (十年) 的大作中提到: 】
: 重点并不在 watch 上，declarative ui 是 model -> view 的映射。理论上只要给定了一个确定的状态，state 也好 data 也好，都能生成一个确定的 ui。
: react 里面 newState = reduce(oldState, action)，这是一个非常确定的状态。举一个不太恰当的例子：
: import { reactive, watch, toRef } from "vue";
: ...................
--
FROM 124.240.15.*