Event: hasEvent() and so on.

[damien]

I propose to have an interface for the undocumented .data('events') storage.

E.g. @return {Boolean} $elem.hasEvent('click');

@return {Boolean} $elem.hasEvent(funcHandler);

@return {Object} all bound events related to the parameter (undefined returns all bound events) $elem.getEvent(undefined|String|Function);

I think a public API like that is necessary since .data('events') is not officially exposed by the docs. Furthermore these functions could be a loosely depending component to remove it within a custom build.

[dmethvin]

Do you have some intended use cases? How would you account for delegated events?

[Rick Waldron]

Weren't we going to provide a plugin in for this?

[damien]

e.g. to avoid double binding it would be possible to check if the event already has the same event bound. Or to receive all available events (which already have handlers) for a specific dom element.

Delegated events are an issue and I have no useful answer (yet) how to solve that :)

A plugin or an optional component for that would be fine.

[dmethvin]

@rwaldron yep, there was some discussion about doing that but .data("events") was undocumented so it's basically creating new functionality. I'm not convinced .hasEvents is the right solution. The other use people mentioned was debugging; that is still doable but not a supported part of the API.

Is avoiding doubled event handlers the only use case? If so it might be better to have a feature like .on("click.mybutton!", fn) with the ! saying you don't want to attach a second handler if there is already a click event with namespace mybutton.

In a large page it's really important to consider that code other than yours may need to attach events so non-namespaced events are a bad idea in general.

I'm still not clear on the scenario where you lose track of the fact that an event handler was already attached. You could always add a class name to indicate the fact, which would also allow you to select the elements that didn't already have that class to attach the event. That seems likely to be faster than either of the two proposed features.

[damien]

I needed that for my toe.js library where I checked if another event of a different type was bound to the given element before firing another event delayed. ​https://github.com/dantipa/toe.js/blob/master/src/gestures/tap.js#L40

However my major concern is that I'm worrying about the reliability of data('events') since it is undocumented and therefor not a public API. So I think a method to access (at least all) bound events is necessary. Even if jQuery doesn't provide any further processing.

[dmethvin]

It doesn't look like the code is using the jQuery special events system, that might make it easier. For example, when a doubletap was attached you could set a data item on the element to indicate it was there.

For this particular use case ("Is some other event attached? If so I'll change the behavior of this event") the only-attach-one shorthand I mentioned above isn't useful. I'll mark this ticket open for discussion in 1.9 but it would be handy to have other examples.

I think a method to access (at least all) bound events is necessary.

I thought what was being proposed here was a simple Boolean-returning method that said whether the element had a particular event (or event.namespace) attached. Something like jQuery.event.has(elem, "click").

[gibson042]

-1 unless we get a clear use case, and even then we should keep it simple. Not having much insight into event listeners is a failing of both W3C DOM and jQuery, but an API we later regret would be worse.

[mikesherov]

-1

[Rick Waldron]

-1, Maybe an events() (as a alias for data("events")?)

[gibson042]

-1

[gnarf]

-1, We should expose some way to peek at events, but this doesn't seem that useful.

[david71rj]

+1 to @rwaldron idea.

I needed that one time, copy a node event to another node. So I have a use case for that. In IE we can't change attr[type] from input or button, so jQuery doesn't allow that in all browsers (​http://jsfiddle.net/Aub7E/2/) but Chrome, for instance, allow that normally (​http://jsfiddle.net/rgyB7/).

My solution is clone input node, but set the new type attribute and re-apply all events from original (and attrs). Currently it doesn't is possible, but can be easily implemented - and it solve the type change bug to IE.

Futhermore, I think that IE6 don't need too focus. But browsers that support can't do that because of IE6.

[dmethvin]

Just to clarify why .events() isn't the answer, the entire data structure retrieved here is undocumented. If we provide a formal documented way to get it we'd need to document the data structure. Given that we may have the opportunity to make changes in 2.0 I don't think now is the best time to do that.