使用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多很多，體積這方面基本能夠忽略。