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.
> You received this message because you are subscribed to the Google Groups "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
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.
> How about $("#something").delegate(".thing","click", func).
> It almost makes too much sense :).
> On Nov 5, 6:31 pm, Robert Katić <robert.ka...@gmail.com> wrote:
>> 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:
>> 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.
>> On Nov 5, 2:44 am, xwisdom <xwis...@gmail.com> wrote:
>>> Hello,
>>> Just wondering if version 1.4 will include improvements to live()
>>> events.
> You received this message because you are subscribed to the Google
> Groups "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en > .
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);
> 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)
> ...;
I understand the logic behind you wanting a $.live method (for the
edge cases where, presumably, you have hundreds or thousands of
elements that you're trying to match - and you don't want to run the
initial selector). Although there's a lot that I don't like about it:
- You are now passing in a selector to a non $(...) or .foo() method.
This goes against all the conventions that the library has - when you
interact with DOM elements, stay within the jQuery set.
- The only case where this matters is in a fringe case (namely, only
when you use both a complicated selector AND run it in IE < 8, since
all other browsers are using querySelectorAll) - but the existence of
the method in jQuery would remove the need to ever use the one method
that everyone should use.
- Presumably since you're in a situation where you're really caring
about performance - then why are you using .live to begin with?
Shouldn't you be binding lower in the document? This is why the
closest method was added, to make tasks like this even easier.
I would simply recommend: If you're in a situation where you're
starting with a critical number of elements on your page, enough to
ruin your pages' overall performance, then you should use a basic form
of event delegation, like so:
$("#someRootTable").click(function(e){
$(e.target).closest("td.foo").each(function(){
// Your code goes here.
});
});
Which is really what you should be doing anyway (live method or not).
On Thu, Nov 5, 2009 at 7:13 AM, xwisdom <xwis...@gmail.com> wrote:
> 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.
> --
> You received this message because you are subscribed to the Google Groups "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić <robert.ka...@gmail.com> wrote:
> $("#someRootTable").delegate("td.foo", "click", function(e){
> // Your code goes here.
> });
> Would be easer and safer because the event will be handlet only by "td.foo"
> elements inside "#someRootTable".
> --Robert
> On 6. stu. 2009., at 04:56, John Resig <jere...@gmail.com> wrote:
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> jquery-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
> 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
> On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić <robert.ka...@gmail.com > > wrote:
>> $("#someRootTable").delegate("td.foo", "click", function(e){
>> // Your code goes here.
>> });
>> Would be easer and safer because the event will be handlet only by
>> "td.foo"
>> elements inside "#someRootTable".
>> --Robert
>> On 6. stu. 2009., at 04:56, John Resig <jere...@gmail.com> wrote:
>> You received this message because you are subscribed to the Google
>> Groups
>> "jQuery Development" group.
>> To post to this group, send email to jquery-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> jquery-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en > .
> 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
> On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić <robert.ka...@gmail.com > > wrote:
>> $("#someRootTable").delegate("td.foo", "click", function(e){
>> // Your code goes here.
>> });
>> Would be easer and safer because the event will be handlet only by
>> "td.foo"
>> elements inside "#someRootTable".
>> --Robert
>> On 6. stu. 2009., at 04:56, John Resig <jere...@gmail.com> wrote:
>> You received this message because you are subscribed to the Google
>> Groups
>> "jQuery Development" group.
>> To post to this group, send email to jquery-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> jquery-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en > .
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;
});
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.
> 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:
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?
On Nov 6, 3:01 pm, John Resig <jere...@gmail.com> wrote:
> > 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:
> 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?
> On Nov 6, 3:01 pm, John Resig <jere...@gmail.com> wrote:
> > > 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:
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.
On Nov 6, 5:29 pm, Robert Katić <robert.ka...@gmail.com> wrote:
> On Nov 6, 4:40 pm, lrbabe <lrb...@gmail.com> wrote:
> > 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?
> > On Nov 6, 3:01 pm, John Resig <jere...@gmail.com> wrote:
> > > > 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:
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:
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:
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.
> > 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:
On Sat, Nov 7, 2009 at 5:47 PM, Robert Katić <robert.ka...@gmail.com> wrote:
> 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.
> On Nov 6, 3:01 pm, John Resig <jere...@gmail.com> wrote:
>> > 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:
>> I'd appreciate tickets/patches for both of these - they both sound
>> like great additions.
>> --John
> --
> You received this message because you are subscribed to the Google Groups "jQuery Development" group.
> To post to this group, send email to jquery-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
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.
On Nov 7, 5:58 pm, John Resig <jere...@gmail.com> wrote:
> I've already landed the commits - looks great - thanks! (I'll close
> the ticket once my network stops flaking out.)
> --John
> On Sat, Nov 7, 2009 at 5:47 PM, Robert Katić <robert.ka...@gmail.com> wrote:
> > 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.
> > On Nov 6, 3:01 pm, John Resig <jere...@gmail.com> wrote:
> >> > 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:
> >> I'd appreciate tickets/patches for both of these - they both sound
> >> like great additions.
> >> --John
> > --
> > You received this message because you are subscribed to the Google Groups "jQuery Development" group.
> > To post to this group, send email to jquery-dev@googlegroups.com.
> > To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en.
> 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.
> On Nov 7, 5:58 pm, John Resig <jere...@gmail.com> wrote:
> > I've already landed the commits - looks great - thanks! (I'll close
> > the ticket once my network stops flaking out.)
> > --John
> > On Sat, Nov 7, 2009 at 5:47 PM, Robert Katić <robert.ka...@gmail.com> wrote:
> > > 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.
> > > On Nov 6, 3:01 pm, John Resig <jere...@gmail.com> wrote:
> > >> > 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:
> > >> I'd appreciate tickets/patches for both of these - they both sound
> > >> like great additions.
> > >> --John
> > > --
> > > You received this message because you are subscribed to the Google Groups "jQuery Development" group.
> > > To post to this group, send email to jquery-dev@googlegroups.com.
> > > To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en.
|
