redux 和 mobx 调研结果- mobx

调研方向

  • 设计思想/基本用法/生态环境/性能优化
  • 总结

设计思想

mobx 的设计思想我总结之后,主要有以下两点:

  1. 函数响应式编程;
  2. 任何源自应用状态的东西都应该自动地获得;

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 函数以确保任何组件渲染中使用的数据变化时都可以强制刷新组件;

  1. 使用 @inject 给组件注入其需要的store,放置于 props 上;

  2. 观察并使用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 "分而治之",当组件变多,应用变复杂时,团队协作会变困难,状态管路容易出现问题,代码难以维护;
原文地址:https://www.cnblogs.com/xiaonian8/p/13749713.html