@Ketteiron trackGetterAcces 这种设计可能是有问题的，我想想有没有优雅的姿势自动清除缓存

@Ketteiron 1. 没想过自动计算依赖
2. useStoreSelector 计数不会出错，缓存不是目的，缓存是为了稳定的引用，是服务于 view 层。view 层用了缓存，不用了不缓存，不存在 view 层控制 model 层缓存，这个缓存就是服务于 view 层的
3. 调用层有完整的 TS 类型推到，实现层还有一些 any 会修复

@shunia 补充一点，多个 store 的交互参考<https://zh.mobx.js.org/defining-data-stores.html>, Zenith 完整的支持这种模式

@shunia - 不好意思，没有保留 BaseStore 的细节。state 是继承自 ZenithStore
- memo 是实现计算属性的核心，如果 filteredTodos 是通过 this.state.todos.filter 返回的值，组件层每次读区 filteredTodos ，都会返回一个新的索引，触发组件渲染。 @memo 显示声明了依赖项，当依赖项不变的时候，永远返回上一次的引用，组件不会额外渲染。当 this.state.todos 的索引改变的时候，可能是删除、增加、修改，filteredTodos 就会触发重新计算，因为索引变化，组件触发重新渲染
- fiteredTodos 也就是这类派生状态，是鼓励写复杂的，响应式会更加友好，后续 setState 就不用考虑，todo 索引改变了，filter 的值改变了，fiteredTodos 自动计算，体现在 UI 层。把 setState 的复杂逻辑，转移到 get 中，后面业务逻辑复杂，setstate 的时候不需要考虑太多参数

@BingoXuan 是的，Zenith 要做的就是在设计好的基础上，保护好数据，优雅的更新数据，简单的获取数据。Zentith 对于复杂数据职责划分，保留了领域 store 的能力，可以一个 rootstore 组合多个领域 store 。可以参考 mobx 的这篇文章<https://zh.mobx.js.org/defining-data-stores.html>

@pakholeung372 思路很像，一开始也写过 this.store = create(
() => ({
current: undefined,
}),
)

@novaline 没有重复造轮子，核心是 immer 。github 有跟 RTK 的对比

@gkinxin 这一块示例不完整，github 有完整的示例。多个组件如何读取状态、set action

@rich1e 这是 Zenith 的性能优势。借助 immer 的不可变状态，共享引用以及 Zenith 的计算属性，可以实现更改一个深度状态，只渲染状态树的这条分支

@shunia 1. 解决了 zustand 没有计算属性的问题，有了计算属性，就不需要在组件层 selector ，可以把所有状态内聚的 store 中，计算属性 store 内以及各个组件都可以复用。可以做到没有 UI 的情况下，完成完整的业务逻辑
2. 把“set”方法保护起来，组件中是无法 set 的，可以自由读取状态，set 状态必须调用 store 的 action

@lanten 不需要写模版语言，组件层使用起来跟 zustand 是一样的。额外支持：1. 默认局部状态，支持多实例； 2. 计算属性。3.复杂状态性能优势明显 store 是纯粹的 class 写法，没有额外的约束

@uglyer 不是单例，也不推荐单例。使用 createReactStore 创建的都是局部状态，组件多实例彼此不影响。store 随着组件的生命周期销毁。直接 const todostore = new TodoStore()是单例，不推荐这么做，不过有些真正的全局状态可以这么干

@netabare 五个人协同开发，每个人都知道 get,set 在干嘛，但无法避免状态和逻辑散落在组件中，彼此就无法感知其他人做了什么。这在工程化上会是一个挑战

@codehz zustand 的使用体验，api 设计的非常棒。我觉得它缺失的是：set 不是私有方法，没能限制在 store 中调用；派生状态没有内聚在 store 中

@codehz 我很认同你说的 flux 核心原则，但是 zustand 做得并不好，派生状态目前只能通过 usememo 散落在各个组件里，并没有内聚到 store 中。另外一个就是组件可以直接 set zustand 的 state ，并没有限制到只能调用 store 的 action ，在实际开发中就会出现状态和 action 可能都大量散落在组件中的情况

@codehz Zustand 的设计和使用方式，被默认理解和实践为一种‘函数式姿态’，但它在工程语义上其实是在模拟对象模型

确实可以，但需要这么多"约定"和"注意事项"来规避闭包陷阱时，是否说明这套 DSL 本身在表达"有状态对象"时不够直观

Zenith store 灵感来源于 mobx 的<https://zh.mobx.js.org/defining-data-stores.html>这篇文章。但是实现和 api 不相同

抛开 immer ，Zenith 和 Zustand 最主要区别是：
1. Zustand 太自由了，Zenith 修改状态只能约束在 store 中，工程化不友好
2. Zenith 支持使用 memo 计算属性
3. Zenith 派生状态都内聚在 store 中