emit semantics
See original GitHub issueEmit is similar to DOM events, but works explicitly within the vdom tree and is user-triggerd. Calling vm.emit(evName, …args) on a view will trigger an event that bubbles up through the view hierarchy. When an emit listener is matched, it is invoked and the bubbling stops.
This does not seem to work well with explicitly injected views, which is the only use case where I have tried to use this api. It seemed natural to emit an event from within a view, then allow for anyone who has access to the vm instance to be able to subscribe to that event. I guess I was expecting something more like EventEmitter than DOM events.
Calling vm.config({ onemit: { event() } })
felt clunky anyway so I think I’ll add on
and off
to domvm.ViewModel.prototype
in my app, but just wanted to spark a discussion since this was somewhat unexpected for me.
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (5 by maintainers)
Top GitHub Comments
oh yeah 😃
made possible by the fact that fancy handlers are already called with
this === vm
Or, just:
?
That would be a great justification for emit, per my comment that GUI events provide the wrong abstraction and need to be mapped to the intended action.