Scope & Closures Chapter 5

YDKJSY Scope & Closures

Chapter 5 : Scope Closure

Closure is all around you in JavaScript, you just have to recognize and embrace it.- Kyle Simpson

Click to view full text

Closures happen as a result of writing code that relies on lexical scope. They just happen. You do not even really have to intentionally create closures to take advantage of them.

Nitty Gritty

Closure is when a function is able to remember and access its lexical scope even when that function is executing outside its lexical scope.

Let's start with...

lexical scope

function foo() {
  var a = 2;

  function bar() {
    console.log( a ); // 2
  }

  bar();
}

foo();

Function bar() has access to the variable a in the outer enclosing scope because of lexical scope look-up rules.

It is said that the function bar() has a closure over the scope of foo().

But, closure defined in this way is not directly observable, nor do we see closure exercised in the above snippet.

Let us then consider code which brings closure into full light:

CLOSURE

function foo() {
  var a = 2;

  function bar() {
    console.log( a );
  }

  return bar;
}

var baz = foo();

baz(); // 2 -- Whoa, closure was just observed, man.

The function is being invoked well outside of its author-time lexical scope. Closure lets the function continue to access the lexical scope it was defined in at author-time.

Whatever facility we use to transport an inner function outside of its lexical scope, it will maintain a scope reference to where it was originally declared, and wherever we execute it, that closure will be exercised.

Block Scoping Revisited

let and closure

for (let i=1; i<=5; i++) {
  setTimeout( function timer(){
    console.log( i );
  }, i*1000 );
}

There's a special behavior defined for let declarations used in the head of a for-loop. This behavior says that the variable will be declared not just once for the loop, but each iteration.

Modules

There are other code patterns which leverage the power of closure but which do not on the surface appear to be about callbacks.

let's start with this

As this code stands right now, there's no observable closure going on.

But now we have...

CLOSURE

The most common way of implementing the module pattern is often called "Revealing Module", and it's the variation we present here.

CoolModule() is just a function, but it has to be invoked for there to be a module instance created.

The CoolModule() function returns an object. The object we return has references on it to our inner functions, but not to our inner data variables. We keep those hidden and private. It's appropriate to think of this object return value as essentially a public API for our module.

The code above is a module creator which can be invoked any number of times, each time creating a new module instance.

This is a...

single module instance

Here, we turned our module function into an IIFE (see Chapter 3), and we immediately invoked it and assigned its return value directly to our single module instance identifier foo.

Modules are just functions, so they can receive...

parameters

Another slight but powerful variation on the module pattern is to name the object you are returning as your...

public API

By retaining an inner reference to the public API object inside your module instance, you can modify that module instance from the inside, including adding and removing methods, properties, and changing their values.

YDKJSY Scope & Closures Chapter 5 Scope Closure