redux 和 mobX對比

• 如下內容會嚴格遵循下面三個觀點

  • 這部分的每個小塊都是爲了吹兩者之一
  • 要怎麼黑另一個才能更好的達到吹的效果
  • 要吹得有理有據，黑得不帶痕跡

• 爲何這兩個庫能夠被用來對比

  1. 目的一致

  都是狀態管理庫，用來管理應用的內部狀態

  2. 受衆大致一致

  通常都會被用到react中，雖說這並非必須的，你固然也能夠用到vue或者angular裏，可是，大多數狀況下，都不會這麼作

  3. 可相互替代

  在項目之初，你能夠選擇兩者之一來知足你的項目需求，可是到某一天你忽然以爲另外一個更和你氣味相投，你徹底能夠花點時間遷移過去，你會發現，它彷佛也能知足你的那些需求

1. 學習難度對比:

   • mobX的學習中，你能夠聽信關於30分鐘快速入門的神話，這畢竟不是對一個語言而言的《7天從入門到精通》系列，由於它真的很簡單，而且在這三十分鐘過去以後，你惟一須要花的時間就是偶爾翻翻文檔就能夠自如的使用它了。
   • redux的入門學習也沒那麼難，即便有些概念顯得比較抽象，你最多須要多花上半個小時就能夠掌握它們了，可是當你真的去使用的時候，你會發現這一切原來並不是想象的那麼簡單，你不得不花更多的時間來學習更多：

   當你須要異步的時候，你不得不考慮redux-thunk，你怎麼可能不須要異步 想用Promise，沒問題，先看看redux-promise-middleware怎麼樣 想搞個日誌之類的東西，redux-logger已經準備好了 當你須要使用state中的兩個值來計算出一個值的時候，你若是稍有代碼潔癖，你確定不肯意這樣作，這時候，你須要的東西叫作Reselect ...

   第一波黑的不錯，你有沒有望而卻步

2. 工做量對比（如下代碼直接在nodejs環境下測試）:

   • 通常來說，這裏應該用一個couter之類的示例來作

const { createStore } = require('redux')
  const ADD = 'ADD'
  const initState = {count: 0}
  // action
  function counter(state = initState, action) {
    switch(action.type) {
      case ADD:
        return {...state, count: state.count + action.payload.count}
      default:
        return state
    }
  }
  // reducer
  const AddOne = () => ({type: ADD, payload: {count:1}})
  // store
  const store = createStore(counter)
  store.subscribe(() => console.log(store.getState()))
  setInterval(() => store.dispatch(AddOne()), 1000)
複製代碼

不算註釋，大約15行左右，那麼，mobx想要具有壓倒性的優點，應該極力控制本身的大小纔對

• 一個mobx的counter大概得長成這樣吧

const { observable, autorun } = require('mobx')
  const appState = observable({
    counter: 0,
    add(value){this.counter += value}
  })
  autorun(() => console.log(appState.counter))
  setInterval(() => appState.add(1), 1000)
複製代碼

好像只用了7行，約莫是redux實現的一半大

個人天哪，多出了那麼多行代碼，我還要不要下班了 3. 內存開銷對比:

• 大小隻是浮於表面的東西，對於應用更友好的東西，纔是核心的要點

  • 在寫redux的action的時候，老是須要用到擴展語句或者Object.assign()的方式來獲得一個新的state，這一點對於JavaScript而言是對象的淺拷貝，它對內存的開銷確定是大於mobX中那樣直接操做對象屬性的方式大得多。

  這一點比較6，算是一個可被重視的問題

---

以上內容黑得主角很明顯是屬於redux的，那，萬一咱們換個視角看看呢

---

1. 狀態管理的集中性:
   • mobX中居然有這樣的寫法:

   const {observable} = require('mobx')
     const appState = observable({ counter: 0 })
     appState.counter += 1
   複製代碼

   直接修改狀態？這和react的理論徹底相悖啊，還怎麼和react搭配使用啊，個人狀態萬一被同事給悄悄改了但是會引起一場戰爭的啊，仍是開啓嚴格模式吧。
   • 你說redux作的怎麼樣？試試不經過action更新一下state,固然不能成功啊。
2. 樣板代碼的必要性:
   • 關於樣板代碼，就要追溯到redux的基本設計選擇了，redux三大原則:
     • 單一數據源
     • State 是隻讀的
     • 使用純函數來執行修改 因此能夠說是這些樣本代碼保證了state的狀態的可管理性，畢竟全部的東西都是涇渭分明的，讓出錯的可能性和找問題的成本降到了最低。

---

以上，使用mobX入門簡單，構建應用迅速，可是當項目足夠大的時候，仍是使用redux，若是的確對mobX愛不釋手，那仍是開啓嚴格模式，再加上一套狀態管理的規範吧。