Open sorrycc opened 8 years ago
如果更新逻辑不能很好地封装在 domain class 里
这里的更新逻辑具体是指什么
我这边用mobx做了个小项目,目前没发现不能cover的逻辑。
@jzlxiaohei 能分享一下项目 GitHub 吗?
感觉 MobX 很有些 MVVM 的味道啊
@sorrycc 我们正在做一个富应用(类似百度H5的网页编辑器),包括你的DVA,哪个更合适一点?
看来目前还是用Redux妥当啊
@JanzenZhangChen 这里: Mobx和VUE都太自由了,随意修改store就造成更新,必然导致bug极难定位你这个论断是怎么得出的, 能具体说说嘛?
@xiangsongtao 我的描述确实有点问题,不是因为随意修改store,就会导致bug。而是会导致逻辑的封装不严谨。对store的不同操作逻辑可能被放在各个不同的组件内,不能被抽象出来,导致这个组件很可能没办法很好的复用,或是解耦。在多人团队合作的时候,很可能因为高自由度而导致逻辑的混乱。
目前用Mobx和vue开发小项目都很爽。但是在SPA项目中使用确实没有redux来的有安全感。感觉C层会越写越薄,View会承载大量逻辑。最后就导致维护的难度上升。
@JanzenZhangChen 我使用mobx的时间不多, 我觉得每个路由应该对应一个特定的页面(比如dashboard和email两个不同的页面), 而这个页面的状态store应该由这个页面自己管理, 而不是在全局管理. 如果需要用到公共状态, 比如theme, 则通过inject注入到需要的页面中. 整个过程还算可控.
也许做过大项目才能体会到你说的'安全感', 谢了
@JanzenZhangChen 使用 mobx 符合领域模型的 class 在中小项目中能提高效率,并不意味着大项目中就不适合吧。Java 大项目照样用 OO 的这一套抽象啊。个人理解,二者实际上区别应该在于 Redux 适合 IM 一类状态随时间序列变化的系统,而 mobx 更适合后台管理等对许多复杂数据模型做 CRUD,没有时间序列概念的系统。
@xiangsongtao @doodlewind 我个人感觉,其实这个问题不是简单的对错,而更多是一个权衡。 更多的是架构设计的方式不同。 store被reducer管理之下,其实还是很清晰的。 我觉得和OO的这一套最大的本质差别在于,对数据的操作逻辑放在哪里?(这句话其实也有问题,最大的区别应该是命令式编程与函数式编程的区别
redux控制下MVC的分层会很明显,view会很纯粹。但是逻辑就被分散到C层,M层(reducer)。虽然写起来很烦,但是分层以后,相对降低了维护的难度。我认为这是SPA最需要解决的痛点。复用的其实就只有view层,对数据的处理逻辑就要另外用。
mobx(vue)控制下因为没有action,reducer的承载,对model的操作会倾向写在view里面,使其变得大且复杂。当逻辑多了以后,这个组件就需要承载组件通信,复杂业务逻辑,还有一些对dom的特殊处理等问题。这些都会在一个组件内完成。那么维护这些逻辑的成本就会随着迭代急剧上升。也因为逻辑都在一个地方,所以直接使用一个复杂业务逻辑组件就简单很多。如果这时候来一个特殊需求,你就只能在这个组件内写特殊逻辑分支了。在redux内则不会有这个问题。
mobx 有action的感念。 strict
模式下,必须标记了@action
才能修改对象。
当然view里也能标记,所以我们要求 view里必须使用model 自己的方法修改数据。
我们的代码了,组件一般需要一个model,例如
static propTypes = {
model: PropTypes.instanceOf(UserModel).isRequired,
}
作为深受OO‘毒害的人’, 这种是我接受起来就容易的方式了,组件需要什么model, model里有组件需要的数据(字段)和action(方法)。业务模型一目了然,反而是redux的业务模型,散落在action和reducer里,让我觉得表述业务时,有点不清楚。
mobx(vue)控制下因为没有action,reducer的承载,对model的操作会倾向写在view里面
我很赞成 @JanzenZhangChen 纯 View 的理念,不过你提到的这点不完全成立。mobx 有 strict 模式来强制把 model 操作封装在 action 中,也同样也可以围绕 model 和 store 来组织代码,让 View 保持为 React 应该有的纯 View。这样不仅保留了和 Redux 理念上一致的模型层抽象,也能够提升开发的效率,少写 redux 的 boilerplate(我们组内交流的观点还是普遍反映 redux 这一套比较难用,目前在考量 Rx+mobx 的方案)。
@doodlewind 我用下来,mobx不太需要和rx配合,直接数据驱动就好,流式的,毕竟很少真正需要。
另外mobx的作者,又写了个 mobx-state-tree, 我感觉这个几乎把redux一些理念上优点都集成进来了,不过有点复杂,而且比较新(意味着可能有坑
@jzlxiaohei @doodlewind 嗯,我后面没怎么跟进mobx的演化了。其实我也挺喜欢mobx的,只是现在还不敢贸然在正式环境上线。
我基本都是后台项目。 mobx + antd 加了polyfill, IE9可以用。 (firefox好像反而没人问
感觉MBOX灵活,MVVM的,数据驱动,理解特别容易,VIEW只是STATE的一个展现。
没用过mobx
不知道是否有和vuex
一样监测store
的变化 否则组件内部直接修改store
确实比较难维护
先要明白 mobx 和 redux 的定位是不同的。redux 管理的是 (STORE -> VIEW -> ACTION) 的整个闭环,而 mobx 只关心 STORE -> VIEW 的部分。
但作为两个目前最火的 React 应用框架库,人们习惯于把他们比较到一起。下面我们也来看下 mobx 和 redux 相比的优缺点。(据说每个列 3 点会让人更容易记住。。)
优点
基于运行时的数据订阅
通过 OOP 的方式组织领域模型 (domain model)
修改数据方便自然
缺最佳实践和社区
随意修改 store
逻辑层的限制