Mobx

标签：observable computed state Mobx action Redux

Mobx解决的问题

React的数据管理，除了redux之外，一个新的状态管理方案mobx
传统React使用的数据管理库为Redux。Redux要解决的问题是统一数据流，数据流完全可控并可追踪。要实现该目标，便需要进行相关的约束。Redux由此引出了dispatch action reducer等概念，对state的概念进行强约束。然而对于一些项目来说，太过强，便失去了灵活性。Mobx便是来填补此空缺的。

这里对Redux和Mobx进行简单的对比：

Redux的编程范式是函数式的而Mobx是面向对象的；
因此数据上来说Redux理想的是immutable的，每次都返回一个新的数据，而Mobx从始至终都是一份引用。因此Redux是支持数据回溯的；
然而和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进行判断。

computed

Mobx中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或者借助runInAction。

import { observable, autorun, configure, action, runInAction } from "mobx";
configure({
  enforceActions: "always"
})
class Store {
  @observable isTabbarShow = true;
  @observable list = [];
  @observable cityName = "北京";

  @action changeShow() {
    this.isTabbarShow = true;
  }
  @action changeHide() {
    this.isTabbarShow = false;
  }
  // 异步
  @action async getList() {
    const { data: { data: { cinemas } }} = await axios({
      method: "GET",
      url: "https://m.maizuo.com/gateway?cityId=420600&ticketFlag=1&k=6987442",
      headers: {
        "X-Client-Info": '{"a":"3000","ch":"1002","v":"5.2.1","e":"16666980064323683447341057","bc":"110100"}',
        "X-Host": "mall.film-ticket.cinema.list"
      }
    })
    console.log(cinemas);
    runInAction(()=> {
      this.list = cinemas;
    })
  }
  @action setList(list) {
    console.log("12321321", list)
    this.list = list
  }
}
const store = new Store()
export default store;

标签：observable,computed,state,Mobx,action,Redux
From： https://www.cnblogs.com/bingquan1/p/17012930.html