jQuery Forum

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

I've been wondering this too. I assume this is discussed somewhere else that I can't seem to find.

Here's a common use case I run into:

// code to define a custom tab event goes here

function makeTabbingTakeYouToNextEmptyField() {

$('input').on('tab', focusNextEmpty);

}

function makeTabbingTakeYouToNextInvalidField(invalidTags) {

$.each(invalidTags, function(i, tag) {

var $tag = $(tag);

var events = $tag._data ? $tag._data('events') : $tag.data('events');

if (events.tab && events.tab[0]) {

var oldTabHandler = events.tab[0].handler;

$tag.data('oldTabHandler', oldTabHandler);

$tag.off('tab', oldTabHandler);

}

});

}

// Later when field becomes valid the oldTabHandler will be restored

Is it being taken away simply because the current data structure has too much room for screwing things up and it really needs a stronger public API, and this ._data('events') approach is a shim until jquery can get to that place in the roadmap?

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Do you want an abstraction, or do you want no abstraction? If you want to treat jQuery's entire state as exposed and mutable, then jQuery itself will have to assume everything is fair game and its code gets much more complex and difficult to change or optimize. That's especially bad when code written by many different people should be running together on the page, because now jQuery can't guarantee anything about the state to its clients.

Yes, the solutions to most of these edge cases is for you to manage things yourself via an additional abstraction, or avoiding jQuery's abstraction altogether and using a different one. For example, if you don't truly need DOM events involving semantics like default actions and propagation via the DOM tree, then jQuery's own event handling might NOT be the right one for your custom events. Something like promises or callbacks might be a better fit.

As far as making the standard behavior of the tab key change, I don't think that's a good idea.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

I'm not sure I was clear - I wasn't recommending a tab event be a part of jquery, I'm asking what the direction is and why access to the list of events is being removed.

If there is no roadmap to replace the undocumented functionality I can propose something though:

$.fn.events()

Returns an object with all events applied to the first tag, in the format:

{

click: [ handler, handler, ... ],

change: [ handler, ... ]

}

$.fn.events(eventName)

Returns an array of events of name eventName applied to the first tag, if any.

These fit well with the existing API, .on() and .off().

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

@m_gol @cmochini, regardless of your rationale you guys are asking for a paradigm shift ;o) jQ is just a library after all. jQ is not an application framework. And on top of that it is a mature library. Which makes adding/removing new abstractions extremely difficult. Not on the code level but on the level of the library architecture and library logic.

@dave jQuery is conceptually between user and a dynamic complex hierarchy (aka DOM). State of the DOM can be extremely volatile especially "... when code written by many different people should be running together on the page" ... And indeed in jQ there are no mechanisms to reflect that. This is a region of complex web app situations where people have indeed architected and implemented different solutions with different abstractions. One example would be backbone.js.

As far as jQ is concerned, my humble opinion is this is very clearly an concept that should be packaged in one or more plugins.

--DBJ

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

@dbjdbj What you're asking is impossible. If _data('events') is removed, there is no access to this information - it can't be encapsulated in a plugin.

It's trivial to add to jquery however:

events: function(name) {

var evs, r;

if(!(this[0] && (evs = internalData(this[0], 'events', undefined, true))))

return null;

function mapEv(evArray) {

return jQuery.map(evArray, function(evData) { return evData.handler; });

}

if (name)

return evs[name] ? mapEv(evs[name]) : null;

r = {};

jQuery.each(evs, function(p, v) {

r[p] = mapEv(v);

});

return r;

}

This gives users a simple abstraction on the events that have been attached by jquery. This is a typical part of any event system: the ability to inspect what's been added. It avoids exposing the rest of the guts and introducing the fears Dave Methvin described.

Re: Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

This is a typical part of any event system: the ability to inspect what's been added

And how do you do that with the DOM API?

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

> This gives users a simple abstraction on the events that have been attached by jquery.

It's not an abstraction, that's raw data without the context needed to use it properly. You have the functions that may be called when an event occurs, but as soon as you start making assertions about them (e.g., these functions WILL be called, NO OTHER functions will be called) those assertions are wrong.

That code doesn't know about event name remapping, delegated events, or pre/postDispatch handlers for example. Something as simple as $(form).on("focus", "input", fn) would break those assumptions because it looks like there are no focus events on any input when there certainly are.

http://updates.html5rocks.com/2012/02/Detect-DOM-changes-with-Mutation-Observers

--DBJ

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

"...a typical part of any event system: the ability to inspect what's been added..."

Enter "Mutation Observers" ;o)

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Dave Methvin I agree with your point that delegated events add complexity here - but it's certainly still solvable in a way that allows users to ask jquery what events it holds on a tag and take useful action as a result.

