使用mobx和mobx-react代替redux和react-redux-CSDN博客

一：主要介绍一下mobx-react

mobx-react的优点：

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

1、安装，这里有两个包需要安装，mobx 和 mobx-react

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

或者

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

注意如果要兼容IE必须使用5.x.x或者之前的版本

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

引入mobx

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

export default mainStore;
复制代码

3、在任意组件里加入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 就行，增强组件复用性。