The window Object & Global Variables

I think another good way how to hide private functions would be using "Revealing Module Pattern". You don't need to create any Helper object and as a bonus you get rid of binding "this" to the context. Using this approach you just return from within self-executing function only the methods you want to be public. Another advantage is you don't need to bind anything to window object. Instead you assign self-executing function to a variable.

'use strict';

//note: we are not binding to window object

var RepLogApp = (function($) {
    var $wrapper = null;

    function initialize($wrapp) {
        $wrapper = $wrapp;

        $wrapper.find('.js-delete-rep-log').on(
            'click',
            handleRepLogDelete // note: no binding necessary
        );
        $wrapper.find('tbody tr').on(
            'click',
            handleRowClick
        );
    }

    function updateTotalWeightLifted() {
        $wrapper.find('.js-total-weight').html(
            // we are calling method without "this" keyword
            calculateTotalWeight()
        );
    }

    // some other methods go here ....

    function calculateTotalWeight() {
        var totalWeight = 0;
        $wrapper.find('tbody tr').each(function () {
            totalWeight += $(this).data('weight');
        });

        return totalWeight;
    }

    return {
        // methods what you return will be public
        // note: there is no "calculateTotalWeight" method listed - so it's private
        initialize: initialize,
        updateTotalWeightLifted: updateTotalWeightLifted,
        handleRepLogDelete: handleRepLogDelete,
        handleRowClick: handleRowClick
    }

})(jQuery);

// usage is the same

//index.html.twig
$(document).ready(function() {
    var $table = $('.js-rep-log-table');
    RepLogApp.initialize($table);
});

Hey Lukáš Pápay!

This is great! I've seen this pattern... but I don't know why I didn't show it! Honestly, while it has the same effect, I like returning a var from the self-executing function better than modifying window inside, actually :).

Anyways, thanks for sharing! Very good example!

Adding 'use strict' should be done only inside the IIFE. The strict mode directive applies to the current scope and all child scopes. By putting it outside the IIFE, it puts the global context in strict mode and so all contexts as well, which is likely to break third-party libraries not written as strict.
By putting it inside the IIFE, only your own code (which lives inside the IIFE) will be turned into strict mode

Yo Stof!

Actually, we should definitely add a note about the scope of "use strict" - you're absolutely right. But, I don't believe that adding it at the top of the file affects other files (e.g. http://stackoverflow.com/qu... - each file is considered its own "program" and acts independently. I just verified this by keeping the "use strict" at the top of RepLogApp.js, and then setting a variable without "var" inside of index.html.twig. But, as the StackOverflow mentions, if you perform a simple concatenation of your JS files, then you can still have a problem. So I'm going to add a note about this!

Thanks!

Ah, I was not aware that it was limited per file. But I concatenate my JS files all the time anyway, which may be why I missed this distinction.

I wasn't exactly sure myself - you made me do further research ;). We'll have a note added to text & then video in the coming days.

Thanks for the tip!

Now I know why we use window and $ in self executing function as argument, excellent explanation. As a PHP dev, it always makes my head spin when I working with js. My headache is getting better.

Hey Yan,

Haha, we're glad you like it! Yea, JS become really fun and easy if you start understanding it better. ;)

Cheers!

Only one thing I didn't understand. You said that passing jQuery as an argument eliminates the possibility of it be set to null. But when we add the 'window' argument, we could modify it (adding the RepLogApp). Maybe because 'window' argument has the same name as global 'window', the code inside the function actually used the global variable?

Hey boykodev!

Great question - good attention to detail :). When the code inside the function references window, it's referencing the window argument that's passed into the function (at the very top). This, by chance, has the same name as the global variable, but that's not important. Let me give you an example. This code would also work:

(function(fooBarNotWindow, $) {
    fooBarNotWindow.RepLogApp = {
        // ...
    }
})(window, jQuery);

In this case, we are still ultimately modifying the global, window object - but we just gave it a different name. So.... I guess my point is this: in the original code, by passing window as an argument, it means that when we reference window in the function, it refers to the argument, not the global variable. Of course, the variable is a reference to the global object. But, there is one subtle difference: you can modify window, but you could not accidentally replace it:

// inside the self-executing function

// yep, you can modify the window object, it references the global object
window.foo = 'bar';

// but if you do this, it will NOT actually set the *global* window object to null
// this will *only* set the *local* variable to null.
window = null;

I hope that explanation wasn't too confusing :). The self-executing function gives you some isolation, and it's important to understand why they're used. But it's still a bit imperfect. The module system (as you'll see in our Webpack tutorial) is a more perfect system.

Cheers!

Wasn't confusing at all, thanks! What about if you still want to access a global 'window', inside the function with 'window' argument. Is there a way to do this?

Awesome :). Well, you still are referencing the global window argument. In some ways, it's no different than this in PHP:

$foo = new Foo();
$bar = $foo;

// we're referencing $bar, but obviously, we're also referencing $foo, they're the same
$bar->getName();
// but doing this does not *also* unset $foo
$bar = null;

The only thing that you absolutely will not be able to do if you have the window argument is set the global window variable to a completely different value (e.g. window = 'foo'), because this will only change the local variable. And there's no way around this (if you have the window argument), which is really the point of the self-executing function :).

Cheers!

Oh, I see...you can modify the object, you just can't set it to something else. It's some sort of a foolproof system :)

Exactly right :). It's similar to the const keyword you'll learn about in our ES6 tutorial: a constant can still be modified, just not re-assigned.