Does ES5's "use strict"; influence closure?

Question

If I am not wrong, under strict mode, functions don't get access to global object (The 'this' is undefined for the function). On the other hand, inner function need access to its parent's 'this' for closure to work. Does JavaScript make an exception for inner functions under strict mode?

Answer 1

Closures have nothing to do with the this pointer. Closures are a concept of functional programming not object oriented programming. The this pointer is a concept of object oriented programming. Both can work simultaneously and independently without causing problems.

For example consider the following function in strict mode:

function getCounter() {
    "use strict";

    var count = 0;

    return function counter() {
        return ++count;
    };
}

Here a call to the getCounter returns a closure. The function counter closes over the value count. You can then use the returned counter as follows:

var counter = getCounter();

counter(); // 1
counter(); // 2
counter(); // 3

I think you're confusing closures with nested functions. Read the following thread. It explains closures really well: JavaScript closures vs. anonymous functions

In strict mode the this pointer is undefined when it would point to the global object. Otherwise you may use it normally. This prevents you from accidentally creating global variables. However it doesn't cause any hinderance.

Consider the following constructor function for example:

function Counter() {
    "use strict";

    var count = 0;

    this.increment = function () {
        count++;
    };

    this.getCount = function () {
        return count;
    };
}

You can create an instance and use it as follows:

var counter = new Counter;
counter.increment();
counter.getCount();        // 1

However if you forget to put the new then this will point to the global object which in strict mode is undefined. Hence trying to assign the method increment to this will throw an error.

Getting back to the original question, you can always store the value of the this pointer in another variable if you wish to access it in a nested function. For example:

function Counter() {
    "use strict";

    var that = this;

    that.count = 0;

    return function counter() {
        return ++that.count;
    };
}

I know that this is a really stupid example but it has all the elements required to get my point across. You can now use the above function as follows:

var counter = new Counter;

counter(); // 1
counter(); // 2
counter(); // 3

That's all that there is to it.

Answer 2

By your question, I believe you meant Constructors and instanced objects. use strict pragma does not affect it. Accessing and calling an object's property of type function through dot or square brackets notation inside an expression automatically sets the ThisBinding to the object from which you got the function reference.

function Foo() {}
Foo.prototype.someMethod = function() {
    console.log(this.blah);
};
var foo = new Foo();
foo.blah = 1;

//this:
foo.someMethod();
//implicitly does this:
foo.someMethod.call(foo);

Fiddle

TJ has probably explained this behavior in a simpler manner in Mythical Methods:

[...] when you call a function using an expression that gets the function reference from an object property (e.g., object.functionName() or object['functionName']()), the object is set automatically as "this" within the function call.

---

use strict only makes a difference when the this binding is not set (null or undefined), which is not the case here.

Then as you know, when the this reference is not set when entering function code, in non-strict mode it refers to the global object (the window object in browser environment) while in strict mode it is undefined. See ES5.1 Section 10.4.3

---

Now if you mean closures as in a function inside of another, use the old lexical scope trick.

function outerFunction() {
    var _this = this;
    function innerFunction() {
        // _this references the outerFunction's this
    }
}

This behavior is not influenced by use strict either.