简述redux

redux已经用的比较熟了，实际上redux并没有想象中那么复杂，就像redux官方文档说的没有黑魔法，这里我来重述一下redux的几个主要概念：
store：数据存储部分，store最后其实就是一个加工后的javascript原生对象，这个对象跟大家常规构建的javascript对象是一样的，只不过redux对这个对象进行了一系列的加工，这个对象最终长得像这样( 只是像，并不是 )
<blockquote>
{
  dispatch:(action),
  getState:(),
  subscribe:()
}
</blockquote>
看看这个对象应该很亲切吧，我们在实际使用的时候用的最多就是dispatch和getState了，这个很类似于构建了一个对象，对外export了几个方法，getState方法执行后将会返回存储在store中最新的数据，dispatch这个方法接收一个action对象，然后根据action对象来选择reducer来更新数据

action：这个也是相当好理解的，这就是个普通的javascript对象，就像这样
<blockquote>
{
  type:'update',
  payload:{}
}
</blockquote>
这就是一个简单的对象而已，用来描述类型，带入一些数据，这个就像一个请求，包含了请求的类型，还有这个请求附带的一些数据，store接收到这个对象的时候会根据type的值来选择对应reducer来处理

reducer：实际上reducer就是一堆会返回数据的方法，当store的dispatch被触发的时候就会根据action中带的type来选择对应的reducer处理，reducer是用于处理state的，因为action只是用来通知store，我要更新啦，要怎么更新呢？store自己不管，它让一个叫reducer的方法集合来处理，我们的dispatch不是带了个action进来嘛，action就是个简单的描述发生了什么变化和带一些数据进来的对象，reducer方法集你就对着action带进来的信息对照着action对象的TYPE来处理吧。无数的小reducer返回的小state合成应用完整的根state。这里要注意的就是在reducer处理的时候要返回新的对象，不要直接在原对象上直接修改。
reducer一般长这样：
<blockquote>
function update(state={},action){
  const { type } = action;
  switch (type){
    case 'update':
    return {...state,action.payload}
    break;
  }
  return state
}
</blockquote>

这三个就是redux的核心，一个存储对象，一个描述发生变化的action对象，一个根据action对象处理存储数据的方法集。

不使用redux的话

首先，我们应该知道，react自身仅仅是一个完整的模式中的View层实现，一个UI框架，在redux没有出来之前，我们单纯使用react也可以正常开发，效率也不比用上了redux低，redux主要起到了一个数据流管理的作用，redux是基于Flux模式的实现并完善，是区别于Mvvm，mvc模式的新模式；

redux提供的主要作用是数据存储管理，这里说的数据存储，除了应用需要的数据外还包括一些UI的状态等。

没有使用redux的时候，我们基本是直接通过父组件往子组件传props的方式，或者是直接在组件内使用state的方式来记录组件的各种数据状态，在应用并不大，并且你不需要使用诸如时光回溯，撤销操作这些东西的时候，不使用redux其实开发速度还会更快，因为你省略了去写action，写reducer，设计store这一系列的操作，实际上这也算一个比较繁琐的过程，事实上我们把数据、状态等信息直接存储在当前组件的情况下也有好处，你自己需要的东西都在自己的口袋里，想要这些东西的时候直接在自己的口袋伸手找就可以了，而不是像redux一样，你要根据连接进来的aciton啦，state啦去对应的action和reducer文件里找，也不需要维护大量的action、reducer。

不使用redux的话，每个组件需要的数据或方法直接从上级组件或者自身内部定义提供，当你需要修改的时候直接找到对应组件里面就可以了，这是很方便的。

使用redux的话会有什么不同

首先我要说的是，加入了redux，其实就是将应用需要用的大部分数据抽离，存储到一个对象进行统一管理，然后通过传入react组件的props来使用。打个比方：
<blockquote>
const store = {
  uiState:{},
  list:[]
};
<App store={store} />
</blockquote>
  首先我定义了一个store对象，我把它当做一个props参数传给了App组件中，那么理所当然的，App这个组件可以读取到里面的uiState和list，这也就是加入了redux之后的本质，在react之外定义了一个存储对象作为根存储，将里面的数据分发到对应需要数据的react组件中去，这个根存储对象提供了dispatch方法来让你可以对存储对象内的数据进行变更，和不使用react的时候的区别，就是我们将组件需要用到的方法，数据、状态等这些东西都统一放到了react外部的存储对象进行统一管理，这个统一管理的好处如redux官方所说的，由于state 在什么时候，由于什么原因，如何变化已然不受控制，Redux 试图让 state 的变化变得可预测。

我们回想一下没有使用redux的时候，我们把组件需要的数据存储在组件内，组件的state是相当难以预测的，并且对应用数据的加工监测、添加新模块也会很困难，但是放到了redux中之后，应用大部分需要用到的数据及状态保存在redux中，而redux使用的函数式编程模式使得我们可以很方便的给redux添加中间件，将数据流像工厂流水线一样可以对数据进行加工、监测，极大幅度的提高了应用的可预测性，对应用的调试也更加方便，中间这个过程可以应用大量好用的中间件，也可以自己编写，中间件这个东西在这里其实也很好理解，就是数据在流动的时候会停留的一个小型加工器，根据你需要的变更对数据进行加工后输入输出。

中间件的实现在官方的文档里有很详细的解释，例子也很好，只不过一开头会看的有点懵，多看几遍看懂它会很有益的！

Tips

• 异步操作如ajax，fetch一般都写在action，毕竟实际上这些都是请求触发数据变动的操作，那么我觉得理所当然的放在action里
• 在web开发的时候，redux基本都会配个react-router
• 关于react-redux的connect 函数，文档建议尽量少用connect直接绑定到各个组件，推荐绑定多的顶层组件往下props，但是实际开发的时候多connect其实更直观也挺好管理的，开头的时候我就是太在意减少connect数量而把一堆方法props下去。然后用起来更蛋疼。。。所以还是要看实际情况的
  待续……