哪些场景需要 SSR 服务
现如今 Web 前端的主流 UI 框架都是 React 和 Vue，以及 Angular，这些框架主流的做法都是在客户端基于 JS 来完成 HTML 内容结构的渲染。对于一些 HTML 内容结构主要由动态数据构成的复杂页面，在性能表现一般的移动设备上渲染的计算就会显得有点吃力，那么此时如果有 SSR 服务在服务端完成 HTML 内容结构的渲染，可以显著提升渲染的性能。
当然还有页面需要做 SEO 的场景，不过这不是本文想要表述的范畴。
单页 Web 应用相较于传统的 Web 页面通常都具有较长的生命周期，页面（前端路由实现的“虚拟页面”）切换时的数据如何有效的保存或销毁，应用会不会内存泄漏亦或是内存会不会被无限制的使用而导致系统资源耗尽。基于这样的应用场景，数据的通信和传输、管理和存储对于前端单页 Web 应用来说越来越重要。而如何基于单页 Web 应用的 UI 渲染模式设计出与之契合的数据管理的架构模式，这是我一直在尝试和探索的方向。
基于 React 的单页 Web 应用，Flux 在目前仍然是较好的架构模式，但 Flux 更多的是侧重于数据的通信和传输，在这方面，我在之前的 Ballade: 重新诠释 Flux 架构 中有详细的介绍。
而本文主要介绍的是数据的管理和存储，并且在这方面是可以脱离于 Flux 的架构模式去独立探索和发展的。
在上一篇文章《Immutable 在 JavaScript 中的应用》 中主要介绍了 Immutable 之于 JavaScript。而基于 Immutable 的特性，将其应用在 React 项目的开发中非常合适，解决了 React 中的一些痛点，能进一步提升 React 组件的性能以及更好的管理组件的状态。
在介绍 Immutable 如何在 React 中应用之前，先来谈谈 React 组件是如何更新的。
React 是基于状态驱动的开发，可以将一个组件看成是一个有限状态机，组件要更新，必须更新状态。
通常说的组件的状态就是组件的 state 对象，state 是可以由当前组件自行修改更新的，这种自更新的状态的为了便于理解区分可以称之为“动态”的状态。但除了更新 state 外，组件还可以通过 props 来更新，props 属性不能由组件自行修改，必须由父组件来修改，然后再传递给当前组件，更新组件的 props 也能引起组件的更新，可以将 props 称之为“静态”的状态。这样的状态区分是广义上的，如果你不认可 props 也是状态也没关系，这里可以不用拘泥于文字。
由于 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 Router 是专为 React 设计的路由解决方案，在使用 React 来开发 SPA （单页应用）项目时，都会需要路由功能，而 React Router 应该是目前使用率最高的。
React Router 并不是 Facebook 的 React 官方团队开发的，但是据说有官方人员参与开发。React Router 的设计思想来源于 Ember 的路由，如果原来有用过 Ember 的路由，那么应该对 React Router 不会陌生。
什么是路由？
对于没有开发过后端，也没有开发过 SPA 的前端来说，「路由」这个名词可能会让人比较困惑，这里的路由并不是指「硬件路由」，也不是网络七层协议中的「网络层路由」，但是其思想原理是一样的。我尽量简单通俗的介绍一下。
假如我们有一台提供 Web 服务的服务器的网络地址是：10.0.0.1，而该 Web 服务又提供了三个可供用户访问的页面，其页面 URI 分别是：
http://10.0.0.1/ http://10.0.0.1/about http://10.0.0.1/concat