阿城的日志
Qiutc's blog高效的 Mobx
前言
由于最近开启一个新的个人小项目,准备还是使用 React 及其生态来实现整个技术架构,之前一直使用的是 React + React-Router + Redux 组合,虽然说使用 Redux 来管理整个应用的数据流有着优点,但是 Redux 的写法繁琐也确实让人诟病,当然这里并不是说 Redux 不好。基于项目本身并不大,决定寻找一个新的解决方案,而 Mobx 在之前就有所耳闻(只是一直没有时间和需求去深入了解),借着这次机会正好可以好好学习下 Mobx 的理念。
本文中强烈建议使用 ES6 的语法并且本文也只用 ES6 语法来举例实现。
开始使用
START!!!🏃
首先第一步当然是引入 Mobx,这里很简单,两种方式:
- 使用 npm 安装然后引入:
|
|
- 使用 script 标签引入:
|
在 Mobx 的使用中,使用 ES6 语法的 修饰器(Decorator) 将可以极大的简化组织代码,当然,如果使用 ES5 的语法也未尝不可,但是我这里还是强烈建议大家使用 修饰器,并且本文中的所有例子也都基于修饰器来说明。
对于 ES6 中的修饰器这里简要说明一下,修饰器其实是对与一种函数形式的语法糖,通过以下例子可以一目了然其行为作用:
|
配置 ES6 以及 修饰器 ,最方便的当然是使用 babel 来编译 ES6 代码了,在 .babelrc 中配置:
|
这里使用了 ES6 中 stage-1 提案标准,然后加入 transform-decorators-legacy 来支持修饰器。
核心概念
数据流
在一个数据管理框架&库中,其最重要的就是它的数据管理模式了,也就是其数据流。对于 Mobx 来说,它的数据流简明清晰,并且也是单向数据流,如下图所示。
图片来源:cn.mobx.js.org/
它由几个部分组成:Actions、State、Computed Values、Reactions
在整个数据流中,通过事件驱动(UI 事件、网络请求…)触发 Actions,在 Actions 中修改了 State 中的值,这里的 State 既应用中的 store 树(存储数据),然后根据新的 State 中的数据计算出所需要的计算属性(computed values)值,最后响应(react)到 UI 视图层。
当然,如此说明仍然是过于抽象,接下来就进入实际例子分析。
例子
|
运行这个例子,将可以看到控制台打印出来的数据,我们通过下面几个部分来分析代码。
可观察状态(State)
在上面的例子中,定义了一个 Store 类作为数据存储,通过 @observable
修饰器可以将其中的属性转变为可观察的状态值,其语法为:
|
@observable
接受任何类型的 js 值(原始类型、引用、纯对象、类实例、数组和、maps),observable 的属性值在其变化的时候 mobx 会自动追踪并作出响应。
当 value 是一个对象类型值的时候,它会默认克隆该对象并且把其中每个属性变为可观察的值,这里默认是深拷贝,也就是说其对象的后代属性都会变成可观察的,比如 @observable classProperty = { obj: { name: 'q' } }
,当 classProperty.obj.name
改变的时候,在 Mobx 中也是可以观察到并响应的;
当然在这里可以加一些调节器来做一些配置:
- @observable.deep (默认)对对象进行深拷贝;
- @observable.shallow 它只对对象进行浅拷贝;
- @observable.ref 禁用对象的自动转化,只转化其引用;
这里需要注意的是,当定义好其 observable 的对象值后,对象中后来添加的值是不会变为可观察的,这时需要使用 extendObservable 来扩展对象:
|
计算属性值(Computed Values)
计算属性值实际上是一类衍生值,它是根据现有的状态或者其他值计算而来,原则上在计算属性中尽可能地不对当前状态做任何修改;
同时对于任何可以通过现有状态数据得到的值都应该通过计算属性获取。
语法为:@computed get computesValue [function]
;
如上面的例子中,只需要获取其 list 属性的总数 total 的时候,我们可以根据其 list 来计算出 total,
|
同时,当状态改变使得计算属性的值发生改变的时候,其也是可观察到的。
在 store 对象中,还可以定义 state 属性的 setter:
|
在每次改变 Store.squared 的时候,会先运行 set squared
函数,从而改变 Store 中的 state。
动作(Action)
在 Mobx 中,对于 store 对象中可观察的属性值,在他们改变的时候则会触发观察监听的函数,这里注意两点:
- 该属性必须是定义的可观察属性(@observable)
- 它的值必须发生改变(和原值是不等的):
|
在 Mobx 中,其本身并不会对开发者作出任何限制去如何改变可观察对象;
但是,它还是提供了一个可选的方案来组织代码与数据流,@action
,其规定对于 store 对象中所有可观察状态属性的改变都应该在 @action
中完成,它使代码可以组织的更好,并且对于数据改变的时机也更加清晰。
语法形式:@action actionFuncName[function]
|
可以看到,这里将 store 中 list 属性的改变都放在 @action change
函数之中,外加只需要调用该函数即可。
运行观察(autorun)
在上面的例子中,当触发了可观察状态属性的改变后,其变化的监听则是在传入 autorun 函数中作出响应。
autorun 接受一个函数作为参数,在使用 autorun 的时候,该函数会被立即调用一次,之后当该函数中依赖的可观察状态属性(或者计算属性)发生变化的时候,该函数会被调用,注意,该函数的调用取决的函数中使用了哪些可观察状态属性(或者计算属性)。
例子 1:
|
在该例子中,autorun 的函数依赖了 mstore.count 属性,该属性是可观察的,其每次变化都会加 1 ,因此其中的函数在第一次立即触发,之后每次改变 mstore.count 的值都会被触发;
例子 2:
|
该例子中和 例子1 是类似的,auto 中的函数依赖了计算属性 mstore.result ,其每次变化的时候也都会触发该函数;
例子 3:
|
在该例子中,只在使用 autorun 的时候触发了一次其传入的函数,之后即使调用 mstore.add() 也并未观察到,这是因为之后的调用中 mstore.result 并没有改变,所以不会触发观察;
例子 4:
|
在该例子中也只是在使用 autorun 的时候调用了一次其传入的函数,之后 mstore.count 的值即使改变也并没有触发观察,这是因为 mstore.count 并不是可观察的。
在实际使用中,autorun 中的函数就是用来操作 Reactions 的,当可观察状态属性的值发生改变的时候,可以在该函数中利用状态值来更新改变 UI 视图(记录日志、持久化),在 Mobx 结合 React 的使用中,mobx-react 库则是封装了 autorun 用来在 store 中的可观察状态属性值发生改变的时候 rerender React 组件。
异步行为
在很多时候,比如网络请求 ,其 Actions 行为是异步的,这里通过以下一个例子说明如何编写异步的 Action:
|
在 React 中使用 Mobx
在 React 中使用 Mobx 需要用到 mobx-react。其提供了 Provider 组件用来包裹最外层组件节点,并且传入 store(通过)context 传递给后代组件:
|
使用 @inject
给组件注入其需要的 store(利用 React context 机制);
通过 @observer
将 React 组件转化成响应式组件,它用 mobx.autorun 包装了组件的 render 函数以确保任何组件渲染中使用的数据变化时都可以强制刷新组件:
|
TIP
useStrict
在 mobx 中,可以有很多种方式去修改 state,mobx 并不对其做限制;但是如果使用了严格模式:
|
那么将会限制开发者只能通过 @action 来修改 state,这将会更有利于组织代码以及使数据流更清晰。
参考
转载请注明来源:qiutc.me/post/effici…
留言
正在加载验证码......