Understanding Immediately-Invoked Function Expressions - Part 2

In the first part of this series we covered the basics of what an immediately-invoked function expression (IIFE) is and how it works using some simple examples. In this part we will look at some common ways IIFEs are used in applications.

The Module pattern

A common use for IIFEs is to create private members that can only be accessed using public methods. For example, consider the following object literal:

The Revealing Pattern

A variation of the standard Module pattern is called the "Revealing" Module pattern. The difference between the two is that all of the methods are defined in the local IIFE scope, and the returned object contains pointers to the methods to be exposed ('revealed') to the public interface:

Whether you use the standard Module pattern or the Revealing pattern is mostly a matter of style than functionality. YMMV, or course, so where performance is tantamount, always test, test, test.

IIFEs as namespaces

IIFEs can also be used as a namespace strategy. A standard best practice is to avoid cluttering up the global scope with your objects. You can limit what you want exposed in the global scope (or even not have anything in the global scope at all, but I find it useful to at least have one name used, commonly my application singleton) by placing all your private data and functions inside the IIFE, while exposing just the public members you need:

In this example we create an IIFE and pass in our global App object explicitly instead of relying on the scope chain. This helps keep our namespace module stay loosely coupled from any external code. The way we pass the global object into the IIFE may look odd if you're not familiar with the syntax:

The other part of the statement is using an 'or' to either use the current App object if it exists (and is not falsy) or an empty object. This is particularly useful if you've broken your code up into several files to make the design more modular. The first namespace module loaded will initialize App as an empty object, while subsequent modules simply extend the existing App.

A good example of this modular namespacing pattern is in developing jQuery plugins. jQuery best practices dictate that a plugin should only use a single name in the jQuery object. Therefore an IIFE is used to privatize the plugin data and methods, with a single public method added to the jQuery object:

ABOUT TRAINING CONNECTION

Founded in 2006, Training Connection is a traditional computer and business skills training company. We believe that learning from a live trainer is the most effective way to learn! Our training centers are located in Chicago and Los Angeles and we deliver all our courses onsite countrywide.
All rights reserved. Copyright 2006-2015.