使用mobx和mobx-react代替redux和react-redux

一：主要介绍一下mobx-react

mobx-react的优势：

用mobx和mobx-react代替redux和react-redux已经时大势所趋，既解决越写越零散的reducer，又解决了跨组件引入状态管理的问题。
复制代码

一、安装，这里有两个包须要安装，mobx 和 mobx-react

npm i mobx mobx-react --s-d   
复制代码

或者

npm install mobx-react --save
复制代码

注意若是要兼容IE必须使用5.x.x或者以前的版本

二、建立mobx主文件(例子建立的目录是mobx/index.js)

引入mobx

class mainStore{
       @observable firstState = 0;
       @action onClick=()=>{
         console.log('触发了action')
     }
}

export default mainStore;
复制代码

三、在任意组件里加入mobx-react并使用

import React from 'react';
import { inject , observer } from 'mobx-react';

@inject('store')
@observer
class test extends React.Component {
    constructor(props){
        super(props);
        console.log(this.props.store.loginState);
        this.props.store.onClick('login')
    }
}
复制代码

二：从三个方面比较mobx-react 与 redux_react

主要比较参数：

库体积，打包项目体积

开发体验

性能对比
复制代码

(1)库体积，打包项目体积

redux比mobx打包体积略大，几乎能够忽略不记，可是lib包比mobx小20k，因此这轮redux胜

(2)开发体验

开发效率：因为mobx是双向绑定的，开发的时候你会以为mobx写的都是有效代码；redux写同一个功能会多写不少代码，代码逻辑绕啊绕。

代码质量：redux直接写，不作react渲染优化是个大坑，可是react渲染优化又比较繁琐，可能还要添加第三方插件，增长没必要要的代码量。mobx基本不作渲染优化，渲染更新，是否更新的生命周期都被禁用了，还优化个屁。

综上 开发体验上mobx比redux领先太多。

(3)性能对比

性能对比 这次比较是redux项目已经优化，mobx项目未优化的状况下进行的，mobx项目优化后会补坑

Mbox

Mobx专一于解决数据级别的响应，它不关系数据的来源方式，只要一个对象中的属性、一个基本类型变量发生了变化，对这些数据的订阅就会自动执行。使用Mobx管理状态时，当咱们更新观察对象的状态后，由观察对象的改变带来的界面重渲染、数据序列化等一系列反作用，Mobx会自动帮咱们完成。

Mobx的主要概念

Actions: 改变state的操做。

ObservableState:应用的可被观察的数据状态。

Computed: 从state中经过纯函数的操做衍生出的值，state变化它也会跟着变化。

Reactions：须要对state变化动态做出反应的东西，它包含不一样的概念，基于被观察数据的更新致使某个计算值，或者是发送网络请求以及更新视图等，都属于响应的范畴，这也是响应式编程在 JavaScript 中的一个应用。

Autorun: 依赖收集，监听触发，autorun 背后由 reaction 实现。因为 autorun 与 view 的 render 函数很像，咱们在 render 函数初始化执行时，使其包裹在 autorun 环境中，第 2 次 render 开始遍剥离外层的 autorun，保证只绑定一遍数据。这样 view 层在本来 props 更新机制的基础上，增长了 autorun 的功能，实现修改任何数据自动更新对应 view 的效果。（ps:使用autoRun实现Mobx-react很是简单，核心思想是将组件外面包上autoRun，这样代码中用到的全部属性都会像上面Demo同样，与当前组件绑定，一旦任何值发生了修改，就直接forceUpdate，并且精确命中，效率最高。）

Mobx流程

(三)Mobx的优缺点

优势：

1.使用起来十分顺手，下降开发难度。十分“智能”，当咱们更新观察对象的状态后，由观察对象的改变带来的界面重渲染、数据序列化等一系列反作用，Mobx会自动帮咱们完成。

2.面向对象的使用方法，较为符合咱们平时开发的逻辑。

缺点：

1.无反作用隔离，非严格模式下能够对observable直接修改，这样容易形成 store 被随意修改。在项目规模比较大的时候，像 Vuex 和 Redux 同样对修改数据的入口进行限制能够提升安全性。所以若是不规范Mobx使用的话将会致使数据流变化混乱问题。

2.在收集依赖时，Mobx会把autorun执行一遍来触发里面observable的getter从而收集依赖。可是万一你写出了如下的代码，Mobx是收集不到你想要收集的依赖的

3.observable跟普通的plainObject傻傻分不清楚，observable跟plainObject外貌上一摸同样，有时可能会误会了observable的本质

(四)Mobx与Redux的区别

1.从数据管理模式的差异上看，Mobx是基于双向绑定的响应式的实现，而redux是基于flux的单向数据流的实现。

2.从开发上来看是和面向对象和函数式编程的区别。可是前端开发须要常常与反作用打交道，因此前端开发很难与完美的函数式编程相结合。

3.redux的state是只读的，产生新的state的过程是pure的；Mobx的state可读可写，而且action并非必须的，能够直接赋值改变，这也看出了Mobx改变数据的impure。

