Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been writing most of my javascript applications in an OO style close to what I would use for most other languages. However, this means that most callbacks need to have a reference to an object, and I generally handle that by using $.proxy (or dojo.hitch, or whatever the framework's tool for this is) to be sure that the callbacks are operating in the context of my object, rather than the tag they were attached to.

Very quickly, this seems to lead to using proxied calls for almost everything, and can look like I'm fighting against the tool, particularly if the tool is jQuery.

Do you have a policy on how to handle javascript function binding in your work? Do you try fit your design to how the tool binds it's functions, or do you force the bindings to work according to your design?

share|improve this question
1  
Can you precise why you don't generally simply use closures or inline functions ? –  dystroy Apr 18 '13 at 15:06
    
Neither scales past a certain level of complexity, and they both present the same issue, where jQuery blows away the current object scope. Stuffing a bunch of variables just so that I have access to them in the closure seems like a worse solution. –  Dan Monego Apr 18 '13 at 15:48
5  
I know people often try to refute this fact, but the developer of JavaScript, Brendan Eich himself claimed "I was recruited to Netscape with the promise of “doing Scheme” in the browser." which is functional and based entirely on using lexical closures. Using JavaScript as an OO language is going against the grain, regardless of what many people may believe. JQuery embraces this fact, which is part of why it's so successful. –  Jimmy Hoffa Apr 18 '13 at 15:50
1  
A code example of what you're trying to do would be helpful - it sounds like what you want is something like the module pattern, but you might be trying to do it using OO methods. –  Tacroy Apr 18 '13 at 15:58
1  
@Esailija jQuery is a monadic api with internal continuation pumps, you can say that it's OO but there's nothing OO about that style or implementation. the DOM has nothing to do with javascript, that's strictly an implementation of the browser. Also, in javascript closures have a type similar to lambda-mu, that is not typical of non-functional languages. Furthermore, no, most languages do not have arbitrary depth lexically scoped closures, sorry to burst your bubble.. –  Jimmy Hoffa Apr 18 '13 at 23:02
show 3 more comments

2 Answers

up vote 4 down vote accepted

Well the alternatives to function binding are a lot worse, instead of a simple $.proxy call, the popular alternative is to type this every time

var self = this;
$().click( function(e) {
    self.doit(e);
});

Compared to

$().click($.proxy(this.doit, this));

I have an active feature request for jQuery where this would be possible:

$().click(this);

This is what the standard event listener api supports:

elem.addEventListener("click", this);

The method .handleEvent is then called on this when the event occurs, with proper context. The element as this is just useless because it can be always attained from event.currentTarget.

So it's not a code smell in that you could replace it with something simpler or better.

share|improve this answer
add comment

If you need the context for multiple functions, I agree with Esailija's solution. It's common and simple.

If you only need it once, this is also available:

$().click( function(e) {
    this.do_something();
}.bind(this) );

If do_something takes no arguments (so it'll discard the e) and the anonymous function would only call it, I believe this also works:

$().click( this.do_something.bind(this) );
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.