Tuesday, 30 May 2017

Revisiting concepts of JavaScript for SharePoint / Office 365 developer - Part 2 - JavaScript Namespaces

Hi All,

In this article I’ll explain the details of JavaScript namespaces, which should know for SharePoint / Office 365 developer who uses the JavaScript Object Model(JSOM) for SharePoint / Office 365 development.

Background: I have written one article regarding JavaScript variables (http://prashamsabadra.blogspot.in/2016/11/revisiting-concepts-of-javascript-for.htmlhttp://prashamsabadra.blogspot.in/2016/11/revisiting-concepts-of-javascript-for.html ). In this article we will discuss regarding JavaScript namespaces. I feel it’s really very important to understand the concept of namespaces while working on JSOM or SharePoint hosted apps.

Global Namespace:

1. By default JavaScript doesn’t provide namespace. 

2. Anything we write in JavaScript file and placed into global namespace by default including all variables and functions.

3. In browser, global namespace container is “Window” object. 

4. Issue with directly using global namespaces: Since whatever we write to JavaScript file goes to global namespaces, there might be chances that naming conflicts appear. For example, if on my site if we are loading couple of JavaScript files, there might be chances that same function name or same variable name there in different files. Which will cause the conflict and code will not behave correctly. Solution to this problem is using namespaces in our JavaScript code. 

Custom Namespace:

1. To address issue with global namespace as mentioned above in point 4 under Global Namespace section, we can create our own custom namespaces in JavaScript.

2. Custom namespace is nothing but the object defined within the global namespace.

3. Defining custom namespace:

//Custom NameSpace
             var Validations = window.Validations || {};

Here, we are creating custom namespace “Validations” under global namespace object  “window”.  It checks if global variable “Validations” is exist already then set the reference to it otherwise create new global variable.

4. We can add our methods/functions then under namespace “Validations” as 

Validations.validateEmpty = function (){
              // Method code goes here

Here, we have created a method called “validateEmpty()” under namespace “Validations”.  So now even though if same method is in another JS file on the same page then also conflict will not occur. Since here our method is isolated by our custom namespace. 

While calling “validateEmpty()” method we need to call it by using namespace like Validations.validateEmpty();

5. Similarly we can create our variables in our custom namespace like

               //Custom NameSpace
               var Constants = window.Constants || {};

              and then we can create variables under our custom Constants namespace like

              Constants.cssFileURL = “My CSS File URL”;

This is very common scenario where we can have all our validations methods in “Validations” namespace, all constants in “Constants” namespace and all SharePoint list CRUD operations in “SharePointCRUD” namespace. In this way our code will be isolated and there will be no chances of code conflicts. 

Advantages of using Namespaces:

1. Code Isolation: No code conflicts with other code on page in case multiple JavaScript files are loaded or any third part JavaScript files referred. In SharePoint online, SharePoint itself loads its JavaScript files so there are high chances of conflicts. To better solution is to use our custom namespaces.

2. Clean code, improves code readability. Code maintenance is easy. 


Enjoy Reading J

As usual any comment / suggestions / feedback / questions always welcome :)


Aakash Morya said...

Hi @PrashamSir, I just tried this example by creating two function with same name in same file with 2 different namespace. And when I used with the help of Namespace it worked like charm!!!!!.

Thanks for the share..

I am always crazy behind this small small things which make the code more reliable. So I think I am on the right place....

Prasham Sabadra said...

Hi Aakash,

Thanks for the comment. Yes, you are correct these small small things make code more reliable, less error prone and easy to maintain.