When the element is can-defined, not able to dispatch DOM events

[matthewp]

el.dispatchEvent(new Event("some-event"));

this should dispatch the event on the element, but since can-define sets up its own addEventListener, the DOM event doesn't work.

[matthewp]

There's a test in master that is being skipped for this bug, DOM events work when can-defined

[matthewp]

So to summarize, we need to support both defined property events and arbitrary DOM events.

@justinbmeyer One way to fix this would be to wrap canEvent.addEventListener and fallback to the Node.prototype.addEventListener if the eventName is not one of the defined properties. Does that sound reasonable to you?

Pseudo-code:

var canEvent = require("can-event");

var aEL = canEvent.addEventListener;
canEvent.addEventListener = function(eventName, fn){
  if((this instanceof HTMLElement) && !this._define.definitions[eventName]) {
    return Node.prototype.addEventListener.apply(this, arguments);
  }

  return aEL.apply(this, arguments);
};

[matthewp]

Implemented the above in #19

[justinbmeyer]

Can we use DOM events everywhere?

…

Sent from my iPhone

On Jan 22, 2017, at 4:15 PM, Matthew Phillips ***@***.***> wrote: Implemented the above in #19 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[justinbmeyer]

We probably need can-define to not setup its own event stuff if it exists already

…

Sent from my iPhone

On Jan 22, 2017, at 4:15 PM, Matthew Phillips ***@***.***> wrote: Implemented the above in #19 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[matthewp]

I'm not understanding how that could work. If someone listens to a defined property event it has to go through the can-event system, doesn't it? Otherwise that property isn't bound and won't fire events.

[justinbmeyer]

It doesn't have to go through can-event. can-observation just calls obj.addEventListener("event", callbacks) here: https://github.com/canjs/can-observation/blob/master/can-observation.js#L154

I'm betting it can keep native DOM events and avoid using addEventListener ... the lack of batching MIGHT be an issue still. However, most VM props don't need to change at the same time ... their property values that are objects/lists, which would use can-event, would need batching and have it.

[justinbmeyer]

Regarding batches, you can probably add the event dispatching in the event queue, so it would be fired at the right time. You'll have to make sure it add the batchNum, but everything should be possible.

[matthewp]

I don't think I'm following your suggestion here. can-define does all of this stuff: https://github.com/canjs/can-define/blob/master/can-define.js#L649

You are saying to remove this, correct? If we remove that, how will it know that a property is being observed?

[justinbmeyer]

" property is being observed" happens when a property is being read and isn't related to the code you shared.

However, that code is important. Could we provide our own addEventListener that calls the element's addEventListener as the base functionality instead of the can-event addEventListener?

[matthewp]

Filed canjs/can-define#145