Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I can't find any accessible examples showing how two (or more) different modules are connected to work together.
So, I'd like to ask whether anyone has time to write an example explaining how modules work together.
In order to approach to Modular design pattern, you need to understand these concept first:
Immediately-Invoked Function Expression (IIFE):
(function() {
// Your code goes here
}());
There are two ways you can use the functions. 1. Function declaration 2. Function expression.
Here are using function expression.
What is namespace?
Now if we add the namespace to the above piece of code then
var anoyn = (function() {
}());
What is closure in JS?
It means if we declare any function with any variable scope/inside another function (in JS we can declare a function inside another function!) then it will count that function scope always. This means that any variable in outer function will be read always. It will not read the global variable (if any) with the same name. This is also one of the objective of using modular design pattern avoiding naming conflict.
var scope = "I am global";
function whatismyscope() {
var scope = "I am just a local";
function func() {return scope;}
return func;
}
whatismyscope()()
Now we will apply these three concepts I mentioned above to define our first modular design pattern:
var modularpattern = (function() {
// your module code goes here
var sum = 0 ;
return {
add:function() {
sum = sum + 1;
return sum;
},
reset:function() {
return sum = 0;
}
}
}());
alert(modularpattern.add()); // alerts: 1
alert(modularpattern.add()); // alerts: 2
alert(modularpattern.reset()); // alerts: 0
jsfiddle for the code above.
The objective is to hide the variable accessibility from the outside world.
I would really recommend anyone entering this subject to read Addy Osmani's free book:
"Learning JavaScript Design Patterns".
http://addyosmani.com/resources/essentialjsdesignpatterns/book/
This book helped me out immensely when I was starting into writing more maintainable JavaScript and I still use it as a reference. Have a look at his different module pattern implementations, he explains them really well.
I thought i'd expand on the above answer by talking about how you'd fit modules together into an application. I'd read about this in the doug crockford book but being new to javascript it was all still a bit mysterious.
I come from a c# background so have added some terminology I find useful from there.
Html
You'll have some kindof top level html file. It helps to think of this as your project file. Every javascript file you add to the project wants to go into this, unfortunately you dont get tool support for this (I'm using IDEA).
You need add files to the project with script tags like this:
<script type="text/javascript" src="app/native/MasterFile.js" /></script>
<script type="text/javascript" src="app/native/SomeComponent.js" /></script>
It appears collapsing the tags causes things to fail - whilst it looks like xml it's really something with crazier rules!
Namespace file
MasterFile.js
myAppNamespace = {};
that's it. This is just for adding a single global variable for the rest of our code to live in. You could also declare nested namespaces here (or in their own files).
Module(s)
SomeComponent.js
myAppNamespace.messageCounter= (function(){
var privateState = 0;
var incrementCount = function () {
privateState += 1;
};
return function (message) {
incrementCount();
//TODO something with the message!
}
})();
What we're doing here is assigning a message counter function to a variable in our application. It's a function which returns a function which we immediately execute.
Concepts
I think it helps to think of the top line in SomeComponent as being the namespace where you are declaring something. The only caveat to this is all your namespaces need to appear in some other file first - they are just objects rooted by our application variable.
I've only taken minor steps with this at the moment (i'm refactoring some normal javascript out of an extjs app so I can test it) but it seems quite nice as you can define little functional units whilst avoiding the quagmire of 'this'.
You can also use this style to define constructors by returning a function which returns an object with a collection of functions and not calling it immediately.
Here https://toddmotto.com/mastering-the-module-pattern you can find the pattern thoroughly explained. I would add that the second thing about modular JavaScript is how to structure your code in multiple files. Many folks may advice you here to go with AMD, yet I can say from experience that you will end up on some point with slow page response because of numerous HTTP requests. The way out is pre-compilation of your JavaScript modules (one per file) into a single file following CommonJS standard. Take a look at samples here http://dsheiko.github.io/cjsc/
You can find Module Pattern JavaScript here http://www.sga.su/module-pattern-javascript/
Related
This question already has answers here:
Use of 'prototype' vs. 'this' in JavaScript?
(15 answers)
Closed 5 years ago.
I have been doing some exercises on the interesting "level up your coding" site, Exercism.io and they use the CommonJS style modules for their code samples and testing with Jasmine. I've always thought modules were a hassle I didn't want to deal with, but in these bite size chunks, they look like they could be very useful to begin using in my Single Page Applications. So I've been Googling around and searching Github for some good samples for using CommonJS Modules - and still haven't found one that explains in detail what the main patterns are, and how they differ. For example, one answer I submitted looked like this:
var HelloWorld = function () {};
HelloWorld.prototype.hello = function () {
return 'Hello, World!'
};
module.exports = HelloWorld;
But another one looked like this
var Bob = function () {
this.hey = function (input) {
input = input.split('');
if (input.indexOf('!') >= 0) {return 'Whoa, chill out!'}
if (input.indexOf('?') >= 0) {return 'Sure.'}
return 'Whatever.'
};
}
module.exports = Bob;
Specifically I'm wondering what the difference is between nesting a function inside the parent definition, as done with the Bob hey() function, as opposed to the way the HelloWorld hello() uses the prototype instead.
To start with the two functions you gave as examples are completely different from each other and have different purposes.
Based off of the code you have as an example, the way you are calling them is also incorrect.
For your Bob example, all you are doing is assigning a function to a variable. In order to call it, you simply have to do Bob(). If you do a Bob.hello() you are going to get an error.
The HelloWorld on the other is not just a function, well.. It is, since you declared it as an empty function that is what it will call if you do HelloWorld(). However you defined hello as it's prototype function, for you to invoke that directly you would have to do HelloWorld.prototype.hello(). I reckon that these are used mainly to alter behaviours of existing objects or functions.
You are asking what are the most efficient ways of writing modules, but in reality there is not right answer for that. All a module is is a piece of code that can be exported and reused by other files. They can be functions, objects, simple variables whatever you'd like!
So basically you can do all these:
// moduleThatExportsANumber.js
module.exports = 1
// moduleThatExportsAnObject.js
module.exports = {}
// moduleThatExportsAFunction.js
module.exports = function () { return 'say somethign!'}
// main.js Lets call all the modules!
const number = require('./moduleThatExportsANumber)
const object = require('./moduleThatExportsAnObject)
const function = require('./moduleThatExportsAFunction)
console.log(number) // 1
console.log(object) // {}
console.log(function) // function () { return 'say somethign!'}
console.log(function()) //say somethign!
The whole thing about modules is simply writing stuff in a file, exporting that stuff, which in the case of CommonJS is done through module.exports = [whatever you are exporting], and later importing, which for CommonJS is require('./filename')
Now... Going back to the original thing that was asked, your cheatsheet. I don't know any CommonJS ones unfortunately, however here is a decent blog post about the CommonJS module system and here is a JavaScript one that you may like as well.
I'm looking for something that will import the contents of an object to the global scope:
var y = {}
y.x = 5
//do some magic here
console.log(x); //5
I want to do this is so I can make an easy to use module with memorable function names without having to worry about things accidentally getting overridden by other modules.
Consider this example:
funModule = {};
funModule.washClothes = function(clothes){...}
funModule.walkDog = function(dogName){...}
//etc
funModule.UNITED_STATES_DEFICIT = ...;
Here I've created a module that has some useful functions and constants (implementations and values were replaced with "...").
I don't want my users to have to type out the module name every time they call function or use a constant. That would result with really messy code:
funModule.walkDog(funModule.UNITED_STATES_DEFICIT);
I could try it again by defining everything globally:
washClothes = function(clothes){...}
walkDog = function(dogName){...}
//etc
UNITED_STATES_DEFICIT = ...;
but if a different module has also defined the commonly named function washClothes we've got trouble. (in my actual case the commonly named function is run)
Removed from technical context, here is the problem I'm faced with:
Firstly I want to use simple and memorable names to make the module easy to learn and fun to use.
Secondly I don't want the easy names to make the module impossible to use with others. Especially as it grows, a lot of common names will be used. It would be great if the users could decide whether or not import the names directly.
Thirdly I realized as I'm typing this that what I'm describing is something that definitely already exists, in python. See http://effbot.org/zone/import-confusion.htm for more detail.
tl;dr How can python-like imports be done with javascript?
EDIT:
It seems there is not a universal way to do this.
Using Window won't work in all environments (but will work in any common browser).
Apparently ES6 Modules are not available to web browsers directly.
This question is different from this one because its not about Node.js. I was looking for a universal way to do it, but that doesn't seem possible, so I'll limit it to web browsers, (namely chrome, firefox, safari, opera, and maybe ie)
EDIT:
This general article about Scope could be useful for anyone with a similar question as mine: https://toddmotto.com/everything-you-wanted-to-know-about-javascript-scope/
Object.prototype.makeglobal=function(){
for(key in this){
if(window[key]){//replace window if youre not in a browser
//already exist, error handling
console.error(key+' already exist in window');
}else{
window[key]=this[key];
}}};
Use like this:
funModule.makeglobal();
//now you can
washClothes();
But this is bad as it pollutes the global object.
2.Your user should create his own namespace:
function(){
this.washClothes();
//more of his content
}.call(funModule);
3.You could also add a loader:
funModule.load=function(func){
console.log(func);
console.log(this);
func.call(this,this);
};
Now you can do:
funModule.load(function(fun){
this.washClothes();
fun.washClothes();
});
4.If youre concerned about readability you may use function chaining (?):
funModule.washClothes=function(){
//your code
return this;
}
now you can do:
funModule.washClothes("tshirts").washClothes("trousers").washClothes();
ES6 Modules are what you want.
If you will define your object as es6 module you could do this (using the names in your example):
import { washClothes } from "fun-module";
and then washClothes will be globally available on the file that imported it, just like you want.
Read about it here.
If you really want a magic solution like in the comment in your post and don't want to use ES6 and you run in the browser you can put it on the window object:
window.x = 5
In JavaScript, at least in a browser, global variables are properties of the window object: that is, window.x and x (where x is global) reference the same value. So, in theory, you could use Object.assign() to copy your object's properties to the window object making them global variables. This is roughly equivalent to globals().update(myobj.__dict__) in Python.
But just as import * is usually a bad idea in Python, so too this sounds like a bad idea, except even worse because window has a lot of other properties that you probably don't want to clobber.
After some additional research I found a way, without polluting the global namespace, to allow users to directly access module contents.
This solution allows the user to:
Write code that directly references the module's functions/properties
Define precedence if there are multiple modules written in this same style
Still access the module's functions/properties by module name*
*This feature comes with a catch
Here's the code
Module
funModule = {};
//This stuff is the arbitrary contents of the module:
funModule.washClothes = function(clothes){...}
funModule.walkDog = function(dogName){...}
//etc
funModule.UNITED_STATES_DEFICIT = ...;
//etc
//This part is necessary:
funModule.run(userApp)
{
for(key in this){
eval(key + " = " + this[key] + ";");
}
userApp();
}
The only way (that I could find) to dynamically define functions both in funModule.run's scope and in funModule is to use Eval. Using call, apply, or bind to manipulate scope would still require use of the this keyword and the whole point of this unusual style is to make client code as simple and non-repetitive as possible.
Client Code 1
function myApp()
{
washClothes(UNITED_STATES_DEFICIT);
}
funModule.run(myApp);
Here in the client code it is possible to directly access everything except for funModule.run. So the global namespace is kept clean but the user's code does not need unnecessary repetition.
Client Code 2
function myApp()
{
washClothes(UNITED_STATES_DEFICIT);
}
funModule.run( otherModule.run.bind({},myApp) ); //otherModule has precedence here
Assume otherModule is a different module that features the same run function. funModule will load its contents then call its first argument. The first argument will load otherModule's contents, overriding anything from funModule with the same name.
Client Code 3
function myApp()
{
//directly access stuff from funModule
walkDog()
var big = UNITED_STATES_DEFICIT * 3.14;
//explicitly access stuff from specific modules
clothes = new otherModule.Clothes();
funModule.washClothes(otherModule.washClothes(clothes));
}
funModule.run(myApp)
This is the feature that makes use of eval necessary. The user can opt out of ambiguity of direct access. They can still access properties/methods by naming the module they come from.
But Why?
Some StackOverflow users were understandably concerned about the unusual set of constraints in the question, so I figured I would answer the following question:
Why don't you use a short alias for your module.
I tried to answer that question in this article, which pulls from this question and answer.
This question already has answers here:
Location of parenthesis for auto-executing anonymous JavaScript functions?
(4 answers)
Closed 5 years ago.
What is the semantic difference between these two snippets of code?
Example 1
var x = (function () {} ());
Example 2
var x = (function () {} )();
The difference in writing is where we put our parenthesis pair () which tells the JavaScript interpreter to execute the code block at once. Technically, there is no difference. If I may rephrase the wording of my question and eliminate the word "semantic", then the new question has already been answered and elaborated upon here: https://stackoverflow.com/a/6645915/1268003
But, the semantic part is my dilemma and what I hope this thread could shine some light on. Due to it being "semantic", there can be no objective answer and my question is admittedly on the borderline of not being valid according to the FAQ of Stackoverflow. However, I can argue for the validity of this question which just might happen in the comments. For now, lets move on.
Defining the problem
The absolute vast majority of all JavaScripters out there seems to use example 2. Actually, I haven't yet found one exception to that rule (or where have I been lately?). jQuery plugin developers in particular, write code like so:
Example 3 (see example of an example)
(function ($) {} )(jQuery);
My bible, JavaScript: The Definitive Guide , doesn't use this practice at all - not once. Author David Flanagan sticks to example 1 (page 249 is the place where author comments this practice).
Never mind which construct, added parenthesis all have one and only one intention: To maximize readability. To clarify. Then, may I ask, clarify what?
My reasoning
When writing a closure in JavaScript, we're defining a local variable in a function that is not supposed to be accessible from code outside. For the most part and due to context, our function is an anonymous one that isn't bound to an identifier. Like so:
Example 4
function () { var local = "Local variable!"; }
Again due to context and what is usually the practice, we want to execute that snippet of code at once. So we throw in a couple of parenthesis. This will tell the JavaScript interpreter to run the function:
Example 5
function () {} ()
To clarify this in code, best practice is to add a couple of parenthesis, in a way this also clarifies the closure:
Example 6
(function () {} ())
This is an exact replica of example 1. My reasoning thus gives that example 1is the way we "should" write code. Whenever I choose to use example 2, I only clarify the use of a closure, not the fact that our anonymous function is executed at once. But by the smallest of efforts to place our clarification-parenthesis on the outside of the entire code snippet, we can catch both.
Yes I can critique my reasoning. In example 3, I find it appealing to think "hey, outside reference is copied to an alias on the inside". The alternative:
Example 7
(function ($) {} (jQuery))
..isn't as clear in this particular regard. However, example 2 doesn't use this pass-by-value technique. Personally, for the most part when I write closures, I don't have to pass anything in. And still, if we are allowed to be fundamentalist about it, the jQuery plugin practice never clarifies the immediate execution of our anonymous function.
Example 1 users
If my reasoning holds true, why is it then that the entire community out there use example 1? Is their sole intention to only cast one of two clarifications? Maybe just maybe, they don't even have a purpose but are following the lead of a mere tradition of which purpose we might not be able to explain? I haven't yet written a jQuery plugin, or used example 2 because I began my career reading the bible. But if you are among the many who use example 1 and have a reasoning for it, please share =)
Why? Readability
Many things are done in code because of the mantra of "Readability". It is invaluable in writing code. Your code should be easily inherited by another developer.
You forgot one
Or zero, as it were.
Example 0
var x = function(){ }();
And here is why people don't use that: it is hard to read. Usually these closures become very large, very quick. Someone shouldn't have to get to the very end of the closure to determine that it is just a variable named x with no self execution - such as var x = function(){}; To this end, developers wrapped their self executing closures with parenthesis: var selfExecuting = (function(){})();, or even plainly (function(){})(); so that from line 1 it was obvious that this was self executing. It also means that if you come across a function like this: var notExecuting = function(){}; you can generally assume at line 1 that it is not self executing.
Readability is very important when coding. It is important for maintenance. It is important for consistency. It is important for documentation.
Although, keep in mind, development code should not be production code.
I'm trying to get 2 scripts to run on the same page but they won't play nice with each other. One is called TabTop http://www.isdntek.com/tagbot/tabtop.htm and the other is Clic*Pic http://www.isdntek.com/tagbot/gallery.htm, both by isdntek. I can get either one of them to run fine all by themselves, but not both together. I looked around and tried to find the answer to this problem by myself, but to no avail.
I would greatly appreciate any help that can be provided.
Thanks!
You can wrap each script in a self calling function:
(function(){
//As long as you don't use global variables
//the content here is protected from any interaction with the outside
})();
Now, if both codes use global variables, the task will be unfortunately harder.
The RainbowCodeModule6.js file is used by both pages, it sets a very large number of global variables (quite a few because it doesn't declare local variables within functions), so it is quite possible that with two scripts trying to use the same set of globals, they are getting conflicts. e.g. (my wrapping for posting here)
function changeShades(color){ //--update the vertical column of light/dark shades
var ymax=paletteymax
if (!color){return}
for (i=0; i<ymax; i++){
document.getElementById('colorShades'+i).
style.backgroundColor=colorBrightness(color,(ymax-1-i)/(ymax-1))
}
}
The above doesn't keep it's counter i local and depends on the global paletteymax. I can't say if that's your problem, but it is indicative of poor programming and application architecture. Another example:
function dec2hex(R,G,B) { //--Converts three R-G-B components to
// a single internet hex color
var hexTest="0123456789ABCDEF";
Rd_hi=R/16; Rd_lo=R%16;
Rd=hexTest.substr(Rd_hi,1)+hexTest.substr(Rd_lo,1)
Gn_hi=G/16; Gn_lo=G%16;
Gn=hexTest.substr(Gn_hi,1)+hexTest.substr(Gn_lo,1)
Bu_hi=B/16; Bu_lo=B%16;
Bu=hexTest.substr(Bu_hi,1)+hexTest.substr(Bu_lo,1)
hexval='#'+Rd+Gn+Bu
return hexval;
}
Why they decided to keep hexTest local but let all the other variables go global is beyond me. Variables R, G and B are also global, but here they are kept local because they are formal parameters in the function declaration.
It also uses document.write to write a table in parts, which is never a good idea. I think it's just a poorly written script, find something else.
I am trying to clean up some older code, and it currently uses variables set with ScriptManager for use in the Javascript code to show/hide parts of the page.
The variables are currently just _showNameDiv, etc.
I'd like to put these all onto a common namespace, to make things a little bit cleaner, such as MyCompany.Toggles.ShowNameDiv.
I tried to create a namespace
var MyCompany = {
Toggles: {}
}
And within the code behind do this:
JavaScriptRegistrar javaScriptRegistrar = GetJavaScriptRegistrar();
javaScriptRegistrar.Register("MyCompany.Toggles.ShowNameDiv", true);
But I only get 'undefined' on that variable. (GetJavaScriptRegistrar is a wrapper for ScriptManager).
Is there a way to do what I am trying to do?
Am I going about this the wrong way?
Is there a better alternative that will get me the same benefit?
Keep in mind this is old code, and I cannot do a whole page rewrite. I am trying to make an incremental step that I might use to use as an example that I can show to my coworkers.
Well it's difficult to figure what could be the problem without knowing what those pieces of code exactly do (expecially JavascriptRegistrar).
One possible problem is maybe the scope of the javascript "namespace" you declare.
By using the "var" keyword, you're not making the namespace global, it's only defined in the closure it's defined into.
I suppose the javascript code that the JavascriptRegistrar class registers expects a global variable and does not find any so it returns undefined.
Here a piece of code to "expose" gloabally you're variable:
(function(window, undefined) {
var myCompany = {
Toggles: {}
};
window.MyCompany = myCompany;
})(window);