JavaScript: Clarifying The Keyword ‘this’

http://henrycode.tumblr.com/post/37627169791/javascript-clarifying-the-keyword-this

by henryzhu • 14 years ago

155 72 14 years ago

henrycode.tumblr.com

Whoaa512• 14 years ago

Thanks, I love having simple one liners to remember complex concepts :)

tantalor2• 14 years ago

One exception to the first exception: in a function with "use strict", "this" is never the global object.

flebron4• 14 years ago

I don't see the "exception to the exception", he is saying that if strict mode is on, "this" isn't the global object when saying foo(), it's undefined. And that's true.

It's possible to both have "use strict" and "this" be the global object (i.e. it's not true that it's never the global object), as simple as...

  "use strict"; // global scope
  var x = 1;

  (function() {
  "use strict";
  return this.x;
  }).call(this);

raju• 14 years ago

I am not sure that's quite what you want. Declaring x as a 'var' does not make it a property on the global object. Your example will return an 'undefined'.

I think this is what you want

  "use strict";
  this.x = 1;

  var ret = (function() {
    "use strict";
    return this.x;
  }).call(this);

  console.log(ret); //returns 1

tantalor2• 14 years ago

Fair point, but I thought it was clear I was referring to the first "exception", that is, calling a function like "foo()". Your example, while interesting, doesn't apply.

I'll be more clear:

> When there is no ‘.’ the keyword ‘this’ is bound to the global object window.

False if the function has "use strict".

jrajav• 14 years ago

You could probably factor exceptions 1) and 3) into the rule too!

         foo();

1) What's left of a bare function call is nothing - except for a blank line that leads to the top indentation level. In other words, what's left of it is the global scope. So, 'this' refers to the implicit global object in your environment. (Alternatively, in strict mode, since nothing is to the left of the call, 'this' is bound to nothing.)

    new Foo();

3) To the left of this function call is the 'new' keyword. So, 'this' refers to the new object that was just created for the constructor.

ChickenFur• 14 years ago

Thanks Henry!

ender72• 14 years ago

Sadly, one last, unfortunate inconsistency:

All event handlers have the value of 'this' bound to the object that emitted the event:

  var div = document.createElement('div');
  div.addEventListener('click', function(e) {
    console.log(this); // prints <div></div>
  });

lucian3032• 14 years ago

Unfortunate? Would you prefer to bind that yourself?

gruseom3• 14 years ago

Would you prefer to bind that ['this'] yourself?

Certainly. Why should some state be teleported in magically while other state (the argument 'e' in the above example) has to ride the bus? Does it belong to a different class of Being? I don't think so. This forces me to spend precious brain cells remembering which things go in which buckets and what the rules are for accessing the buckets - i.e. busywork - rather than the problem at hand.

The easiest thing is to explicitly bind to just that state you need and ignore everything else. That's more or less what the argument "e" offers: it's a bag of all the goodies you might need while handling your event. Clearly, therefore, the DOM element emitting the event should be available through that same mechanism – and as you generally can get everything you need in that department through things like e.target, I find it simplest to remain blissfully ignorant of 'this'.

flebron4• 14 years ago

That's not a JS inconsistency, that's just the browser calling yourhandler.call(yourobject, eventobject).

The underlying statement is that "event handler" is not a concept in JS, it's just a way of calling functions that some implementations use for some things (browsers for actions, node for I/O, etc...).

In fact, this didn't use to be true of old IE versions if I remember correctly, so it's not a matter of the language, but of what the browser does with your function during event firings.

ender72• 14 years ago

You can get the current emitting object via e.currentTarget. Modifying 'this', while cute, just makes yet another thing that must be explained to people when you start talking about 'this'.

jpolitz7• 14 years ago

The this keyword is confusing, it's good to see posts clarifying it. However, while the rule in the post will be right in many cases, this list is incomplete, even for some common usages of this, and might lull folks into a false sense of security:

1. "To the left of the dot" should be "to the left of the dot or bracket". E.g. o["foo"]() also passes o as this.

2. When you pass callbacks to built-ins like forEach, you can supply a thisArg, and if you don't, this will be bound to undefined (http://es5.github.com/#x15.4.4.18). (EDIT): Copying from cwmma below. Some callbacks, like setInterval and setTimeout, pass the global object rather than undefined. I suspect that DOM callbacks tend to use the global object and JS callbacks tend to use undefined, but that's not a blanket statement by any means.

3. This isn't purely JS, but when interacting with the DOM, this is also implicitly bound as a DOM element in event listeners. E.g. document.addEventListener('click', function() { console.log(this); }) will print the document object when you click on the page. This is quite relevant for any JS web development; if it makes it easier to conceptualize, imagine that the browser is calling a method with the DOM element to the left of the dot.