4.在可预测性、可维护性上看，redux得益于它的清晰的单向数据流和纯函数的实现，在这方面优于Mobx。

5.redux是单一数据源；而Mobx是多个store。

6.redux中的store是普通的js对象结构，而Mobx中的会对其进行observable化，从而实现响应式。

7.从代码量上看，Mobx能少写不少代码，而redux要经过action,reducer等等的编写才能实现整个流程。

（五）Redux

Redux 是 JavaScript 状态容器，提供可预测化的状态管理.核心概念就是初始状态经过reduce接收只是一个接收 state 和 action，并返回新的 state，所得的就是当前状态。

Redux三大原则

单一数据源 整个应用的 state 被储存在一棵 object tree 中，而且这个 object tree 只存在于惟一一个 store 中。

State 是只读的 惟一改变 state 的方法就是触发 action，action 是一个用于描述已发生事件的普通对象。

使用纯函数来执行修改 为了描述 action 如何改变 state tree ，你须要编写 reducers。Reducer 只是一些纯函数，它接收先前的 state 和 action，并返回新的 state。并不作其余操做（修改传入的参数；执行有反作用的操做；调用非纯函数）。

redux各个组成部分

Action

Action 是把数据从应用传到 store 的有效载荷,它是 store 数据的惟一来源。通常来讲你会经过 store.dispatch() 将 action 传到 store。

注意：“action” 和 “action 建立函数” 这两个概念很容易混在一块儿，使用时最好注意区分。Action 建立函数 就是生成 action 的方法
复制代码

Reducer

actions 只是描述了有事情发生了这一事实，并无描述应用如何更新 state。而Reducer就是一个纯函数，接收旧的 state 和 action，返回新的 state。 如今只须要谨记 reducer 必定要保持纯净。只要传入参数相同，返回计算获得的下一个 state 就必定相同。没有特殊状况、没有反作用，没有 API 请求、没有变量修改，单纯执行计算。

Store

Redux 应用只有一个单一的 store，Store是把action和reducer联系到一块儿到对象Store 有如下职责：

1.维持应用的 state； 2.提供 getState() 方法获取 state； 3.提供 dispatch(action) 方法更新 state； 4.经过 subscribe(listener) 注册监听器; 5.经过 subscribe(listener) 返回的函数注销监听器

Redux流程

react+redux流程

Redux优缺点

优势 1.纯函数的开发模式，无反作用。 2.单向数据流流动天然清晰，任何的dispatch都会通知到reducer来处理，加强更新粒度可控性。 3.利用中间件的模式来解决异步带来的反作用问题。 4.可时间回溯。为了解决阻碍回溯的“对象引用”机制，将 immutable应用到了前端。这下全部状态都不会被修改，基于此的redux-dev-tools提升了开发体验 缺点：

1.代码书写啰嗦，形成代码冗余

扩展

Redux处理异步的中间件

Redux针对异步数据流的状况，也设计出中间件这个概念来隔离异步所带来的反作用。它的主要目的就是控制异步dispatch，分离反作用。

接下来讲说最具表明性的两个异步中间件：redux-thunk 和 redux-saga。

redux-thunk

redux-thunk 的任务执行方式是从 UI 组件直接触发任务,redux-thunk 的主要思想是扩展 action，使得 action 从一个对象变成一个函数。

redux-saga sages 采用 Generator 函数来 yield Effects（包含指令的文本对象）。Generator 函数的做用是能够暂停执行，再次执行的时候从上次暂停的地方继续执行.在 redux-saga 中，UI 组件自身历来不会触发任务，它们老是会 dispatch 一个 action 来通知在 UI 中哪些地方发生了改变，而不须要对 action 进行修改

redux-thunk 的缺点：

（1）action 虽然扩展了，但所以变得复杂，后期可维护性下降； （2）thunks 内部测试逻辑比较困难，须要mock全部的触发函数； （3）协调并发任务比较困难，当本身的 action 调用了别人的 action，别人的 action 发生改动，则须要本身主动修改； （4）业务逻辑会散布在不一样的地方：启动的模块，组件以及thunks内部。 redux-saga 的优势： （1）声明式 Effects：全部的操做以JavaScript对象的方式被 yield，并被 middleware 执行。使得在 saga 内部测试变得更加容易，能够经过简单地遍历 Generator 并在 yield 后的成功值上面作一个 deepEqual 测试。 （2）高级的异步控制流以及并发管理：可使用简单的同步方式描述异步流，并经过 fork 实现并发任务。 （3）架构上的优点：将全部的异步流程控制都移入到了 sagas，UI 组件不用执行业务逻辑，只需 dispatch action 就行，加强组件复用性。

总结

优化事后的redux项目性能比较好，mobx暂时还没想到特别好的优化方案，找到了会补坑；框架体验，开发效率，学习成本方面mobx更好，但愿优化事后的mobx性能有所提高；代码打包体积redux确实要小点，可是若是项目比较庞大，redux开发代码会比mobx多很多，体积这方面基本能够忽略。