Response title
This is preview!
Move this topic
On vs live vs Delegate using jqm 1.1
in jQuery Mobile
•
11 years ago
I have upgraded to jqm 1.1 and jquery 7.1 and I thought I would stat using on instead of live. Only problem is I can't get on to work. In the example below, .on does not work but the live and delegate works fine. What am I doing wrong.
- //$(''tr.showMoreDetails').on("click", function(e) {
- //$(''tr.showMoreDetails').live("click", function(e) {
- $(document).delegate('tr.showMoreDetails',"click", function(e) {
- showPropDetails(this.id);
- });
1
Replies(21)
Re: On vs live vs Delegate using jqm 1.1
11 years ago
I don't see anything offhand that should be wrong. Is this in a "pageinit" or "pagebeforeshow" type function? Maybe it is firing off too soon?
---
http://zsprawl.com
---
http://zsprawl.com
Leave a comment on zSprawl's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
Here's a .live to .on translation:
-- Kevin
$(''tr.showMoreDetails').live("click",fn)
$(document).on("click",''tr.showMoreDetails",fn)
-- Kevin
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
I find that the following syntax has better performance and logically flows better as well (for me at least).
This allows for the event handler to only attach to the ID selector and apply to its children instead of searching the whole DOM when you attach it to document.
- $("#id_selector").on("click","filter_selector_here", fn);
This allows for the event handler to only attach to the ID selector and apply to its children instead of searching the whole DOM when you attach it to document.
Leave a comment on Kevin B's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
I saw this article a while back and bookmarked it, because it was helpful in understanding the different bindings.
http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html
-mp
http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html
-mp
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
Leave a comment on mspisars's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
That was a very good explanation. Thanks mspisars.
Leave a comment on jimboidaho's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
There's actually no advantage to using .on vs .bind(), .live(), or .delegate(). In fact, there is a very tiny penalty to using .on(), since it's just syntactic sugar on top of the others.
I haven't found a need to use .live() - I know it's slow. The only reason I can see for using it is if you are using a much older version of jQuery that doesn't have .delegate(). Maybe there are some specific use cases, but I haven't run across one that I need.
The advantage of using the old methods is that I can glance at code and know instantly if it is using.live() and so perhaps might use some updating to gain some speed. With .on() you have to squint at the thing and think about what it's calling under the hood.
So, I've decided not to jump on the on() bandwagon, in favor of clarity.
I haven't found a need to use .live() - I know it's slow. The only reason I can see for using it is if you are using a much older version of jQuery that doesn't have .delegate(). Maybe there are some specific use cases, but I haven't run across one that I need.
The advantage of using the old methods is that I can glance at code and know instantly if it is using.live() and so perhaps might use some updating to gain some speed. With .on() you have to squint at the thing and think about what it's calling under the hood.
So, I've decided not to jump on the on() bandwagon, in favor of clarity.
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
From what I understand, the way bind() and live() implement on() is slower than the way delegate() does it since it appears to hook to the document level and allows things to bubble all the way to the top.
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
@watusiware,
It is actually the opposite. From the article:
Here are the basic problems that I am trying to avoid:
It is actually the opposite. From the article:
And specifically delegate() or the proper on() methods are more efficient then live()Did you know that the jQuery.bind(),.live(), and.delegate()methods are just one line pass throughs to the new jQuery 1.7.on()method? The same is true of the.unbind(),.die(), and.undelegate()methods.
Here are the basic problems that I am trying to avoid:
- This method is deprecated as of jQuery 1.7 and you should start phasing out its use in your code.
- (Wasted selection) The selection that is made is basically thrown away since it is only used to register the event handler on the document.
- Since all selector/event information is attached to the document
once an event does occur jQuery has match through its large metadata
store using the
matchesSelectormethod to determine which event handler to invoke, if any. - Your events always delegate all the way up to the document. This can affect performance if your DOM is deep.
Leave a comment on watusiware's reply
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
True...
But delegate() uses on() differently and "better" then live() or bind() does (assuming I understood what I read).
---
http://zsprawl.com
---
http://zsprawl.com
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
@zSprawl, you understood what you read correctly :)
Leave a comment on Kevin B's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
I might be revealing what I don't know here, but...
See the section with the bar chart "Improved performance on delegated events." Is that just fluff?
Or, is the issue you guys are discussing just a fundamental drawback of jQuery Mobile's ajax navigation? Because it switches out pages in the way it does, if you want to attach an event handler that's going to work on an element that doesn't yet exist (if it's on some other page that can be navigated to) you must attach the event handler to $('body') and therefore it will have to bubble all the way up to the body element. That just seems unavoidable if you want to use event handlers along with the ajax navigation in JQM. I guess the only alternatives would be to either use data-ajax="false" for pages that require an event handler or just put the event handlers inline. The former is not an option for my app, but I suppose I could put everything inline. Honestly though, my DOM isn't that deep, so I'm not really seeing any performance issues when registering the event handlers to $('body').
Leave a comment on dcarrith's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
No it is not fluff, the performance improvements are there...
They targeted the "most used" cases first and the rest later:
Now, this is for delegate() or the on() equivalent, live() still has performance drawbacks.
-mp
They targeted the "most used" cases first and the rest later:
The graph on that page you link is pretty accurate.With that in mind, jQuery 1.7 event handling was refactored with an eye to making delegated events much faster, especially for the most common cases.To optimize the code for the most commonly used forms of selectors, we examined a cross-section of code from Google Codesearch. Nearly two-thirds of the selectors used in
.live()and.delegate()method calls were in the formtag#id.classwhere one or more of tag, id, or class were used. By parsing those simple selectors in JavaScript at the time the event was attached, we were able to outperform even the browser’s native-code implementations ofmatchesSelectorduring event delivery. For more complex selectors we still use the Sizzle engine, so all existing code should continue to work.
Now, this is for delegate() or the on() equivalent, live() still has performance drawbacks.
-mp
Leave a comment on mspisars's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
I don't understand how you (as a group, not any individual) are coming to the conclusion that .delegate or .live is more or less efficient than using .on in the same way.
-- Kevin
It's just a syntax difference. I can agree that using .on with a parent element that isn't the document is more efficient than delegating from the document, but that is the same case for .delegate and .live. Keep in mind, .live now also proxies to the .on method, and, .live does and always has accepted a context, just like .delegate and .on.
All of these methods use .on, so regardless of which one you use, you are getting the benefit of the improved event handling of .on. The only difference is syntax.
All of these methods use .on, so regardless of which one you use, you are getting the benefit of the improved event handling of .on. The only difference is syntax.
$("a","#content").live("click",handler);
$("#content").delegate("a","click",handler);
$("#content").on("click","a",handler);
.live of course still has the drawback of selecting all "a" tags inside of "#content" when it doesn't need to, however the actual event handling is done the same as the other two. Good reason to move .live to .delegate for code that needs to be backwards compatible, or .on for code that doesn't.
-- Kevin
Leave a comment on Kevin B's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
@dcarrith
I have been going mad trying to use on() on AJAX-loaded elements. Though I like the concept of on(), I don't understand why you can use $(document).on() with stuff to be loaded, especially since loading content via AJAX isn't that uncommon - Curious to see how this works out in fetchlink feature slated for JQM 1.2 (if I remember correctly, that will also load and replace content via AJAX).
I ended up wrapping all my event-bindings in a bindMeUp() function which I call on Ajax success. Inside this function I'm binding to the elements directly and lock them for the specific event-binding (when the next AJAX call comes around). Seems to work ok, although lot of extra code and less structure in my master.js file.
Oh, and I posted this as a bug in Jquery. Closed.
I have been going mad trying to use on() on AJAX-loaded elements. Though I like the concept of on(), I don't understand why you can use $(document).on() with stuff to be loaded, especially since loading content via AJAX isn't that uncommon - Curious to see how this works out in fetchlink feature slated for JQM 1.2 (if I remember correctly, that will also load and replace content via AJAX).
I ended up wrapping all my event-bindings in a bindMeUp() function which I call on Ajax success. Inside this function I'm binding to the elements directly and lock them for the specific event-binding (when the next AJAX call comes around). Seems to work ok, although lot of extra code and less structure in my master.js file.
Oh, and I posted this as a bug in Jquery. Closed.
Leave a comment on frequent's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
@frequent: My app is using AJAX navigation almost entirely (except for when I need to switch over to https) and I'm also using event handlers that are defined in a main js file without any issues. When I first started to switch over to using on() I was running into problems. But, after I read http://api.jquery.com/on/ several times, I got the hang of it. I'm not sure what you're doing differently, but here are some examples of what I'm doing (maybe this isn't the best way to do it, but I'm not binding to document). I figured it would be better to bind to the lowest element in the DOM that I know will exist on first page load. For example, for any of the pageshow, pagebeforeshow, pagehide or whatever events, I'm doing something like this:
- $('body').on('pageshow', '#page_id', function(event, ui) {
- // whatever I need to do
- });
I'm using a slider control, so I have an event handler that looks like this:
- $('body').on('change', '#slider_control_id', function(evt) {
- // whatever I need to do
- }
Or, for click events anywhere in any of my pages that could be loaded, I have event handlers like this:
- $('body').on('click', '#id_of_button_or_whatever', function(evt) {
- evt.preventDefault();
- // whatever I need to do
- }
Leave a comment on dcarrith's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
Mea culpa for getting it backwards.I don't understand how you (as a group, not any individual) are coming to the conclusion that .delegate or .live is more or less efficient than using .on in the same way.
.delegate(), .bind(), .live() call .on(). So, there is a small (very small) speed penalty for using them vs on().
My argument for using the former is that they make it clearer which method you are using. A .live() call jumps out at you a lot more easily than a particular set of parameters to an .on() call!
Re: Re: On vs live vs Delegate using jqm 1.1
11 years ago
I agree, i prefer .delegate though because it both make sense when you read it and is not depreciated yet, meaning it'l be backwards compatible and future compatible for atleast another year or two if not much longer.
-- Kevin
-- Kevin
Leave a comment on watusiware's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
@dcarrith: Thanks. I'll give that I try, too. Bubbling from body up to document shouldn't be that many "bubbles"...
Leave a comment on frequent's reply
Re: On vs live vs Delegate using jqm 1.1
11 years ago
@frequent: I think the bubbles occur from the element that is being clicked on up to body in my case. So, using body instead of document is probably only saving two levels of bubbling...but not sure about that.
Leave a comment on dcarrith's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to jimboidaho's question
{"z2952216":[14737000003345611,14737000003345622],"z8744100":[14737000003348247,14737000003348327,14737000003346658,14737000003346680],"z965437":[14737000003348315,14737000003348313,14737000003348579,14737000003348613,14737000003348611],"z3123152":[14737000003345620,14737000003346678,14737000003347993,14737000003349105],"z7664639":[14737000003347621,14737000003349101],"z7947755":[14737000003345962,14737000003350018,14737000003350047],"z5049151":[14737000003349039,14737000003349103]}