jQuery Forum

A quick example:
$(".msg").each(function(i, $this){
  $(".hide", this).click(function(){
     $this.hide();
  });
});
I actually proposed this set of changes to Yehuda on IM and then had a back and forth as to how to best implement them. I think they actually hold some promise. I like this since it's relatively pain-free which helping to reduce
extra syntax (when dealing with closures in jQuery it's common that
you'll need to declare references to the wrapped jQuery set - something
that this avoids).
The proposal is a set of 3 changes - each change is making the second argument of a callback function equal to $(this).
 - Modifying existing callbacks that have no second argument (like .filter, as Yehuda mentioned).
 - Modifying event callbacks to have a second argument be $(this) (which, can conflict with .trigger(event, data)).
 - Modifying each callbacks to have a second argument be $(this) (replacing the existing second argument of this).
Obviously changing the second incoming argument to .each(function(i,$this)) is going to require a little bit of finesse. I did a quick search on Google Codesearch but didn't see any immediate warning signs:
<a href="http://www.google.com/codesearch?hl=en&lr=&q=">http://www.google.com/codesearch?hl=en&lr=&q=</a>\.each\%28\s*function\%28\s*\w%2B%2C\s*\w%2B\s*\%29+lang%3Ajavascript&sbtn=Search
<span style="display: block; padding-left: 6em; text-indent: -1em;"><span></span></span>
If we make a change like this I would like it to be an all-or-nothing proposition (having a half-baked API modification landing seems kind of lame) BUT it must be done in a way that we're sure won't break important code. (At the very least, a change like this would have to be done in a major 1.x release.)
A quick note: It's probably important to use function(i, $this) in the
examples (to help differentiate it from a "normal" self [which
generally equates to var self = this;]).
<br clear="all">--John

