Been working on a js module pattern for a while to meet the escalating needs of "some website". Essentially, I just need a good way of grouping / encapsulating scripts, along with the sometime need for OO patterns.
I've got a structure that works ok, but I'm not happy with certain parts of it... so I'm in the process of refactoring it. Here is the updated pattern:
(function (global) {
var M = {
VERSION : 1.0
};
global.M = M;
//jQ document.ready()
global.onload = function(){
console.log('M VERSION: %s', M.VERSION);
var main = new M.Main();
};
M.Main = function(){
var _class1;
var _class2;
var _class3;
function _init(){
_class1 = new M.Class('foo','baz');
console.log('_class1.param2 : %s', _class1.getParam() ); //works
_class2 = new M.OtherClass('faz','boo');
_class2.setParam('Boozaz');
console.log('_class2.param2 : %s', _class2.getParam() ); //works
_class3 = new M.Class('fuz','boz')
console.log('_class3.param2 : %s', _class3.getParam() ); //works
_class3.prototype = new M.Super();
console.log('_class3.__param : %s', _class3.prototype.getProtected() ) //works
}
_init();
return true;
};
M.Super = function(){
var __param = 'jQ';
M.Super.API = {
getProtected : function(){ return __param }
}
return M.Super.API;
}
M.Class = function( p1, p2){
var _param1;
var _param2;
function _init(){
_param1 = p1;
_param2 = p2;
}
function _getParam(){
return _param2;
}
function _setParam(e){
_param2 = e;
}
M.Class.API = {
getParam : function(){ return _getParam(); },
setParam : function(e){ _setParam(e) },
publicMethod : function(){ ... }
}
publicMethod() //fails
this.publicMethod() //fails, this scopes to DOM window
M.Class.API.publicMethod() // works, but is kludgy
_init();
return M.Class.API;
};
})(typeof window === 'undefined' ? this : window);
This produces a satisfactory DOM structure (on inspection via firebug) - but I'm losing scope of this in one specific area = calling the "public" methods of the returned object, internally.
publicMethod() //fails
this.publicMethod() //fails, this scopes to DOM window
M.Class.API.publicMethod() // works, but kludgy syntax
In the previous iteration of this pattern, the "class" object is self-executing, and reference to this is maintained :
M.Class = function( p1, p2){
var _param1;
var _param2;
var _root;
function _init(){
_root = this; //this gets referenced for later usage
_param1 = p1;
_param2 = p2;
}
function _getParam(){
return _param2;
}
function _setParam(e){
_param2 = e;
}
M.Class.API = {
init : function(){ _init(); },
getParam : function(){ return _getParam(); },
setParam : function(e){ _setParam(e) },
}
console.log('getParam, internal :%s', _root.getParam() ) //success
return M.Class.API;
}();
M.Class.init();
However, in the refactored pattern, I wish instantiate these "classes" via new, to gain more control over execution order.
I've read many, many articles on the fairly mind numbing subject of lexical scope in js... yet come up with no conclusions.
How should I maintain the scope of this in my updated module pattern?
This is one of those philosophical questions that everyone asks when writing a library or module: should functions reference the container object using this or the variable name? The answer is: it depends.
If you know that the function will always be called with the correct value of this (e.g. a method on a prototype), then use this. However, if the function might be called any other way, then use the variable name. If you decide at some later stage to change the name, it's a pretty simple search and replace exercise. And calling myLib.utils.someFn is a lot clearer than calling this.someFn to me. And if you feel it's too much typing, you can always revert to var sF = myLib.utils.someFn and go from there.
Edit
To answer your questions:
publicMethod() //fails
There is no publicMethod identifier in the current scope, it will fail.
this.publicMethod() //fails, this scopes to DOM window
If the call was M.Class(), then this is a reference to M. If you are getting window, then you are calling the function some other way.
M.Class.API.publicMethod() // works, but is kludgy
Because that is how you have set it up. If you don't like it, set it up some other way.
Lastly:
)(typeof window === 'undefined' ? this : window);
seems to be one of those mystic incantations that seem to proliferate on the web. What is the purpose? If the intent is to pass a reference to the global object to the function, then:
)(this);
is sufficient everywhere. The purpose of the above is to ensure that the function has a reference to the global object because referencing window might resolve to some other object. Including logic that may or may not pass in the global object seems like a backward step. In what scenario is it preferable to reference the (possibly re-assigned) window property of the global object rather than the global object itself?
What if all of your methods were "private" except the ones you manually expose through M.Class.API?
function _getParam(){
return _param2;
}
function _setParam(e){
_param2 = e;
}
function publicMethod(){
console.log("public method");
}
M.Class.API = {
getParam : _getParam,
setParam : _setParam,
publicMethod : publicMethod
}
publicMethod(); // succeeds
this.publicMethod(); // still fails
M.Class.API.publicMethod(); // still works, still is kludgy
You should also be aware that returning an anonymous object from a function may have unintended consequences when calling that function with the new keyword. See this Stack Overflow question.
Related
I have a library which has defined a class as this. I would like to call getMe() function outside class A with my own me.
var me;
var A = function(_me){
me = _me;
}
A.prototype.getMe = function(){
me();
}
I have class B where I call it like
A.prototype.getMe.call(this) but this would throw an error as me is not defined. How can I pass me into this ? I would like to make minimum changes to getMe function.
The only way to do this is, I guess to use an if .
A.prototype.getMe = function(){
if(!me){
me = this.myMe
}
me();
}
So I did A.prototype.getMe.call({myMe: myMe}, args) but would it define the variable in global space ?
You can't reasonably do this, not least because A is fundamentally broken (see below).
Whether you can do it at all depends entirely on where the A code is: If it's at global scope, you can do what you want but shouldn't. If it isn't at global scope, you can only do it from code within the scope where me is declared (or a scope within it).
If it's at global scope, you'd do it like this (but don't :-) ):
// The "A" Code
var me;
var A = function(_me){
me = _me;
}
A.prototype.getMe = function(){
me();
}
// Your code using it
new A(); // Create `A.prototype.getMe`, because unless
// `A` is called at least once, it doesn't exist
var myMe = function() {
console.log("myMe called");
};
me = myMe; // Set the global `me`
A.prototype.getMe(); "myMe called"
The only way to do this is, I guess to use an if .
if(!me){
me = this.myMe
}
So I did A.prototype.getMe.call({myMe: myMe}, args) but would it define the variable in global space ?
Yes, it would. That's what me = this.myMe does.
From that observation, it sounds like you can modify A's code. If so, fix it so that it doesn't define a prototype function in terms of a global variable. Perhaps isolate the code from the function into a function that doesn't expect to be called on an instance and pass in me as a parameter.
I am working on an existing library to make a small change. So I can only change inside getMe function definition. And I cant change var me definition.
In that case, you can add a new optional parameter at the end, and use that if provided and me if not provide:
A.prototype.getMe = function(myMe){
var meToCall = myMe || me;
meToCall();
};
Live Example:
// The "A" Code
var me;
var A = function(_me){
me = _me;
}
A.prototype.getMe = function(myMe){
var meToCall = myMe || me;
meToCall();
}
// Your code using it
A.prototype.getMe(function() {
console.log("My me!");
});
And, separately, A is fundamentally broken if it's really as shown (barring an extremely specific use-case). Having constructor code set a global (global at least to A's code) that's then used by a prototype function is a huge design and maintenance red flag.
Consider the cross-talk horror:
// The "A" Code
var me;
var A = function(_me){
me = _me;
}
A.prototype.getMe = function(){
me();
}
// Using it
var a1 = new A(function() {
console.log("me1");
});
a1.getMe(); // "me1" -- so far so good
var a2 = new A(function() {
console.log("me2");
});
a2.getMe(); // "me2" -- yup, still fine
a1.getMe(); // "me2" -- what the...?!?!?!!
For prototype methods, is there a safe way to ensure this is always the object itself (outside of checking instanceof and throwing an error).
var Dialog = function() {};
Dialog.prototype.open = function() {
var open = this;
// how do ensure "this" is always the Dialog
console.log(open);
};
With this code, any user can mistakenly "coerce" the context to be incorrect. For example:
var pointer = new Dialog().open;
pointer(); // "this" would become Window
I'm trying to find a way to handle this internally so that I don't have to throw an error or rely on the user to always do the right thing.
A user could always call pointer.call(dialog) but that means they need a separate pointer for the dialog, and this is a good example of a burden on the user rather than me, the author.
It's really screwy and kind of ruins the performance gains you get with prototypical inheritance but you could explicitly bind each of the functions within the constructor.
function log(obj) {
document.querySelector('pre').innerText += obj.toString() + '\n';
}
function Dialog() {
this.open = this.open.bind(this);
}
Dialog.prototype.open = function() {
log(this);
};
Dialog.prototype.toString = function() {
return '[object Dialog]';
};
var d = new Dialog();
d.open();
var open = d.open;
open();
<pre></pre>
This would create unique function objects for each method of each instance of Dialog but technically it would work as intended.
You cannot really prevent this using prototyping. The bind suggestion by Mike C does indeed do the deed, but it is basically a very elaborate/expensive way to use the decorator pattern, which does solve the scoping issue:
function Dialog() {
var dialog = this;
dialog.open = function() {
console.log(dialog, this);
};
}
var d = new Dialog();
d.open();
var open = d.open();
open();
Keep in mind that this approach is much less memory efficient than the prototype example in your question, so never use it if you have a lot of instances.
I searching across the web about the jquery.namespace process. finally i got a answer in the stack overflow with this example script..
jQuery.namespace = function() {
var a=arguments, o=null, i, j, d;
for (i=0; i<a.length; i=i+1) {
d=a[i].split(".");
o=window;
for (j=0; j<d.length; j=j+1) {
o[d[j]]=o[d[j]] || {};
o=o[d[j]];
console.log(o);
}
}
// console.log(o); //Object {}
return o;
};
// definition
jQuery.namespace( 'jQuery.debug' );
jQuery.debug.test1 = function()
{
alert( 'test1 function' );
};
jQuery.debug.test2 = function()
{
alert( 'test2 function' );
};
// usage
jQuery.debug.test1();
jQuery.debug.test2();
It has 2 parts, once is "Jquery.namespace" - function and another is declaring new methods to name space. But i unable to understand what is "Jquery.namespace" function exactly do here.. i tried to understand line by line, but i couldn't get the process what the function do here..
Any one explain me about the function, about how that's works? or any other easy method to make name spacing using jQuery..
Thanks in advance
The function is taking arguments which are a list of namespaces you want created.
lets simplify it so it only takes one namespace
jQuery.namespace = function(namespace) {
var o=null, j, d;
d=namespace.split(".");
o=window;
for (j=0; j<d.length; j=j+1) {
o[d[j]]=o[d[j]] || {};
o=o[d[j]];
}
}
return o;
};
The function is then fairly simple. What is actually happening is starting from the window we are recursively checking if the objects we have declared in our namespace exist. For example take the call jQuery.namespace('foo.bar') the function would check to see if the window had an attribute foo and if not it would create it. The function would then check if window.foo had an attribute bar and if not create it.
In the end all the function does is create an object linked to the window (a global variable) which has all the relevant sub-objects. You are then just assigning functions and variables to the nested object rather than directly to the window which you would otherwise do with global variables.
I am trying to understand the way that javascript passes functions around and am having a bit of a problem groking why a prototype function can NOT access a var defined in a function constructor while a function defined in the constructor can access the var. Here is code that works:
var model = function model() {
this.state = 1;
this.GetState = (function(scope){
return function(){ return scope.state;};
})(this);
}
var othermodel = function othermodel(mdl) {
this.GetStateFn = mdl.GetState;
}
othermodel.prototype.WriteState = function() {
console.log(this.GetStateFn.call());
};
var m = new model();
var o = new othermodel(m)
o.WriteState();
This works and makes sense - the GetState() function can access this.state.
However, if I create GetState as follows:
model.prototype.GetState = (function(scope){
return function(){ return scope.state;};
})(this);
The result will be an error that scope is not defined.
I would prefer to have this work with the prototype method as I do not want a copy of the function in ever model, but it would seem that prototype can't work because it can't access the specific instance of the model.
So, can someone provide me with a good explanation of a) what I need to do to get this to work with prototype (assuming I can) and b) if I can't get it to work with prototype, what is the reason so I can understand better the underpinnings of the issue.
Why not simply write the function this way
model.prototype.GetState = function() { return this.state; }
var othermodel = function othermodel(mdl) {
this.GetStateFn = mdl.GetState.bind(mdl);
}
othermodel.prototype.WriteState = function() {
console.log(this.GetStateFn.call());
};
The above code will work, as in most cases you will execute code like m.GetState(). That is an example of invoking a function as an object method. In that case, this is guaranteed to point to the object m. You seem to know how the prototype chains work, so I won't go there.
When assigning the function reference to the other model, we use the .bind to ensure that within GetState, this points to mdl. Reference for bind: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Function/bind
Your original IIFE's were in effect your implementation of bind. The issue was the value of this was wrong. Currently, every time you need to assign models function to some other function, you will need to use bind at all those times. You have tagged your question as node.js, bind is available on the Function prototype in node.js and any ES5 compatible browser. If you need to run the above code on older browsers or environments that do not support bind, replace bind with your IIFE.
As for why your code isn't working,
model.prototype.GetState = (function(scope){
return function(){ return scope.state;};
})(this);
Here, this doesn't refer to the eventual model object (m). this can refer to any one of 5 options in javascript. Refer: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Operators/this
Lets assume the above code is in an html file inside some script tag. Then this will refer to the window object. window doesn't have any property called state, hence the undefined. If you were to console.log(this.m, this.o) at the end of you script, you would see the respective m and o objects.
When defined like this:
var model = function model() {
this.state = 1;
this.GetState = (function(scope){
return function(){ return scope.state;};
})(this);
}
the anonymous function is declared and immediately executed. this is passed as a parameter to that self-executing function. As a result - a new function is returned, but this function has scope parameter in its closure - so that it is accessible after the scope has exited. As a result - the function, when invoked, can still access state property of that "enclosed" this (the one that became scope and was closed upon).
If you define it like this:
model.prototype.GetState = (function(scope){
return function(){ return scope.state;};
})(this);
the mechanism is the same, it's just this is not. It is now the context of the scope you execute the above code in. Assuming it's done in global scope - it would be window object.
If you don't want to use bind because of its support with older browsers, you could try this:
http://jsfiddle.net/j7h97/1/
var model = function (state) {
this.state = state || new Date().getTime();
};
model.prototype.GetState = function () {
return this.state;
};
model.prototype.WriteState = function () {
console.log("model WriteState: " + this.GetState());
};
var othermodel = function othermodel (mdl) {
this.GetStateFn = function () {
return mdl.GetState.call(mdl);
};
};
othermodel.prototype.WriteState = function () {
console.log("othermodel WriteState: " + this.GetStateFn());
};
var model1 = new model();
model1.WriteState();
var othermodel1 = new othermodel(model1);
othermodel1.WriteState();
var model2 = new model();
model2.WriteState();
var othermodel2 = new othermodel(model2);
othermodel2.WriteState();
Seems to do what you want without bind. I created the model.prototype.WriteState for testing purposes.
It depends on where it is called. If it's in global scope, this will not refer the the model. If it's running in a browser it will refer to the global window object instead.
http://jsfiddle.net/ZLH7J/1/
What the jsFiddle and code below shows are two examples that essentially do the same thing. When trying to call first(); or this.first(); in either example, an undefined error is thrown. I can call the functions later through the instance, but not when trying to instantiate the object using init(){...}() like a constructor. I put init() at the bottom thinking it was an order of operations thing, but that is not the case. This does not work the way I thought it would work.
I am curious to understand how this is supposed to be done, and why this cannot be done.
//create and return an obj
var fishSticks = function(){
return {
first: function(){
document.getElementById('output').innerHTML="Success";
},
init: function(){
try{
first(); //err
this.first(); // also err
}catch(e){
document.getElementById('output').innerHTML=e.toString();
}
}()
}
}
//do function stuff and then return 'this'
var fishFillet = function(){
var first = function(){
document.getElementById('output2').innerHTML="Success";
}
var init = function(){
try{
first(); //err
this.first(); // also err
}catch(e){
document.getElementById('output2').innerHTML=e.toString();
}
}()
return this;
}
var test = new fishSticks();
var test2 = new fishFillet();
You need to understand two things:
1) JavaScript does not automatically insert this like Java does, so the first() call will only look through the lexical scope for a definition of first, it will nok look at the this object. Therefore the call to first() should work but this will be bound to something else than what you might expect inside first.
2) Local variables in a constructor do not become members of the constructed object.
In your second example, if you comment out the call in "init" to this.first() then you get the "Success" message.
The first version doesn't work because JavaScript simply does not allow for references to be made within an under-construction object to the object itself. There's just no way to do it.
The second one works (well the simple reference to "first" works) because "first" is declared as a local variable. Local variables are not properties of any object, and in particular they're not properties of the object allocated when the function is called with new. That's why this.first() doesn't work.
In the second one, you could make this.first() work by declaring things differently:
var fishFillet = function(){
this.first = function(){
document.getElementById('output2').innerHTML="Success";
}
var init = function(){
try{
this.first(); //will work
}catch(e){
document.getElementById('output2').innerHTML=e.toString();
}
}()
return this;
}
Also, for what it's worth, the weird anti-pattern of
var something = function() { ... }
is not as useful as
function something() { ... }
There's no reason to use the var declaration instead of the function declaration.
How about...
var fishFillet = function () {
var first = function () {
document.write( 'Success' );
};
var init = function () {
first();
};
init();
return {
first: first
};
};
And then:
var ff = fishFillet(); // calls init() which calls first()
ff.first(); // call first() manually
Live demo: http://jsfiddle.net/uaCnv/
So, first you define all your functions, next you manually invoke init, and last you return an object containing those functions which should be available through the resulting object (as methods).
Since you are using both as a constructor, format them as such:
function fishFillet(){
this.first = function(){
document.getElementById('output2').innerHTML="Success";
}
this.init = function(){
try{
this.first();
}catch(e){
document.getElementById('output2').innerHTML=e.toString();
}
}
}
var food = new fishFillet();
food.init();
The reason it wasn't working for you is b/c "first" is created as a local varaible, and is deleted after execultion. Init isn't being called until after the execution of the constructor has finished