调研方向
- 设计思想/基本用法/生态环境/性能优化
- 总结
设计思想
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 触发状态更新；
vi设计http://www.maiqicn.com 办公资源网站大全https://www.wode007.com
发展趋势
内存/mobx-state-tree
总结
综上，使用mobx-react ， 会有这些优缺点：
- 优点：上手简单， 代码量少，响应快速，生态环境不错，正在茁壮成长；
- 缺点： 由于store "分而治之"，当组件变多，应用变复杂时，团队协作会变困难，状态管路容易出现问题，代码难以维护；