Designing of Large Scale JavaScript Application Part 3

The basic definition of a Module is 

Modules are an integral piece of any robust application's architecture and are typically single-purpose parts of a larger system that are interchangeable.

The Importance

Consider a large application like FaceBook, that has different functionalities on the same page. Like landing page there are basic layout, feeds, friends available for chat, updates from friends, notifications, chat window, advertisement etc.

Now suppose if the complete page is designed with raw coding practice you can say that if every thing is working fine then whats' the issue in  that. but suddenly the landing page in the production environment gets crashed. And maintainance team starts looking into the code and sayes Oh My God.... 1000's line of code in a single file after lots of debugging and tesing they got the culprit, one of the adertiser put some JS code in the html content of their advertisment.

No one favours such case. Issue in a non relevant section craches the complete page is this is the way you want ot code, No obviously. Now Modlues comes to existance. Design your modules in such a way that they have very limited knowledge about whats going on the other section of the page and have simple single responsibility of their own functionality.

This makes the modules loosely coupled and makes the system to support adding, removing or replacing modules without the rest of the modules in the system falling over due to tight coupling.

Modules have a very limited knowledge of what's going on in the rest of the system. Instead, we delegate this responsibility to a mediator via a facade.

This also makes the system more stable and scalable as each module has its own dependencies, so  management , maintainance and error handling would be easier. Also if one module breaks the other modules will not be affected.

The other way around is we DIVIDE the application in Modules AND now we can RULEthem easily.

Here is a simple module in native JavaScript

var notificationsModule = (function() {

    var notifications = []; //private

    return { //exposed to public

        addItem: function(values) {

            notifications.push(values);

        },

        getItemCount: function() {

            return notifications.length;

        },

        getLatest: function(){

           return notifications.pop();

        }

    }

}());

Since there is no access modifiers in JavaScript so variables can't technically be declared as being public nor private and so we use function scope to simulate this concept and can be achieved very easily via a modular pattern. A module can encapsulates 'privacy', state and organization using closures. Module wraps a mix of public and private methods and variables, protecting pieces from leaking into the global scope and accidentally colliding with another developer's interface. With this pattern, only a public API is returned, keeping everything else within the closure private.

This provides a clean solution for shielding logic doing the heavy lifting whilst only exposing an interface you wish other parts of your application to use. The pattern is quite similar to an immediately-invoked functional expression (IIFE) except that an object is returned rather than a function.

The other thing that i like the most is asynchronous loading of the modules and their dependencies. Most of the time we prefer to have minimum number of JS files reffered on the pages just to reduce the number of http requests made to server for fetching these files so we generally merge all the js files in a single file. The drawback of this approach is the single JS file  gets larger and larger in size which decrease the performance as booting time of the application increases and we are actually loading unnecessary methods and events for a specific page. Other than that its become difficult to maintain the whole code in a single file. The only solution for this problem is to load only the required modules for the particular page along with their dependent module, Module loading should be On-demand and Asynchronous. Therefore I personally like "CommonJS"  its very simple to use and fulfil all such requirements efficiently. Other advantage is that you can segregate the modules in different JS files and commonJS will take care of loading the depndencies of the module (other JS files ) asynchronously when required.

Simple example of the commonJS module

define([

            "shared/base/logger"

            , "app/model/appManager"

], function(logger, appManager) {

    logger.logInfo("Application initialized");

    var app = new appManager();

    logger.logInfo("Application started");

    return app;

});