状态管理

将关乎全局的状态放到reducer中去管理，组件中的UI状态可以使用组件自己的state来管理。

关乎全局的状态指：不同组件公用的state，要与后端数据交互的state等。这些state请永远不要在组件内部随意的使用setState的方式来改变，一个组件的对于这种state的改变无法通知给其他组件，每个组件都维护自己的state，虽然可以实现组件内部的状态更新，但是会导致整体的状态混乱。

组件可自己管理的状态类型

1. 与外界状态无关的UI状态

   但是每个组件与外界状态无关的UI状态可以自己维护，譬如全选按钮。自己setState，然后通过this.state获取。因为这些状态只影响这个UI组件本身，不会影响其他组件，也就没有必要通过redux管理了。

    export default class OrderTable extends Component {
      constructor(props, context) {
        super(props, context);
        this.state = {
          isCompleteShowing: false,
        }
      }
   	
        switchShow(){
           this.setState({
           	 isCompleteShowing: !this.state.isCompleteShowing,
           })
        }
    }
   

2. 单向的state对UI的影响

   如果外部的state会影响组件内部的UI展示方式，但是组件内部UI的变更确不会影响外部的状态变更，这种单向的state对UI的影响也可以由组件自己内部管理state。但这时一定要启用componentWillReceiveProps来感知外界状态的变更。譬如一个订单处理列表，默认不显示已完成的订单，但是提供按钮供用户选择显示已完成的订单项。这时这个显示不显示的UI state就可以由组件自己管理。

3. 与其他组件无关的状态

   这种即使是要与后端接口通信也可以自己维护，但是一定不能与后端接口交互，就是请求后的结果不要对组件内部状态有变更。譬如查询功能，查询的几个条件输入框的状态可以自己维护，我们要做的只是把所有输入框的查询条件组成的state传给action，作为参数，调用数据请求接口，但是请求的返回并不会影响这些输入框的状态。

组件维护的非redux管理的state的存放位置

比较合理的是放在左右组件组成的功能区，就是放在所有小组件的外部，所有数据段组成的一个完整的实际用处的state的层级。毕竟页面会是组件套组件，几个组件组成一个功能区。

依旧拿查询的例子。查询模块是一个功能区组件，包括输入框、下拉框等小组件，这时候state应该放在查询功能区，输入框依旧是通过this.props.value的方式获取查询功能区的state参数。

组件划分：对着UI设计图一层层拆分到最细

最细的意思是这个组件绝对可以通用了，不会因为外界state与设计不符而不能工作。

组件拆分的越细腻，可复用性越高，可维护性越好，而且要给未来留路，未来某个页面在组件的props里要新加内容，也要支持。