Question with v-view and event bindings about discussion

Depending on the type of event you are using they will be destroyed when the ViewModel is destroyed (read bottom of http://vuejs.org/guide/events.html). However, if you are using some of the ViewModel events such as vm.$on or vm.once you can manually destroy those with vm.$off (see http://vuejs.org/api/instance-methods.html#vm-off-event-callback-). If you are setting up event listeners with native Javascript or jQuery you will have to also manually destroy those events.

[malkomalko]

http://cl.ly/image/0W2w0C2t1a3C

That's a quick ss of the type of event I was talking about.

Not tested but you should be able to stop listening for that event with vm.$off

[yyx990803]

When a VM is destroyed, no matter manual or automatically, all its listeners are turned off, both $on and v-on types.

[malkomalko]

Thanks for the clarification. One thing I'm trying to reason about with these events is you have to have an idea in your head on the hierarchy. Sometimes in order to communicate b/w components you have to $dispatch an event up, catch it with an $on at the top component and then $broadcast to another child component.

Thinking maybe it would be a better idea to just dispatch the event once from the vm of choice. But having a lot of component.$parent.$parent just to find the correct vm kind've stinks. Maybe a way to target the parent vm by name so you can dispatch properly.

Hopefully this wasn't too cryptic, just starting to find some patterns as I'm building out my app with Vue.

[malkomalko]

Is there some property to access the component name from the view model? If so I can just iterate up through the $parent stack to get access to the appropriate component.

[yyx990803]

The built-in VM events are meant for reusable components, which often have no knowledge of what the surrounding hierarchy looks like.

When you have full control of the components and their structure, it is often cleaner to have a global event bus shared by all VMs. This way you don't have to worry about propagating events and still keep VMs loosely coupled.

[malkomalko]

@yyx990803 I'm thinking you could still get the reusable aspect of components by still having a global type of event bus. What do you think the tradeoffs are of broadcasting your apps events from $root?

[yyx990803]

By global event bus I mean just a single Emitter instance, accessed by all VMs, and you simply namespace the events. When broadcasting you are recursively walking down the entire VM tree which can be expensive when you have large structures.

[malkomalko]

Yah, now after thinking about it I probably wouldn't go that approach and would want to try to keep all of my components designed in a way they are isolated. If that means having to manage the pathway of events firing to get to the right place, I can live with that.

[yyx990803]

The propagation mechanism is just like DOM events, and since you compose components in the DOM, personally I find it pretty natural to work with.

[malkomalko]

Love it! Closing this.