@dreamerblue 可以进一步聊聊有哪些方面可以改进的吗？

@ysmood Zenith 跟 Zustand 和 Stalo 做的事是不一样的，跟 Valtio 和 MobX 相似。就不要再讨论 zustand like 的方向了

@ysmood zenith 强制工程化，在此基础上提供优雅的更新，便捷的使用。不会为了简单好用弱化对做真确事的最求

@horizon 谢谢，欢迎使用、交流

@XCFOX Zenith 和 Valtio 确是很相近，下面是整理的对比，Zenith 在封装和工程化上会有一些优势，使用确实没 Valtio 简单

@ysmood zenith 追求的不是简单，是工程化。他可以不用 context ，但是不推荐这么做，不推荐成为单例，不推荐成为全局状态。使用 context ，store 可以具备组件相同的生命周期，随着组件实例而实例，跟随组件销毁。至于 computed value ，这是响应式系统非常关键的点，有了 computed value ，你只需要关注派生状态依赖什么就可以了，这不是耦合，这是减少后续开发的负担。后续的 set 操作就可以足够轻量，不需要 set 一个状态的时候，考虑其它状态需要如何控制

@XCFOX 请教一下 Valtio 是如何实现计算属性的，get 方法如果 return 类似 this.todos.filter(t => true)或者 this.todos.map(t => t)是否存在性能陷阱

@youyouzi View 层像 Zustand 一样简单。zustand 的 store 本身不支持计算属性，派生逻辑只能写在组件的 selector 里

@codehz 第一版就是基于 zustand 封装的，但是 zustand 不是核心。核心是 immer ，不可变状态，后续就移除了 zustand

@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