Web前端的状态管理（State Management）

背景

我相信不少朋友跟我同样，初次听到什么Flux, Redux， Vuex，状态管理的时候是一脸懵逼的。由于在外面以前前端大部分开发的时候，根本没有那么多的概念。自从ReactJS火爆后，什么Flux, Redux，React全家桶是一套一套接踵而来。搞的不少开发者甚是头大。所谓的ReactJS全家桶即ReactJS + Redux + Webpack， 固然其中的Redux能够用其余例如Mobx之类的替换。本来可能只是很简单的一些数据展现需求，当想用尝试使用ReactJS时，去Google搜索了一些教程，忽然发现怎么用个React须要这么多东西。正现在年比较有名的一篇文章里面描述的那样 — ”在2016年学习前端是怎样一种体验"。

很显然，时代在进步，技术在进步，Web业务需求在进步，浏览器性能的大幅度提高，促使JS能处理愈来愈多的事情。为了知足愈来愈复杂、丰富的WebApp需求，愈来愈多的本来后端处理的业务逻辑开始转移到前端来处理，同时更多复杂的前端业务在浏览器上面催生，原有的不少技术体系、解决方案已经不能很好的支撑这些愈来愈复杂的需求了。因此当咱们在面临各类业务需求的时候，一定会出现各类各样的适合不一样业务需求的技术解决方案。

不少朋友刚刚上手React的时候，被什么Redux, 函数式都搞的有点摸不着头脑。由于以前不少时候写前端用一个jQuery就足矣，当转换到ReactJS时,突然多出了个Webpack, Redux, 然而Redux里面又包含了什么Reducer、Action、State管理、函数式等等概念, 搞的人的确很头大。前期较高的学习成本，形成了不少朋友就放弃了ReactJS的选型。并且不少开发者初期并不了解这些框架所解决的问题，缺少足够的实践经验，形成不少人误认为这是把简单的问题越搞越复杂。可能你们回想原本很简单的问题，我用个jQuery就能搞定，甚至纯手撸原生Javascript均可以，怎么忽然多出了这么多东西。例如ReactJS只是单纯的View层的解决方案，而Redux是一种状态管理框架，不只支持ReactJS，还支持Angularjs, 官方宣称的是它能够支持任务其余的视图库。正因愈来愈复杂的前端需求，层出不穷的前端解决方案和技术的推陈出新，造就了前端社区异常火爆的局面。而本文主要探讨前端的状态管理（State Management）

服务端渲染的WEB开发

服务端渲染图示

 

就在几年前，前端工程师的大部分工做，可能还停留在利用CSS, HTML切页面，而后利用JS作些简单的动态交互，更进一步的前端开发者可能须要懂Java, 或者PHP之类的语言，由于须要将写好的页面与模板引擎完成整合。

用服务端语言（例如NodeJS, Java, Python, Ruby, PHP等等）写过Web的朋友应该都很清楚，之前大部分时候咱们写的Web，尤为经典的MVC模型。多年之前，那会还不流行先后端分离式的开发，虽然Ajax技术已经很流行，可是Web页面的功能和交互并无那么复杂。大部分的页面点击一个链接，即请求到服务器，服务器控制路由（Router）决定响应的View，服务器将数据库获取的数据Model与HTML模板结合，而后生成HTML页面响应到浏览器。那时候Web大部分的业务都是服务器直接处理的，不少所谓的状态管理也都是服务端直接操做操做缓存（Cache）或者数据库来完成的。因此那时候的前端并无太多的所谓的状态须要管理，顶多你们有时候会在内存里面用一全局对象，来处理些简单的数据共享。随着Web前端的发展，愈来愈多的后端工做转移到了前端，数据的共享，同步变的异常复杂和麻烦，因此这个时候急需这种完善的状态管理解决方案的出现。

先后端分离的单页应用(SPA）

单页应用与服务器端交互图示

 

单页应用（Single Page Application）

利用Ajax作单页应用，经典的案例确定就是Gmail了。早期可能你们都还用iframe这种古老的子页面加载方案，随着Ajax技术的愈发成熟和盛行，后来愈来愈多的Web应用开始利用浏览器Hash作路由转发，Ajax作页面加载 的方式写无跳转状态的Web应用（即单页应用。后来便有了相似Backbone, Angularjs为表明的MVVM前端框架的诞生。

浏览器愈来愈快的访问性能，早就了愈来愈多的PC应用开始WebApp化，不少时候咱们不须要安装某个应用，只须要简单的输入一个URL地址，即可以轻松访问咱们须要的服务，相信不少朋友已经在使用Chrome上不少强大的Web应用了。愈来愈多的Web开始想靠近相似于Native应用化的体验，因此SPA这种类型的Web开发愈来愈受欢迎，典型的就是咱们经常开发的后台管理应用了。

组件化与状态管理(Web Component And State Management)

组件直接的数据共享

 

Web组件化(Component)一个是被聊透了的话题了，它的益处无需多言，更好的编码效率，更好的代码阅读性，维护性，补充HTML5语义化标签的不足。然而，正由于在开发愈来愈复杂的SPA时，开始将各个页面开始模块化，页面公告模块组件化，一个页面拆分红多个子组件，组件的不断复用和从新组合，以前简单的组件端到端（组件到服务器端）的数据请求变的复杂和多余，单个数据源常常在不一样页面但相同组件中共享，各类路由信息（Routing）须要处理。

咱们能够想象一下，当一个页面中，相同的组件获取来自同一个接口的数据，这就意味着组件共享的是相同的数据Model。 正常逻辑下，其中一个组件若是进行了Model更新操做，服务器数据库的数据即相应的发生了改变，可是其余相同数据接口的组件，因为组件直接是相互隔离的，数据Model并非同一个，因此组件与组件直接的数据通讯便成为了一个很大的问题。固然，咱们有个粗暴的解决方案，就是，在某个组件更新完数据后，咱们从新reload整个页面，可这个时候整个本来想达到的SPA效果就没有了，体验大减，而你打开Network检测工具，你会发现整个页面发送了多个重复的接口请求，这无疑形成了很大的性能损失和资源浪费。因此才会出现Redux,Vuex这种专门针对状态管理的技术方案。

总结

总而言之，并非全部的Web应用和使用场景都须要添加状态管理，不少时候服务端渲染任然是更好的选择，而是否须要添加状态管理框架，是用Redux，仍是Mobx, 咱们能够根据本身的业务实际状况和技术团队的偏好而添加，而有些状况下，本身建立一个全局对象多是更适合的选择。有的人可能以为Redux这种函数式编程的方式让人难以理解，那么你也能够选择Mobx这种面向对象编程思惟的状态管理框架。若是你以为React这种骑术门槛过高，适应能力差，我以为VueJS, Vuex多是更适合你的选择。

说了这么多，但愿本身能解释清楚前端状态管理是怎么一回事。

原文地址http://imziv.com/blog/article/read.htm?id=80