Imagine that we have a module called ModuleA and, as a developer, you want
to add more functionality to this module. However, for some reason, you decide to implement this new functionality in a completely separate module and then dynamically augment the original module with all the data and capabilities of this new module. You can achieve this as shown here:
var ModuleA = (function(coreModule){
var someData = "this is some data to be used later"; coreModule.someMethod = function(){
};
return coreModule; })(ModuleA);
As you can see, we are again using the module pattern here, as the intent is to add the new functionality in a modular fashion.
In this IIFE, a reference to coreModule object is returned.. There is, however, one
important thing to keep in mind here. We are passing ModuleA as a parameter to our
anonymous container function. Also, the property someMethod is being added to the
passed-in coreModule, which is in fact a reference to ModuleA.
Therefore, at the end of this function execution, ModuleA has a new property method
called someMethod, which has access to the value of someData variable.
There is one assumption that we are making here. We are assuming that ModuleA
does exist as an object, and if not, we will get an execution error when we run the preceding code. You will see shortly how we can fix this issue, but for now, let's take this augmentation concept and use it to extend ImagesInc_GlobalData module
in our application.
Module naming conventions
As we are getting more involved with module implementation in our application, it is best to use more specific naming for our modules. Generally speaking, it is a good idea to use names that are as specific as possible for our modules. This minimizes the chance of naming conflicts between our application modules and third-party modules that we might be loading in our application. For this reason, as we move forward, we will be adding ImagesInc_ prefix to all of our module names, to make the names more specific to our application. It is also worth mentioning that some developers choose to use all capital lettering for the name of their modules in the code, as a convention. We will not be using this convention in our application. In your own coding practices, whether to use all capital lettering for your module names or not is something that you should decide on with your team. This is so you can establish a set of standards which all the members of the team would be required to follow.
Simple augmentation of ImagesInc_
GlobalData
As you may recall, we used our ImagesInc_GlobalData module (previously named GlobalData) to store application-level data for us. This module also provided a
couple of interfaces, so other pieces of the application could have access to the private data that we had stored in this module.
Let's create another JavaScript file, which adds more data and a new interface to this module. We can call this file Modules_2.js and add it to the list of JavaScript files
that our main page loads at runtime, as follows:
<script type="text/javascript" src="js/Modules.js" ></script> <script type="text/javascript" src="js/Modules_2.js" ></script> As you can see, this file is added as any other JavaScript file would be in our index. html. However, one thing to notice in the preceding code is the order that the two
module files have been added. This order is important and we will talk more about it shortly, but for now, keep in mind that our ImageInc_GlobalData module is loaded
first in our application (as it resides in Modules.js). Then, the code residing in Modules_2.js will add more functionality to this module, as it is loaded afterwards.
We need to add the following lines of code to Modules_2.js:
(function(coreModule){
coreModule.someText = "this is a test for module augmentation";
coreModule.getExtendedModuleMsg = function(){
ImagesInc_LoggingHandler.logInfo(coreModule.someText); };
})(ImagesInc_GlobalData);
Here, we have used an anonymous function to create a namespace, using an IIFE. We have also passed in a reference to the ImagesInc_GlobalData object (module)
in the form of a parameter to this function.
Inside this anonymous function, we have added two properties to the passed-in object reference, coreModule. This means that our ImagesInc_GlobalData now has
two new properties added to it. Let's verify this by running a test, as follows: // displays "this is a test for module augmentation"
When we call getExtendedModuleMsg method on ImagesInc_GlobalData object,
we see that the code runs properly and the expected message is shown in the console.
As the ImagesInc_GlobalData module did not originally have the method getExtendedModuleMsg, it now appears that it has been augmented with these
new properties.
This simple example demonstrates how we can augment our original module without directly modifying the code in that module. We also saw that the