The window Object & Global Variables

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!

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!

Hey Yan,

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

Cheers!

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.