Init + Module Pattern JS

module_pattern_init.js

// JS Module Pattern:
// http://j.mp/module-pattern

// Redefine: $, window, document, undefined.
var APP = (function($, window, document, undefined) {
  // Automatically calls all functions in APP.init
  $(document).ready(function() {
    APP.go();
  });

  // For use only inside APP.
  var PRIVATE_CONSTANT_1 = 'foo';
  var PRIVATE_CONSTANT_2 = 'bar';

  // Expose contents of APP.
  return {
    // APP.go
    go: function() {
      var i, j = this.init;

      for (i in j) {
        // Run everything in APP.init
        j.hasOwnProperty(i) && j[i]();
      }
    },
    // APP.init
    init: {
      call_automatically_one: function() {
        // Called on page-load.
        // Can still be called individually, via:
        // APP.init.call_automatically_one();
      },
      call_automatically_two: function() {
        // Called on page-load.
        // Can still be called individually, via:
        // APP.init.call_automatically_two();
      }
    },
    util: {
      call_specifically_one: function() {
        // Must be called individually, via:
        // APP.util.call_specifically_one();
      },
      call_specifically_two: function() {
        // Must be called individually, via:
        // APP.util.call_specifically_two();
      }
    }
  };
// Parameters: Zepto/jQuery, window, document.
})(typeof Zepto === 'function' ? Zepto : jQuery, this, this.document);

@h3h - I just realized (coming back to this to show a coworker), that I never answered your question about why making methods public. I do that so that they can be run on page load automatically, but then can be run selectively if need be. Let's say you want to bind something to an element on page load, but then via Ajax insert another set of similar elements. You could be just jQuery's .live(), but maybe there's some other logic that needs to run.

In that case, the functions inside the init could do something along the lines of...

$(/* selector */).unbind('click.namespace').bind('click.namespace', function() {...});

But, it's really a "6-of-one, half-dozen of another" type situation, I agree. :)

Thank You for very important pattern.

alias them for easy munging, and more clear use of globals

I honestly don't know what that sentence means. I get the words but I am not seeing the meaning. What is more clear use of globals trying to say? Is not window already a global?

Protects you from: undefined = true

In all my years this has never happened to me. Why do we need to protect against it? I can think of hypothetical cases where it could be exploited but to be honest in the grand scheme of things does this actually happen enough that coders have to activly work around it?

(Keep in mind I'm not advocating disusing it. It is still a good pattern. I'm simply asking for more facts checks on the exploit ability and frequency of such use cases in the wild.)

window, document, jQuery, and undefined get shrunk to one-letter variables with it's minified

Ahh, that makes really cleaver sense. In fact I'd argue that a good minifier worth its salt would wrap the code in this module pattern for you.