聊一聊的有限状态机

1,073 阅读6分钟

一、前言

现代前端开发框架,如React、Vue、Mina(小程序可以理解为类Vue框架),都是由状态来控制视图的生成和更新,即状态决定视图,状态发生变化视图自动更新,无需开发干预其更新的过程。

二、现代前端开发框架存在的弊端

react编程艺术.png 现代前端开发框架的编程哲学UI=f(state),即视图是状态的某种映射,对一个具体的应用来说,映射函数f是确定的,state状态变化之后UI进行相应变化。

简单来说就是状态决定视图,我们开发者所做的工作就是响应用户和系统的事件、编写各种业务所需的逻辑、然后生成响应的状态、进而驱动UI视图更新。(其中驱动UI更新由各个框架内部完成、无需开发者关注,事件响应不是本文的重点,后续再另写文章详细探讨)

换言之,开发者所写的业务代码最终就是为了生成所需的状态,响应时机大致有以下几类:

1. 框架内置事件
2. 用户事件
3. 状态更新事件
4. 全局通知事件

开发者绝大部分的代码都是在处理这些事件触发之后的业务逻辑,过程中有异步接口调用、定时器等异步逻辑,也有上下文计算的同步逻辑,新的状态就在这些逻辑中不断的生成。对于开发者来说非常地自由,因为没有框架会约束开发者对状态的更新行为,某种意义上来说这本来是一种优点,会让开发者写起代码感觉很爽,哪里需要就在哪里对状态进行更新。但从另外一个角度想,这种自由带来的无序,因为太过自由、太过随意,最终就导致本来一次完整的状态更新被迫分散的很多地方,特别的当代码量很大、参与人数很多的情况,这种混乱程度尤为明显,对于不太熟悉这部分代码的人来说,很难直观的判断出哪些状态在哪些时机需要被更新。

一般来说较小的项目,这种矛盾并不明显,如果一个项目需要长期维护和迭代,参与的人较多且会随着时间推移不断变化,最终这写代码将变得难以维护而不得不重写;期间再遇到较大的业务逻辑变更的时候,这种模式就会产生灾难性的后果,会让后续接手的人痛苦不堪。根据过往经历,大致存在以下几类弊端:

1. 状态分散,无法直观感知哪些状态被变更了。特别是使用React Hooks、Vue Composition API写法导致状态更加的零散,甚至层层嵌套,对于开发者来说非常不友好
2. 状态随处可更新,存在很多不必要的中间态状态变更、或者是重复的状态变更,而且很难察觉到
3. 线性编码思维,大部分开发者习惯瀑布式的代码编写方式,过程中发现状态不够用,又去前面补充新的状态,长期来看这种方式效率是较低的

总结:状态及其变更过程不受约束,带来的结果就是随意、混乱、不良的开发习惯

三、有限状态机能解决什么问题

有限状态机是一种用来进行对象行为建模的工具,其作用主要是描述对象在它的生命周期内所经历的状态序列,以及如何响应来自外界的各种事件.

简单理解就是有限状态机用来描述对象的状态,以及响应外界变化所经历的状态序列变迁过程。

当对象的状态数量较多、状态变更比较复杂时,有限状态机能很好的描述整个过程。如果将状态单独抽象出来并构建成状态机,状态的变更都遵循状态机的描述,那么对象的状态及其变更过程就会可读性很强、更直观、更易维护。

四、前端开发引入有限状态机有什么好处

现代前端开发框架的状态及其变更过程是不受约束的,而有限状态机能很好的描述状态及其变更过程,将两者结合起来就可以规避前面所述的弊端。总结了下,至少有以下几点好处:

1. 写业务逻辑前,先设计好状态机以及页面交互,有利于培养整体的架构思维
2. 状态的变更受到状态机的约束,更有规律可循
3. 状态和逻辑分离,一旦交互发生变更,更多的变更发生在状态机的设计上,对业务逻辑的影响相对较小
4. 视图只依赖状态机、状态机的变换由业务逻辑来控制、用户操作触发执行业务逻辑,三者彻底分离,开发过程只需遵循共同的约定,依赖程度很低

五、更进一步

视图、状态、逻辑彻底分离

三者分离之后,意味着遵循共同的约定即可,完全可以独立开来分别进行开发,随着未来分工的精细化程度越来越高,很有可能会发生分工上的变化:

1. 随着视觉稿转代码工具越来越成熟,未来的静态视图开发可能不再需要人工,必须人工参与的部分将会越来越少,如建立绑定关系
2. 有限状态机描述状态及其变更过程,对应到前端开发上来,其实描述的就是交互过程,现实中交互过程是由产品或者交互设计师完成的,他们更熟悉整个过程和细节,状态机由他们来维护会更加的合理
3. 视图只依赖状态机,意味着状态机加上一份测试数据,不需要依赖任何的业务逻辑,即可遍历所有的交互状态,实现自动化测试也会更容易
4. 前端开发的工作会更加的纯粹,都集中在业务逻辑的编写上,开发体验会好很多

有向带环图

描述有限状态机的数据结构是有向带环图,完全可以向绘制流程图一样,通过可视化的方式绘制出来,这样显得更直观、且更易维护

六、参考文章

深入浅出理解有限状态机

探索使用有限状态机(FSM)构建 Web 应用

xstate

前端引入有限状态机旨在将各个开发环节彻底分离,降低它们的依赖,能工具化的环节就用工具替代,以便开发者的精力更加聚焦于业务逻辑,提升前端的开发体验,最终是为了提升前端的生成效率。

欢迎有兴趣的朋友一起探讨~~~