Side navigation
#11945 closed feature (wontfix)
Opened June 21, 2012 10:10AM UTC
Closed October 29, 2012 05:07PM UTC
Last modified November 27, 2012 05:43PM UTC
Event: hasEvent() and so on.
Reported by: | damien | Owned by: | damien |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | event | Version: | git |
Keywords: | 1.9-discuss | Cc: | |
Blocked by: | Blocking: |
Description
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.
Attachments (0)
Change History (14)
Changed June 21, 2012 01:22PM UTC by comment:1
owner: | → damien |
---|---|
status: | new → pending |
Changed June 21, 2012 02:02PM UTC by comment:2
Weren't we going to provide a plugin in for this?
Changed June 21, 2012 02:05PM UTC by comment:3
status: | pending → new |
---|
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.
Changed June 21, 2012 07:27PM UTC by comment:4
status: | new → pending |
---|
@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.
Changed June 21, 2012 10:24PM UTC by comment:5
status: | pending → new |
---|
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.
Changed June 23, 2012 01:23PM UTC by comment:6
_comment0: | 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 I thought simple Boolean-returning method that said whether the element had a particular event (or event.namespace) attached. Something like `jQuery.event.has(elem, "click")`. \ \ → 1340457829378803 |
---|---|
component: | unfiled → event |
keywords: | → 1.9-discuss |
milestone: | None → 1.9 |
priority: | undecided → low |
status: | new → open |
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")
.
Changed September 27, 2012 01:41PM UTC by comment:7
-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.
Changed October 14, 2012 10:30PM UTC by comment:8
-1
Changed October 14, 2012 11:29PM UTC by comment:9
-1, Maybe an events() (as a alias for data("events")?)
Changed October 22, 2012 05:20PM UTC by comment:10
-1
Changed October 22, 2012 05:31PM UTC by comment:11
-1, We should expose some way to peek at events, but this doesn't seem that useful.
Changed October 29, 2012 05:07PM UTC by comment:12
resolution: | → wontfix |
---|---|
status: | open → closed |
Changed November 06, 2012 01:03AM UTC by comment:13
+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.
Changed November 27, 2012 05:43PM UTC by comment:14
milestone: | 1.9 → None |
---|
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.
Do you have some intended use cases? How would you account for delegated events?