I find myself needing:
var self = this;
a lot within my javascript ‘classes’. Although this is commonly done, it feels a bit wrong.
What I’m hoping to find in this question is a better way to deal with this, or a something to convince me this is quite alright.
Is this the standard way to keep the correct bindings around? Should I standardize on using ‘self’ everywhere, unless i explicitly need ‘this’.
edit: I know exactly why I need this, I’m just wondering if it’s considered a bit evil and why. I’m aware there’s also the ‘apply’ built-in javascript function to explicitly define scope when calling a method. Is it better?
As others have said: This “extra variable” is (at some level) the only way to get about the fact that
thisis a special expression and thus, being not a variable, is not bound in an execution context/closure.However, what I think you are asking (or what I really want to answer) is:
Summary
While I tried this once, and had the same question, I no longer use this approach. Now I reserve the construct for when I need access in a closure. To me it adds a little “hey, this is what I really want!” semantic to my code:
this -> thisandself -> this (but really that) in a closureQuestions ala carte:
Do what feels right to you. Don’t be afraid to try one method and switch back later (but please try to remain consistent within each project 🙂
“self” is the most common name used. As per above, I prefer the opposite approach — to use
thisexcept when a closure binding is required.Evil is a silly subjective term (albeit fun sometimes). I’ve never said it was evil, just why I do not follow the approach. Some people tell me I am “evil” for not using semi-colons. I tell them they should actually come up with good arguments and/or learn JavaScript better 🙂
The problem with
apply/callis that you must use them at point of the function invocation. It won’t help if someone else calls one of your methods as thethismay already be off. It’s most useful for doing things like the jQuery-style callbacks where thethisis the element/item of the callback, etc.As an aside…
I like to avoid “needing self” on members and thus generally promote all member functions to properties where the receiver (
this) just “flows through”, which is normally “as expected”.The “private” methods in my code begin with a “_” and if the user calls them, that’s on them. This also works better (is required, really) when using the prototype approach to object creation. However, Douglas Crockford disagrees with this “private” approach of mine and there are some cases where the look-up chain may thwart you by injecting an unexpected receiver:
Using the “self” bound in the constructor also locks the upper limit of the look-up chain for a method (it is no longer polymorphic upward!) which may or may not be correct. I think it’s normally incorrect.
Happy coding.