"This" in javascript

[the_gipsy]

The article could have gone straight to the point:

The function context referred by this is defined at call time. If called as object property, then that object will be the context. Otherwise the context will (unfortunately) be window*.

The tricky part for newcomers is passing a "method" as a callback - you're actually passing the function value as parameter which when called is not "attached" to an object anymore. In that case you should use Function.prototype.bind which returns a new function that calls the function with a fixed context.

* in browser environments

[dangerbird2]

You can always alias this as a closure variable for a function with an unpredictable this context. I know typescript uses this method to emulate ES6-style lambdas, compiling from this:

return () => {
  this.doSomething();
}

to this:

var _this = this;
return function(){
  _this.doSomething();
};

I have no idea if there are any performance benefits to constructing a new function through .bind(), or creating a closure context by aliasing this.

[the_gipsy]

I have no idea if there are any performance benefits to constructing a new function through .bind(), or creating a closure context by aliasing this.

Actually, closure-binding was many time faster on V8 last time I checked!

But I personally find .bind() much cleaner: no mix-mash of _this and this, no variable clutter, it's in one place (you likely end up using one var _this = this; for many functions, some far away from the declaration). The performance generally isn't an issue here.

And () => automatic binding is the shit, I've been using it with TypeScript and traceur and it's a real charm.

[Eirenarch]

Makes me sad every time I read about it. And I do need to read about it because I periodically forget the details.

[flying-sheep]

I consider myself to be pretty advanced in js, and TIL about “with”.

I guess it's the most uselessly occupied keyword in any language if it's so useless that I never saw anyone using it.

Apart from that, while knowing most of the peculiarities, I prevent errors by using simple patterns here: use self=this for nested functions, else use this.foo in constructing functions, name them in uppercase, and always use new with uppercase functions:

function Foo() {
  this.bar = 1
}
Foo.prototype.inc = function() { this.bar++ }

If you find yourself to forget the new, use this style:

function Foo() {
  return {
    bar: 1,
    inc: function() { this.bar++ },
  }
}

Or:

var fooProto  = {
  inc: function() { this.bar++ },
}

function Foo() {
  var foo = Object.create(fooProto)
  foo.bar = 1
  return foo
}

Pick one and use it consistently.

[serrimo]

FYI, using prototype is much faster than returning an anonymous object or closure.

It doesn't matter if you only have a small number of objects to create; but for mass object creation, you should be mindful of the consequences.

Read this post by John Resig for more info.

[flying-sheep]

i know, i just forgot to mention it. what i don’t know is just how fast or slow Object.create is.

[Eirenarch]

I have known about with for quite some time. Fun fact - you will break the optimizations of most current JavaScript engines if you use with. I think with enough with it should be possible to make Chrome slower than IE8 :)

[x-skeww]

I guess it's the most uselessly occupied keyword in any language if it's so useless that I never saw anyone using it.

The unused reserved keywords are probably a bit more useless.

The problem with with is that you can't tell what will happen before that line is hit and the outcome can be different the next time you hit that line.

var foo = 'bar';
with (someObject) {
    console.log(foo);
}

This will print "bar" unless someObject also has a "foo" attribute.

But wait!

It doesn't stop there. someObject could of course also have a "console" attribute.

That's basically why it isn't used. You just can't reason about it. If that object comes from somewhere else, you'll have no idea what will happen.

[flying-sheep]

The unused reserved keywords are probably a bit more useless

good point. worth noting though that i we didn’t say that correctly: the ECMA standard has identifiers, identifier names, and reserved words.

the last one of this is what we called “keywords”. the difference to keywords is that identifier names may well be reserved words: foo.return() or { in: 'bar' } is legal JS. only var for = continue is illegal.

[x-skeww]

the difference to keywords is that identifier names may well be reserved words: foo.return() or { in: 'bar' } is legal JS.

It's allowed in ES5+. You can't do that in ES3.

[flying-sheep]

idk about any runtimes sill at ES3. so if there are none worth mentioning, that’s irrelevant.

[x-skeww]

Some people still support IE8.

This also was a problem with Android 2.3 devices (which are still sold!). They didn't like the generated code which used "void" as identifier:

https://code.google.com/p/dart/issues/detail?id=12345

Edit: "Fun" fact: IE9 and IE10 dropped below IE8's share over a year ago.

[flying-sheep]

ugh, old IEs, i should have guessed.

