单页 Web 应用相较于传统的 Web 页面通常都具有较长的生命周期，页面（前端路由实现的“虚拟页面”）切换时的数据如何有效的保存或销毁，应用会不会内存泄漏亦或是内存会不会被无限制的使用而导致系统资源耗尽。基于这样的应用场景，数据的通信和传输、管理和存储对于前端单页 Web 应用来说越来越重要。而如何基于单页 Web 应用的 UI 渲染模式设计出与之契合的数据管理的架构模式，这是我一直在尝试和探索的方向。
基于 React 的单页 Web 应用，Flux 在目前仍然是较好的架构模式，但 Flux 更多的是侧重于数据的通信和传输，在这方面，我在之前的 Ballade: 重新诠释 Flux 架构 中有详细的介绍。
而本文主要介绍的是数据的管理和存储，并且在这方面是可以脱离于 Flux 的架构模式去独立探索和发展的。
由于 React 的单向数据流的设计，衍生出了单向数据流的架构模式 Flux。
在 MVC 的分层架构中，Flux 属于 M 层，也就是 Model，而在 Flux 中，Store 是关键部分，Action 和 Dispatcher 都是围绕着 Store 来设计的，所以 Flux 架构模式的目标就是基于单向数据流如何更好的管理数据，在 Views 或 Controller-views 与数据之间进行解耦。
我在之前的 React 应用的架构模式 Flux 有详细的介绍过 Flux 架构模式及其应用。
"Flux is more of a pattern than a framework."
这是 Flux 在其 github 主页上截取的一句话，翻译成中文就是：Flux 更像是一种架构模式，而不是一个单纯的框架。
React 组件之间的数据通信在 初探 React 组件 有初步接触，父组件可以通过声明 props 来向子组件传递数据，但是子组件无法向父组件传递数据，兄弟组件之间也不能相互传递数据。React 的这种单向数据流的通信模式能确保数据的流动简单可控，非常严谨，React 也一直秉承着简单严谨的设计思想。
那如上提到的非父子组件的数据通信该怎么办呢？有几种方案：
回调函数 父组件注册回调函数，子组件执行回调函数，这种方案比较简单，适用范围也有限，适合简单的子组件向父组件的数据通信；
事件 事件通信是 JavaScript 最常用的通信方案，这种通信方案不用局限于组件之间的关系，比较灵活，但是当应用复杂庞大的时候，使用这种通信方式会导致管理混乱，不可控；
Flux Facebook 官方团队提出来专门应用于 React 的一套应用的架构模式，本文将要讲述的就是该方案。
