在沒有引入Redux之前，对于各个组件之间共享状态的处理，通常是用传给子组件的事件处理器来处理。状态的处理分散到各个组件代码中，很不利于维护。
引入Redux之后，状态的管理集中到一个地方处理，并且把处理过程中的不同关注点对应到Action、Reducer、Store等几个概念。Action：代表要执行的动作，Reducer：计算出新的状态，Store：集中应用所有的状态。
能够集中管理状态，然后分离关注点，从而提高代码可读性、可维护性是使用Redux管理状态的好处。
Redux适用场景
多交互、多数据源
需要共享某个组件的状态
某个状态需要在任何地方都可以拿到
一个组件需要改变全局状态
一个组件需要改变另一个组件的状态
redux方法
import {
compose,
createStore,
applyMiddleware,
combineReducers,
bindActionCreator
} from 'redux';
Action
代表发生了什么事。
action.js
ActionTypes
ActionCreator
action.js
export const SET_AAA;
export const SET_BBB;
// ...other action constants
export function setAAA(aaa) {
return {
type: SET_AAA,
aaa: aaa
};
}
export function setBBB(bbb) {
return {
type: SET_BBB,
bbb: bbb
};
}
// ...other actions
Reducer
表示状态如何改变，输出有最新状态。
注意：只有状态的计算；不应该有副作用；没有API调用；没有对原State的改动。
reducer.js
const initialState = {
aaa: '',
bbb: null,
ccc: null,
// ...
};
export default function(state = initialState, action) {
switch(action.type) {
case "SET_AXXX":
return {...state, aaa: {...xxx}};
case "SEND_XXX":
return {...state, bbb: action.xxx};
case "SET_BXXX":
return {...state, bbb: action.bbb};
case "SET_CXXX":
return {...state, ccc: action.ccc};
default:
return state;
}
}
Store
一个应用只有一个Store。
store.js
import { createStore } from 'redux';
import { SomeComponent } from './reducers';
let store= createStore(SomeComponent);
store的提供的方法有：
常用redux插件：react-redux，redux-thunk，redux-logger
react-redux
import {
connect,
Provider,
connectAdvanced,
createProvider // 最新代码为：ReactReduxContext -- Nov 7, 2018
} from 'react-redux';
Example
Vanilla React
ReactDOM.render(
<Provider store={store}>
<MyRootComponent />
</Provider>,
rootEl
)
React Router
ReactDOM.render(
<Provider store={store}>
<Router history={history}>
<Route path="/" component={App}>
<Route path="foo" component={Foo}/>
<Route path="bar" component={Bar}/>
</Route>
</Router>
</Provider>,
document.getElementById('root')
)
connect
connect([mapStateToProps], [mapDispatchToProps], [mergeProps], [options])
显示组件（Presentational Components）、容器组件（containers）
State 范式化（摘自官方文档）
当一个系统较复杂时，有时数据结构会比较复杂，并且有时部分数据可能重复的，有时还有一些问题：
- 当数据在多处冗余后，需要更新时，很难保证所有的数据都进行更新。
- 嵌套的数据意味着 reducer 逻辑嵌套更多、复杂度更高。尤其是在打算更新深层嵌套数据时。
- 不可变的数据在更新时需要状态树的祖先数据进行复制和更新，并且新的对象引用会导致与之 connect 的所有 UI 组件都重复 render。尽管要显示的数据没有发生任何改变，对深层嵌套的数据对象进行更新也会强制完全无关的 UI 组件重复 render
正因为如此，在 Redux Store 中管理关系数据或嵌套数据的推荐做法是将这一部分视为数据库，并且将数据按范式化存储。
设计范式化的 State
范式化的数据包含下面几个概念：
- 任何类型的数据在 state 中都有自己的 “表”。
- 任何 “数据表” 应将各个项目存储在对象中，其中每个项目的 ID 作为 key，项目本身作为 value。
- 任何对单个项目的引用都应该根据存储项目的 ID 来完成。
- ID 数组应该用于排序。
嵌套数据范式化
因为 API 经常以嵌套的形式发送返回数据，所以该数据需要在引入状态树之前转化为规范化形态。Normalizr库可以帮助你实现这个。你可以定义 schema 的类型和关系，将 schema 和响应数据提供给 Normalizr，他会输出响应数据的范式化变换。输出可以放在 action 中，用于 store 的更新。
参考文章：
Redux官方网站
Redux官方文档中文版
阮一峰 - Redux 入门教程（一）：基本用法 共3篇
react-dnd 使用实例
结合 Immutable.JS 使用 Redux