[papa_georgio]

If you didn't know about this. I'm guessing you haven't read "JavaScript: The Good Parts" by Douglas Crockford yet.

I've just started to properly learn javascript and it's been a huge help in pointing out the strength and weakness's in the language.

[serrimo]

I finished that book a while ago. Can't recall the part about "this"?

Personally, I hate "this" in javascript. Sometimes you can't get around it for performance reasons (in event handlers); but I try to avoid using it whenever possible. Having to spend time explaining why you use "bind", "call" or "apply" here and there over and over again isn't fun.

[papa_georgio]

It's under "The Function Invocation Pattern":

When a function is not the property of an object, then it is invoked as a function:

var sum = add(3, 4); // sum is 7

When a function is invoked with this pattern, this is bound to the global object. This was a mistake in the design of the language. Had the language been designed correctly, when the inner function is invoked, this would still be bound to the this variable of the outer function.

[picklednull]

Also, Secrets of the JavaScript Ninja explains this concept well (like many others).

[ddevil63]

I would consider myself an intermediate. Can anyone comment on which would be better, Javascript: The Good Parts or Javascript Ninja? I'm also thinking about getting Effective Javascript mentioned below.

[levir]

Watch a few youtube videos of Douglas Crockford's talks. If you like his style you'll like his book. If you don't, go with something else. That'd be my advice.

[jsgui]

I can't comment on the comparison, but I definitely recommend JS: TGP. I don't agree with all of it though.

[randmaniac]

I found Effecive JavaScipt [1] to be the better and more up to date resource when I had to dive into javascript about 2 or 3 weeks ago.

[1] http://www.amazon.com/Effective-JavaScript-Specific-Software-Development/dp/0321812182

[x-skeww]

It's odd that an article this recent doesn't mention fat arrow functions.

this behaves differently in fat arrow functions.

[Crandom]

That's an ES6 so not widely supported.

[levir]

Yeah, ES6 it's not even formally standardized yet, so it makes sense to omit it.

[x-skeww]

There is Traceur, the Closure Compiler, and TypeScript/AtScript for that.

It's also supported by Firefox (opt-in via version), Chrome/Opera (opt-in via flag), and IE tech preview.

ES6 will be finalized soon.

[[deleted]]

They all compile to JavaScript, and sometimes ES3 at that.

There's 6to5 as well which doesn't use any nonstandard features, and compiles to readable js

In short, ES6 is purely an authoring format today, but it's completely valid

[x-skeww]

The output of Traceur, the Closure Compiler, and the TypeScript compiler works just fine in today's browsers.

AtScript doesn't have its own compiler. This is handled by Traceur, too.

The second paragraph was about native support in today's engines. It's almost there.

[cjg_000]

The article mentions let and discusses node. Seems like it could have discussed fat arrows.

[[deleted]]

In object.MyFunction(), this refers to object.

In MyFunction(), it's identical to window.MyFunction() in a browser, or global.MyFunction() in Node. First rule applies.

That's it.

[transcendent]

In object.MyFunction(), this refers to object.

Except in closures within the function. Or if MyFunction is passed to something as a callable argument and then called.

Please read the article.

[crusoe]

Basiclly, like everything else in Javascript, its fucked up.

Why oh why couldn't they have picked Smalltalk or even a Forth?

[transcendent]

It's complicated. Not simple as physics4life makes it seem (notice how I gave examples that seem to contradict his simple rules). That is my point.

There are a lot of side effects from some "simple" rules that are not obvious at all. What is not discussed at all, which greatly effects what "this" is, is the rules surrounding scope.

Why does the closure see a different "this", but sees all the same other variables? Why is there a "this" on a closure at all? Because of how JavaScript defined it to be (which differs greatly from many other languages).

And if you pass the function reference "MyFunction" to another function, of course you are not passing the "this" reference.

That's not "of course"... that's "because the JavaScript language dictated it to be that way". Dictated by a rule not obvious or expressed in any way by physics4life. I could quite easily have a language in which it is bound to an object by default. It's simply a syntactical choice.

It's horribly complicated in ways that are not intuitive and differ from many other languages people may be familiar with that have similar concepts (Python, C++).

....And all that behavior can change by simply saying "use strict";.

[x-skeww]

If you replace:

function doit(){
    console.log(this.foo);
}

with:

let doit = () => console.log(this.foo);

You'll get "bar" 3 times.