What about the performance implications of creating those jQuery objects
for each call? Could you check the length property of the callback
function and only pass the jQuery object if it is actually declared to
expect 2 arguments?
What about modifying each() so that it passes three arguments to its
callback: the index, the element, and the wrapped element:
function(i, e, $e) { // e === $e[0] }
That avoids the compatibility problem, but loses the parallel with the
other methods, unless you pass both e and $e to their callback as well.
    David
John Resig wrote:
> A quick example:
>
> $(".msg").each(function(i, $this){
> $(".hide", this).click(function(){
> $this.hide();
> });
> });
>
> I actually proposed this set of changes to Yehuda on IM and then had a
> back and forth as to how to best implement them. I think they actually
> hold some promise. I like this since it's relatively pain-free which
> helping to reduce extra syntax (when dealing with closures in jQuery
> it's common that you'll need to declare references to the wrapped jQuery
> set - something that this avoids).
>
> The proposal is a set of 3 changes - each change is making the second
> argument of a callback function equal to $(this).
>
> - Modifying existing callbacks that have no second argument (like
> .filter, as Yehuda mentioned).
> - Modifying event callbacks to have a second argument be $(this)
> (which, can conflict with .trigger(event, data)).
> - Modifying each callbacks to have a second argument be $(this)
> (replacing the existing second argument of this).
>
> Obviously changing the second incoming argument to
> .each(function(i,$this)) is going to require a little bit of finesse. I
> did a quick search on Google Codesearch but didn't see any immediate
> warning signs:
> http://www.google.com/codesearch?hl=en&lr=&q=
> <http://www.google.com/codesearch?hl=en&lr=&q=>\.each\%28\s*function\%28\s*\w%2B%2C\s*\w%2B\s*\%29+lang%3Ajavascript&sbtn=Search
>
> If we make a change like this I would like it to be an all-or-nothing
> proposition (having a half-baked API modification landing seems kind of
> lame) BUT it must be done in a way that we're sure won't break important
> code. (At the very least, a change like this would have to be done in a
> major 1.x release.)
>
> A quick note: It's probably important to use function(i, $this) in the
> examples (to help differentiate it from a "normal" self [which generally
> equates to var self = this;]).
>
> --John
>
>
> On Mon, Jul 20, 2009 at 11:14 PM, Yehuda Katz <wycats@gmail.com
> <mailto:wycats@gmail.com>>

If those functions (find, trigger, each, etc) all bind the "this" to
the object, what's the need for additionally passing it as the second
parameter?

The "this" is not a jQuery object, but a DOMElement.
function(i, $this) {
  // $this == $(this)
  // $this[0] == this
}
- Richard

It is my understanding they aren't. 'this' is the item in the obj/arr,
first param is index (I'm guessing 'key' in the obj case). istm this
prevents you from ever manipulating the context of the iteration
callbacks mentioned. Am I wrong?
Regards
Peter
getify wrote:
> If those functions (find, trigger, each, etc) all bind the "this" to
> the object, what's the need for additionally passing it as the second
> parameter?
>
> On Jul 21, 1:54 am, Yehuda Katz <wyc...@gmail.com> wrote:
>
>> On Mon, Jul 20, 2009 at 10:30 PM, David Flanagan <da...@davidflanagan.com>wrote:
>>
>>
>>
>>
>>> What about the performance implications of creating those jQuery objects
>>> for each call? Could you check the length property of the callback
>>> function and only pass the jQuery object if it is actually declared to
>>> expect 2 arguments?
>>>
>> Yep! John and I had discussed this. I think it's the way to go.
>>
>>
>>
>>
>>> What about modifying each() so that it passes three arguments to its
>>> callback: the index, the element, and the wrapped element:
>>>
>>> function(i, e, $e) { // e === $e[0] }
>>>
>>> That avoids the compatibility problem, but loses the parallel with the
>>> other methods, unless you pass both e and $e to their callback as well.
>>>
>> Nah. If we do it, we need to do it right. I'd be ok with a jQuery.legacyEach
>> = true, but John didn't like that ;)
>>
>>
>>
>>
>>
>>
>>
>>
>>> David
>>>
>>> John Resig wrote:
>>>
>>>> A quick example:
>>>>
>>>> $(".msg").each(function(i, $this){
>>>> $(".hide", this).click(function(){
>>>> $this.hide();
>>>> });
>>>> });
>>>>
>>>> I actually proposed this set of changes to Yehuda on IM and then had a
>>>> back and forth as to how to best implement them. I think they actually
>>>> hold some promise. I like this since it's relatively pain-free which
>>>> helping to reduce extra syntax (when dealing with closures in jQuery
>>>> it's common that you'll need to declare references to the wrapped jQuery
>>>> set - something that this avoids).
>>>>
>>>> The proposal is a set of 3 changes - each change is making the second
>>>> argument of a callback function equal to $(this).
>>>>
>>>> - Modifying existing callbacks that have no second argument (like
>>>> .filter, as Yehuda mentioned).
>>>> - Modifying event callbacks to have a second argument be $(this)
>>>> (which, can conflict with .trigger(event, data)).
>>>> - Modifying each callbacks to have a second argument be $(this)
>>>> (replacing the existing second argument of this).
>>>>
>>>> Obviously changing the second incoming argument to
>>>> .each(function(i,$this)) is going to require a little bit of finesse. I
>>>> did a quick search on Google Codesearch but didn't see any immediate
>>>> warning signs:
>>>> http://www.google.com/codesearch?hl=en&lr=&q=
>>>> <http://www.google.com/codesearch?hl=en&lr=&q=
>>>> \.each\%28\s*function\%28\s*\w%2B%2C\s*\w%2B\s*\%29+lang%3Ajavascript&sbtn­=Search
>>>>
>>>> If we make a change like this I would like it to be an all-or-nothing
>>>> proposition (having a half-baked API modification landing seems kind of
>>>> lame) BUT it must be done in a way that we're sure won't break important
>>>> code. (At the very least, a change like this would have to be done in a
>>>> major 1.x release.)
>>>>
>>>> A quick note: It's probably important to use function(i, $this) in the
>>>> examples (to help differentiate it from a "normal" self [which generally
>>>> equates to var self = this;]).
>>>>
>>>> --John
>>>>
>>>> On Mon, Jul 20, 2009 at 11:14 PM, Yehuda Katz <wyc...@gmail.com
>>>> <mailto:wyc...@gmail.com>>

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="font-size: medium; ">On Jul 20, 2009, at 11:14 PM, Yehuda Katz wrote:</span></div></span></div><div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">At the moment, traversal callbacks, like the ones passed to find/filter/etc. take a single "index" parameter</span></blockquote></div>
<div><span class="Apple-style-span" style="font-size: 12px; "><div>I wasn't aware that .find() can take a callback. Is this new?</div><div><br class="Apple-interchange-newline">--Karl</div><div><br class="Apple-interchange-newline">____________</div><div>Karl Swedberg</div><div><a href="http://www.englishrules.com">www.englishrules.com</a></div><div><a href="http://www.learningjquery.com">www.learningjquery.com</a></div><div>
</div></span></div>

This seems pointless to me. You can create a new jQ object from 'this'
anytime you want - and only when you want, avoiding the overhead.
Would be useful if $this referred to the whole collection being
iterated, not the current element in the loop.
cheers
ricardo

Have you considered using a flyweight object?
It's about seven times faster in FF3.5 than creating a new jQuery
object on every iteration:
var el = document.body;
var t = new Date;
for(var i=0;i<10000;i++)
$(el);
console.log(new Date - t);
var $fly = $();
var t = new Date;
for(var i=0;i<10000;i++)
$fly[0] = el;
console.log(new Date - t);
And you can still make it a proper jQuery object by calling $( $fly )
inside the callback function, so that it can be referenced afterwards.
Moreover, in this case it would be unnecessary to use `this.setArray
( jQuery.makeArray(selector) )` in the `init` method, you could just
check if it's a flyweight object and simply create a new object with
the element.

Another helpful side effect is that if someone tries to reference any
of the flyweight objects in the callback (or `this`), then it won't
contain any elements, which makes it somewhat easier to spot the
error:
http://pastebin.com/f6d022e67

Changing event callbacks would be a critical change. jQuery UI uses
trigger with an additional argument everywhere.
Jörn