状态管理库的理解,hooks、vuex、pinia应该如何正确使用

1,622 阅读4分钟

废话

挺久没有写文章了,没啥太多高深的可以说。这次再谈谈状态管理吧,也是我这4年来的一个始终使用的方式。

一、什么是状态管理?

首先这个词我不是很喜欢。这个词的范围也太大了。在前端一般的状态管理中,包含了全局公用数据、内部业务数据、非业务数据三方面的数据管理。

抛开抽象名词,其实状态管理就是数据管理。如何让数据在项目中被更好的管理。

我更喜欢把这块称之为前端数据库管理。当然前端其实对于这块是比较散乱的。

二、我认为的对于vuex,pinia,redux错误使用方式

1、以vuex为例,经典的购物车案例

我们都知道早期文章都灌输一个思想,vuex可以共享组件数据,并且具有响应式。

最经典的例子购物车:

定义一个购物车列表

商品页面

数据添加,然后放到购物车列表

多个页面都可以使用购物车的数据

数据就是

vuex
shopList: [{name:'', id: 1}]
axtion: {
    setShopList(state, data) {
        state.push(data)
    }
}
商品页面
$store.commit('setShopList', data)

2、正确理解购物车数据定位

从数据库角度来看,购物车应该是一个独立的表,从全局系统角度他是一个公共数据表,但是服务于特定业务场景的购物车。

那么假设有系统dht

下面的子表就是shopList

从文件放置位置来说,放在store下面,shopList模块(文件)中

这样很好,从后端的数据管理角度没问题。并且从后端角度看,这是解耦的,每个模块(系统)负责一部分功能

3、前端不是后端,前端是一个业务集合体,不管是以前还是现在,前端对于页面访问速度都有要求,哪怕你是个后台系统

从小型项目来说那样做没问题,但是前提是这个项目永远的小,不会变大。

如果变大,那么就造成了我首次启动系统的时候需要加载业务数量的模块数据

一个大型后台管理系统(页面少说都是50+以上),对接的后台系统可以是一个,也可以是多个。但是你要这样把所有的模块都堆积到系统启动上面吗?

为什么后台可以这么干,因为后台不是实时启动。是先启动好了,等着用户去访问。

但是前端等于是一个客户端,需要把所有可用模块加载完成之后才可以访问。

三、不管是老时代html,还是现在的hooks

1、html时代工程化举例

除了jq等第三方插件,其实对于数据管理,应该是有一个独立的js文件去管理数据的或者是一个数据对象去管理

但是每个页面都是独立一个html文件,所以一般不是太在意。而且那时候的前端大多数并没有工程化的概念

2、vuex,redux,hooks时代

这种需要全局加载的数据或者代码应该只负责需要全局加载的数据部分。减少首次加载。其实对于一个前端页面来说,首屏加载在300kb到500kb以下才是合理的。但是现在往往是组件库(大家都不管按需加载)这个毒瘤导致了首屏无法降低到2M以下。

3、数据管理就应该只是管理数据,不要和服务管理混合

除了按需加载数据模块之外,其实对于vuex或者是redux我比较烦看到的是,为什么要把接口数据写到vuex模块中,这样不就多加载了一个模块,还是强耦合。然后特别容易发生一件事就是,我想要两个模块之间互相调用就完了。而往往数据服务模块会使用数据库(vuex)获取一些关键数据进行处理。

4、致谢

往期文章:

三年不断优化更新的接口服务封装代码推荐,支持后端多种微服务对接,可多平台移植使用

前端数据缓存(前端数据库)的一些见解,利用内存存储帮你优化接口请求