上一篇中简单的描述了Redux的主要使用流程，本篇针对上一篇做一些补充。
1、Action 与 Reducer的详细理解
先回顾一下不使用Redux的情况下，React的Class该怎么写。
import React, { Component } from 'react';
class Test extends Component{
constructor(props){
super(props);
state={
name:''
}
}
handlerFunc = () =>{
const inputName = this.refs.inputValueTest.value;
this.setState({
name:inputName
})
}
render() {
const {name} = this.state;
return (
<div>
<label> {name} </label><br/>
<input ref="inputValueTest" /><br/>
<button onClick={this.handlerFunc}>confirm</button><br/>
</div>
);
}
}
嗯，主要就是这样：constructor 里初始化状态，然后渲染组件，onClick里绑定点击事件，事件函数中setState()一下，此时得到了新的状态，并使虚拟DOM重新渲染，最终Label显示我们输入的值。
这个过程理解了的话，也就能够和Redux进行对照理解。
然后看看使用Redux 后，组件是怎么写的：
import React, { Component } from 'react';
import PropTypes from 'prop-types'
class Test extends Component{
static propTypes = {
firstname:PropTypes.string.isRequired,
addName:PropTypes.func.isRequired
}
handlerFunc = () =>{
const inputName = this.refs.inputValueTest.value;
this.props.addName(inputName);
}
render() {
const {firstname} = this.props;
return (
<div>
<label> {firstname} </label><br/>
<input ref="inputValueTest" /><br/>
<button onClick={this.handlerFunc}>confirm</button><br/>
</div>
);
}
}
观察两种写法，会发现：
（1）初始化状态没有了，
（2）setState()也移除了，然后通过属性结构赋值。
总之，状态管理方面的东西都被移除了。因为采用Redux框架，本身就是要让他接管状态的，所以，redux框架下的React的代码就很好理解了。就是react组件里面是没有State相关的东西（当然，特殊情况下还是需要用的组件自己的状态管理的）。它所要做的就是，传递动作（按钮点击）或者请求（请求数据），并根据自身属性向HTML中填入数据。这里用到了prop-types这个库。来进行属性的校验。
之后可以这样理解，setState()方法在Redux那边被拆分成两步，现在Action中，把获取到的值，弄成一个Object，代码如下：
import { ADDNAME} from "./action-type";
//包含所有的action creator
export const addName = (name) =>({type:ADDNAME,data:name})
这里面的addName 就是React代码里按钮触发的方法中要执行的函数，name 就是我们或得到的输入框里的值。
接着redux帮我们做的就是用Store中提供的dispatch方法，把这个动作传到reducer那去，然后来看看Reducer做了什么：
import {ADDNAME} from './action-type'
const initialState = {
name:'Peter'
}
const name = (state=initialState,action) => { //形参默认值
switch(action.type){
case ADDNAME:
return action.data
default:
return state
}
}
由于我们把React中的状态让redux单独拎出来，所以最终会生成一棵大的状态树,也就是一个Object。所以这里的name，最终会成为这个状态树的一个属性，值就是返回值，action.data ,对应action里传入的值。可以看一下,状态树可以通过Store.getState获得：
Reducer 可以类别理解为，充当了setState的角色。并且也负责了初始化state的任务。
所以，reducer在case到ADDNAME 这个动作之后，就把从action那传来的值，做了一个相当于setState（）的操作。要是一开始没有触发任何动作，则Store会帮我们在程序运行之初执行一遍Reducer,使用初始值，initialState
this.setState({
name:action.data
})
2、展示组件与容器组件
redux写的代码单拎出来与react代码是没啥联系的。写完上面的东西后，一运行就会报错，一大堆undefined。这个时候就需要一个connect来连接Redux和React。现在有这么一个库'react-redux'. 使用里面的connect 即可。如下：
import React from 'react'
import {connect} from 'react-redux'
import {addName} from '../redux/actions'
import Test from '../component/Test'
export default connect(
state => ({
firstname :state.name
}),
{addName}
)(Test)
（1）容器组件
这样就写好了一个组件，官方称之为容器组件，我个人把更愿意把它称之为封装组件，就是引入之前写好的React组件Test，再引入之前action和reducer 里的动作、状态，进行一个封装，这样就把Test里事件函数与属性匹配到了一起。
其中 firstname 对应Test 里面的firstname 属性 ，state.name 就是reducer 里定义的那个name.这样的话，到时候Test组件里用的firstname的值，就是state.name给赋上去的。属性状态匹配完之后要匹配动作，Test中点击事件中执行的addName,就匹配action里的addName。因为我这里两边都命名为addName，根据es6规则，属性名和属性值相同的话，可以省略不写，这样就单写一个就可以。这样，点击按钮之后，数据就会通过action传到Reducer那去做类似于setState（）这样的操作。
最终拿出去用的，也都是这个组件，可以把它命名为TestContainer.jsx 用于路由或者直接放到哪都可以。
（2）展示组件 这个就是Test那个组件。里面一般不包含任何Redux相关的东西。纯净的React组件。称之为展示组件。可以理解为容器组件（封装组件）的一部分
3、异步
一个web应用，大多数都需要做请求操作的。而在React + Redux这样的一个结构中，异步请求操作最合适的位置就是放到Redux中的action中。首先，展示组件，即Test组件，这个是view层。view层显然不适合掺杂异步请求的。然后reducer其实是实现的类似于setState（）的作用，并且这个时候才请求数据就有点晚了。所以在Redux中的Action中做异步请求是比较合适的。action其实也是个传接数据的载体。
既然选择在Redux中进行异步请求，就需要引入一个库 react-thunk，来帮助我们进行异步请求.
首先进行配置。
import {createStore,applyMiddleware} from 'redux'
import {finalReducer } from './reducers'
import thunk from 'redux-thunk'
//生成store对象
const store = createStore(finalReducer,applyMiddleware(thunk));//内部会第一次调用reducer函数，得到初始state
export default store
第一步 npm i redux-thunk;
第二步 引入 redux-thunk的thunk 以及Redux的applyMiddleware
第三步，在createStore中加入这个库
很简单。
然后就是使用了
正常来说，一般我们是触发一个动作，让他进行请求，得到数据后，再去setState.在Action中也是一样。如下：
export const addNameAsync = (name) =>{
return dispatch =>{
setTimeout(()=>{
dispatch(addNameCreater(name))
},2000);
}
}
这里用setTimeout模拟请求过程。两秒后，数据请求到了，再把数据给Reducer进行状态替换。这里的话，我们需要手动调用dispatch这个函数，向Reducer去分发动作。
总结
Redux这块一开始接受很多概念确实很难理解。学习就是如此，一下子铺天盖地的抛出很多你从来没听过的概念，无论是谁都接受的很困难。作为学习者，就需要类比，理解，然后追根溯源，看看底层如何实现。
就本篇与前一篇的例子而言，原本不到一百行的东西，在使用了Redux之后，分出了这么多个文件。确实，折中小来小去的玩意儿，放在一个文件里写就完事儿了。但是如果没有状态管理的这个意识。在进行大型项目的构建时，就很麻烦，一个请求过来的数据，可能要在多个组件用。这个时候，无论MobX 还是Redux这类的状态管理库，会节省很多开发时间，提高开发效率。
另外就是封装性很好，清晰的文件结构和代码结构，能够大大提高项目的可扩展行、可维护性以及降低耦合度。而对于一些把任何东西写到一起的那种项目，一个页面上千行甚至几千行，扩展维护起来的体验可想而知。
作为开发者，还是要对自己写的东西负责。
=========================
多少要有点基本的素养。不要动不动就把请求写在componentWillMount里!!!
