redux 和 mobX对比

以下内容会严格遵循下面三个观点
- 这部分的每一个小块都是为了吹二者之一
- 要怎么黑另外一个才能更好的达到吹的效果
- 要吹得有理有据，黑得不带痕迹
为什么这两个库可以被用来对比
1. 目的一致
都是状态管理库，用来管理应用的内部状态
1. 受众大体一致
一般都会被用到react中，虽然说这并不是必须的，你当然也可以用到vue或者angular里，但是，大多数情况下，都不会这么做
1. 可相互替代
在项目之初，你可以选择二者之一来满足你的项目需求，但是到某一天你突然觉得另一个更和你气味相投，你完全可以花点时间迁移过去，你会发现，它似乎也能满足你的那些需求

学习难度对比:
- mobX的学习中，你可以听信关于30分钟快速入门的神话，这毕竟不是对一个语言而言的《7天从入门到精通》系列，因为它真的很简单，并且在这三十分钟过去之后，你唯一需要花的时间就是偶尔翻翻文档就可以自如的使用它了。
- redux的入门学习也没那么难，即使有些概念显得比较抽象，你最多需要多花上半个小时就可以掌握它们了，但是当你真的去使用的时候，你会发现这一切原来并非想象的那么简单，你不得不花更多的时间来学习更多：
当你需要异步的时候，你不得不考虑redux-thunk，你怎么可能不需要异步
想用Promise，没问题，先看看redux-promise-middleware怎么样
想搞个日志之类的东西，redux-logger已经准备好了
当你需要使用state中的两个值来计算出一个值的时候，你如果稍有代码洁癖，你肯定不愿意这样做，这时候，你需要的东西叫做Reselect
...

第一波黑的不错，你有没有望而却步
工作量对比（以下代码直接在nodejs环境下测试）:
- 一般来讲，这里应该用一个couter之类的示例来做

  const { createStore } = require('redux')
  const ADD = 'ADD'
  const initState = {count: 0}
  // reducer
  function counter(state = initState, action) {
    switch(action.type) {
      case ADD:
        return {...state, count: state.count + action.payload.count}
      default:
        return state
    }
  }
  // actions
  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实现的一半大

我的天哪，多出了那么多行代码，我还要不要下班了

内存开销对比:

大小只是浮于表面的东西，对于应用更友好的东西，才是核心的要点
- 在写redux的action的时候，总是需要用到扩展语句或者Object.assign()的方式来得到一个新的state，这一点对于JavaScript而言是对象的浅拷贝，它对内存的开销肯定是大于mobX中那样直接操作对象属性的方式大得多。
这一点比较6，算是一个可被重视的问题

以上内容黑得主角很明显是属于`redux`的，那，万一我们换个视角看看呢

状态管理的集中性:
- mobX中竟然有这样的写法:
```
  const {observable} = require('mobx')
  const appState = observable({ counter: 0 })
  appState.counter += 1
```
直接修改状态？这和react的理论完全相悖啊，还怎么和react搭配使用啊，我的状态万一被同事给悄悄改了可是会引发一场战争的啊，还是开启严格模式吧。
- 你说redux做的怎么样？试试不通过action更新一下state,当然不能成功啊。
样板代码的必要性:
- 关于样板代码，就要追溯到redux的基本设计选择了，redux三大原则:
  - 单一数据源
  - State 是只读的
  - 使用纯函数来执行修改
    所以可以说是这些样本代码保证了state的状态的可管理性，毕竟所有的东西都是泾渭分明的，让出错的可能性和找问题的成本降到了最低。

以上，使用mobX入门简单，构建应用迅速，但是当项目足够大的时候，还是使用redux，如果的确对mobX爱不释手，那还是开启严格模式，再加上一套状态管理的规范吧。

redux 和 mobX对比

以上内容黑得主角很明显是属于redux的，那，万一我们换个视角看看呢

以上内容黑得主角很明显是属于`redux`的，那，万一我们换个视角看看呢