大部分情况下都是因为数据职责划分问题。不在于工具，而在于设计。

@jaydenWang #10 @jaydenWang #11 你这两个回复很重要，更清晰的说明了你这个工具的核心关注点，我觉得整个宣传物料里完全没有体现，给的 demo 也完全没有体现。 另外那个 class 的整个的语法和结构非常难受，十分不统一，比如： - 构造函数里用 super 传入 initialState 但是又完全不体现出它是一个 state ，后面又有 .state - 莫名其妙蹦出来一个 @memo ，这个明显需要现代打包工具或者 TypeScript 的支持 - fiteredTodos 和 addTodo 的实现是不是过于复杂了？收益又是什么？好像都是 one liner 可以做完的事情 另外你这里还有一个非常蛋疼的点：多个 Store 之间如何交叉调用？必须实现在组件里，无法在 Store 内部实现？

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

rtk zustand jotai 不想给同事挖坑就老老实实使用这些广为人知的 library

抱歉，吐槽草率了 看了一下，还是很优秀的设计

@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 的时候不需要考虑太多参数

我写了几十万行 react 的业务代码了，除了 setState 和 context 基本没用过其他的状态管理。恕我直言，99% 的业务代码都不用考虑单独搞个 model 层

@Chrisssss 这个倒是真的，主要是要做编辑器，设计器这类应用可能才需要用到 model 层

@shunia 补充一点，多个 store 的交互参考, Zenith 完整的支持这种模式

前端是不是故意的，越来越复杂了。。搞得门槛变高了，后端都看不懂了 https://i.imgur.com/LaO5dh3.png