项目优化---业务实践封装一

114 阅读3分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第1天,点击查看活动详情

不知道怎么起一个响亮的名字,暂且作罢。汇总一下上周和本周参与项目的一点点记录和总结,也许谈不上总结,可能算是想法吧。和业务封装有关话题,有几个前置条件,文字慢慢表述太麻烦了。不如一条一条列出,来的直接。

1、项目是临时参与,抓壮丁呗,参与时间短,干完一个功能模块就走人,所以给自己一句话,“要节制”
2、业务范畴是和投标相关的项目,就是甲方供应商和专家互动的过程,各种评审和文档确认环节。有点博弈的意思,两者之间又频繁互动的过程。
3、框架采用的是vue3+vite,需要说的是频繁实时交互,考虑消息及时性,技术上则会用到消息通信相关。我拿到项目后,发现用了4秒发一次http请求的方式,真是为了不大材小用,虽然心里觉得不妥,这种情况,你说的对,好好好,能接受,就这样。

以上就是前置条件,下来就是项目中自己看不下去的部分,搞了简单的封装,主要是为了方便提效

项目的第一眼--怎么使用的消息通信的啊

微信图片_20220812114032.png

里面的方法块本来散于其他地方,这是简单汇集后的,方便截图

能看出什么吗?

我拿到后,看的有点木乱,都是什么跟什么啊。

  • 用到了hooks,有点欣慰,不过解构里面的pbRoom是什么鬼,名字起的太拙劣了吧。中英结合体,评标房间,好吧。想起来了一句话,“要节制”
  • 还要const pbRoomHook = pbRoom() ,执行一下。。。继续
  • watch什么。监听store里面的socketMsgData状态,接收消息的,为什么要这样搞,原来是系统加载的时候,定时4秒钟发一次请求,然后放到store里面,更新状态,难怪要监听,也不能每个组件都监听吧。。。十几个组件在一个页面呢哦。。。。

我们来看看,十几个组件堆积的场景:
微信图片_20220812114909.png

组件拙劣命名

想起来了一个“域冗余”,妥妥的表现,上次目录都说了这是components,目录下的子文件名还要加前缀Components

已经建了,不想改了。实在不然要和另外一个前端逼逼了。。。

  • 有个show方法,是点按钮显示后,pbRoomHook.socketSend 发送消息的

总结或者想法对白:

watch不能每个组件监听,需要收进去,封闭起来,每个组件不能引,太恶心了,而且在组件中使用,const pbRoomHook = pbRoom();

这么干有点奇怪,不喜欢,也要封闭起来,下来就是改名、改名、改名。

优化第一个版本:

收watch,脱离单个组件,入口页面加载即可

先把需要的方法放到一个文件里面,向外封闭

微信截图_20220812125253.png

微信截图_20220812121219.png

但是上面有2点需要注意

  • 监听socketMsgData的状态后,进行消息识别后,如何让使用的组件能收到消息呢?可以使用订阅发布的方式,先订阅一堆消息主题,监听到消息后,在发布给对应的主题。

  • 引入了工具库的eventEmitter的onon和emit

utils.eventEmitter.$emit(cName, params)
// 信令主题注册
IMService.Register('pb_from_profession_signed')

单组件引入方式

/**
 * 组件使用方式
 * 订阅者
 */
import utils from "@/utils";
const { eventEmitter } = utils
const EVENT_NAME = "pb_from_profession_signed"
eventEmitter.$on(EVENT_NAME,function(){
    // 接收对应信息
})

总结和想法:

第一版的优化,向外封闭,有点效果,引入简单了好多,接收消息部分也简单了不少,但是还是有点麻烦。

代码上还是有一些多余的定义。

组件内部使用部分,虽然简单了不少,但是还是又丑又长

想了想,能不能这样

// 接收部分
IMController.receive(EVENT_NAME, (data) => {
    // 接收对应信息
})

// 发送部分
IMController.send(...)

下章我们继续。。。