add event bus example to help v1 expectations

[eljefedelrodeodeljefe]

This adds an example of how to use similar behavior like with
$broadcast / $dispatch in v1. The motivation comes from not using
vuex immediately for shared state components.

Not sure whether this would need to go rather into a guide, but I wanted to start a discussion about this globally, as I am not the biggest fan of the vuex pattern. This would ease my expectations as a developer coming from v1

[chrisvfritz]

@eljefedelrodeodeljefe Have you seen this section in the migration guide?

[eljefedelrodeodeljefe]

Yes. And I found it a little confusing, because of this eventhub object. In a template file and browserify based workflow I wouldn't really know how to get a reference to the object. I think deprecating dispatch and broadcast was a right decision, but there should be an equal alternative that is evented - speaking as a backend developer.

[eljefedelrodeodeljefe]

Of course one could just require the eventhub everywhere, but that seems a little steep and not so lightweight, no?

[chrisvfritz]

If you're using a module system, you don't actually have to do anything special to get a reference to the object - just export it from a file just as with any other module:

module.exports = new Vue()
// OR
export default new Vue()

Doing this isn't really "heavy" unless you consider module systems themselves heavy. If you prefer to access the event hub globally on any component instance though, you can also do this:

Vue.prototype.$eventHub = new Vue()

Then you can do this within a component:

methods: {
  addTodo: function (newTodo) {
    this.$eventHub.$emit('add-todo', newTodo)
  }
}

[eljefedelrodeodeljefe]

No, sure, but I meant that the Vue instance just for being an event hub is heavy, considering that the instance you are using has this functionality already built-in. It's just extremely bad style.

[chrisvfritz]

Vue instances are actually very cheap if you're worried about performance.

[eljefedelrodeodeljefe]

No, I am worried about style and what documentation suggests and what it not suggests. As is it's promoting vuex for shared state management with a very bad style alternative of using an event hub via an object that doesn't have this as sole purpose.

[chrisvfritz]

What specifically are you worried about with the alternative mentioned in the guide? Having a separate event hub has distinct advantages, most notably that you can use it across many root Vue instances or even it outside of components.

[eljefedelrodeodeljefe]

1. It's not really modular. When I wanted to do something like that in backend development, I would either require a global EE or extend from an EE.
2. It doesn't follow do one thing and do it well, as Vue for sure is no EventEmitter and can easily see API changes, when the global dev scope requires it, as just done with Vue 2.
3. it's just plain bad bad style.

Not here to argue about good coding practices, especially since I find fronted dev and frameworks peculiar. Closing.

[riccardolardi]

Just to say I too would be really glad about a clear best practice on this. Find it hard to transition from $dispatch and $broadcast to this new system.

[chrisvfritz]

@alberto2000 The best practice is laid out here: use Vuex. In cases where that's too difficult a transition, the global event bus example should a fairly painless process, since the migration helper catches 100% of instances and much of it can be handled with find-and-replace.

[riccardolardi]

@chrisvfritz thanks. only problem I have is I have multiple instances of the parent component and when I emit a notification from a child, all those instances register it - instead of just the one that's parent to the child - earlier $dispatch would be perfect here

[chrisvfritz]

@alberto2000 Component's custom events allow you to do the same thing, but more explicitly.

[riccardolardi]

@chrisvfritz how can I communicate from a child only to its own parent but not to all other instances of that same parent component? They all are listening to the same event and will catch it too, right?

[chrisvfritz]

Nope. 🙂 Try it.

[riccardolardi]

@chrisvfritz I did and that's what happened. I have four parent components, each has a child. Now, one child component emits an event and I'd like it to be only heard by its own parent - the problem though is, that all other parents hear the event as well. $dispatch would only send the event up the tree along to the "real" parent...

[chrisvfritz]

Let's open a thread on the forum then. Post a code example and ping me, then it should be easier to see what's going wrong in your case.