原生“跨组件”通信方式

2023年 11月 13日 63.5k 0

现在已经是“组件化”开发时代了。

相信大家平时在vue或者react中都碰到过“跨组件”通信的需求,通常我们需要将数据放在一个公共的父级上,然后用context之类的方式传递下去,或者借用pinia这样的开源库去更好的管理这些数据。

不过,大部分项目可能没有那么复杂,可能只有极少部分需要“跨组件”通信或者全局传递的,专门去引入一个全局状态管理库还是有一定成本的,不仅仅是性能开销,还有学习成本。

另外,还有一些旧项目,由于前期组件设计未考虑周全,或者由于后期需求迭代,导致需要跨组件通信,此时再引入状态管理库也有很大的改造成本。

框架用久了,可能有些都忘了,原生 web 并没有组件化的概念,整个页面都是开放的,所以,借助原生的一些行为和方式,也能很轻易的解决“跨组件”通信问题,下面列举了几个方式,一起看看吧~

一、label for

举个例子,下面是之前做的一个错别字纠错功能,也就是自动检测错别字,然后提供替换和忽略一些功能,如下:

现在不用关注是怎么实现的,如果按照组件化拆分,右边的纠错面板肯定是单独的组件。

很自然的,关于忽略的相关函数也是写在这个组件,类似于这样。



const ignore = () => {
  // 相关操作
}


...
忽略
...

嗯,很好,组件化很不错,逻辑也很清晰。

过了两天,产品又需要在另外一个地方也要有“忽略”功能,当鼠标悬浮的时候,下拉选项中也有忽略选项,并且这两个忽略的功能是完全一样的,如下:

再单独实现一遍肯定是不行的,把这个函数抽离出来?但是还有新的问题,整个错别字的列表也是需要更新的,是不是也要把这个列表也独立出来?

no,当然不需要这么麻烦,仅需要一个label标签就可以轻松搞定,如下:



...

  忽略
  ...

...

当然,右边的忽略按钮也需要加上一个相同的ID(实际中是动态生成的)。



...
忽略
...

这样,通过label+for就将这两个元素关联起来了,点击这个label元素就相当于点击了右边的忽略按钮,无需任何跨组件通信,是不是非常方便呢?

二、主动触发事件

有时候,需要通信的事件可能并不是通过按钮点击的,比如这样一个写作页面,按照页面布局和功能,各个部分肯定是单独的组件,如下:

其中,右上角有一个“保存”按钮,可以保存内容,假设是这样。



const save = () => {
  // 相关操作
}


...
保存
...

现在,产品又提出一个要求,希望在写作时,按 Ctrl + S也能保存内容。

那么,你会怎么处理呢?把保存方法封装一下?全局通信?

其实,我们要做的事情很简单,只需要主动去触发一下保存按钮的点击事件就可以了,当然需要获取到这个按钮,所以要加个ID。



...
保存
...

然后在写作组件中直接通过触发click事件就好了。



// Ctrl+S 保存
const save = () => {
  document.getElementById('saveBtn').click()
}

当然,我更习惯于用dispatch的方式来触发。

document.getElementById('saveBtn').dispatchEvent(new Event('click'))

这样的好处是不限类型,任意事件都可以触发,而不仅仅是点击事件。

dom.dispatchEvent(new Event('mouseover'))

关于dispatchEvent,下面还有更灵活的运用。

三、dispatchEvent 和 addEventListener

dispatchEvent不仅可以触发常见的点击事件,也能够触发任意自定义事件。

举个例子,有两个相互独立的功能区,有两个按钮,分别点击后,会做一些操作,比如请求接口,最后会弹出同一个奖励弹窗

如果按照组件话的思维来考虑,可能需要将奖励弹窗的状态放在一个公共的父级,然后依次回调,或者用全局状态管理库区管理这些状态。

但是,如果从原生 web 来考虑,其实不必那么麻烦,下面是一些伪代码。



const getPrize = () => {
  // 领奖励一系列逻辑
}


...
领奖励A
...

然后还有功能区 B。



const getPrize = () => {
  // 领奖励B一系列逻辑
}


...
领奖励B
...

然后还有奖励弹窗。



const open = () => {
  // 打开弹窗
}


...
奖励弹窗
...

那么,怎么让其他功能区的组件打开奖励弹窗呢?

这就需要用自定义事件了,很简单,直接触发一个自定义事件,假设就叫做prize。

document.dispatchEvent(new CustomEvent('prize'))

放在业务组件中就是。



const getPrize = () => {
  // 领奖励一系列逻辑
  document.dispatchEvent(new CustomEvent('prize'))
}


...
领奖励A
...

然后,我们可以在页面任意地方都监听到这个事件,直接通过addEventListener就可以了。

document.addEventListener('prize', () => {
  // 监听到了prize
})

所以,我们可以把这个监听直接放在奖励弹窗组件中。



const open = () => {
  // 打开弹窗
}

onMounted(() => {
  document.addEventListener('prize', () => {
  	// 监听到了prize,打开弹窗
    open()
	})
})


...
奖励弹窗
...

这样,无论组件是什么样的嵌套关系,都可以随心所欲地通信了。

四、最后总结一下

本文更多的还是提供一种思路,实际开发中可以自己权衡,什么方式比较合适,下面总结一下这三种方式

  • label for比较适合于按钮点击事件的复用,可以将label元素与button元素绑定起来。
  • 相比label for而言,主动触发事件更灵活,可以触发任意事件,无需button元素,也不限制点击事件。
  • dispatchEvent 和 addEventListener是最灵活的方式了,几乎可以做到全局通信,通过dispatchEvent触发,然后通过addEventListener监听。

当然,这些方式也不能滥用,毕竟用多了就显得逻辑混乱,如果全局通信的情况比较多,还是建议使用传统的组件化方式就行管理。

相关文章

JavaScript2024新功能:Object.groupBy、正则表达式v标志
PHP trim 函数对多字节字符的使用和限制
新函数 json_validate() 、randomizer 类扩展…20 个PHP 8.3 新特性全面解析
使用HTMX为WordPress增效:如何在不使用复杂框架的情况下增强平台功能
为React 19做准备:WordPress 6.6用户指南
如何删除WordPress中的所有评论

发布评论