前言
今日早读文章由美团点评
赵玮龙投稿分享。正文从这开始～
假设你已经对react,redux有一些实战经验，基本的东西不会涉及，文章专著于如何尽量做到react-redux最佳实践。先谈谈之前Eric在Medium上发文喷setState，这件事情很早就引起热议，其实无非就是setState对于新手不友好以及文档的晦涩导致的。
React抽象来说，就是一个公式
UI=f(state)我们把最终绘制出来的UI当做一个函数f运行的结果，f就是React和我们基于React写得代码，而f的输入参数就是state。
作为React管理state的一个重要方法，setState肯定非常重要，如果只是简单用法，也不会有任何问题，但是如果用得深，就会发现很……尴尬。
我刚开始接触React的时候，就意识到React相当于一个jQuery的替代品，但是就像单独依靠jQuery难以管理大型项目，所以也需要给配合使用的MVC框架找一个替代品，我选择的替代品是Redux，我很早就将React和Redux配合使用；现在，回过头来看看React的setState，发现坑真的不少，不禁感叹自己还是挺走运的。
对setState用得深了，就容易犯错，所以我们开门见山先把理解setState的关键点列出来。
setState不会立刻改变React组件中state的值；
setState通过引发一次组件的更新过程来引发重新绘制；
多次setState函数调用产生的效果会合并。
这几个关键点其实是相互关联的
setState不会立刻改变React组件中state的值(他是异步触发的，也就是考虑到列队处理的必要性)
在React中，一个组件中要读取当前状态用是访问this.state，但是更新状态却是用this.setState
如果需要同步我们还是更需要函数式的setState用法，
如果传递给this.setState的参数不是一个对象而是一个函数，那游戏规则就变了。
这个函数会接收到两个参数，第一个是当前的state值，第二个是当前的props，这个函数应该返回一个对象，这个对象代表想要对this.state的更改，换句话说，之前你想给this.setState传递什么对象参数，在这种函数里就返回什么对象，不过，计算这个对象的方法有些改变，不再依赖于this.state，而是依赖于输入参数state。
可以这么写一个函数：
functionincrement(state,props){return{count:state.count+1};}
可以看到，同样是把状态中的count加1，但是状态的来源不是this.state，而是输入参数state。
对应incrementMultiple的函数就是这么写。
functionincrementMultiple(){this.setState(increment);this.setState(increment);this.setState(increment);}
对于多次调用函数式setState的情况，React会保证调用每次increment时，state都已经合并了之前的状态修改结果。
简单说，加入当前this.state.count的值是0，第一次调用this.setState(increment)，传给increment的state参数是0，第二调用时，state参数是1，第三次调用是，参数是2，最终incrementMultiple的效果，真的就是让this.state.count变成了3，这个函数incrementMultiple终于实至名归。
值得一提的是，在increment函数被调用时，this.state并没有被改变，依然，要等到render函数被重新执行时（或者shouldComponentUpdate函数返回false之后）才被改变。
让setState接受一个函数的API设计很棒！因为这符合函数式编程的思想，让开发者写出没有副作用的函数，我们的increment函数并不去修改组件状态，只是把“希望的状态改变”返回给React，维护状态这些苦力活完全交给React去做。
正因为流程的控制权交给了React，所以React才能协调多个setState调用的关系。
让我们再往前推进一步，试着如果把两种setState的用法混用，那会有什么效果？
我们把incrementMultiple改成这样。
functionincrementMultiple(){this.setState(increment);this.setState(increment);this.setState({count:this.state.count+1});this.setState(increment);}
在几个函数式setState调用中插入一个传统式setState调用（嗯，我们姑且这么称呼以前的setState使用方式），最后得到的结果是让this.state.count增加了2，而不是增加4。
原因也很简单，因为React会依次合并所有setState产生的效果，虽然前两个函数式setState调用产生的效果是count加2，但是半路杀出一个传统式setState调用，一下子强行把积攒的效果清空，用count加1取代。
这么看来，传统式setState的存在，会把函数式setState拖下水啊！只要有一个传统式的setState调用，就把其他函数式setState调用给害了。
如果说setState这儿API将来如何改进，也许就该完全采用函数为参数的调用方法，废止对象为参数的调用方法。
当然，React近期肯定不会有这样的惊世骇俗的改变，但是大家可以先尝试函数式setState用法，这才是setState的未来。
当然这还不是全部的问题所在，全局的state状态，可以使得多个组建共享状态才是我们所期望的