从时间旅行的乌托邦，看状态管理的设计误区

Redux 的状态管理理念非常优雅，随之附带的时间旅行调试支持也非常酷炫。但这个特性是否是传说中的银弹，又会给使用者带来什么额外的负担呢？让我们重新思考一下吧。

什么是时间旅行

在 2015 年的 React Europe 会议上，Dan Abramov 展示了通过 Redux DevTools 让开发者在历史状态中自由穿梭，从而提升调试体验的 Demo，这个工具的使用体验非常惊艳，也取得了非常好的反响。在此之后，Vuex 与 MobX 等状态管理库也陆续在它们的调试工具中引入了对类似功能的支持。
我们可以认为，前端状态管理领域中，狭义的『时间旅行』概念是在满足了下面这几个前提后，开发时在历史状态中任意回溯的功能：

将局部 state 统一到全局 store 中做状态管理。
开发环境中安装了与状态管理库配套的 DevTools，或引入了特殊的监控组件。
开发环境中启用了 Webpack 的 HMR 热加载。

需要特别注意的是，这个功能完全是调试时使用的。不过，由于这个能力给人的印象过于深刻，它也成为了许多人转向 React + Redux 技术栈的主要理由之一：漂亮的概念模型加上漂亮的调试体验，这套方案简直就是神器啊！而正如 React 第一个在浏览器里实现了声明式渲染一样，Redux 也第一个在浏览器里实现了理想中的调试体验，这些原创性的工作对前端领域的贡献是非常大的。在下文中，我们对 React + Redux 一些潜在问题的分析，也是建立在尊重社区工作的基础上的。

阅读原文…