前端为什么需要状态管理

什么是状态

百度百科是这样介绍的：状态是人或事物表现出来的形态。
我们举个生活例子来理解下状态与状态改变：
状态可理解为精神上一种现状，即当前的心情。
那状态是如何改变的呢？比如你刚找到一个女朋友，那刚开始恋爱的时候可理解为初始化状态，后来经过相处，你们又刚开始恋爱时期变为热恋时期，你又达到了一种很幸福的状态，在后来你女朋友跟别人跑了，你又达到了很失落的状态。这就是状态的改变，是通过像相处这样的行为来触发的。

前端中的状态

上面我们了解了状态是当前的一种形态，状态是有行为来触发改变为另一种状态的。那么在前端中，比如用户点击按钮弹出弹出框，点击展开按钮展示更多信息，点击查询按钮查询出很多列表数据等等，因为用户的一些行为触发的页面形态的变化，这些便形成了前端中的状态变化。

概括一下，在前端中，大致有两种状态：
+ 数据状态 （比如后台返回的接口数据）
+ UI状态 （比如显示弹出框）

古今状态管理

既然我们了解了前端状态，下面来看下古今的状态管理。
在古代，前端基本上是没有什么状态管理可言的，当时就是切切图片，用jquery做些简单交互，比如$('#id').addClass('hide');,通过添加一个class样式来改变UI元素的显示与隐藏。这种方式我们可以看成是一种状态的变化。

在今天，我们有了更完善的状态管理机制，来管理页面的状态。比如：redux、vuex、ngrx等等。

为什么需要管理状态

说了这么多，我们前端为什么需要redux等机制来管理页面状态呢？不用它，我们不也这么多年走过来了么，也没见少啥却啥。这个问题，说实话我也郁闷了很久。下面来根据收集到的知识来谈谈这个问题。

现如今大多采用前后端分离的开发模式，后端只负责数据的增删改查，前端来负责页面的逻辑。这种分离模式得益于mvvm框架的出现，来开发单页面应用（SPA），确切说这种状态管理机制的引入是来自于组件化/模块化的开发方式，当一个页面中，相同的组件获取来自同一个接口的数据，这就意味着组件共享的是相同的数据Model。 正常逻辑下，其中一个组件如果进行了Model更新操作，服务器数据库的数据即相应的发生了改变，但是其他相同数据接口的组件，由于组件直接是相互隔离的，数据Model并不是同一个，所以组件与组件直接的数据通信便成为了一个很大的问题。当然，我们有个粗暴的解决方案，就是，在某个组件更新完数据后，我们重新 reload 整个页面，可这个时候整个原本想达到的SPA效果就没有了，体验大减，而你打开 Network 检测工具，你会发现整个页面发送了多个重复的接口请求，这无疑造成了很大的性能损失和资源浪费。所以才会出现Redux,Vuex这种专门针对状态管理的技术方案。其目的就是减少重复的接口请求，提高用户体验。

那是不是所有项目都用状态管理机制更好呀？
当然不是，小项目最好还是不用，因为提高了项目的复杂度，反而不用会更好。这种状态管理机制是针对大项目的，组件树结构复杂，如果不用状态管理机制，两个组件的层级比较远，又用到相同数据，在性能上会有所消耗。

下图不使用状态管理机制：

下图使用状态管理机制：

还需要注意的是这种状态管理机制只是页面的临时存储，如果刷新页面，这种状态存储库就被初始化了，之前的数据状态也没有了。

参考资料：
https://blog.csdn.net/hj7jay/article/details/54340672
https://www.jianshu.com/p/94d8f8a36ab0
https://blog.csdn.net/qq_36263601/article/details/78470522