It would be nice if asking questions here resulted in people interested in discussion and helping out rather than a dismissive attitude. I'm saddened by the amount of hostility to basic discussion here. Two users asked a simple question.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

@cmoschini I apologize if I am a bit frustrated by this topic. As Scott mentioned, the W3C event model does not expose its data about which events are attached so it is not as if we're bucking a trend here. And your assertion that exposing just the handlers by themselves is some sort of "abstraction" is as wrong as it can be. Is calling your assertion wrong hostile? If I said it was right would that be less hostile, even though I would be incorrect?

It's great that you specified a concrete implementation, but it clearly is incomplete and doesn't solve a lot of important use cases so making it available and would open a cascade of complaints about that.

My advice is to think about how you'd solve this problem lacking the access to jQuery's internals and come up with a solution. That's how most abstractions work, rather than trying to dig into the implementation details of the layers below them. There are some pretty complex interactions inside jQuery regarding this, and I'm not anxious to expose them in a haphazard way for edge cases, only to find we're stuck supporting them when they don't work out.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Thanks Dave, you're right hostile might be going too far, and I apologize. But the tone here was a bit dismissive - it would be nice if it was constructive.

The fact the DOM doesn't offer this doesn't seem very relevant to me - jquery has the data on what events it's been asked to handle (some DOM, some not, notably), and when 2 pieces of code need to deal with something they share, it really helps to be able to inspect and sometimes manipulate those events. My tab example is a good illustration - if I can't ask what if any tab event has been attached, the whole thing can't work.

The question of how to answer this without accessing jquery's internals is a bit cyclical - if jquery exposes what it has on record for events, then it's not internal... if it doesn't, then these use cases aren't possible and that's a shame. I think it's a mistake (and a tad dismissive) to call these edge cases. As two examples, both the Node.js and .Net event systems offer 3 basic operations: the ability to add an event (subscribe), remove an event (unsubscribe), and list events that have subscribed. jQuery offers just the first two, and is missing the third but has this undocumented workaround that gets moved around. It's just a fundamental part of an event system, and punting because the DOM standard missed the boat doesn't seem like a very good reason.

So if you're interested I'm happy to work with you on how to abstract things so an .events() call like I proposed can capture the more complex details you pointed out. For example it might instead return:

{

selector: 'input',

handler: function...

}

For each object in the array instead, where selector may be null for events attached that don't define one.

Re: Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

My tab example is a good illustration - if I can't ask what if any tab event has been attached, the whole thing can't work.

Perhaps this is an indication that your design is flawed. Presumably, you're expecting someone else to trigger the tab event and the result of that changes based on some condition. Why not have a function that gets called instead? You can always change the behavior of the function based on conditions. Then the function does what it needs to and triggers an event. This is already how the DOM works. You never directly trigger an event. You call a method and that method triggers an event (or not).

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Scott before rushing to dismiss it I hope you'd take a bit longer to understand the example. I'm not directly triggering an event anywhere in that example, and I'm not sure where you got that straw man from. I'll expand on the example to be more concrete, but first let me just be clear:

Event systems typically have 3 basic operations: Add, Remove, and List. jQuery is missing List. I'm happy to work with others here to sort out a nice abstraction for List - it would be nice if it wasn't an endless series of commenters trying to blow users off..

In the example we have a few basic constructs:

In one library we setup a custom event, the tab event - it's just an event that fires if you hit the tab key on an input or link. Again to be clear I'm not proposing this event be added to jquery, jquery's custom event support already covers this base nicely. It's just part of the example.

