For some time now, I've been using the design pattern of objectOne, shown below. I cannot remember where I picked it up. I tried to find it but couldn't. Perhaps its some hybrid of things I read about. Today I discovered that it is very flawed, since this is resolving to the window object, making all public methods global. I was under the impression that when this is used within a function, it would refer to the function itself, as opposed to the global window object. I guess this is not the case? Could someone explain something that I'm missing or point me to a resource that explains it? I'm also interested in either fixing this pattern or finding a similar one that doesn't have this problem with global method names. I suppose if I would use a variable other than this, perhaps fn, and i return that, then it would fix things. Thanks in advance for any help with this question, sorry its sort of vague.
JS Fiddle:
http://jsfiddle.net/nLL8y/3/
myapp = {};
myapp.objectOne = function() {
var that = this,
p = {};
this.public = function() {
console.log(this);
};
p.private = function() {};
return this;
}();
myapp.objectTwo = {
public: function() {
console.log(this);
},
notPrivate: function() {}
};
myapp.objectThree = function() {
var fn = {},
p = {};
fn.public = function() {
console.log(this);
};
p.private = function() {};
return fn;
}();
//creates global functions
myapp.objectOne.public();
//doesn't allow private
myapp.objectTwo.public();
//seems to work
myapp.objectThree.public();
myapp is used as a namespace in your example. objectOne and objectTwo are constructors so they should start with capital letter. But your biggest problem is using methods directly as opposed to creating objects:
var myapp = {};
myapp.ObjectOne = function() {
this.public = function() {
console.log(this);
};
var private = function() {};
};
myapp.ObjectTwo = function() {
this.public = function() {
console.log(this);
},
this.notPrivate = function() {}
};
var o1 = new myapp.ObjectOne();
o1.public();
var o2 = new myapp.ObjectTwo();
o2.public();
Related
If I have:
name.sub = function() {
var sub = {};
var placeholder = "test"
var test = function() {
return 42;
};
// Desired code would be here
return sub;
};
I want to use a placeholder to access the variable so that I get 42.
Something like
window["name"]["sub"][placeholder] is seemingly looking for name.sub.test.
The only answers I found were if it was a global variable.
Using eval would work, but I've heard it should be avoided where possible.
placeholder = "test";
console.log(eval(placeholder + '()'))
// Would return 42
My actual end goal is to have an associative array where:
console.log(array[placeholder]);
// Would return 42
Any help would be appreciated.
This is what I ended up using for anyone interested:
name.sub= function() {
var sub = {};
var placeholder = "test"
var test = function() {
return 42;
var newObj = {};
newObj["test"] = function() {test()}
console.log(newObj[placeholder]())
// Should return 42
};
You can't access variables inside a function from outside said function.
Instead, you could do this:
name.sub = function(placeholder) {
var functions = {
"test": function() {
return 42;
},
};
return functions[placeholder]();
};
name.sub("test"); // 42
I'm not sure if that's what you're looking for but hopefully it is. Explain more?
You can't access local variables inside a function the same way you can access properties of window in global scope.
kangax wrote an interesting article about Understanding delete [in JavaScript], which includes an explanation of what Activation objects are - which I think is what you're looking for.
I suggest you read the entire article, but long story short:
Inside functions, declared variables (and functions) are added as properties to the activation object of the current scope, as they get added to window in the global scope.
But unlike window:
Note that Activation object is an internal mechanism and is never really accessible by program code.
Conclusion: What you're asking is not (currently) possible.
Your options are limited to:
Using an intermediate object:
name.sub = function() {
var sub = {};
var placeholder = "test";
var array = {};
array.test = function() {
return 42;
};
console.log(array[placeholder]());
return sub;
};
Using eval, exactly like you suggested:
name.sub = function() {
var sub = {};
var placeholder = "test";
var test = function() {
return 42;
};
console.log(eval(placeholder + '()'));
return sub;
};
Using window, by removing var from test's declaration:
name.sub = function() {
var sub = {};
var placeholder = "test";
test = function() {
return 42;
};
console.log(window[placeholder]());
return sub;
};
I suggest the first option for the sake of performance over eval, for compatibility over window (might collide with other code), and simply because of personal taste and what I consider good practice.
By what i understand of your question,
its seem like you are looking for a key/value pair to a JavaScript object literal,
window.name is reserved btw: https://developer.mozilla.org/en-US/docs/Web/API/Window/name
var sub = {
'test': function() {
return 42;
},
'test2': 42;
}
sub['test']();
sub['test2'];
add by
Using dot notation:
sub.test3 = "value3";
Using square bracket notation:
sub["test4"] = "value4";
Maybe im thinking to simple , but seems like this is what you are looking for
What is the proper way to use _self to always have access to an object? Is using _self ok, or is it bad practice?
I want a good way to get at myObject's attributes and methods, even from functions that aren't called in myObject's context. There are solutions like .bind(this), using _self, and jQuery's $.proxy().
For example:
var myObject = {
name: 'Tyrion',
alias: 'imp',
_self: function() {
return this;
},
// I know this context is fine, but let's pretend it's being called from elsewhere.
getAlias: function() {
var _self = myObject._self();
return _self.alias;
}
}
In order to do what you're looking to do, you'd have to change a few things. #elclanrs is right about what your this context is. I'll put two options below.
var myObject = {
name: 'Tyrion',
alias: 'imp',
// I know this context is fine, but let's pretend it's being called from elsewhere.
getAlias: function() {
// you'd have to do this in every method.
var _self = this;
return _self.alias;
}
}
The other option is a bit different, and not as usable, but I'm adding it so you can see it:
var myObject = function() {
var _self = this;
_self.name = 'Tyrion';
_self.alias = 'imp';
_self.getAlias = function() {
return _self.alias;
};
};
in the second instance, getAlias would be better as a prototype method, but you won't have access to the _self variable, only this.
You can do this too but I wouldn't necessarily recommend it.
var obj = {
_self: this.obj, // if you don't have .obj it points to window
thing: 'thingy',
alsoThis: function() {
return 'another thing'
}
};
obj._self;
It's also possible that since it's not within a closure, or a function in otherwords, the context of this._self may be incorrect if the context is changed by the scope which its referenced in.
Generally, I just do var _self = this; right before a function which I am nesting another function within that requires the this context outside the parent function since the nested one will not have the ability to access the value of this being nested.
That's usually not too common in my experience, and you really shouldn't be declaring such a property/var that needs to be used for the purpose that _self vars serve. It isn't a good practice and would be best to not do.
What if you run into a situation where you need to have _self = some other context?
thisis determined by the invocation of the function. (aka, the way the function is called) See my other answers for more details.
var myObject = {
name: 'Tyrion',
alias: 'imp',
_self: function () {
return this;
},
// I know this context is fine, but let's pretend it's being called from elsewhere.
getAlias: function () {
var _self = myObject._self();
return _self.alias;
}
};
//member invocation
console.log(myObject._self() === myObject); // true
var aFucntion = myObject._self;
//functional invocation
console.log(aFucntion() === myObject); // false
console.log(aFucntion() === this); //true
Instead of worrying about the context of this, a workaround is to assign this to a value in an outer function, and then access that value in an inner functions. This is called closure
var MyObject = function (title) {
var _self = this,
helper = function () {
return _self.title + " " + _self.name;
};
this.title = title;
this.fullName = function () {
return helper(); //functional invocation
//if helper used this, this would be global
};
this.name = 'Tyrion';
this.alias = 'imp';
this.getAlias = function () {
//access to _self through closure
return _self.alias;
};
};
//constructor invocation
var aObject = new MyObject("Mr.");
console.log(aObject.getAlias()); //imp
console.log(aObject.fullName()); //Mr. Tyrion
FYI:
If _self returns myObject, context would not mater.
_self: function () {
return myObject;
}
Very simple question, not sure if there are any differences in these ways of creating a javascript "module". I'm hoping somebody can clarify it for me.
A)
var foo = function() {
var bar = function() {
console.log('test');
};
return {
bar: bar
};
};
B)
var foo = function() {
function bar() {
console.log('test');
};
return {
bar: bar
};
};
C)
var foo = function() {
this.bar = function() {
console.log('test');
};
return {
bar: this.bar
};
};
A and B are essentially the same, though there is a very minor difference between A and B due to function/variable hoisting, theoretically you could write code which would work in B but break in A, but practically speaking you'd have to really write weird code to do so.
C will work, but is conceptually wrong. The point of using this.funcName in a function is as a constructor (creating lots of objects using new Thing(). If you aren't using the function as a constructor you shouldn't be using that style as someone scanning the code may mistake the function as a constructor instead of its actual purpose which is a module.
At first, you forgot to execute the function expression: the module pattern is an IEFE. You just create a function.
Your last example is nonsense, it looks like a constructor function when assigning properties to this - and when executed as a IEFE it breaks (and using it with new has undesired effects; an when returning an object it's useless).
For the difference between the first and the second snippet see var functionName = function() {} vs function functionName() {}. In context of the module pattern, the function declaration is recommended.
//Javascript Module Pattern
var person = (function() {
var cname = 'CheapFlight';
return {
name: "Santosh Thakur",
getAge: function() {
return cname;
},
growOlder: function() {
return cname + " Updated";
}
};
}());
person.cname = "New Company"
console.log(person.cname);
console.log(person.name);
console.log(person.getAge());
console.log(person.growOlder());
prefix var before a function makes it a "class"-ish, this means you can make many versions of it. This goes for A
For example:
var hi = function()
{
var bye = function()
{
alert("bye");
}
bye(); // this will call bye
var something = new bye(); // this will create a new instance of bye();
}
var something = new hi();
something();
B means you can only call bar, not make a new instance of it inside the function.
C is the same as bar because of its scope
Class-ish:
var Dog = function( hair, type )
{
this.hair = hair;
this.type = type;
}
var fred = new Dog( "long", "Dalmation" );
alert( fred.hair );
var dave = new Dog( "short", "Poodle" );
alert( dave.type);
This is a class ^
ORIGINAL QUESTION:
i am studying js and i would like to know if there is any (useful) difference between these two ways of protecting the global scope other than the fact that the second one can be reused (called again).
option1:
var question = {};
(function(){
question.option1 = function() {
// some code
};
})();
option2:
var question = {};
question.option2 = function () {
//some code
};
question.option();
thanks!
EDIT 1:
thank you #luisperezphd. is there any difference between what you wrote and this (besides verbosity)?
var question = {};
question.option3 = {};
question.option3.privateVar = 0;
question.option3.testing = function () {
question.option3.privateVar++;
// some code
};
question.option3.testing();
EDIT 2:
thank you lanston and luisperezphd! i did not realize that question.option3.privateVar was available in the global.
is there any difference between this:
var question = {};
(function(){
var privateVar = "some value";
question.option4 = function(){
alert(privateVar);
}
})();
question.option4();
and this:
var question = {};
question.option5 = function() {
var privateVar = "some value";
var someFunction = function() {
alert(privateVar);
}
return someFunction;
}
question.option5()();
?
There is no difference in the example you gave, but there is a difference you haven't exploited. In the first example, you can utilize variables and not pollute the global namespace or the object namespace. The equivalent of a private field in most object orientated languages. You would do that like so:
var question = {};
(function(){
var PrivateVariable = 0;
question.option1 = function() {
PrivateVariable++;
// some code
};
})();
alert(question.PrivateVariable); // returns 'undefined'
The reason the code above returns undefined is because PrivateVariable is not a field in question. But functions in question can access PrivateVariable. This is truly a private variable.
On the other hand, if you wrote it like this:
var question = {};
question.PrivateVariable = 0;
question.option1 = function() {
question.PrivateVariable++;
// some code
};
alert(question.PrivateVariable); // returns 0
In this second case, PrivateVariable is in fact not private and publicly accessible.
Incidentally, you normally wouldn't reference question from inside a function that belongs you question. Instead, you would use the this keyword, like so:
var question = {};
question.PrivateVariable = 0;
question.option1 = function() {
this.PrivateVariable++;
// some code
};
But this would only work on public variables. It makes it more clear what is going on. Also, in some cases, it makes maintaining the code easier in that if you change the name of the variable from question you wouldn't have to change references to it inside the function. There are other benefits, but I don't know if I should get into it here.
#svdsvd,It's quite different between liusperezphd's and yours, the PrivateVariable,you can't get it in the global,but you can get your question.option3.privateVar in the global
I have the following JS code:
var Item = function ()
{
this.property = '';
this.myfunction = function ()
{
var value = this.property;
};
};
however, this does not point to the defining class so value doesn't get anything.
how do I access this.property from inside my function?
You need to create a closure which captures the value of parent scope's this:
var Item = function ()
{
this.property = '';
var self = this;
this.myfunction = function ()
{
var value = self.property;
};
};
Update: As others have pointed out, this closure is not needed when Item is used as a constructor (new Item()). Noting it here for future reference.
just create an alias for this. It will get closure'd.
var Item = function ()
{
this.property = '';
var self = this;
this.myfunction = function ()
{
var value = self.property;
};
};
Your code works as is if you call Item() as a constructor.
var item = new Item();
item.property = "the property";
item.myfunction(); // value = "the property"
this changes depending on the context. The context being how a function was invoked, not how it was defined, but how it was called.
Besides that, you seem to be mixing up two patterns here. I'm sure you meant something like:
var Item = function() {
this.property = '';
};
Item.prototype.myfunction = function() {
var value = this.property;
};
Instead you kind of mixed a closure pattern with prototypal, which doesn't seem very useful there. Closure is good for hiding members, allowing for true private members, but here you're exposing the property anyway. There's no reason not to stick that function on the prototype.
Do yourself a favor and ignore any concepts you have of more traditional OO, they won't do you any good here. Prototypal isn't nearly the same thing.