13

What do you call these patterns? What is the difference between them? When would you use each? Are there any other similar patterns?

(function() {
    console.log(this);  // window
})();

(function x() {
    console.log(this);  // window
})();

var y = (function() {
    console.log(this);  // window
})();

var z = function() {
    console.log(this);  // window
}();

EDIT: I just found two more seemingly redundant ways to do this by naming the functions in the last two cases...

var a = (function foo() {
    console.log(this);  // window
})();

var b = function bar() {
    console.log(this);
}();

EDIT2: Here is another pattern provided below by @GraceShao which makes the function accessible outside the function scope.

(x = function () {
    console.log(this);  // window
    console.log(x);     // function x() {}
})();
console.log(x);         // function x() {}

// I played with this as well 
// by naming the inside function 
// and got the following:

(foo = function bar() {
    console.log(this);  // window
    console.log(foo);   // function bar() {}
    console.log(bar);   // function bar() {}
})();
console.log(foo);       // function bar() {}
console.log(bar);       // undefined
alnafie
  • 10,558
  • 7
  • 28
  • 45
  • 1
    It "pattern" is called a "self invoking function" or "self evaluating function". They are all semantically identical in this case. However, there are slightly different rules for the their associated "names" and results, if any. Generally they are useful to create a new lexical scope. –  Jun 11 '12 at 17:20
  • 1
    In all cases, you're creating a function, and invoking it. In some cases you're assigning the return value to a variable, in other cases not. –  Jun 11 '12 at 17:22
  • 8
    I personally prefer Ben Alman's term: [Immediately-Invoked Function Expression (IIFE)](http://benalman.com/news/2010/11/immediately-invoked-function-expression/) – lbstr Jun 11 '12 at 17:29
  • 3
    The key thing to note here is that the functions do not self-execute. As Esailija stated, recursion is an example of a function that self-executes. In the examples, something IS invoking the function, but it is not the function itself. – lbstr Jun 11 '12 at 17:37

6 Answers6

38

Here are your functions again with some comments describing when/why they might be useful:

(function() {
    // Create a new scope to avoid exposing 
    // variables that don't need to be
    // This function is executed once immediately
})();

(function fact(i) {
    // This named immediately invoked function 
    // is a nice way to start off recursion
    return i <= 1 ? 1 : i*fact(i - 1);
})(10);

var y = (function() {
    // Same as the first one, but the return value 
    // of this function is assigned to y
    return "y's value";
})();

var z = function() {
    /* This is the exact same thing as above 
     (except it is assigned to z instead of y, of course).
     The parenthesis in the above example don't do anything
     since this is already an expression
    */
}();
jasonleonhard
  • 12,047
  • 89
  • 66
Paul
  • 139,544
  • 27
  • 275
  • 264
  • 2
    +1 It may be worth noting that you would usually store the result of a function such as the second as well. – pimvdb Jun 11 '12 at 17:29
  • Are there any other ways you can do this besides the ones I mentioned? – alnafie Jun 11 '12 at 17:31
  • You should also mention the scope issue with the third and fourth examples :) – Florian Margaine Jun 11 '12 at 17:33
  • 1
    @alnafie Anywhere a function is an expression, not a statement, it can be executed immediately with `()`. So `!function(){console.log('Hi');}()` and `+function(){console.log('Hi');}()` will both execute. – Paul Jun 11 '12 at 17:33
  • @FlorianMargaine can you elaborate on the scoping issue? :) – alnafie Jun 11 '12 at 17:41
  • @FlorianMargaine I'm not sure what issue you mean. It creates a new scope just like the first function. Is that what you mean? – Paul Jun 11 '12 at 17:45
  • @PaulP.R.O. no, y and z are not created in a new scope, hence it may be global. That's what I meant by "issue" :-) – Florian Margaine Jun 11 '12 at 18:03
  • @FlorianMargaine `y` and `z` are local to the scope they are declared in, because the `var` keyword was used. Anything declared inside the anonymous function is in a local scope to that function, just like the first function. – Paul Jun 11 '12 at 18:06
  • Yes, but I mean that they are not included in a new scope like in the other examples – Florian Margaine Jun 11 '12 at 18:07
6

In this case they are all semantically identical. The ECMAScript specification contains the full production rules, so this is a gross simplification.

Also note that I am ignoring the named function's name (x) as the name is not used; it could be referenced within the body but since it is a FunctionExpression (via the grammar production) it would never (in a correct JS implementation) contaminate the containing scope - see the comments.

(function() {
    console.log(this);  // window
})();

(function x() {
    console.log(this);  // window
})();

var y = (function() {
    console.log(this);  // window
})();

var z = function() {
    console.log(this);  // window
}();

Reduced (the bodies are inconsequential in this case, they all "return undefined"):

(function() {})();

(function x() {})();

var y = (function() {})();

var z = function() {}();

Reduced (in the ECMAScript grammar FunctionExpression is a production rule, but here I use it to mean "an expression that is a function"):