In another library we help make tabbing through the form a bit faster, where for example if you choose a past entry from a typeahead in a name field, the address fields are filled out for you, and so to make things faster hitting tab at that point tabs to the next empty field, instead of the fields we just filled in for you. So the core piece here is - the library attaches an event to on('tab'...

Finally, there's another library, a validation library, and when it marks fields invalid, if you focus in on an invalid input, and hit tab, again to speed up fixing the fields that are invalid we tie into tab to bring you to the right field. But, if we simply added an event to on('tab' we'd have 2 targets we'd be trying to tab over to, when what we really want is to remove any existing tab event (regardless of what library or other code put it there) temporarily, set it aside then put it back - a bit like the way jQuery's .hide() sets aside the value of display for when an element gets shown again later. So, it sets that tab event on invalid fields as it marks them invalid, and removes it and restores the old tab event as fields are fixed.

The core communication point here is jQuery's event model - to change the design would require adding further dependencies to these two libraries, making them more tightly coupled than they need to be - bad design.

So that's a very long explanation, so there's no more confusion about this example (I hope). I wanted to state it quickly as just one simple example of how listing events can be very useful and help leverage the rest of the jQuery API, but I see a number of people have wanted to dive on it and hold it out as a reason to tell users to just go away. Hopefully there's no more confusion and we can get on to coming up with something constructive here.

Re: Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

So you're assuming that nobody else would ever want to do the same thing, right? Because as soon as someone else decides that they want to be first, your forced-first validation implementation breaks.

On a side note, I'd like to reiterate Dave's comment at the beginning. Changing the behavior of the tab key is a bad idea. No matter how wonderful you think it is, it's breaking a known system and killing accessibility.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

I'm not proposing any change to the tab key in the jquery library - can we try to stay on topic?

Sticking with the ability to list events, then by your same logic should jQuery .hide() and .show() go away, since someone could change the display CSS property in between/before usage of hide and show and disrupt its expectations? That this feature is bad design because "nobody else would ever want to do the same thing?"

It's the same basic set of requirements - if you're using this library you just have to know it will play nice with other libraries (if any) that interact with this event, unless you manage to interrupt that during the time the user is interacting with invalid fields. A pretty simple requirement to comply with. And a nice decoupling and separation of concerns, leaving jquery as the common dependency - a fair assumption in many applications today.

There are plenty more use cases around libraries playing nicely with each other. For example a jQuery plugin might have to destroy and recreate some DOM elements in order to respond to a request (as a simple example imagine a rotator plugin that lets you add a clickable area to it). It's useful to check on any events assigned to that DOM object you're going to have to destroy, set them aside, and reattach them once you've recreated things.

Or simple read scenarios - you could gather usage data of your plugin for example and include a list of events people actually tied into.

But none of these plugin extensions are possible if jQuery buries this basic info about what events are attached to what. It's a basic feature of any good event model, and it's not a lot of code.

Re: Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

I'm not proposing any change to the tab key in the jquery library - can we try to stay on topic?

We are staying on topic. When you want a feature added, you must provide use cases. If the use cases presented are deemed invalid or bad, then the feature won't be implemented.

Sticking with the ability to list events, then by your same logic should jQuery .hide() and .show() go away, since someone could change the display CSS property in between/before usage of hide and show and disrupt its expectations? That this feature is bad design because "nobody else would ever want to do the same thing?"

These aren't even close to the same thing. Can we try to stay on topic?

There are plenty more use cases around libraries playing nicely with each other. For example a jQuery plugin might have to destroy and recreate some DOM elements in order to respond to a request (as a simple example imagine a rotator plugin that lets you add a clickable area to it). It's useful to check on any events assigned to that DOM object you're going to have to destroy, set them aside, and reattach them once you've recreated things.

This is another terrible thing. Don't destroy the DOM if you don't need to. I've never seen a rotator plugin that requires destroying the DOM instead of just decorating it.

Or simple read scenarios - you could gather usage data of your plugin for example and include a list of events people actually tied into.

This can (and probably should) be accomplish by wrapping .on() to store which events are being used.

http://updates.html5rocks.com/2012/02/Detect-DOM-changes-with-Mutation-Observers

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

either I have not pressed the "Publish" button or my last post was not Published ... never mind, discussion is already progressed nicely

@cmochini @scot Once again , please read about "Mutation Observers":

you guys are hitting closely to the issues because of which this new abstraction is introduced.

And this IS the abstraction which was invented for you facing these kind of issues: DOM manipulation in presence of multiple "simultaneous" users.

Please be sure to read first comment from one Mr Rafael Weinstein ...

--DBJ

Re: Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

I don't really see the correlation to Mutation Observers. The feature request is "provide a list of bound event handlers". Mutation Observers doesn't solve that problem. The use case presented is "let me be the only handler to respond to this event, then later restore all previous handlers." Mutation Observers doen't solve that problem either.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Thanks Scott. Yeah I'm not asking for Mutation Observers - that's a lot more complex than what I'm asking for. I see that there's a comment saying that the problem is more complicated, but he's describing a different problem I'm not asking to have solved. In fact, that is the perfect thing for a jquery plugin, one that would be possible in older browsers only if it could regularly check on the events jquery is currently aware of. Leading us right back to this proposal.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Come up with a solution that doesn't require access to jQuery internals, or use them anyway and deal with the consequences. We're not going to sanctify access to internals, especially partial access that will be error prone. If you can convince the W3C that getEventListeners is a good idea, we may reconsider.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Dave, the only thing that makes it internal is that jQuery hasn't got an external .events() call - if it did, it wouldn't be internals. In addition, if I set 5 events on something and want to ask "Did you get those?" I should be able to see the external stuff I passed into it.

Thanks for dismissing your users.

Re: Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Dave, the only thing that makes it internal is that jQuery hasn't got an external .events() call - if it did, it wouldn't be internals.

I'm not sure what you hope to accomplish by defining the words internal and external. It's actually much more than that. Making something publish isn't just a matter of exposing a method that returns a value. It requires documentation, tests, and never ending support. It's a guarantee that the data structure is permanent. It's a hindrance to potential performance improvements and architectural changes. It's a statement that we think it's a good idea to query, inspect, and modify the data. This isn't just some random thing that we overlooked. It's a conscious decision that was made a long time ago and has been repeatedly explained.

In addition, if I set 5 events on something and want to ask "Did you get those?" I should be able to see the external stuff I passed into it.

Why? The answer to "Did you get those?" is "Yes; I did not throw an error, assume everything is fine." You don't need to ask if your handlers were applied. If you need to track your own handlers for whatever reason, you can do that in your code.

Thanks for dismissing your users.

If three days of constant responses is dismissive, then I'll just stop now.

At this point, if you'd like to continue down the road of getting this into jQuery, you'll need to convince the W3C or WHATWG to spec this functionality. If you think you can accomplish this, try reviving this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036187.html Expect the same type of responses that you've received here.

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Yeah - I thought we were juusssst turning the corner here several posts ago on commenters working with me rather than asking me to go away, and then it was back to, your use cases are the problem, and we don't need this.

Can we at least get an answer to the original question? Is the ._data('events') approach going to remain available for the next few versions?

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

Working with you to do what? We aren't interested in exposing any internal data and you haven't made a convincing case to do so either by logic or example. (Please don't take that as an invitation to continue this discussion, we've had plenty.)

There is currently a way for you to get this internal data, as you know, but we don't recommend that you use it. We make no guarantees as to how long your code might continue to work.

m_gol

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

I'm sorry I wasn't participating in the discussion earlier though it was me who asked first. I've read all the comments and I really don't understand this hostility about jQuery devs... I for one am grateful for Dave & Scott time, they pointed out problems with keeping this API official, they presented various arguments agains it; I don't see how that kind of interaction could possibly count as "dismissing users". If that's what they'll get for their commitment, it wouldn't surprise me if they no longer feel like answering questions on forum. So, thanks Dave & Scott!

Now, to the topic: If I understand correctly, what you're saying is that you don't want to be obligated to keep the internal events representation in case in some time you'd find another way to work with event handling because, as there is no DOM getEventListeners method, without keeping in-jQuery information about registered events it would be impossible to keep exposing that information.

I also didn't think about delegated events which is a big problem, indeed. Also, since there is no way to statically determine if one of handlers calls stopImmediatePropagation(), there are only two cases were working with registered handlers can make sense:

1) You know exactly what handlers were attached. This can be true only if they were attached in your code which means they can be de- or re-attached without delving into jQuery internals

