一次踩坑经历看vue几个组件通信的适用场景

一次业务中Vue组件通信的踩坑记录

踩坑场景

一次踩坑经历看vue几个组件通信的适用场景

一次踩坑经历看vue几个组件通信的适用场景

需要的效果是移动端的一个编辑个人信息的页面。点击姓名一栏,跳转到另一个页面去编辑姓名。

其中,设计到的通信时有2个方面

  • 点击姓名时,携带name跳转到【姓名编辑页】,并显示到input上
  • 用户走编辑接口时,需要跳转回之前的页面,并且把修改后的name携带回来。
那么如何做呢,我把这两个vue组件,很草率的设计成【不同路由】的组件了。计划用eventBus或者vuex通信。

由于缺乏认知,没有真正的理解eventBus和路由传参、vuex各自的适用场景,所以才造成了草率的设计,

实际上,这里的组件关系设计是不合理的,应该设计成父子关系。因为从逻辑上他们也是父子关系,也方便通信。

选择用eventBus来做的“瑕疵”

我使用eventBus后,基本上可以通信了,但有点“瑕疵”

在用户点击姓名一栏时,我跳转路由,并且$emit触发事件
一次踩坑经历看vue几个组件通信的适用场景

在编辑页面,我在mouted里$on监听事件

一次踩坑经历看vue几个组件通信的适用场景

这样的导致的Bug是,第一次进入编辑页时,无法监听到事件,数据也无法被传递到编辑页面

原因是,第一次emit时,编辑组件还不存在,还没监听你就触发,自然是触发不了事件的。

那么,这算不算eventBus的缺陷呢?

我觉得这是由于我对eventBus的理解不够。

我以为eventBus是专门处理兄弟组件之间通信的,但是实际上,eventBus是专门处理 [同一个路由下] 的复杂组件之间通信的。

如果涉及夸路由的组件通信。可以考虑利用$route对象传参或者Vuex

在上面例子中,跨路由的组件通信,使用eventBus可能出现我emit,但是另一个组件还不存在,也没有监听。

导致第一次的数据传递失败.

选择监听$route的变化

这也是一个不错的方法

点击phone时,我click事件里,跳转路由,并且传递params参数

一次踩坑经历看vue几个组件通信的适用场景

在另外一个页面,我通过this.$route
一次踩坑经历看vue几个组件通信的适用场景
.params.phone赋值给phone

选择用vuex做

Vuex来做的话也可以,但是其实不太合适

在点击name时,我跳转路由,并且提交commit来修改state

一次踩坑经历看vue几个组件通信的适用场景

在编辑name的页面,选择用this.$store.state.name绑定到Input上,用@input事件监听变化,变化后提交commit

一次踩坑经历看vue几个组件通信的适用场景
一次踩坑经历看vue几个组件通信的适用场景
一次踩坑经历看vue几个组件通信的适用场景

回到最初,设计成父子组件的关系。

如果上天在给我一次机会,我觉得一定要把它们设计成父子关系。

最后总结一下Vue通信的几个方式,和各自的适用场景

  • 父子组件通信: 父子关系
  • eventBus通信 : 同一个路由下,复杂组件的通信。
  • Vuex: 全局的、跨越路由、非父子组件的通信都可以用它关系
  • 利用$route的params或者query: 跨路由的可以用,但同一个路由下就不适合用了。
  • localStorage / cookie / sessionStorage: 全局可以用,但是存储到本地
  • 甚至利用Vue实例上添加值 (不建议)

相关推荐