FunctionExpression()

FunctionExpression()

var y = FunctionExpression()

var z = FunctionExpression()

Ignoring the assignment of the result (which would always be undefined) it can be seen that all forms are the same.

Happy coding.

  • Interesting way to look at it! – alnafie Jun 11 '12 at 17:36
  • 3
    Note that IE (before 9) is an example of an incorrect JS implementation where a named function expression *does* contaminate the containing scope. – Matthew Crumley Jun 11 '12 at 17:44
  • @MatthewCrumley so if I am understanding you correctly, if you use the second version IE will create window.x ? – alnafie Jun 11 '12 at 17:54
  • 2
    @alnafie yes you can easily test it: `(function x() { console.log(this); // window })(); window.x; //Undefined in IE >8 or real browser` – Esailija Jun 11 '12 at 17:56
  • 1
    @alnafie In `IE < 8` you can wrap it in another closure (your first function in your question): `(function(){ (function x() { })(); })(); window.x // undefined in all browsers` – Paul Jun 11 '12 at 18:05
2

Self invoking anonymous function. The function body will be invoked immediately.

(function() {
    console.log(this);  // window
})();

Self invoking function. The function body will be invoked immediately. You can still refer to the function x inside the function body. So when you want to execute something immediately, and then you may want to iterate it, you can just reference to it directly.

(function x() {
    console.log(this);  // window
    console.log(x);     // function x() {}
})();

The self invoking anonymous function on the right side will be invoked immediately, and the returned value will be assigned to the y. Usually it has a return value when you use this pattern, otherwise, y will be undefined.

var y = (function() {
    console.log(this);  // window
})();

IMO, it is same as the third one. The parentheses of the 3rd enclosing the function are just for making the function look like one entire thing. But the functionalities of the both are the same.

var z = function() {
    console.log(this);  // window
}();

Similar to the 2nd one, but you can reference the x outside the function scope by using:

(x = function () {
    console.log(this);  // window
    console.log(x);     // function x() {}
})();
console.log(x);         // function x() {}
Grace Huang
  • 5,355
  • 5
  • 30
  • 52
0

(function() { 'use strict'; you can use this type

Why?: An IIFE-Immediately Invoked Function Expression removes variables from the global scope. This helps prevent variables and function declarations from living longer than expected in the global scope, which also helps avoid variable collisions.

Why?: When your code is minified and bundled into a single file for deployment to a production server, you could have collisions of variables and many global variables. An IIFE protects you against both of these by providing variable scope for each file.

Rakesh Ranjan
  • 1
0

It's time to use ES06, Here are your functions using arrow function from ES06.

 (() => {
    // Create a new scope to avoid exposing variables that don't need to be
    // This function is executed once immediately
})();

(fact = (i)=>(
  // This named immediately invoked function is a nice way to start off recursion
  i <= 1 ? 1 : i*fact(i - 1)
))(10)

const y = (() => (
    // Same as the first one, but the return value of this function is assigned to y
     "y's value"
))();

const z = (() => {
    // This is the exact same thing as above (except it's assigned to z instead of y, of course).
    // The parenthesis in the above example don't do anything since this is already an expression
})();
Ruhul Amin
  • 1,751
  • 15
  • 18
0

JavaScript in the browser is the lacks namespacing. Every piece of code runs in the global scope; therefore, internal application code or third-party dependencies can pollute the scope while exposing their own pieces of functionality. Polluting global namespace causes name collision. This name collision is very common in large projects and can be extremely harmful.

Imagine, for instance, that a third-party library instantiates a global variable called utils. If any other library, or the application code itself, accidentally overrides or alters utils, the code that relies on it will likely crash in some unpredictable way. Unpredictable side effects can also happen if other libraries or the application code accidentally invoke a function of another library meant for internal use only.

 (function () {
      // create state variables
      // make some operation
      // then return those
      const export = {
           export1: () => {},
           export2: () => {}
      }
      return exported
})()

it is used to create a private scope, exporting only the parts that are meant to be public.

Parentheses around function expressions

Why do we even need those? The reason is purely syntactical. The JavaScript parser has to be able to easily differentiate between function declarations and function expressions. If we leave out the parentheses around the function expression, and put our immediate call as a separate statement function(){}(3), the JavaScript parser will start processing it, and will conclude, because it’s a separate statement starting with the keyword function, that it’s dealing with a function declaration. Because every function declaration has to have a name (and here we didn’t specify one), an error will be thrown. To avoid this, we place the function expression within parentheses, signaling to the JavaScript parser that it’s dealing with an expression, and not a statement.

You might also see this in some projects:

+function(){}();
-function(){}();
!function(){}();
~function(){}();

This time, instead of using parentheses around the function expressions to differentiate them from function declarations, we can use unary operators: + , - , ! , and ~. We do this to signal to the JavaScript engine that it’s dealing with expressions and not statements.

Yilmaz
  • 35,338
  • 10
  • 157
  • 202