Namespaces and conflict-free handling

In JS programming we may encounter a problem with naming conflicts. Naming conflicts are handled in two cases, and we usually create namespaces for internal modules, and for different framework class libraries, we use conflict-free processing (docu coexistence) to resolve them.

1. Inside the module, register a namespace

A large module can be subdivided into small modules, the namespace is actually in the scope of large modules to declare a small scope, so that the different scopes between the same name identifier does not affect each other.

1) Use the immediate execution function expression (iife) as the scope.

var a = 1;(function() {    var a = 2;    Console.log (a); // 2 }); Console.log (a) ; // 1

Iife internal want to call the external variable with the same name, the external name of the variable can be passed into the argument, but the outside to call the Iife scope of the variable is inconvenient.

2) object literal to create a namespace.

　　The object literal {} is a scope, and we usually declare an object literal and then use "." The way to create several properties for it is this principle.

var Lxt = {    A: {},    = 1= 2; console.log (LXT.A.A); // 1console.log (LXT.B.A); // 2

A in scope A and B in the scope of a do not interfere with each other, this is the object literal way to create a namespace.

3) Create a namespace using the registration function.

The registration function is the enhanced version of the above, if the above example does not define A and B beforehand, then the following LXT.A.A will error, the registration function is actually the process of defining the space encapsulated together.

 var  Lxt = {};  var  namespace =  var  spaces = Space.split ("."    );     var  currentscope = scope;  for  (var  i = 0, len = spaces.length; i < Len; I++ currentscope[spaces[i]] {currentscope[spaces[i]]  = {};    } currentscope  = Currentscope[spaces[i]]; }}; Namespace (Lxt,  "A" ); Namespace (Lxt,  "B"); 

The result is the same as the LXT declared in 2).

2. Conflict-free handling of different class libraries

The principle of conflict-free processing is simple, the class library is loaded before the save conflict is named, the class library loads and then assigns the conflicting name back to the value.

Take "$" for example, I declare a global variable "$" in $1.js, also declare a global variable "$" in $2.js, load $ First, then load the $ $ immediately after the call, "$" will not point to the $ content.

// $1.js: var $ = J = {    function() {        return "from $1.js ...";    }};

// $2.js: var $ = K = {    function() {        return "from $2.js ...";    }};

Page has introduced $1.js and $2.js after testing found that access to the test function is not.

Console.log ($.test ()); // From $2.js ...

So how do we deal with conflict-free? For example, to save "$" at the top of the code, the variable holds the contents of "$", mimicking the noconflict function of jquery, and assigning the saved variable to "$" when the function is called. The final effect is "$" pointing to "$" content.

// $2.js var _$ = window.$; var $ = K = {    function() {        return "from $2.js ...";    },     function () {        = _$;         return K;    }};

The test results are as follows:

$.noconflict (); Console.log ($.test ()); // From $1.js ...

　　

Namespaces and conflict-free handling