I just got into javascript and here is my understanding of module:
We have some “private data” that we do not want to share or corrupt so we stored them in the inner function. And we tell the enclosing function to return the value of the inner function. Thus we can use those value at our expense without worrying about data corruption. Because now the “value” we are using are references of the real value that is still being protected inside the inner function.
Is this correct?
An example of module:
function CoolModule(){
var something = "cool";
var another = [1,2,3];
function doSomething(){
console.log(something);
}
function doAnother(){
console.log(another.join("!"));
}
return{
doSomething:doSomething,
doAnother:doAnother
};
}
var foo=CoolModule();
foo.doSomething();
foo.doAnother();
Hi Zhou Xiang,
I’d say that is a pretty good understanding of a module. However, keep in mind the idea behind a module is to share while keeping the underlying logic of a function or the like untouchable. This is how Arrays in Javascript happen to have so many methods attached to them (forEach, Map, Sort, and the like). Modularity allows for people to share code with others without having to worry too much about other people manipulating the logic, and therefore render their code useless.
Thanks! I will take a look at that link and if I have any more question i will tag you!
Edit: I see… we do want to share those data, but we do not want others to touch our inner functions in case something got messed up and ruined our code.
Like a robot you can swapped out the arm to a sword, but dont touch our brain. is that correct?
they are just a way for the author to keep his program in small bite sized pieces as to not end up chocking later when the program swells. The machine could care less if the code is organized or not.
Anytime. Also notice that what you are returning in CoolModule() is an object that contains two functions within. Just thought I’d point out that var foo is now a pointer to that object that you’ve just created on the same line.
Hi,
If you have a function named calculatetInterest() and a library you include in your page also has a function named calculateInterest() then a name collision occurs and one of them becomes unusable.
In order to remedy this issue modern languages have built-in features, like package in Java, namespace in C# and C++, but Javascript does not have these (did not, until ES6), it has only global and function scope (block scope added in ES6).
What you’re doing in your code is simply exploiting the function scope as a module scope using closures.
So, your doSomething() function does not pollute the global scope, avoiding a probable name clash.
In your example, you’re using a closure to store state. It doesn’t really have anything to do with modules per se: you can use a module to hide data in the way you describe, but modules are more for hiding implementation details of a program and only exposing the parts an end user needs, they aren’t really for storing data.
Programs get complicated quickly, as @Dereje1 says it’s a way to keep things organised.
So here, only foo() is accessible outside the module:
function helperFunction() {
// do stuff
}
export function foo() {
helperFunction()
}
And modules let you easily use namespaces as @alper6 says:
// module1.js
function foo() {}
function bar() {}
export default { foo, bar };
// module2.js
import myFuncyNamespace from 'module1';
myFuncyNamespace.foo()
myFuncyNamespace.bar()
