Should work with objects that have their own event system
can-define should work with objects that already have an addEventListener, such as dom elements.
I'll create a test with an object that has its own mini event emitter system so we can better look at the solution.
Added a test here: c93641f8ee441b3d948e47f8f1a8b75ed6d500f7
@justinbmeyer I did a quick and dirty implementation that uses the element's native addEventListener here: 4fbb7ebc549fe083e80d9d7a11d8cf448996e3ba
The result of that change is that the DOM events now fire but the property events do not (without that change the opposite happens).
Last I left off with this there was a problem with can-observation expecting 3 argument events.
I patched my local can-observation to fix this:
onDependencyChange: function(ev, newVal, oldVal){
if(arguments.length === 1 && Array.isArray(ev.args)) {
newVal = ev.args[0];
newVal = ev.args[1];
}
this.dependencyChange(ev, newVal, oldVal);
},
However, it still fails because there is no batchNum associated with this event:
The problem is that I changed can-define to use canEvent.trigger, which triggers real DOM events if it's a DOM element. However this fails because there is no batch stuff happening now.
So I'm not sure how to fix this now. I suppose maybe canEvent.trigger might need to do some batching.
@matthewp I've been thinking about this probably and how it relates to can-operate.onKeyValue. Some event systems won't have a batchNum. It might be possible to "force" this via the onKeyValue symbol / setup. Can explain more later.
@matthewp can-operate only expects a onKeyValue that will be called with the new value. We should talk about what this will mean for this effort.
Just noting that this never was fully fixed, should revisit.