摘要:原理分析的核心就是通过观察某一个变量,当该变量产生变化时,对应的内的回调函数就会发生变化。回调函数若依赖外部环境,则无法进行收集很好理解,的回调函数在预执行的时候无法到达那一行代码,所以收集不到。
Mobx解决的问题
传统React使用的数据管理库为Redux。Redux要解决的问题是统一数据流,数据流完全可控并可追踪。要实现该目标,便需要进行相关的约束。Redux由此引出了dispatch action reducer等概念,对state的概念进行强约束。然而对于一些项目来说,太过强,便失去了灵活性。Mobx便是来填补此空缺的。
这里对Redux和Mobx进行简单的对比:
1. Redux的编程范式是函数式的而Mobx是面向对象的;
2. 因此数据上来说Redux理想的是immutable的,每次都返回一个新的数据,而Mobx从始至终都是一份引用。因此Redux是支持数据回溯的;
3. 然而和Redux相比,使用Mobx的组件可以做到精确更新,这一点得益于Mobx的observable;对应的,Redux是用dispath进行广播,通过Provider和connect来比对前后差别控制更新粒度,有时需要自己写SCU;Mobx更加精细一点。
Mobx核心概念Mobx的核心原理是通过action触发state的变化,进而触发state的衍生对象(computed value & Reactions)。
State在Mobx中,State就对应业务的最原始状态,通过observable方法,可以使这些状态变得可观察。
通常支持被observable的类型有三个,分别是Object, Array, Map;对于原始类型,可以使用Obserable.box。
值得注意的一点是,当某一数据被observable包装后,他返回的其实是被observable包装后的类型。
const Mobx = require("mobx"); const { observable, autorun } = Mobx; const obArray = observable([1, 2, 3]); console.log("ob is Array:", Array.isArray(obArray)); console.log("ob:", obArray);
控制台输出为:
ob is Array: false ob: ObservableArray {}
对于该问题,解决方法也很简单,可以通过Mobx原始提供的observable.toJS()转换成JS再判断,或者直接使用Mobx原生提供的APIisObservableArray进行判断。
computedMobx中state的设计原则和redux有一点是相同的,那就是尽可能保证state足够小,足够原子。这样设计的原则不言而喻,无论是维护性还是性能。那么对于依赖state的数据而衍生出的数据,可以使用computed。
简而言之,你有一个值,该值的结果依赖于state,并且该值也需要被obserable,那么就使用computed。
通常应该尽可能的使用计算属性,并且由于其函数式的特点,可以最大化优化性能。如果计算属性依赖的state没改变,或者该计算值没有被其他计算值或响应(reaction)使用,computed便不会运行。在这种情况下,computed处于暂停状态,此时若该计算属性不再被observable。那么其便会被Mobx垃圾回收。
简单介绍computed的一个使用场景
假如你观察了一个数组,你想根据数组的长度变化作出反应,在不使用computed时代码是这样的
const Mobx = require("mobx"); const { observable, autorun, computed } = Mobx; var numbers = observable([1, 2, 3]); autorun(() => console.log(numbers.length)); // 输出 "3" numbers.push(4); // 输出 "4" numbers[0] = 0; // 输出 "4"
最后一行其实只是改了数组中的一个值,但是也触发了autorun的执行。此时如果用computed便会解决该问题。
const Mobx = require("mobx"); const { observable, autorun, computed } = Mobx; var numbers = observable([1, 2, 3]); var sum = computed(() => numbers.length); autorun(() => console.log(sum.get())); // 输出 "3" numbers.push(4); // 输出 "4" numbers[0] = 1;autorun
另一个响应state的api便是autorun。和computed类似,每当依赖的值改变时,其都会改变。不同的是,autorun没有了computed的优化(当然,依赖值未改变的情况下也不会重新运行,但不会被自动回收)。因此在使用场景来说,autorun通常用来执行一些有副作用的。例如打印日志,更新UI等等。
action在redux中,唯一可以更改state的途径便是dispatch一个action。这种约束性带来的一个好处是可维护性。整个state只要改变必定是通过action触发的,对此只要找到reducer中对应的action便能找到影响数据改变的原因。强约束性是好的,但是Redux要达到约束性的目的,似乎要写许多样板代码,虽说有许多库都在解决该问题,然而Mobx从根本上来说会更加优雅。
首先Mobx并不强制所有state的改变必须通过action来改变,这主要适用于一些较小的项目。对于较大型的,需要多人合作的项目来说,可以使用Mobx提供的api configure来强制。
Mobx.configure({enforceActions: true})
其原理也很简单
function configure(options){ if (options.enforceActions !== undefined) { globalState.enforceActions = !!options.enforceActions globalState.allowStateChanges = !options.enforceActions } }
通过改变全局的strictMode以及allowStateChanges属性的方式来实现强制使用action。
Mobx异步处理和Redux不同的是,Mobx在异步处理上并不复杂,不需要引入额外的类似redux-thunk、redux-saga这样的库。
唯一需要注意的是,在严格模式下,对于异步action里的回调,若该回调也要修改observable的值,那么
该回调也需要绑定action。
const Mobx = require("mobx"); Mobx.configure({ enforceActions: true }); const { observable, autorun, computed, extendObservable, action } = Mobx; class Store { @observable a = 123; @action changeA() { this.a = 0; setTimeout(this.changeB, 1000); } @action.bound changeB() { this.a = 1000; } } var s = new Store(); autorun(() => console.log(s.a)); s.changeA();
这里用了action.bound语法糖,目的是为了解决javascript作用域问题。
另外一种更简单的写法是直接包装action
const Mobx = require("mobx"); Mobx.configure({ enforceActions: true }); const { observable, autorun, computed, extendObservable, action } = Mobx; class Store { @observable a = 123; @action changeA() { this.a = 0; setTimeout(action("changeB",()=>{ this.a = 1000; }), 1000); } } var s = new Store(); autorun(() => console.log(s.a)); s.changeA();
如果不想到处写action,可以使用Mobx提供的工具函数runInAction来简化操作。
... @action changeA() { this.a = 0; setTimeout( runInAction(() => { this.a = 1000; }), 1000 ); }
通过该工具函数,可以将所有对observable值的操作放在一个回调里,而不是命名各种各样的action。
最后,Mobx提供的一个工具函数,其原理redux-saga,使用ES6的generator来实现异步操作,可以彻底摆脱action的干扰。
@asyncAction changeA() { this.a = 0; const data = yield Promise.resolve(1) this.a = data; }Mobx原理分析 autorun
Mobx的核心就是通过observable观察某一个变量,当该变量产生变化时,对应的autorun内的回调函数就会发生变化。
const Mobx = require("mobx"); const { observable, autorun } = Mobx; const ob = observable({ a: 1, b: 1 }); autorun(() => { console.log("ob.b:", ob.b); }); ob.b = 2;
执行该代码会发现,log了两遍ob.b的值。其实从这个就能猜到,Mobx是通过代理变量的getter和setter来实现的变量更新功能。首先先代理变量的getter函数,然后通过预执行一遍autorun中回调,从而触发getter函数,来实现观察值的收集,依次来代理setter。之后只要setter触发便执行收集好的回调就ok了。
具体源码如下:
function autorun(view, opts){ reaction = new Reaction(name, function () { this.track(reactionRunner); }, opts.onError); function reactionRunner() { view(reaction); } }
autorun的核心就是这一段,这里view就是autorun里的回调函数。具体到track函数,比较关键到代码是:
Reaction.prototype.track = function (fn) { var result = trackDerivedFunction(this, fn, undefined); }
trackDerivedFunction函数中会执行autorun里的回调函数,紧接着会触发obserable中代理的函数:
function generateObservablePropConfig(propName) { return (observablePropertyConfigs[propName] || (observablePropertyConfigs[propName] = { configurable: true, enumerable: true, get: function () { return this.$mobx.read(this, propName); }, set: function (v) { this.$mobx.write(this, propName, v); } })); }
在get中会将回调与其绑定,之后更改了obserable中的值时,都会触发这里的set,然后随即触发绑定的函数。
Mobx的一些坑通过autorun的实现原理可以发现,会出现很多我们想象中应该触发,但是没有触发的场景,例如:
1. 无法收集新增的属性
const Mobx = require("mobx"); const { observable, autorun } = Mobx; let ob = observable({ a: 1, b: 1 }); autorun(() => { if(ob.c){ console.log("ob.c:", ob.c); } }); ob.c = 1
对于该问题,可以通过extendObservable(target, props)方法来实现。
const Mobx = require("mobx"); const { observable, autorun, computed, extendObservable } = Mobx; var numbers = observable({ a: 1, b: 2 }); extendObservable(numbers, { c: 1 }); autorun(() => console.log(numbers.c)); numbers.c = 3; // 1 // 3
extendObservable该API会可以为对象新增加observal属性。
当然,如果你对变量的entry增删非常关心,应该使用Map数据结构而不是Object。
2. 回调函数若依赖外部环境,则无法进行收集
const Mobx = require("mobx"); const { observable, autorun } = Mobx; let ob = observable({ a: 1, b: 1 }); let x = 0; autorun(() => { if(x == 1){ console.log("ob.c:", ob.b); } }); x = 1; ob.b = 2;
很好理解,autorun的回调函数在预执行的时候无法到达ob.b那一行代码,所以收集不到。
参考链接:
1. https://www.zhihu.com/question/52219898
2. http://taobaofed.org/blog/2016/08/18/react-redux-connect
3. https://Mobx.js.org/index.html
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/93486.html
摘要:我现在写的这些是为了解决和这两个状态管理库之间的困惑。这甚至是危险的,因为这部分人将无法体验和这些库所要解决的问题。这肯定是要第一时间解决的问题。函数式编程是不断上升的范式,但对于大部分开发者来说是新奇的。规模持续增长的应 原文地址:Redux or MobX: An attempt to dissolve the Confusion 原文作者:rwieruch 我在去年大量的使用...
摘要:通过装饰器或者利用时调用的函数来进行使用下面代码中当或者发生变化时,会监听数据变化确保通过触发方法自动更新。只能影响正在运行的函数,而无法影响当前函数调用的异步操作参考官方文档用法装饰器函数遵循中标准的绑定规则。 前言: 本文基于React+TypeScript+Mobx+AntDesignMobile技术栈,使用Create-React-App脚手架进行一个移动端项目搭建,主要介绍项...
摘要:用于简单可扩展的状态管理,相比有更高的灵活性,文档参考中文文档,本文作为入门,介绍一个简单的项目。任务已完成下一个任务修复谷歌浏览器页面显示问题提交意见反馈代码创建在中引入主入口文件设置参考入门学习总结 MobX用于简单、可扩展的React状态管理,相比Redux有更高的灵活性,文档参考:MobX中文文档,本文作为入门,介绍一个简单的TodoList项目。 1. 预期效果 showIm...
摘要:三性能优化处理做工具类的项目,性能是非常大的挑战,我总结了以下几个常见的性能优化点数据缓存。防抖,节流,事件委托内存释放。 内容大纲: 1、功能介绍 2、技术架构 3、性能优化 4、细节分享 5、开源说明 一、项目功能介绍 很久没写过技术类的文章了,这次给大家分享一个近期的项目,采用react+mobx+jquery构建的大型工具类项目。查看项目网址。 如果用过易企秀,maka或者...
阅读 2718·2021-11-16 11:45
阅读 1583·2021-09-26 10:19
阅读 1992·2021-09-13 10:28
阅读 2765·2021-09-08 10:46
阅读 1506·2021-09-07 10:13
阅读 1490·2019-08-30 13:50
阅读 1358·2019-08-30 11:17
阅读 1414·2019-08-29 13:18