Response title
This is preview!
Move this topic
Optional scope for events
in Developing jQuery Core
•
3 years ago
Looking for any feedback on #3699 before committing, which is for allowing an alternative scope for events. There is a patch attached to the ticket. The ticket actually proposes a method signature that doesn't really fit jQuery's style. I added a patch that allows the following call signature instead.<div>
</div><div>$(...).bind("type", fn, scope);</div><div>$(...).bind("type", data, fn, scope);</div><div>
</div><div>This also applies to .one() and .live().</div><div>
</div><div>The patch utilizes the internal event.proxy method with a tweak to include an optional scope.</div>
<div><div>
</div><div>--</div><div>Brandon Aaron</div></div>
</div><div>$(...).bind("type", fn, scope);</div><div>$(...).bind("type", data, fn, scope);</div><div>
</div><div>This also applies to .one() and .live().</div><div>
</div><div>The patch utilizes the internal event.proxy method with a tweak to include an optional scope.</div>
<div><div>
</div><div>--</div><div>Brandon Aaron</div></div>
Replies(21)
Re: Optional scope for events
3 years ago
I love that functionality, looks good to me!
Paul Bakaus
UI Architect
http://paulbakaus.com
Am 04.05.2009 um 06:47 schrieb Brandon Aaron <brandon.aaron@gmail.com>:
Leave a comment on pbakaus's reply
Re: Optional scope for events
3 years ago
Would you be able to unbind a specific function with a specific scope?
$(el).bind('click', fn, foo);
$(el).bind('click', fn, bar);
$(el).unbind('click', fn, foo);
Leave a comment on scott.gonzalez's reply
Re: Optional scope for events
3 years ago
I like it... but I think it is confusing and inconsistent.
We add this for events, but why not for animations ? or ajax
requests ?
Also... you need to document, the 'this' of the handler will be the
currentTarget, UNLESS you passed a scope to bind(). I think features
like this affect the learning curve and confuse novice users.
As I see it, I'd rather add a static method like $.bind.
$(...).bind("type", $.bind(scope,fn));
$.bind should copy the guid ($.event.proxy) so that the returned
function can be unbound using just fn and there's no need to save it
in a var.
My $0.02
Cheers
--
Ariel Flesler
Leave a comment on flesler's reply
Re: Optional scope for events
3 years ago
Yes, you can still unbind the named handler. The jQuery.event.proxy method takes care of this.<div>
</div><div>--</div><div>Brandon Aaron</div><div>
</div><div>--</div><div>Brandon Aaron</div><div>
Leave a comment on brandon_aaron's reply
Re: Optional scope for events
3 years ago
I don't agree that this is confusing. I find it to be very beneficial to have a method signature that grows to meet your needs but doesn't get in your way when you don't need all of it. I know we've received both insult and praise for our overloaded methods but that is how we roll! :)<div>
</div><div>It might be inconsistent for the moment but we can fix that. This has been an oft-requested feature (even by the jQuery UI team) specifically for events. Certainly we'll need to review the other places we use a callback and see if it makes sense to provide an optional alternate scope. I'm all for the pattern of anywhere we provide a callback, an optional scope should follow. However, we need to make sure people still have access to the actual element. </div>
<div>
</div><div>Although just giving everyone a $.bind method is much easier on us, I don't think it fits very well into the philosophy of do more, write less. I'd also argue that this would be more of a learning curve to some than the optional scope param. I'm not adverse to providing both though since we'll most likely need $.bind if we start adding optional scopes to other methods in the API. It would be as simple as exposing another jQuery utility method.</div>
<div>
</div><div>Also, I forgot to include the helper methods, like click, in this patch. These would also need include the ajax event methods and probably the ready shortcuts.</div><div>
</div><div>--</div><div>Brandon Aaron</div>
<div>
</div><div>It might be inconsistent for the moment but we can fix that. This has been an oft-requested feature (even by the jQuery UI team) specifically for events. Certainly we'll need to review the other places we use a callback and see if it makes sense to provide an optional alternate scope. I'm all for the pattern of anywhere we provide a callback, an optional scope should follow. However, we need to make sure people still have access to the actual element. </div>
<div>
</div><div>Although just giving everyone a $.bind method is much easier on us, I don't think it fits very well into the philosophy of do more, write less. I'd also argue that this would be more of a learning curve to some than the optional scope param. I'm not adverse to providing both though since we'll most likely need $.bind if we start adding optional scopes to other methods in the API. It would be as simple as exposing another jQuery utility method.</div>
<div>
</div><div>Also, I forgot to include the helper methods, like click, in this patch. These would also need include the ajax event methods and probably the ready shortcuts.</div><div>
</div><div>--</div><div>Brandon Aaron</div>
<div>
Leave a comment on brandon_aaron's reply
Re: Optional scope for events
3 years ago
I agree with Ariel, that this would be better served as a static
method. Dojo does the (fn, scope) (actually, we do a mixmatch and
allow curried args, but I digress) and it definitely is a learning
curve for js n00bs, and certainly not very jQuery-ish. by making it a
separate method, it becomes entirely opt-in for power users and is
nearly as concise as the proposed further overloading of the existing
signature.
I ported dojo's .hitch(), which is likely more in line with Ariel's statement.
http://higginsforpresident.net/js/jq.hitch.js
My $0.02US
Regards,
Peter
Leave a comment on phiggins1's reply
Re: Optional scope for events
3 years ago
<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: 'Lucida Grande'; 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="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "><div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 13px; ">I actually have to disagree with Pete and Ariel on this.<div>There are plenty of concepts that throw off the uninitiated, such as any scoping, or even the funky concept of defining a function in the method signature of another method.</div><div>
</div><div>And since the parameter is the last in the signature, it's completely transparent to people who don't need it.</div><div>The other downside I see to using a static method, besides the fact that it's harder to read is that doing it that way would create 2 function objects for every event.</div><div>What you would have would be:</div><div>function(){/*added by static bind*/</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>function(){ /*proxy*/</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>eventListener; /*actual method*/
</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>}
</div><div>}
<div><br class="webkit-block-placeholder"></div><div>If you're going to need scope correction, chances are you're not just including jquery to do some minimal work, but rather building large applications (and hence, would probably be doing a lot of these calls, and would be more sensitive to performance).</div><div>
</div><div>Brandon, I like your API changes you made to the ticket, and overall, I think this looks good. I agree that consistency should be kept with other aspects of the library, but it's not as common, and I don't think it's important enough to derail this feature.</div><div>Thanks for taking a look at it :)</div><div>
</div><div>
</div></div></span><b>Nate Cavanaugh</b></div><div>Director of User Interface Engineering</div><div>Liferay, Inc.</div><div>Enterprise. Open Source. For life.</div></div><div>
</div></span></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div>
<div><div>On May 4, 2009, at 7:08 AM, pete higgins wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
I agree with Ariel, that this would be better served as a static
method. Dojo does the (fn, scope) (actually, we do a mixmatch and
allow curried args, but I digress) and it definitely is a learning
curve for js n00bs, and certainly not very jQuery-ish. by making it a
separate method, it becomes entirely opt-in for power users and is
nearly as concise as the proposed further overloading of the existing
signature.
I ported dojo's .hitch(), which is likely more in line with Ariel's statement.
<a href="http://higginsforpresident.net/js/jq.hitch.js">http://higginsforpresident.net/js/jq.hitch.js</a>
My $0.02US
Regards,
Peter
</div><div>And since the parameter is the last in the signature, it's completely transparent to people who don't need it.</div><div>The other downside I see to using a static method, besides the fact that it's harder to read is that doing it that way would create 2 function objects for every event.</div><div>What you would have would be:</div><div>function(){/*added by static bind*/</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>function(){ /*proxy*/</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>eventListener; /*actual method*/
</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>}
</div><div>}
<div><br class="webkit-block-placeholder"></div><div>If you're going to need scope correction, chances are you're not just including jquery to do some minimal work, but rather building large applications (and hence, would probably be doing a lot of these calls, and would be more sensitive to performance).</div><div>
</div><div>Brandon, I like your API changes you made to the ticket, and overall, I think this looks good. I agree that consistency should be kept with other aspects of the library, but it's not as common, and I don't think it's important enough to derail this feature.</div><div>Thanks for taking a look at it :)</div><div>
</div><div>
</div></div></span><b>Nate Cavanaugh</b></div><div>Director of User Interface Engineering</div><div>Liferay, Inc.</div><div>Enterprise. Open Source. For life.</div></div><div>
</div></span></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div>
<div><div>On May 4, 2009, at 7:08 AM, pete higgins wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
I agree with Ariel, that this would be better served as a static
method. Dojo does the (fn, scope) (actually, we do a mixmatch and
allow curried args, but I digress) and it definitely is a learning
curve for js n00bs, and certainly not very jQuery-ish. by making it a
separate method, it becomes entirely opt-in for power users and is
nearly as concise as the proposed further overloading of the existing
signature.
I ported dojo's .hitch(), which is likely more in line with Ariel's statement.
<a href="http://higginsforpresident.net/js/jq.hitch.js">http://higginsforpresident.net/js/jq.hitch.js</a>
My $0.02US
Regards,
Peter
Leave a comment on nate.jquery1's reply
Re: Optional scope for events
3 years ago
I still do not agree that this is better achieved by a static bind/hitch method alone (for jQuery). Just because it is a typical power user feature doesn't mean we shouldn't make it easily useable by non-power users. But for me it is more than just catering to various levels of knowledge... it is also about having cleaner code.<div>
</div><div>I'd much rather have my code look like this:</div><div>
</div><div>$('li').click(function( event ) {</div><div> // do some fun stuff here</div><div>}, myObj);</div><div>
</div><div>Than something like this:</div>
<div>
</div><div>$('li').click( $.bind(function( event ) {</div><div> // do some fun stuff here</div><div>}, myObj) );
<div>
</div><div>
</div><div>The lack of extra syntax and power user features made easier are a jQuery features. </div>
<div>
</div><div>--</div><div>Brandon Aaron
</div><div>I'd much rather have my code look like this:</div><div>
</div><div>$('li').click(function( event ) {</div><div> // do some fun stuff here</div><div>}, myObj);</div><div>
</div><div>Than something like this:</div>
<div>
</div><div>$('li').click( $.bind(function( event ) {</div><div> // do some fun stuff here</div><div>}, myObj) );
<div>
</div><div>
</div><div>The lack of extra syntax and power user features made easier are a jQuery features. </div>
<div>
</div><div>--</div><div>Brandon Aaron
Leave a comment on brandon_aaron's reply
Re: Optional scope for events
3 years ago
I don't find this feature all that useful myself, since my callback
functions tend to be a mix of jQuery/DOM, setTimeout, Google Maps/Earth, and
other asynchronous APIs. If I can only bind an object to a callback in one
of those types of APIs and not the others - or if they each sprout
independent ways of doing it - I may as well just use a closure so I have
one way to handle them all.
But I've seen that a lot of people do like this capability, so I certainly
don't object to it, unless of course it slows down my own code.
My one request: please do not call it "scope"! Not in the code, not in the
comments, and not in the docs.
JavaScript has something called scope, and you create it by nesting
functions lexically (or using the "with" statement). Setting the "this"
value for an event or other callback isn't related in the slightest to
scope.
If you need a name for the concept, you could describe it as "binding an
object to the event handler" or - probably better - "calling the event
handler as a method of an object". I don't know of a short and sweet word
for it, but "scope" is already taken. :-)
Thanks,
-Mike
Leave a comment on Michael Geary's reply
Re: Optional scope for events
3 years ago
How about "thisObject"? Taken from Mozilla's docs for the forEach method ( <a href="https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:forEach">https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:forEach</a> ).<div>
</div><div>--</div><div>Brandon Aaron</div><div>
</div><div>
</div><div>--</div><div>Brandon Aaron</div><div>
</div><div>
Leave a comment on brandon_aaron's reply
Re: Optional scope for events
3 years ago
Why not steal the term from grammar and call it the "subject"?
Leave a comment on nbubna's reply
Re: Optional scope for events
3 years ago
This is definitely useful and necessary. I'd put my two cents for it
being called either "scope" or "context," which, though "taken,"
describe the actual purpose of the additional argument. "pointer"
might also be an appropriate name.
--adam
Leave a comment on ajpiano's reply
Re: Optional scope for events
3 years ago
Assuming we do leave it within $.fn.bind(), then I'd say "scope" or
"context". Completely against the other ones mentioned so far :)
Leave a comment on flesler's reply
Re: Optional scope for events
3 years ago
I like that, it's perfectly accurate. Having overloaded methods is
already confusing, calling this feature "scoping" when it has nothing
to do with scope is a step in the wrong direction. Naming and docs
should be based on technically accurate and clearly understandable
concepts.
Leave a comment on ricardobeat's reply
Re: Optional scope for events
3 years ago
Well, to unify against "scope" and "context", i'll throw my $.02
behind "thisObject". It's closer to Mozilla's "thisArg" (which would
also be fine).
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Function/apply
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Function/call
as others have pointed out, "this" is actually neither scope nor context. :)
Leave a comment on nbubna's reply
Re: Optional scope for events
3 years ago
On May 4, 6:47 am, Brandon Aaron <brandon.aa...@gmail.com>
Leave a comment on tarini83's reply
Leave a comment on aheckman's reply
Re: Optional scope for events
3 years ago
I've just had a look at r6344 and there seems to be an extra argument
in jQuery.event.add but that function hasn't been modified (yet?).
And maybe it's been mentioned before but if you're really adding this
feature why not do the same with $.each? Hopefully no one uses the
internal `args` argument and it would be at least as useful as for
events.
Leave a comment on balazs.endresz's reply
Leave a comment on thatcher.christopher's reply
Re: Optional scope for events
3 years ago
Yes, that was left-over code from looking at implementing this feature in a different way (removed now, thanks). We are definitely looking into what it would take to bring this functionality to other methods within the library that use callbacks but wanted to go ahead and get this applied for events due to its popularity.<div>
</div><div>--</div><div>Brandon Aaron
</div><div>--</div><div>Brandon Aaron
Leave a comment on brandon_aaron's reply
Leave a comment on balazs.endresz's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to brandon_aaron's discussion
{"z2948784":[14737000000468311],"z2655730":[14737000000468295],"z394073":[14737000000468293,14737000000468301,14737000000468303,14737000000468309,14737000000468313,14737000000468333],"z2949228":[14737000000468305],"z2949257":[14737000000468327],"z2951857":[14737000000468325],"z2949822":[14737000000468329,14737000000468335],"z2949655":[14737000000468321],"z2656090":[14737000000468297],"z2951844":[14737000000468315,14737000000468323],"z957804":[14737000000468317],"z2656670":[14737000000468299,14737000000468319],"z2951006":[14737000000468307],"z2949163":[14737000000468331]}
Statistics
- 21 Replies
- 2632 Views
- 0 Followers
