状态决定视图——基于状态的前端开发思考

前提

在如今的前端社区，关于MVVM、Model driven view 之类的概念，已经算是很是普及了。React/Vue 这类框架能够算是表明。
而本身虽然有 React/Vue 的使用经验，也了解 MVVM，状态机等核心概念，可是却一直没有很好的应用。

直到前几天接手一个组件开发的需求，写以前尝试细细分析时，才忽然想通这之间的联系。
Emmm……内容比较浅，并非什么了不起的神兵利器。更多的是我的的感悟。

我的困惑

本身在前一段时间里，陷入了如何写好代码的困惑之中，在学习了《重构》、《代码整洁之道》等知识以后，确实有一些好转。可是写代码老是要重构才能好一些些，也是很麻烦的事情，因而就有了以下的思考。

前端与状态

如今的前端开发中，对于状态的管理是重中之重。
而使用 React/Vue 这类 MVVM 框架，经过组件化、自动绑定等方式，能有效下降前端开发时的复杂度。

MVVM

提到状态就不得不提到MVVM框架，而MVVM的框架的核心，并非双向绑定或者依赖收集什么的，而是：状态决定视图。
用代码描述就是：

View = ViewModel(Model)

理想状况下，ViewModel是纯函数，给定相同的Model，产出相同的View。

随着前端的发展，Web应用的状态管理愈发复杂，然而因为前端的一些特性：

• 代码开源
• 请求透明
• 不保存用户数据
• ...

也决定了前端只负责整个Web应用上的视觉和交互层，凡是涉及到数据的，后端必然要作严谨的校验，不相信任何前端的请求。
因此前端的核心工做，就是提供一个友善的人机交互的操做界面。固然，这也符合广义上的前端定义。

而 MVVM 的出现，能有效的提升前端开发的效率和品质，从而获得了大规模的发展与应用。

复杂度

在《代码大全2》这本书中，有句让我印象深入的话：

软件工程的本质便是管理复杂度。

细细想来，也确实是如此。
前端开发天然也属于软件开发，管理复杂度偏偏也是前端目前的核心问题。

有限状态机

那么如何更好的管理前端软件的复杂度？ React 的状态机思想给出了本身的答案。
状态机是我在学习计算机中，时常听到的一个概念，好比学 React 时，会提到 React 就是个状态机，听团队关于编译原理的分享时，也会听到状态机。因此就去专门补习了这个概念。

有限状态机在维基百科上的描述以下：

有限状态机（英语：finite-state machine，缩写：FSM）又称有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动做等行为的数学模型。

有限状态机并非一个复杂的概念

简单说，它有三个特征：

• 状态总数（state）是有限的。
• 任一时刻，只处在一种状态之中。
• 某种条件下，会从一种状态转变（transition）到另外一种状态。
  它对JavaScript的意义在于，不少对象能够写成有限状态机。

启示

随着对状态决定视图与状态机两个概念的学习与思考，因而有了新的思路：

状态决定视图，Action则负责完成状态间的转移，那么写好代码的核心在于，用最恰当的状态去描述界面，用最恰当的动做去完成状态间的转移。

Emmm……很简单的概念，可是本身以前一直没有想的很清楚。

总结

随着对这个概念的了解，本身在开发时的思路也愈发的清晰化。
本身如今写代码以前，会思考一系列问题，想清楚再下手：

• 这个页面有几种状态（初始化状态？成功状态？失败状态？出错状态？）
• 描述这些状态须要什么参数
• 在何时转变状态，须要改变哪些部分

把这些问题想清楚了，剩下的工做就是跟着思路，完成数据与UI部分。
以上就是本身的思路了，若是各位有什么建议的话，欢迎和我交流呀 ? ~

参考资料

• 有限状态机 - 维基百科
• JavaScript与有限状态机