2) You can't make assumptions about handlers. In this case the only non-random thing that could be done is de-attaching all handlers and re-attaching them later (module the delegated events problem).

Something could be done only about the second use-case. The question is, how often it's needed. Also, it would create a lot of other problems, like what to do when other events get attached, how to integrate it with existing handlers kept "on hold" etc.

My use case was caused by the fact that CSS transitions are very hard to be handled using JavaScript. It's hard to pause transitions without causing nasty side-effects, it's almost impossible to control what's happening during the transition etc.

The exact issue that made me asked the question that initiated this thread was that sometimes CSS layout methods are not enough to create sth complicated (especially when you can't use calc() because of Opera and flexbox because of IE9) and I had to resort to computing the used value of height/width of some child elements and use it to set proper CSS values for the container. It usually works well but there's a problem during transitions as I need the final used value, not the current one and there is no way to get it without setting `transition` to `none` and forcing re-layout. But then you lose the transition effect, hence the hack with recording current used value, temporarily disabling transitions, computing final used values, applying back the temporary used values from the middle of transitions and re-applying previous `transition` values. This causes handlers to execute when transitions are disabled, though, hence the need to be able to disable them temporarily and restoring afterwards. This is of course a huge hack so sanctioning events API just for that wouldn't be feasible taking into account all the problems you mentioned.

Hopefully sth will change about that in the future, I have hopes for this emerging standard: https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html

timmywill

Re: What's the rationale of not exposing object's events handlers collections?

10 years ago

So it seems like the conclusion here is to keep $._data( elem, "events" ) and not implement $.events. Advanced users can still retrieve events directly bound to elements (which btw including delegated events, just not in the way some people might expect). Personally, I've found it useful for debugging purposes, but don't really feel it's a good idea to expose in a documented API.

A couple firebug plugins used to use a call to $.data( elem, "events" ) to display jQuery events bound on all elements in the DOM view, which was probably the only feature that got me to use it. This is similar to event breakpoints in devtools (which do interact with natively-bound events and internal data btw), but was still a simpler way to debug as the number of steps from breakpoint to relevant code is much smaller.

I don't think we should be asking, "Can we remove this and have users be OK?" We should be asking, is it possible that keeping $._data as an undocumented interface might be helpful to some of our users, even if I don't agree with the use cases presented in one forum post?"