4. When the caller is strict mode code and the function is called without method-call syntax, undefined is passed as the this argument rather than the global object. You should always use strict mode to avoid accidentally handing the global object around (in strict mode, the "set to global" option is skipped in http://es5.github.com/#x10.4.3).

5. When using this at the toplevel (which is allowed), it is bound to the global object even in strict mode (http://es5.github.com/#x10.4.1.1).

And a few more esoteric ones:

6. In addition to call and apply, Function.prototype.bind() can also change the this parameter of a function, and violate the "left of the dot or bracket" rule (http://es5.github.com/#x15.3.4.5, see boundThis).

7. Inside a with() {} block (which you should never use, but we're trying to cover our bases here), this is bound to the object passed to with in the parentheses.

8. If a property is a getter or a setter, this is bound to the object to the left of the dot or bracket in the field access or assignment expression. This actually matches the rule in the post except for the fact that the "call time" is implicit; there are no () in the expression o.x, but it may call a getter function for x that passes o as this (http://es5.github.com/#x8.12.3).

(EDIT): One more doozy:

9. The dot and bracket operators implicitly convert primitives like numbers, strings, and booleans to objects, so it's not exactly what's to the left of the dot:

    Number.prototype.identity = function() { return this; }
    var x = 5
    var x2 = x.identity()
    typeof x2 === 'object' (true!)
    typeof x2 === 'number' (false!)

You can get the raw primitive if you make the function strict:

    Number.prototype.identity2 = function() { "use strict"; return this; }
    var x = 5;
    var maybe_five = x.identity2();
    typeof maybe_five === 'object' (false)
    typeof maybe_five === 'number' (true)

Please correct me if I've forgotten any...

flebron4• 14 years ago

For 6), a question, is .bind not just returning a new function, which will .call your provided one with the supplied "this"? That is, I think it's better to reason about it not as an exception to the usual semantics, but as something that can already be done by any coder in the language itself, using the usual semantics.

And thank you for 5), I didn't know it! :)

jpolitz7• 14 years ago

That's a reasonable way to think about bind().

On a pedantic note, due to complications with the new() operator, you can't actually implement .bind() in JS using only .call() and .apply() and get the prototype of the resulting objects right.

jQueryIsAwesome11• 14 years ago

Maybe "call" and "apply" belongs to that list?

    Function.prototype.call(this, argument0, argument1...)
    Function.prototype.apply(this, [arguments]) // array for args.

In a related note I created a variation of .bind that can have its bounded arguments an 'this' overwritten called mixbind, and also the methods .mixcall and .mixapply that can be used to overwrite arguments too (you can use NULL or undefined to left holes): https://gist.github.com/4303394

jpolitz7• 14 years ago

Yeah, those were mentioned in the post as exception 2, but maybe I should make a note.

abecedarius• 14 years ago

Do any of you just avoid 'this' and write your Javascript like infix Scheme? You can define objects via JSON literals with function values, and the result seems both simpler to think about and more pleasant to read. (JS engines are tuned for thissy code instead, I think unfortunately, but you can fall back to using prototypes where it makes a difference.)

gruseom3• 14 years ago

Yes indeed. I don't bother with 'this' at all, except when forced to by some interface. I don't even bother to define objects most of the time, just top level functions that can easily be called from a REPL. That simple subset of JS is powerful enough to go a long way — long enough that I'm unconvinced one needs anything else, unless one believes one does — and programming this way feels liberating, like riding a bicycle instead of pushing a car.

javajosh• 14 years ago

So far, my code tends to not use this at all. However, I've not written any applications that go beyond a few hundred lines of JS (interestingly, most of these programs would have been a few thousand lines of Java, if I even bothered to try at all. For UI, the libraries for JavaScript far outstrip anything available for Java!)

I do seem to be gravitating toward an organization scheme that centralizes my applications data into a single place such that all moving pieces of the application get a shot at dealing with inbound messages in an orderly fashion. This allows me to decompose the application into a very small number of function types, each of which has an explicit kind of responsibility.

The only time I've been tempted to go back to OOP has been to write (pure!) functions that seem to just beg for it - complex validation routines in particular. But using OOP for the app as a whole seems to not only be unnecessary, but positively undesirable.

aufreak3• 14 years ago

This is why I avoid using "this". Placing this comment next to any of the 9 points causes the comment to mean something different. However, "this" could be useful in circumstances where that is the exact effect desired. Even in such cases, the relevant object can be made explicit as an argument.

Some time back, I had to explain to some people how to think about "traditional OO" in JS, which I tried to make systematic in a post [1]. (Not trying to self promote here, but most other presentations I've seen start with the prototype mechanism. "this" is not brought in until much later in the post.)

[1] http://sriku.org/blog/2012/04/12/classes-and-javascript/

[edit: fixed typo]

v4134• 14 years ago

Point 7 is wrong.

Example:

a = {k: 10};

b = {k: 20};

var fn = function () {with (a) {this.k = 30;}};

fn.call(b);

console.log("a.k: ", a.k); // 10

console.log("b.k: ", b.k); // 30

jpolitz7• 14 years ago

Thanks, not sure what I was smoking there.

I can't seem to go back and edit, though...

epidemian5• 14 years ago

Thanks for the thorough response! I didn't know about point 9: using strict mode to prevent prototype functions from converting primitive types to objects. That weird behavior has bitten me a couple of times.

jQueryIsAwesome11• 14 years ago

Maybe 10) You can't directly change the value of 'this'

    this = {};
    ReferenceError: Invalid left-hand side in assignment;

But of course you can make sure 'this' is something you expect it to be.

    if(!this.tagName){
        throw new Error("Only DOM objects can used as 'this'")
    }

b3tta• 14 years ago

When using addEventListener, "this" is not necessarily bound to the DOM node. You can also pass an Object whith a "handleEvent" function as attribute, instead of directly passing a function.

You can read more about it for instance here: http://www.thecssninja.com/javascript/handleevent

cwmma2• 14 years ago

Another exception, functions invoked with setInterval have 'this' be window, even if they're invoked in context with it's own 'this'. This got me the other day. https://developer.mozilla.org/en-US/docs/DOM/window.setInter...

jQueryIsAwesome11• 14 years ago

A workaround that I like a little more: http://javascriptisawesome.blogspot.com/2011/11/setinterval-...

cwmma2• 14 years ago

There are totally a bunch of workarounds, it's just another exception to this, I was using CoffeeScript so I was able to grossly simplify the MDN one https://github.com/calvinmetcalf/communist/blob/master/src/s...

pixie_6• 14 years ago

var self = this; why do people bother with 'this'?

shabble• 14 years ago

because you sometimes want to refer to the original 'this' reference inside an inner nested function scope, where the actual 'this' keyword is rebound to the context of the inner function.

    function outer() {
        var outer_this = this;
        var inner = function() {
            var inner_this = this;
            // ...
        }
    }

http://stackoverflow.com/questions/4886632/what-does-var-tha... has some more details.

pixie_6• 14 years ago

Of course there are exceptions to the rule, but the rule should still be - avoid 'this.'

jQueryIsAwesome11• 14 years ago

For consistency and to avoid populating the scope with named variables, look at how jQuery works for good examples of how to use 'this' (the puns are infinite with this)

jpolitz7• 14 years ago

I'm confused... doesn't that just reduce the question to "what is the current binding of self"?

jQueryIsAwesome11• 14 years ago

After assignment "self" does not change even if "this" does.

    var player = { 
        play: function(){
            var self = this;
            setTimeout(function(){
                console.log(self);
            });
        }
    }

v4134• 14 years ago

IMO the use of self as the name of the variable referencing to 'this' is a little dangerous, because in a function, if you miss the line var self = this, self is a valid reference to the window object, so you will not get an expected error for an undefined variable.

pixie_6• 14 years ago

Better a little dangerous 'self' than a lot of dangerous 'this.'

dsego• 14 years ago

how about var that = this;

wildranter• 14 years ago

Tltr; this is a mistake.

ryanjodonnell• 14 years ago

Please fix the indentation in the image. I was so confused by it until I noticed that "location" and "locate" are both properties of the person object. They should both be indented the same.

drblast• 14 years ago

JavaScript has a number of nice features that do make sense, and if you understand how prototype chains work and such the complexity is worthwhile. "This" hasn't been one of those features for me.

I'm sure "this" makes sense in some context, but it forces me to think about the implementation of the language way too much without any benefit that I consider it a misfeature. So I don't use it.

Instead, I capture it with another variable in a prototype declaration:

   var that = this;

and refer to "that" everywhere in the prototype. Tends to be a lot simpler, and usually for event handlers I'll create a closure to avoid the issue entirely.

mistercow• 14 years ago

The ability to wrangle `this` via fat arrows is one of the nicest things about CoffeeScript.

josteink• 14 years ago

The fact that people are still writing clarifications for what something seemingly as simple as "this" actually means is just another argument for avoiding it entirely.

It's a huge source of sneaky, little errors and you wont find any JS object I've written without the first line being "var self = this;".

Basically "this" considered harmful.

slajax• 14 years ago

Articles like this become more and more important as more and more developers learn JS by way of frameworks like jQuery. If you want to understand "this". Understand call() and apply() first.

JavaScript: Clarifying The Keyword ‘this’

Related Stories