前言
笔者在接到低代码平台开发的时候,就在想,如何对"全局状态"进行管理?在现代Web项目中,基本都是组件式开发。组件有自己的内部状态,用于管理内部的变量。并提供更改这个状态的方法,用于控制状态的变更以及组件的重绘。一个组件往往有一个或多个状态来控制组件变量数据,这个数据可以向下传递给内部的子组件,也可以向上暴露给父组件。形成了数据状态的流转。谓之"数据流"。当一个状态数据被多个组件所共用的时候,我们一般做法是进行状态提升。但是当应用程序体量随着业务的需求增大的时候,组件层级过深,一般的方法已经不可取。所以需要一套方案来解决,全局状态的便捷的传递。
选型
笔者对比了社区大量的方案:Redux,Mobx,Rxjs,Reciol。
Redux
这是一个提高跨组件通信的能力的工具。特点:函数式,模式化。
redux的思想是作为独立于组件的一个数据仓库,对数据进行保护,保障数据稳定可靠,可追溯。
redux像是一个带保护的全局使用的Context(useContext)。dispatch+reducer可以很好的保护原始数据,对于更改只允许使用dispatch进行更改。能够保障可回溯性,数据来源清晰,能够十分良好的隔绝副作用。
Mobx
这是一个响应式的框架,当使用Redux出现疲劳的时候,看到Mobx,确实是相当振奋。通过全局定义一个变量,使用observable的概念进行包裹,生成一个信号源。每当变量进行变化的时候都会触发信号。所有使用这个变量的视图,都会采用订阅的方式收到这个信号从而刷新视图。
Rxjs
这也是一个响应式的框架,api和Mobx很像,但是实现是以流的形式实现,一些api风格和流操作一样,比如管道函数等。该库的定义的状态是分散的,可以任意进行组合。但是该库没有数据变化到页面变化的能力,需要useState和useEffect结合实现视图的刷新。
Reciol
Recoil是facebook官方推荐的一个状态管理库,提供了atom(原子数据),selector(派生数据等概念。
recoil的基础思想是atom数据之间没有关联,产生的关联数据全部由selector来产生,atom的变动,相关的selector随之变动,这个和响应式流的思想一致的。
结论
每个库都有优缺点,要看使用场景。
站在使用Inbiz的选型角度来说,因为组件贡献者不少初级开发者和非技术人员。所有要具有以下几个特点:
1、 使用要极其简单
2、 对组件侵入要小,尽量是零污染
3、 采用ts编写,支持hooks
4、 api尽量与useState一致
基于以上三点分析:
Redux拆分数据比较考验技术,且使用者需要按规则编写dispatch+reducer。同时使用的组件需要connect包裹。不支持hooks。
Mobx需要observable进行包裹,需要重新封装自定义hooks。
Rxjs和Mobx类似。但使用更复杂,api学习成本较高。
Reciol还是属于试验阶段。同时需要拆分状态很细,也很考验开发者能力。
综上其实每个库都不能完全满足我们的场景。所以我们决定博采众长,以响应式入手,采用订阅发布模式,重新封装一个库@inbiz/loong。名字龙作为低代码平台龙脊,我想是挺浪漫的
造轮子的原因是:
1、使用起来简单简单更简单。
2、 完全贴合我们的使用场景,新手友好
3、 不需要手动订阅收集依赖,实现使用即自动订阅收集依赖。
4、 其他个性化需求定制
@inbiz/loong的使用
首先安装
css
npm i @focbiz/loong
然后定制代理对象
javascript
import {loong} from '@focbiz/loong'
const state=loong({count:0})
react组件内使用
javascript
import {useLoong} from '@focbiz/loong'
function Counter() {
const [data,setData] = useLoong(state);
return (<div>{data.count}
<button onClick={() => {
setData({count:++data.count})}>+1 }
</button>
</div>)
}
整个api的使用和react原本的useState是一致的体验,完全不需要任何的学习成本直接上手。