Redux是 JavaScript 状态容器，提供可预测化的状态管理。它是受flux启发而开发演变，但又绕过了flux的复杂性。
看起来Redux= React (Re）+d+Flux（ux）
它有三个主要概念：store，action，reducer。
所有的state都以对象树的形式存储于store中。
要改变state的状态，只能通过触发action来改变，action是一个用来描述发生什么的对象。state 的形式取决于自己需要，可以是基本类型、数组、对象等。甚至是 Immutable.js 生成的数据结构。
reducer:
reducer则是用来描述action如何改变state树的。
reducer 是形式为 (state,action)=>state 的纯函数。描述了如何把state转换成一个新的state。
reducer(state=0,action){
switch（action.type）{
case 'INCREMENT':
return state + 1;
case 'DECREMENT':
return state - 1;
default:
return state;
}
}
store：
let store=createstore(reducer);
store 的api：
dispatch(action)// 传递一个action对象
store.dispatch({action}) //来改变store里state的状态。
getState// 获取状态
subscribe(observer) // 订阅，传入一个observer,描述得到值后如何处理。
action：
一个对象，用来描述state要发生怎么样的改变。
比如：
{type: 'INCREMENT'}，{type: 'DECREMENT'}
Redux 没有 Dispatcher 且不支持多个 store。相反，只有一个单一的 store 和一个根级的 reduce 函数（reducer）。随着应用不断变大，你应该把根级的 reducer 拆成多个小的 reducers，分别独立地操作 state 树的不同部分，而不是添加新的 stores。这就像一个 React 应用只有一个根级的组件，这个根组件又由很多小组件构成。
动机：
随着 JavaScript 单页应用开发日趋复杂，JavaScript 需要管理比任何时候都要多的 state （状态）。 这些 state 可能包括服务器响应、缓存数据、本地生成尚未持久化到服务器的数据，也包括 UI 状态，如激活的路由，被选中的标签，是否显示加载动效或者分页器等等。
管理不断变化的 state 非常困难。
如果一个 model 的变化会引起另一个 model 变化，那么当 view 变化时，就可能引起对应 model 以及另一个 model 的变化，依次地，可能会引起另一个 view 的变化。直至你搞不清楚到底发生了什么。state 在什么时候，由于什么原因，如何变化已然不受控制。 当系统变得错综复杂的时候，想重现问题或者添加新功能就会变得举步维艰。
这里的复杂性很大程度上来自于：我们总是将两个难以理清的概念混淆在一起：变化和异步。 我称它们为曼妥思和可乐。如果把二者分开，能做的很好，但混到一起，就变得一团糟。一些库如 React 试图在视图层禁止异步和直接操作 DOM 来解决这个问题。美中不足的是，React 依旧把处理 state 中数据的问题留给了你。Redux就是为了帮你解决这个问题。
网友评论