MobX or Redux?

前言

在过去的项目中一直用的都是Redux，以为挺不错的，按照官方推荐的一些写法，再加上团队风格，打造了一套关于Redux的架构，可是，如今以为写Action、Reducer太繁琐，随着业务不断的增量，相应的文件和代码也会不断的增长，并且对新人来讲不是很是友好(理解Redux比较困难)，据说一方诸侯MobX很是不错，因此在尝试使用了，目前项目中两套架构都是并存，写下本身的一些感想。

都解决什么问题？

一、组件之间复用状态很是困难

React自己没有提供将可复用性状态“附加”到组件的途径（例如，把组件链接到 store）。若是你使用过 React 一段时间，你也许会熟悉一些解决此类问题的方案，好比 props 和 HOC。可是这类方案须要从新组织你的组件结构，这可能会很麻烦，使你的代码难以理解。写下这片博客的时候，React已提供Hook，可是本人以为这都是些hack方案。

二、复杂组件变得难以理解

咱们常常维护一些组件，组件起初很简单，可是逐渐会被状态逻辑和反作用充斥。每一个生命周期经常包含一些不相关的逻辑。例如，组件经常在 componentDidMount 和 componentDidUpdate 中获取数据。可是，同一个 componentDidMount 中可能也包含不少其它的逻辑，如设置事件监听，而以后需在 componentWillUnmount 中清除。相互关联且须要对照修改的代码被进行了拆分，而彻底不相关的代码却在同一个方法中组合在一块儿。如此很容易产生 bug，而且致使逻辑不一致。

在多数状况下，不可能将组件拆分为更小的粒度，由于状态逻辑无处不在。

Redux

Redux由Flux演变而来，但受 Elm 的启发，避开了 Flux 的复杂性。它主要有如下三个核心概念：

一、Actions

一个JavaScript对象，描述发生的动做，主要包含type和payload两个属性。 payload能够是普通的数据或是函数。

const GET_LIST = 'getList';
return {
        type: GET_LIST,
        payload: api.getList(params)
};
复制代码

二、Reducer

定义应用状态如何响应不一样动做（action），如何更新状态；

switch (action.type) {
  case GET_LIST:
  	return Object.assign({}, state, { list: action.payload.result });
  default:
        retur state;
}
复制代码

三、Store

const initialState = {
    orderListData: {}
};
复制代码

存储组件的数据，主要提供如下功能：

3.1.维护应用状态并支持访问状态(getState())；

3.2.支持监听action的分发，更新状态(dispatch(action))；

3.3.支持订阅store的变动(subscribe(listener));

四、异步流

因为Redux全部对store状态的变动，都应该经过action触发，异步任务（一般都是业务或获取数据任务）也不例外，而为了避免将业务或数据相关的任务混入React组件中，就须要使用其余框架配合管理异步任务流程，如redux-thunk、redux-saga、redux-promise。

五、数据流向

MobX

MobX 是一个通过战火洗礼的库，它经过透明的函数响应式编程(transparently applying functional reactive programming - TFRP)使得状态管理变得简单和可扩展。其中核心概念也很是简单，主要有如下几个：

一、Store

使用 observable 很像把对象的属性变成excel的单元格。 但和单元格不一样的是，这些值不仅是原始值，还能够是引用值，好比对象和数组。

import { observable } from "mobx";

class Todo {
    @observable title = '';
}
复制代码

二、Computed values

当添加了一个新的todo或者某个todo的 finished 属性发生变化时，MobX 会确保 unfinishedTodoCount 自动更新。 像这样的计算能够相似于 MS Excel 这样电子表格程序中的公式。每当只有在须要它们的时候，它们才会自动更新。

class TodoList {
    @observable todos = [];
    @computed get unfinishedTodoCount() {
        return this.todos.filter(todo => !todo.finished).length;
    }
}
复制代码

三、Reactions

Reactions和计算值很像，但它不是产生一个新的值，而是会产生一些反作用，好比打印到控制台、网络请求、递增地更新 React 组件树以修补DOM、等等。

autorun(() => {
    console.log("Tasks left: " + todos.unfinishedTodoCount)
})
复制代码

四、Actions

描述要发生的动做

class TodoList {
    @observable title = '';

    @action
    changeTitle() {
        this.title = 'test';
    }
}
复制代码

五、异步流

MobX不须要额外配置另外的库。

六、数据流向

Redux优势

一、流程规范，按照官方推荐的规范和结合团队风格打造一套属于本身的流程。

二、函数式编程，在reducer中，接受输入，而后输出，不会有反作用发生，幂等性。

三、可追踪性，很容易追踪产生BUG的缘由。

Redux缺点

一、流畅太繁琐，须要写各类action，reducer。

二、要想完成异步数据，得配合其余库。

MobX优势

一、学习成本少，基础知识很是简单，跟vue同样的核心原理，响应式编程。

二、写更少的代码，完成更多的事。不会跟Redux同样写很是多的样板代码。

三、使组件更加颗粒化拆分。

MobX缺点

一、过于自由，MobX提供的约定及模版代码不多，若是团队不作一些约定，容易致使团队代码风格不统一。

二、可拓展，可维护性，也许你会担忧Mobx能不能适应后期项目发展壮大呢？确实Mobx更适合用在中小型项目中，但这并不表示其不能支撑大型项目，关键在于大型项目一般须要特别注意可拓展性，可维护性，相比而言，规范的Redux更有优点，而Mobx更自由，须要咱们本身制定一些规则来确保项目后期拓展，维护难易程度；

架构案例

Redux脚手架

MobX脚手架

最后思考

对于Redux更规范，更靠谱，应该使用Redux或Redux模版太多，太复杂了，应该选择Mobx这类推断，咱们都应该避免，也应该要避免这些，这些都是相对而言，每一个框架和库都有各自的实现，特点，及其适用场景，正如Redux流程更复杂，但熟悉流程后就更能把握它的一些基础／核心理念，使用起来可能更有心得及感悟；而Mobx简单化，把大部分东西隐藏起来，若是不去特别研究就不能接触到它的核心／基本思想，也许使得开发者一直停留在使用层次。

因此不管是技术栈仍是框架类库，并无绝对的比较咱们就应该选择什么，抛弃什么，咱们应该更关注它们解决什么问题，它们解决问题的关注点，或者说实现方式是什么，它们的优缺点还有什么，哪个更适合当前项目，以及项目将来发展。

参考

一、你须要Mobx仍是Redux？

二、MobX

三、React

四、Redux