为什么会感觉redux写起来很麻烦？

Redux是基于纯函数的，为了保证它的“纯度”，它的reducer函数必须是严格的 S' = f(S) 的形态，所以，与其说Redux是“状态管理”库，不如说它是“状态转移管理”库，因为Redux是无状态的，状态是在你的程序里的，你自己维持状态，它只是给你提供了一个状态转移的统一方式。这使得它的整个模型看起来是非常干净。

而事实上我们在开发实际项目当中可能有小半（maybe大半）的reducer场景其实应该是 S' = await fAsync(S) 的形态，比方说，我点了一个计数器+1的按钮，在一个美丽的DEMO里，它就+1了，但放到生产需求里，很可能是要先发起一个Ajax请求，请求OK了再+1，甚至这时候不是+1，而是直接和服务端同步一个新的值。

但异步的reducer就破坏了它的“纯度”，因为异步是不确定的，先发不一定先至，这会破坏reducer的“可回放性”，它引以为豪的replay就不成立了，它的基石就崩塌了。

这就注定了它解决不了异步的问题，然后它为了让自己显得很白玉无瑕，死活也不愿意碰异步那摊子脏东西，什么？你要在reducer里发起一个Ajax请求？对不起这不是我们的best practice，我们对此嗤之以鼻，你如果真要这么做，那就……做去吧。

于是Redux在解决异步问题上的“残疾”就注定给它擦屁股的库会如雨后春笋一样的涌现出来，比如其他回答里提到的dva，再比如redux-saga，它们都是勇士，做了redux所不愿意做的那摊子脏活。

这个过程又引入了新的麻烦，一方面是异步本身带来的复杂度，比如redux-saga里的every和latest；另一方面是代码写起来的麻烦，比如redux-saga里各种yield，还有可以堆成山的胶水代码。

所以你觉得redux写起来很麻烦，麻烦就对了，这不是幻觉，因为它为了保证自己的简洁，把麻烦的事情抛给了你。结论很简单，要么就引入更多“生态”，让别人帮你解决麻烦，让它们对你输出价值观。要么就别走redux的函数式路线，去你大爷的纯函数，用别的价值观，我用全局变量全局事件，用watch，用observable，用whatever，反正不用你。

转载自知乎，作者：Jim Liu