对状态管理设计的一点思考

在聊聊我对React Hooks的理解中梳理了对react引入hooks的理解:

• 通用的代码复用方式
• 解决类组件的历史问题,比如在新的架构下生命周期函数重复执行、代码逻辑分离的问题
• 规范使用(代码)范式

在当我们聊状态管理的时候我们在聊什么中梳理了状态管理库redux和mobx相关实现的原理等. 通过对上面文章的回顾总感觉缺少点什么有些东西没有聊透,这篇文章在前文的基础上聊下对状态管理设计的一点思考.

为什么要做状态管理的设计

这里想尝试用一句话去描述做状态管理设计的目的: 通过合理的状态管理设计,可以在面向未来的业务扩展中减少代码的劣化和增加程序的扩展性.
页面是由数据组合而成的,从数据类型上划分,可以分为:

• ui状态 这部分主要为ui状态 较少涉及到持久化或者跟服务端交互
• 数据 从服务端获取的要展示的数据
• 共享逻辑/全局状态等 这个可以理解为一些全局共享态或者依赖数据的计算逻辑 从数据出发进而拼接成组件/功能模块到业务表现层就可以形成多个业务模块. 在技术和业务的演进中会增加状态管理层的概念,为了实现状态的集中化管理,在状态管理中就需要实现数据的分发和数据的变更通知能力.
  在进入好的状态管理设计之前,先从日常开发的一些例子说起来看下‘不那么好’的状态设计是什么样子的.

这里我们化繁就简回到传统的MVC结构来看当前实现可能出现的一些问题
在视图层:

• 承接更多的数据逻辑 比如数据获取和数据操作导致代码越来越重不可维护,比如在react中可以通过复用的hooks去获取数据
• 组件模块拆分粒度低 在绑定多个数据源的时候页面频繁渲染

在数据层:

• 数据层似乎就是一切 似乎一些不要的状态(ui状态)也存在了数据层
• 缺少领域(模块)划分 特别是在数据变更组件更新的场景,缺少划分容易造成多余的组件渲染
• 复用性低 单纯的数据逻辑不可测
• 数据模块之间耦合性高

在Controller层:

• 控制层被弱化 控制层的功能其实都在数据层中承接,无法实现更好的分层结构

‘好的’状态管理设计

其实还是回到了设计的原点,好的设计其实还是在于如何设计分层与解耦

分层

• 数据之间的分层
• ui状态/数据状态的隔离
• 控制层/数据层的分层

解耦

• 数据与UI的隔离 这样数据层可测
• 数据层之间如何共享 可以通过一些依赖注入库解法,降低数据层之间的耦合

一些想法

react最近推出了React Compiler可以在编译阶段对代码进行优化,结合react19的一些新的hooks,感觉 react在尝试给出一些在react体系下的一些通用解法.react似乎在变得不那么‘轻量’.通过react引出的一个想法是在大型项目的维护中定义强制的规则或者开发范式似乎 是更重要的.提供少量的接口(范式),也许是更好的解法.

参考

前端状态管理设计——优雅与妥协的艺术