need help understanding closures usage in this code

Question

Here is a simplified snippet from some code I wrote for managing tablet gestures on canvas elements

first a function that accepts an element and a dictionary of callbacks and register the events plus adding other features like 'hold' gestures:

function registerStageGestures(stage, callbacks, recieverArg) {
    stage.inhold = false;
    stage.timer = null;

    var touchduration = 1000;
    var reciever = recieverArg || window;

    stage.onLongTouch = function(e) {
        if (stage.timer) clearTimeout(stage.timer);
        stage.inhold = true;
        if (callbacks.touchholdstart) callbacks.touchholdstart.call(reciever, e);
    };

    stage.getContent().addEventListener('touchstart', function(e) {
        e.preventDefault();
        calcTouchEventData(e);
        stage.timer = setTimeout(function() {
            stage.onLongTouch(e);
        }, touchduration);
        if (callbacks.touchstart) callbacks.touchholdstart.call(reciever, e);
    });

    stage.getContent().addEventListener('touchmove', function(e) {
        e.preventDefault(); 
        if (stage.timer) clearTimeout(stage.timer);

        if (stage.inhold) {
            if (callbacks.touchholdmove) callbacks.touchholdmove.call(reciever, e);

        } else {
            if (callbacks.touchmove) callbacks.touchmove.call(reciever, e);
        }
    });

    stage.getContent().addEventListener('touchend', function(e) {
        e.preventDefault();
        if (stage.timer) clearTimeout(stage.timer);
        if (stage.inhold) {
            if (callbacks.touchholdend) callbacks.touchholdend.call(reciever, e);
        } else {
            if (callbacks.touchend) callbacks.touchend.call(reciever, e);
        }
        stage.inhold = false;
    });
}

later I call registerStageGestures on a few elements (represented by 'View' objects) in the same page. Something like:

function View() {
    var self=this;
    ..

    function InitView() {
       ...

       registerStageGestures(kineticStage, {
        touchstart: function(e) {
            // do something
        },
        touchmove: function(e) {
            // do something
        },
        touchendunction(e) {
            // do something
        },
        touchholdstart: function(e) {
            // do something
        },
        touchholdmove: function(e) {
            // do something
        },
        touchholdend: function(e) {
            // do something
        },
    }, self);

Everything works fine, however I'm left wondering about two things in the implementation of registerStageGestures:

First, is it necessary to make inhold, timer and onLongTouch members of the stage ? or will closures make everything works well if they are local vars in registerStageGestures ?

Second, is it necessary to call the callbacks with '.call(receiver,' syntax ? I'm doing this to make sure the callback code will run in the context of the View but I'm not sure if it's needed ?

any input is much appreciated

Thanks!

Answer 1

First, is it necessary to make inhold, timer and onLongTouch members of the stage ? or will closures make everything works well if they are local vars in registerStageGestures ?

As far as registerStageGestures() is concerned, var inhold, var timer and function onLongTouch(e) {...}. would suffice. The mechanism by which an inner function has automatic access to its outer function's members is known as "closure". You would only need to set stage.inhold, stage.timer and stage.onLongTouch if some other piece of code needs access to these settings as properties of stage.

Second, is it necessary to call the callbacks with '.call(receiver,' syntax ? I'm doing this to make sure the callback code will run in the context of the View but I'm not sure if it's needed ?

Possibly, depending on how those callbacks are written. .call() and .apply() are sometimes used when calling functions that use this internally. In both cases, the first parameter passed defines the object to be interpreted as this. Thus, javascript gives you the means of defining general purpose methods with no a priori assumption about the object to which those methods will apply when called. Similarly, you can call a method of an object in such a way that it acts on another object.

EDIT:

For completeness, please note that even in the absence of this in a function, .apply() can be very useful as it allows multiple parameters to be specified as elements of a single array, eg the ubiquitous jQuery.when.apply(null, arrayOfPromises)...

Answer 2

There are some simple answers, here.

First, closure:

Closure basically says that whatever is defined inside of a function, has access to the rest of that function's contents.
And all of those contents are guaranteed to stay alive (out of the trash), until there are no more objects left, which ere created inside.

A simple test:

var testClosure = function () {
    var name = "Bob",
        recallName = function () { return name; };

    return { getName : recallName };
};


var test = testClosure();
console.log(test.getName()); // Bob

So anything that was created inside can be accessed by any function which was also created inside (or created inside of a function created in a function[, ...], inside).

var closure_2x = function () {
    var name = "Bob",
        innerScope = function () {
            console.log(name);
            return function () {
                console.log("Still " + name);
            }
        };

    return innerScope;
};


var inner_func = closure_2x();

var even_deeper = inner_func(); // "Bob"
even_deeper(); // "Still Bob"

This applies not only to variables/objects/functions created inside, but also to function arguments passed inside.

The arguments have no access to the inner-workings(unless passed to methods/callbacks), but the inner-workings will remember the arguments.

So as long as your functions are being created in the same scope as your values (or a child-scope), there's access.

.call is trickier.

You know what it does (replaces this inside of the function with the object you pass it)...

...but why and when, in this case are harder.

var Person = function (name, age) {
    this.age = age;
    this.getAge = function () {
        return this.age;
    };
};

var bob = new Person("Bob", 32);

This looks pretty normal.
Honestly, this could look a lot like Java or C# with a couple of tweaks.

bob.getAge();  // 32

Works like Java or C#, too.

doSomething.then(bob.getAge);

? Buh ?

We've now passed Bob's method into a function, as a function, all by itself.

var doug = { age : 28 };
doug.getAge = bob.getAge;

Now we've given doug a reference to directly use bobs methid -- not a copy, but a pointer to the actual method.

doug.getAge(); // 28

Well, that's odd.

What about what came out of passing it in as a callback?

var test = bob.getAge;
test(); // undefined

The reason for this, is, as you said, about context...

But the specific reason is because this inside of a function in JS isn't pre-compiled, or stored...
this is worked out on the fly, every time the function is called.

If you call

obj.method();

this === obj;

If you call

a.b.c.d();

this === a.b.c;

If you call

var test = bob.getAge;
test();

...?

this is equal to window.
In "strict mode" this doesn't happen (you get errors really quickly).

test.call(bob); //32

Balance restored!

Mostly...

There are still a few catches.

var outerScope = function () {
    console.log(this.age);
    var inner = function () {
        console.log("Still " + this.age);
    };

    inner();
};

outerScope.call(bob);

// "32"
// "Still undefined"

This makes sense, when you think about it... We know that if a function figures out this at the moment it's called -- scope has nothing to do with it...

...and we didn't add inner to an object...

this.inner = inner;
this.inner();

would have worked just fine (but now you just messed with an external object)...

So inner saw this as window.

The solution would either be to use .call, or .apply, or to use function-scoping and/or closure

var person = this,
    inner = function () { console.log(person.age); };

The rabbit hole goes deeper, but my phone is dying...