不需要notify

[Liuyll]

不需要在Provider里notify，因为useContext的缘故，即使上层组件受SCU或者Memo的影响，子组件也一定会重渲染。 而且似乎这个库，会带来更重的心智负担，毕竟是依靠顶层setState的状态库，子组件需要做好充足的缓存才能应付更新。 仅讨论

[awmleer]

之所以使用 notify 的方式做通知，主要是为了实现选择性订阅，而且这其实是底层的逻辑，用户完全无感知的～

至于心智负担，其实并不会增加太多（当然不同人感受会有不同），不过“子组件需要做好充足的缓存才能应付更新”这一点我其实没有太理解。。愿闻其详

[Liuyll]

之所以使用 notify 的方式做通知，主要是为了实现选择性订阅，而且这其实是底层的逻辑，用户完全无感知的～

至于心智负担，其实并不会增加太多（当然不同人感受会有不同），不过“子组件需要做好充足的缓存才能应付更新”这一点我其实没有太理解。。愿闻其详

不好意思，代码很久之前拉的，没发现已经更新这么多了。。 我是指B作为A的子组件，C作为B的子组件直接useContext，那么A组件引发的B组件更新势必会影响C组件重渲染，即使C组件并没有依赖B组件需要更新的内容，需要很小心的维持依赖关系。 当然实际情况肯定更加复杂，而且这种状态库无法维持最小依赖，显然这不是reto才存在的问题。有没有想过用类似useObserver之类的对组件做层memo，不过用户需要配合这种额外的工作。 事实上，zustand这样成熟的状态库也存在hooks的通病，所谓心智负担不是独立开发时出现的，而是团队开发时不遵从一致的hooks约定导致的。真实情况当然很复杂，像官方不提倡的useEventCallback就是解决这种问题的产物。 当然reto写的很好，毋庸置疑

[awmleer]

的确，无法精确控制最小的依赖是 useContext 带来的通病。。我之前也对此十分介意，甚至于做过另一个基于 rxjs 的库，就像你所说的 useObserver 。但是后来我觉得这是一个需要权衡的问题，如果追求极致的性能会带来开发者额外的心智成本，那可能一个“好用”的库应该是努力追寻一个平衡点。。 所以 reto 的推荐思路就是通过对组件 memo & 对 Store 拆分，当然这其实是 react 官方推荐的思路。这样做虽然性能达不到完美，但是即便对于中大型应用也完全够用了。。（亲测）