Response title
This is preview!
Move this topic
Will the live() method be improved in 1.4?
in Developing jQuery Core
•
11 years ago
Hello,
Just wondering if version 1.4 will include improvements to live()
events.
See example here:
http://www.zachleat.com/web/2009/05/08/performance-caveat-with-jquery-selectors-and-live-events/
--
Just wondering if version 1.4 will include improvements to live()
events.
See example here:
http://www.zachleat.com/web/2009/05/08/performance-caveat-with-jquery-selectors-and-live-events/
--
Replies(31)
Re: Will the live() method be improved in 1.4?
11 years ago
Yes, 1.4 will include improvements to the live event.
Specifically though this blog post is discussing the ability to not
run the initial selector if all you're doing is binding a live event
(they proposed a $.live). It's not clear if we'll be landing this
specific functionality in jQuery 1.4.
--John
Specifically though this blog post is discussing the ability to not
run the initial selector if all you're doing is binding a live event
(they proposed a $.live). It's not clear if we'll be landing this
specific functionality in jQuery 1.4.
--John
Leave a comment on jeresig's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Hi John,
Thanks for the quick feedback
IMO, I think it would be handy to have something like $.live as I can
see where it would be of great benefit when working with a lot of
elements.
--
Thanks for the quick feedback
IMO, I think it would be handy to have something like $.live as I can
see where it would be of great benefit when working with a lot of
elements.
--
Leave a comment on xwisdom's reply
Re: Will the live() method be improved in 1.4?
11 years ago
What about something like this:
$.live = function(selector, type, callback) {
$.fn.live.call({ selector: selector }, type, callback);
}
$.live = function(selector, type, callback) {
$.fn.live.call({ selector: selector }, type, callback);
}
Leave a comment on nik.pasaran's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I've also been among those clamoring for an optimized $.live method
and have a offered similar hack around in the past <http://
blurf.furf.com/2009/09/jquery-live-from-new-york/> (via Paul Irish's
Anti-Patterns). Last night on the flight to jsconf, I hacked up a more
formal patch which puts optimized live and die methods into the jQuery
root and aliases them back to the jQuery instances.
http://github.com/furf/jquery-live/blob/master/jquery.live.js
Unless I'm missing something, I really haven't modified much and these
changes could be integrated into jQuery with two copies and two
pastes.
Hope that helps.
--
and have a offered similar hack around in the past <http://
blurf.furf.com/2009/09/jquery-live-from-new-york/> (via Paul Irish's
Anti-Patterns). Last night on the flight to jsconf, I hacked up a more
formal patch which puts optimized live and die methods into the jQuery
root and aliases them back to the jQuery instances.
http://github.com/furf/jquery-live/blob/master/jquery.live.js
Unless I'm missing something, I really haven't modified much and these
changes could be integrated into jQuery with two copies and two
pastes.
Hope that helps.
--
Leave a comment on furftastic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I wonder why there would be an $.live with document as the only
interesting context.
Something like
$(document).zombi(selector, type, ...)
would be more flexible (I know, "zombi" is not nice, but I have no
inspirations about a more suitable name).
To avoid to repeat selector on multiple bindings, I suggest something
like:
$(document).make(selector)
.zombi(type, ...)
.zombi(type, ...)
An possible implementation of that: http://gist.github.com/227508
Maybe this is only a silly idea for majority of users (now), but I am
really of idea that this have even more sense then the current
$.fn.live.
interesting context.
Something like
$(document).zombi(selector, type, ...)
would be more flexible (I know, "zombi" is not nice, but I have no
inspirations about a more suitable name).
To avoid to repeat selector on multiple bindings, I suggest something
like:
$(document).make(selector)
.zombi(type, ...)
.zombi(type, ...)
An possible implementation of that: http://gist.github.com/227508
Maybe this is only a silly idea for majority of users (now), but I am
really of idea that this have even more sense then the current
$.fn.live.
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
How about $("#something").delegate(".thing","click", func).
It almost makes too much sense :).
It almost makes too much sense :).
Leave a comment on justinbmeyer's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Meyer, "delegate" was my first candidate too but I was worry that it
was overused :). Seams that I was wrong. Will update it with
"delegate" ASAP.
--Robert
was overused :). Seams that I was wrong. Will update it with
"delegate" ASAP.
--Robert
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I don't think that the method name is at question here, but rather the
unnecessary performance cost of querying a selector before DOMReady
(or even after), ie. $('#anything'), when it is not needed for the
event delegation pattern. The .live method uses only the .selector
property of the jQuery instance and not the actual collection of DOM
elements, so there is no reason to query the DOM, especially before it
is even available.
Also, @robert, my solution supports the following notation, similar to
yours but using the familiar jQuery syntax (before/after DOMReady):
$.live("#mySelector", "click", fn1)
.live("#mySelector", "mouseover", fn2)
...;
as well as (after DOMReady):
$("#mySelector").css("color", "#ff0000")
.live("click", fn1)
.live("mouseover", fn2);
--
unnecessary performance cost of querying a selector before DOMReady
(or even after), ie. $('#anything'), when it is not needed for the
event delegation pattern. The .live method uses only the .selector
property of the jQuery instance and not the actual collection of DOM
elements, so there is no reason to query the DOM, especially before it
is even available.
Also, @robert, my solution supports the following notation, similar to
yours but using the familiar jQuery syntax (before/after DOMReady):
$.live("#mySelector", "click", fn1)
.live("#mySelector", "mouseover", fn2)
...;
as well as (after DOMReady):
$("#mySelector").css("color", "#ff0000")
.live("click", fn1)
.live("mouseover", fn2);
--
Leave a comment on furftastic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
> Also, @robert, my solution supports the following notation, similar to
Leave a comment on jeresig's reply
Re: Will the live() method be improved in 1.4?
11 years ago
<html><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><span>$("#someRootTable").delegate(<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); ">"td.foo", "click", <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.289062); -webkit-composition-fill-color: rgba(175, 192, 227, 0.222656); -webkit-composition-frame-color: rgba(77, 128, 180, 0.222656); ">function(e){</span></span></span></span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><span> // Your code goes here.</span>
<span>});</span></span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.289062); -webkit-composition-fill-color: rgba(175, 192, 227, 0.222656); -webkit-composition-frame-color: rgba(77, 128, 180, 0.222656);">
</span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.226562); -webkit-composition-frame-color: rgba(77, 128, 180, 0.226562);">Would be easer and safer because the event will be handlet only by <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); ">"td.foo" elements inside <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); ">"#someRootTable".<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.273438); -webkit-composition-fill-color: rgba(175, 192, 227, 0.207031); -webkit-composition-frame-color: rgba(77, 128, 180, 0.207031); "></span></span></span></span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.226562); -webkit-composition-frame-color: rgba(77, 128, 180, 0.226562);"><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); "><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); "><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.273438); -webkit-composition-fill-color: rgba(175, 192, 227, 0.207031); -webkit-composition-frame-color: rgba(77, 128, 180, 0.207031); "> <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.285156); -webkit-composition-fill-color: rgba(175, 192, 227, 0.21875); -webkit-composition-frame-color: rgba(77, 128, 180, 0.21875); "> </span></span></span></span></span></div><div>--Robert</div><div>
<span>});</span></span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.289062); -webkit-composition-fill-color: rgba(175, 192, 227, 0.222656); -webkit-composition-frame-color: rgba(77, 128, 180, 0.222656);">
</span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.226562); -webkit-composition-frame-color: rgba(77, 128, 180, 0.226562);">Would be easer and safer because the event will be handlet only by <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); ">"td.foo" elements inside <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); ">"#someRootTable".<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.273438); -webkit-composition-fill-color: rgba(175, 192, 227, 0.207031); -webkit-composition-frame-color: rgba(77, 128, 180, 0.207031); "></span></span></span></span></div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.226562); -webkit-composition-frame-color: rgba(77, 128, 180, 0.226562);"><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); "><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844); "><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.273438); -webkit-composition-fill-color: rgba(175, 192, 227, 0.207031); -webkit-composition-frame-color: rgba(77, 128, 180, 0.207031); "> <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.285156); -webkit-composition-fill-color: rgba(175, 192, 227, 0.21875); -webkit-composition-frame-color: rgba(77, 128, 180, 0.21875); "> </span></span></span></span></span></div><div>--Robert</div><div>
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
If you want to limit, just do this (using the nightlies):
$("#someRootTable").click(function(e){
$(e.target).closest("td.foo", this).each(function(){
// Your code goes here.
});
});
Still pretty simple and requires no additional functionality. I may
just write this up as an example and add it to the live and closest
docs.
--John
$("#someRootTable").click(function(e){
$(e.target).closest("td.foo", this).each(function(){
// Your code goes here.
});
});
Still pretty simple and requires no additional functionality. I may
just write this up as an example and add it to the live and closest
docs.
--John
Leave a comment on jeresig's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I suppose you will need an "return false;" too at the end of the
handler...
--Robert
handler...
--Robert
Leave a comment on rkatic's reply
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Regarding improving live(), I would note two things about liveHandler:
1. Calling closest, context argument still is not used.
I was unable to find the proper ticket. Would I open one?
2. Storing "how much a parent is close to an element" with data API is
an big overhead. An jQuery.lastCloser or something similar would be
enough. Also it would speed up sorting inside liveHandler with
somethin like this:
...
elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser });
....
elems.sort(function( a, b ) {
return a.closer - b.closer;
});
--
1. Calling closest, context argument still is not used.
I was unable to find the proper ticket. Would I open one?
2. Storing "how much a parent is close to an element" with data API is
an big overhead. An jQuery.lastCloser or something similar would be
enough. Also it would speed up sorting inside liveHandler with
somethin like this:
...
elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser });
....
elems.sort(function( a, b ) {
return a.closer - b.closer;
});
--
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Fair enough, @john. I was unaware of the convention regarding
selectors. But isn't "write less, do more" also a convention? ;-)
$("#someRootTable").click(function(e){
$(e.target).closest("td.foo", this).each(function(){
// Your code goes here.
});
});
vs.
$.live("#someRootTable td.foo", "click", function(){
// Your code goes here.
});
Joking aside, your solution would probably solve our key cases at MLB,
although we would still need to use the live method for rendering and
editing dynamic data. But at least, the (unnecessary) selector is much
faster.
$("#someRootTable").live("click", function(e){
$(e.target).closest("td.foo", this).each(function(){
// Your code goes here.
});
});
On the front end, we are rendering large tables of stats data
regularly and, on the back end, we have several interfaces for
manipulating large data, including an XML editor. In the case of the
XML editor, during common usage, $.live increased rendering
performance over $(...).live from 2s to 9ms by eliminating the need to
collect thousands of nodes and attributes.
We haven't noticed any significant performance issues using document
as the root context at event time. When we're acting on large
collections, the collections are usually the most important data on
the page and therefore not too far down in the DOM.
Thanks for the insights. I look forward to a few more at jsconf.
--
selectors. But isn't "write less, do more" also a convention? ;-)
$("#someRootTable").click(function(e){
$(e.target).closest("td.foo", this).each(function(){
// Your code goes here.
});
});
vs.
$.live("#someRootTable td.foo", "click", function(){
// Your code goes here.
});
Joking aside, your solution would probably solve our key cases at MLB,
although we would still need to use the live method for rendering and
editing dynamic data. But at least, the (unnecessary) selector is much
faster.
$("#someRootTable").live("click", function(e){
$(e.target).closest("td.foo", this).each(function(){
// Your code goes here.
});
});
On the front end, we are rendering large tables of stats data
regularly and, on the back end, we have several interfaces for
manipulating large data, including an XML editor. In the case of the
XML editor, during common usage, $.live increased rendering
performance over $(...).live from 2s to 9ms by eliminating the need to
collect thousands of nodes and attributes.
We haven't noticed any significant performance issues using document
as the root context at event time. When we're acting on large
collections, the collections are usually the most important data on
the page and therefore not too far down in the DOM.
Thanks for the insights. I look forward to a few more at jsconf.
--
Leave a comment on furftastic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
> 1. Calling closest, context argument still is not used.
Leave a comment on jeresig's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Adding the context to closest in liveHandler is really an easy thing
to fix...
What we need is a working implementation of the context.
Last time I talked to Brandon Aaron about that (back at the jQuery
conf) he told me that context was broken in his opinion and needed
some additional work before being useful...
Has anything changed?
to fix...
What we need is a working implementation of the context.
Last time I talked to Brandon Aaron about that (back at the jQuery
conf) he told me that context was broken in his opinion and needed
some additional work before being useful...
Has anything changed?
Leave a comment on louisremi's reply
Re: Will the live() method be improved in 1.4?
11 years ago
event.currentTarget as context is not enough?
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Exactly, it's as simple as that.
I actually thought that live wasn't taking advantage of the context
when using the syntax
$(selector, context).live(type, handler);
But I just tested it and it does work.
You can file the ticket.
I actually thought that live wasn't taking advantage of the context
when using the syntax
$(selector, context).live(type, handler);
But I just tested it and it does work.
You can file the ticket.
Leave a comment on louisremi's reply
Re: Will the live() method be improved in 1.4?
11 years ago
To handle click delegation I took the approach of enhancing the click
event using the special events framework. This might be a slight
tangent to this thread, but it does address many of the problems
discussed here. Here's the code:
http://webdev.stephband.info/events/click/js/jquery.event.click.js
It allows you to bind a click as normal, but if you pass in an options
object with the properties 'selector' or 'href' the bound function
fires only when the conditions are met:
jQuery('context')
.bind('click', {
selector: 'h3'
}, handlerFunction);
will fire handlerFunction whenever an h3 (or anything inside an h3) in
'context' is clicked. Since I find 90% of my click bindings are on
links, and I'm often interested in sorting links by type, I also
provide a way to bind to links by type of href:
jQuery('context')
.bind('click', {
href: 'hash'
}, handlerFunction);
will fire handlerFunction when an anchor with href = "#xxx" is
clicked. Similarily, it will take the values 'slash' ( /xxx ),
'url' ( xxx://xxx ), 'empty' ( # ), or an exact match for your href.
One more example:
jQuery('context')
.bind('click', {
selector: 'a[target=overlay]'
href: 'url'
}, handlerFunction);
will fire handlerFunction on links with target="overlay" and an href
that is a full url.
It caches the results of .closest() so when the same element is
clicked twice .closest() is only run the first time. Inside
handlerFunction, e.target is set to the selected element (even if it
was an element inside that element that was originally clicked) for
easy manipulation.
As a solution, I like it because it allows me to continue write
bindings the same way as I always have, but just enhance them with an
options object when I want delegation. I never published it on
jQuery.com, for some reason... perhaps I never considered it entirely
finished. But I have had it working in a couple of website projects.
Cheers,
Stephen.
--
event using the special events framework. This might be a slight
tangent to this thread, but it does address many of the problems
discussed here. Here's the code:
http://webdev.stephband.info/events/click/js/jquery.event.click.js
It allows you to bind a click as normal, but if you pass in an options
object with the properties 'selector' or 'href' the bound function
fires only when the conditions are met:
jQuery('context')
.bind('click', {
selector: 'h3'
}, handlerFunction);
will fire handlerFunction whenever an h3 (or anything inside an h3) in
'context' is clicked. Since I find 90% of my click bindings are on
links, and I'm often interested in sorting links by type, I also
provide a way to bind to links by type of href:
jQuery('context')
.bind('click', {
href: 'hash'
}, handlerFunction);
will fire handlerFunction when an anchor with href = "#xxx" is
clicked. Similarily, it will take the values 'slash' ( /xxx ),
'url' ( xxx://xxx ), 'empty' ( # ), or an exact match for your href.
One more example:
jQuery('context')
.bind('click', {
selector: 'a[target=overlay]'
href: 'url'
}, handlerFunction);
will fire handlerFunction on links with target="overlay" and an href
that is a full url.
It caches the results of .closest() so when the same element is
clicked twice .closest() is only run the first time. Inside
handlerFunction, e.target is set to the selected element (even if it
was an element inside that element that was originally clicked) for
easy manipulation.
As a solution, I like it because it allows me to continue write
bindings the same way as I always have, but just enhance them with an
options object when I want delegation. I never published it on
jQuery.com, for some reason... perhaps I never considered it entirely
finished. But I have had it working in a couple of website projects.
Cheers,
Stephen.
--
Leave a comment on stephband.googlemail.com's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I opened a ticket: http://dev.jquery.com/ticket/5470
with link on commit.
Commit also includes context inside liveHandler (it is a too small
change to make a separate commit).
Component is "unfiled". Please tell me if I made mistakes opening this
ticket.
with link on commit.
Commit also includes context inside liveHandler (it is a too small
change to make a separate commit).
Component is "unfiled". Please tell me if I made mistakes opening this
ticket.
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I've already landed the commits - looks great - thanks! (I'll close
the ticket once my network stops flaking out.)
--John
the ticket once my network stops flaking out.)
--John
Leave a comment on jeresig's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I detect only now that in closest method the selector is evaluated
without selector.
I am not sure which context is more correct: (context || this.context)
or it have to be a document?
PS: It is not completely clear to me why selectors with positions can
not be handled by multiFilter in this situation.
without selector.
I am not sure which context is more correct: (context || this.context)
or it have to be a document?
PS: It is not completely clear to me why selectors with positions can
not be handled by multiFilter in this situation.
Leave a comment on rkatic's reply
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I opened a ticket: http://dev.jquery.com/ticket/5475
Leave a comment on rkatic's reply
Re: Will the live() method be improved in 1.4?
11 years ago
I don't think this is as much of an edge case as John thinks. I've
run into it as well. Another way around it is to set the .live events
outside of the document load listener in the head. That way, it runs
before the selector returns any results.
I can see why it was placed where it is, so you can chain it like
other jQuery methods.
$(foo).live('click', function() {}).css();
If it was
$.live($(foo), 'click', function() {});
Then it could not be chained. But in practice, I never chain .live()
events because for performance reasons I put them outside of the
document load listener so they cannot chain because the DOM isn't
ready anyway.
Often the reason I use .live is because I am setting a click event on
a hundred or so td's in a dynamic table. Using .click is
prohibitively slow, because they all must be removed before removing
the table from the DOM and just setting that many events is slow as
well.
It's true, I could write a custom event delegate script to constrain
the scope to the table and capture events as they bubble up, but it
seems to me that the point of .live is to encapsulate this exact kind
of functionality so I don't need to write this pattern out every time.
Anyway, I'm fine if it doesn't get added to the core, I've got custom
plugins written for $.live and I use the custom event delegation
pattern that John mentions, but it makes the core $().live a lot less
useful. The only benefits it provides is being able to chain it
(Which I don't really need) and it lets me use an already cached
selector (though I could still do that in the $.live() method).
Just some thoughts on how this pattern is used in the wild.
Josh Powell
--
run into it as well. Another way around it is to set the .live events
outside of the document load listener in the head. That way, it runs
before the selector returns any results.
I can see why it was placed where it is, so you can chain it like
other jQuery methods.
$(foo).live('click', function() {}).css();
If it was
$.live($(foo), 'click', function() {});
Then it could not be chained. But in practice, I never chain .live()
events because for performance reasons I put them outside of the
document load listener so they cannot chain because the DOM isn't
ready anyway.
Often the reason I use .live is because I am setting a click event on
a hundred or so td's in a dynamic table. Using .click is
prohibitively slow, because they all must be removed before removing
the table from the DOM and just setting that many events is slow as
well.
It's true, I could write a custom event delegate script to constrain
the scope to the table and capture events as they bubble up, but it
seems to me that the point of .live is to encapsulate this exact kind
of functionality so I don't need to write this pattern out every time.
Anyway, I'm fine if it doesn't get added to the core, I've got custom
plugins written for $.live and I use the custom event delegation
pattern that John mentions, but it makes the core $().live a lot less
useful. The only benefits it provides is being able to chain it
(Which I don't really need) and it lets me use an already cached
selector (though I could still do that in the $.live() method).
Just some thoughts on how this pattern is used in the wild.
Josh Powell
--
Leave a comment on seasoup's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Hi John,
After thinking about it for sometime. I really think it would be good
to have an optimized version of the live call. Here's an example of
what I'm thinking of:
$(context).bind('a.menu:click', callback);
The above would internally use the live() method to setup the click
event for every a.menu element within "context"
--
After thinking about it for sometime. I really think it would be good
to have an optimized version of the live call. Here's an example of
what I'm thinking of:
$(context).bind('a.menu:click', callback);
The above would internally use the live() method to setup the click
event for every a.menu element within "context"
--
Leave a comment on xwisdom's reply
Re: Will the live() method be improved in 1.4?
11 years ago
On Nov 13, 5:06 pm, xwisdom <xwis...@gmail.com>
Leave a comment on stephband.googlemail.com's reply
Re: Will the live() method be improved in 1.4?
11 years ago
On Nov 13, 5:06 pm, xwisdom <xwis...@gmail.com>
Leave a comment on stephband.googlemail.com's reply
Re: Will the live() method be improved in 1.4?
11 years ago
Here's what I would use to separate the selector from the event name:
<script type="text/javascript">
var sel,event = 'a.menu:click.namespace';
if (event.indexOf(':')) {
sel = event.substr(0,event.lastIndexOf(':'));
event = event.replace(sel+':','');
}
alert('selector:'+ sel +" \nevent:" + event);
</script>
The only drawback when using the this method is that users will not be
able to support multiple event names within the same bind call:
$(context).bind('click',callback); // normal use
$(context).bind('click mouseover',callback); // multiple events
$(context).bind('a.menu:click',callback); // using event delegates -
only one event at a time
--
<script type="text/javascript">
var sel,event = 'a.menu:click.namespace';
if (event.indexOf(':')) {
sel = event.substr(0,event.lastIndexOf(':'));
event = event.replace(sel+':','');
}
alert('selector:'+ sel +" \nevent:" + event);
</script>
The only drawback when using the this method is that users will not be
able to support multiple event names within the same bind call:
$(context).bind('click',callback); // normal use
$(context).bind('click mouseover',callback); // multiple events
$(context).bind('a.menu:click',callback); // using event delegates -
only one event at a time
--
Leave a comment on xwisdom's reply
Re: Will the live() method be improved in 1.4?
11 years ago
> The only drawback when using the this method is that users will not be
Leave a comment on stephband.googlemail.com's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to xwisdom's discussion
{"z2877445":[14737000000473347,14737000000473351,14737000000473357,14737000000473361,14737000000473363,14737000000473365,14737000000473373,14737000000473379,14737000000473383,14737000000473385,14737000000473387],"z1214759":[14737000000473371,14737000000473375],"z2950873":[14737000000473345,14737000000473353,14737000000473367],"z165885":[14737000000473349],"z2949132":[14737000000473377,14737000000473393,14737000000473395,14737000000473399],"z2566198":[14737000000473339,14737000000473355,14737000000473359,14737000000473369,14737000000473381],"z2949284":[14737000000473343],"z2949982":[14737000000473337,14737000000473341,14737000000473391,14737000000473397],"z2950164":[14737000000473389]}