Open BryceEWatson opened 9 years ago
Cool! I like the idea.
I think this would a nice improvement. I definitely think bubbling should be opt-in only and I think having a new Event
type will be clean. One drawback is that the this.emit(...)
method will need to have a special condition for when it is called with two arguments and the second argument is an instance of Event
. In addition, while I don't expect this feature to add much code, we need to be mindful of how much code is required to support this feature.
Other things to consider:
event.stopPropagation()
should probably be supportedevent.source
should automatically point to the original widget that emitted the eventevent.type
should be populated with the event type used when emitting the eventevent.data
should be a reference to the original data object:+1:
I still support this proposal. I'm not sure when I would be able to get to this issue so I have tagged the issue as help-wanted
in case anyone else has time to work on this enhancement. I would be happy to answer any questions or provide pointers.
It would be useful if an event emitted from a widget could bubble up the DOM and be caught by a non-immediate parent. One example of where this would be useful is in a single page app architecture, where a parent widget may want to control navigation between children based on navigation events. In this case there could be many child widgets which emit nav events, and they may not be direct children.
After discussing with Patrick, it seems like a simple implementation could look like this:
This would make the bubbling optional, and allow the listener to call stop propagation on the event object.