Making Wheels and Wheels: QuickStart JavaScript modularity

Making Wheels and Wheels: QuickStart JavaScript modularitytime 2016-03-16 21:59:39 segmentfault Original 1190000004619857 ThemesJavaScriptObjective

They say, "Don't reinvent the wheel," like iphone--. It can play music in addition to making calls-but engineers don't have to do a music playback from scratch, perhaps by integrating an ipod into the iphone's system.

This is also true for front-end development, where engineers write only core business code, and other common functions and components can seamlessly load code that someone else has written, like many.

But the reality is that there is a bad iphone engineer who has mixed up the iphone and ipod system, and even soldered the Home button of the iphone to the same volume key as the ipod.

There are some bad JavaScript developers who accidentally declare global variables, confuse "namespaces", make collaborative development less friendly, or he develops a generic module, and users find that the user's own code is messed up after he loads his code.

Primitive People's wording

For example, the following code:

var mylove = "coding";function getLove() { return mylove;}function sayLove(thing) { console.log(thing);}console.log(getLove());//>>> codingsayLove(‘girl‘);//>>> girl

A variable is declared under the Window object mylove , and then the function is used getLove() to get the variable, using setLove() the variable to modify it.

Well, the function is realized. Just after that, maybe when you've declared it somewhere because mylove of carelessness, and your careless colleague doesn't know where to write a function with the same name--maybe a function with 3 parameters setLove() .

Object Encapsulation notation

What do we do? You get the idea that these variables and functions are written in an object:

var loveThing = {  mylove : "coding",  getLove :function() {    return this.mylove; }, sayLove : function(thing) { console.log(thing); }}console.log(loveThing.getLove());//>>> codingloveThing.sayLove(‘girl‘);//>>> girl

This kind of writing has a bit of a modular look, you can see the relationship between these functions and variables. The disadvantage is that all variables must be declared public, so add this to indicate scope to reference these variables. Even more dangerous is the ability to easily change the parameters inside the object:

"sleeping";console.log(loveThing.getLove());//>>> sleeping

Execute function immediately

I always not afraid with the worst malicious speculation programmer, you never think your partner will really change your parameters in other places, do not know whether you will inadvertently modify his. We have to do it before he does-let his module execute first, not to the other side of the machine. At this point, you can avoid exposing private members by using a method called immediate execution functions .

var loveThing = (function(){  var my = {};  var love = "coding"; my.getLove = function() { return love; } my.sayLove = function(thing) { console.log(thing); } return my;})();console.log(loveThing.getLove());//>>> codingloveThing.sayLove(‘reading‘);//>>> reading

We try to get the variables inside:

console.log(loveThing.love);//>>> undefined

Sure enough, the outside simply can't see the parts inside, only the interface provided is used. This will ensure the security of the private variables.

Magnification mode

Of course, when a project needs to be modular, it means that the project is sufficiently large enough to be complex, that a module may need to inherit from another module, or an expansion module, which requires the use of magnification mode :

var loveThing = (function (o){  o.sayOK = function () { console.log(‘OK‘); }; return o;})(loveThing);loveThing.sayOK();//>>> OK!

Wide magnification mode

However, the browser is a non-logical licensing environment, you never know whether the module you refer to has been loaded. loveThingIf I hadn't been loaded before, the above code would have been an error (object not found). The solution is the so-called wide magnification mode :

var loveThing = (function (o){  o.sayOK = function () {}; return o;})(loveThing || {});

The only difference from the previous one is that the argument can be an empty object.

At this point, the most basic JavaScript modular writing you have learned, I believe you also appreciate the original wording of what is not enough.

Subject to space limitations, this concludes this article, and I'll discuss the popular modular specification in the next article.

Making Wheels and Wheels: QuickStart JavaScript modularity