调研方向
- 设计思想/基本用法/生态环境/性能优化
- 总结
设计思想
mobx 的设计思想我总结之后,主要有以下两点:
- 函数响应式编程;
- 任何源自应用状态的东西都应该自动地获得;
mobx 不同于 redux 的单一数据源的统一管理,它可以有多个 store, 为了便于维护 ,每一个 store 都是一个类,这样便于维护和扩展;
同时,为了使数据可以自动更新,使用了响应式编程(异步数据流), 它使用了观察者模式和 装饰器模式,将 state 包裹成observable; 当state 有改变时(自己改变或是 action 触发), 就会相应的去更新由这个state 推导出来的 computed value 以及 reaction;(数据的更新主要由装饰器模式中的对类的修改 );
它的工作流大致是这样子:
基本用法
mobx 与redux 一样也是单向数据流,核心概念是 state,computed value,reaction,action 等。它们的大概功能为:
-
state: 包裹为 observable 的 的数据;
-
computed values: 从当前 state 中计算出的值,类似与 vue 中的computed;
-
reactions: 是当 state 改变时需要自动发生的副作用。比如打印到控制台、网络请求、递增地更新 React 组件树以修补 DOM 等等;不会产生值,常见 api 有 autorun, reaction, observe (针对性观察新旧值)等;
-
action: 是一段可以改变状态的代码。用户事件、后端数据推送、预定事件、等等。通常使用 action 统一对 state 修改,而不是对自身修改;
这样听可能有一点抽象, 以表格为例:在电子表格中,有值的单元格都是 observable state;公式和图标是可从数据单元格和其他公式推导出的computed value;在屏幕上绘制数据单元格、公式的输出结果就是一个 reactions;对数据单元格或公式的修改就是一次action;
这里用一个栗子介绍:
class Person {
// 定义状态
[@observable](https://my.oschina.net/u/2298977) firstName = "huang";
[@observable](https://my.oschina.net/u/2298977) lastName = "yuan";
[@observable](https://my.oschina.net/u/2298977) nickName;
@computed get fullName() {
return this.firstName + " " + this.lastName;
}
@action.bound
increment() {
this.firstName = "zhang";
}
}
decorate{
}
const coolGirl = new Person();
// reactions:打印日志
autorun(() => {
console.log(
person.nickName ? person.nickName : person.fullName
)
});
const ProfileView = observer(props => {
if (props.person.nickName)
return <div>{props.person.nickName}</div>
else
return <div>{props.person.fullName}</div>
});
// action
setTimeout(() => coolGirl.nickName = "yuanzhendashi", 5000);
setIimeout(coolGirl.increment, 1000);
React.render(<ProfileView person={coolGirl} />), document.body);
这是一个很简单的栗子,展示了mobx 的基本使用,主要分为这几个步骤;
- 定义 state;将 Person 的 firstName,lastName,nickName observable 化;
- 注册 computed value: 通过现有的 observable 变化时可以得到 fullName;
- 注册反应 reactions: autorun; 在初始化时和 nickName 发生变化时,会打印日志;
- 在触发 action 的时刻, 修改了firstName;
这是一个最简单的例子,展示了 Mobx 主要的代码组成:定义状态 -> 注册反应 -> 修改状态 -> 执行反应。
生态环境
主要跟大家说说,在与现有的技术栈或应用结合时,Mobx 生态有哪些最佳实践和优质的库。
- 装饰器语法支持:create-react-app 目前还没有内置的装饰器支持。要解决这个问题,要使用 eject 命令;推荐使用mobx 内置的工具 decorate 来对类和对象进行装饰,而这个不需要启用装饰器语法;
- 与react 结合使用:可引入 mobx-react,自动绑定并更新 React 视图模板。
- 状态管理: 可引入 mobx-state-tree,同时具备 immutable 数据的各种管理优势。
与react 结合使用扩展
当与 React 结合时,使用了mobox-react 库来处理 state 变化和view 更新的绑定在用法上,主要分为四个步骤:
1、 使用Provide组件用来包裹最外层组件节点,传入 store 通过 context 传递给后代组件;
2 . 通过 @observer 将 React 组件转化成响应式组件;mobx 用 autorun 包装了组件的 render 函数以确保任何组件渲染中使用的数据变化时都可以强制刷新组件;
-
使用 @inject 给组件注入其需要的store,放置于 props 上;
-
观察并使用store 中的observable 数据
如下面代码
// 以 context 的形式传入store
import { Provider } from 'mobx-react'
<Provider store={coolGirl}>
<ProfileView/>
</Provider>
// 使用状态
import * as React from 'react'
import { inject, observer } from 'mobx-react'
@inject('store') // 如果是以 context 传入的必须要 @inject,否则不需要。
@observer
**export de**fault class ProfileView extends React.Component {
render () {
return ( <div> 我的姓名:{this.props.store.fullName} </div> )
}
}
可以看出,使用起来非常简便;
性能优化
-
尽可能多地使用小组件;@observer 组件会追踪 render 方法中所有的可观测的值,当任何一个值变化的时候,都会重新渲染,所以组件越小,重新渲染的变化就越小。
-
在专用的组件中渲染列表;
-
晚一点使用间接引用值;使用 mobx-react 时,推荐尽可能晚的使用间接引用值。 这是因为当使用 observable 间接引用值时 MobX 会自动重新渲染组件。 如果间接引用值发生在组件树的层级越深,那么需要重新渲染的组件就越少;
快的: <DisplayName person={person} /> 慢的: <DisplayName name={person.name} />
-
对于autorun 和reaction,每次变化的准备时间和结束时间为0.5 ~ 1ms。所以,可能不适合跟踪频繁变化的状态;
-
减少渲染次数: 使用 action 触发状态更新;
发展趋势
内存/mobx-state-tree
总结
综上,使用mobx-react , 会有这些优缺点:
- 优点:上手简单, 代码量少,响应快速,生态环境不错,正在茁壮成长;
- 缺点: 由于store "分而治之",当组件变多,应用变复杂时,团队协作会变困难,状态管路容易出现问题,代码难以维护;
来源:oschina
链接:https://my.oschina.net/hyzccc/blog/3198062