I'm working on implementing a Javascript model on a web app that I'm working on. The purpose of the model is to simply hold information about the state of the page. I have come across two different implementations for creating the model and I was wondering which one was the best to use. The first implementation:
var PageInfo = function () {
this._info = {};
};
PageInfo.prototype = {
getInfo: function () {
return this._info;
},
setInfo: function (updatedInfo) {
this._info = updatedInfo;
}
};
The 2nd implementation:
var pageInfo = function () {
var info = {};
return {
getInfo: function () {
return info;
},
setInfo: function (updatedInfo) {
info = updatedInfo;
}
}
};
Another question I have is about the setInfo() function. When I find myself updating the model, I often want to have the info that I just changed immediately available to me. This has led me to write the setter function as such:
setInfo: function(updatedInfo) {
info = updatedInfo;
return info;
}
which I implement in the code like so:
var info = pageInfo.setInfo(newInfo);
Is this ok or should I be implementing it like this?:
pageInfo.setInfo(newInfo);
var info = pageInfo.getInfo();
Just trying to follow best practices and avoid any issues that may come up from using the wrong implementation.
Both implementations are perfectly acceptable. The former will be faster, albeit by a negligible amount, but exposes its internals to the world. This means that any variable that holds a reference to an instance of PageInfo will be able to manipulate the _info property. Generally this is a non-issue as properties that being with an underscore (_) are considered to be private and should be left alone.
The latter implementation makes use of a concept called closure. A closure is formed when a value is returned that maintains a reference to its defining scope. Essentially it means that the info variable is kept alive. Since the variable is "closed over" it's impossible for it to be modified outside of the interface methods that you provide. In my experience this is rarely needed.
In regards to your second question, again either is acceptable. I like the interface for accessor methods to be consistent so I would say that setInfo should not return anything but there are exceptions to every rule. The exception to the rule occurs when the the value returned by getInfo will not be congruent with what was passed to setInfo. That is, if getInfo returns different value than the value passed to setInfo you might want to return the value out of setValue. Otherwise, the caller could simply re-use the value that was passed to setValue instead of calling getValue.
1st implementation is better, as in 2nd implementation every time you call pageInfo function, you are defining 2 new functions (or set up a closure), while 1st implementation is defining them in prototype and reusing.
For other question, if you only do this to preserve lines, i might suggest something like:
var info = pageInfo.setInfo(newInfo) || pageInfo.getInfo();
assuming setInfo returns undefined.
Related
Stylistically, I prefer this structure:
var Filter = function( category, value ){
this.category = category;
this.value = value;
// product is a JSON object
Filter.prototype.checkProduct = function( product ){
// run some checks
return is_match;
}
};
To this structure:
var Filter = function( category, value ){
this.category = category;
this.value = value;
};// var Filter = function(){...}
Filter.prototype.checkProduct = function( product ){
// run some checks
return is_match;
}
Functionally, are there any drawbacks to structuring my code this way? Will adding a prototypical method to a prototype object inside the constructor function's body (i.e. before the constructor function's expression statement closes) cause unexpected scoping issues?
I've used the first structure before with success, but I want to make sure I'm not setting myself for a debugging headache, or causing a fellow developer grief and aggravation due to bad coding practices.
Functionally, are there any drawbacks to structuring my code this way?
Will adding a prototypical method to a prototype object inside the
constructor function's body (i.e. before the constructor function's
expression statement closes) cause unexpected scoping issues?
Yes, there are drawbacks and unexpected scoping issues.
Assigning the prototype over and over to a locally defined function, both repeats that assignment and creates a new function object each time. The earlier assignments will be garbage collected since they are no longer referenced, but it's unnecessary work in both runtime execution of the constructor and in terms of garbage collection compared to the second code block.
There are unexpected scoping issues in some circumstances. See the Counter example at the end of my answer for an explicit example. If you refer to a local variable of the constructor from the prototype method, then your first example creates a potentially nasty bug in your code.
There are some other (more minor) differences. Your first scheme prohibits the use of the prototype outside the constructor as in:
Filter.prototype.checkProduct.apply(someFilterLikeObject, ...)
And, of course, if someone used:
Object.create(Filter.prototype)
without running the Filter constructor, that would also create a different result which is probably not as likely since it's reasonable to expect that something that uses the Filter prototype should run the Filter constructor in order to achieve expected results.
From a run-time performance point of view (performance of calling methods on the object), you would be better off with this:
var Filter = function( category, value ){
this.category = category;
this.value = value;
// product is a JSON object
this.checkProduct = function( product ){
// run some checks
return is_match;
}
};
There are some Javascript "experts" who claim that the memory savings of using the prototype is no longer needed (I watched a video lecture about that a few days ago) so it's time to start using the better performance of methods directly on the object rather than the prototype. I don't know if I'm ready to advocate that myself yet, but it was an interesting point to think about.
The biggest disadvantage of your first method I can think of is that it's really, really easy to make a nasty programming mistake. If you happen to think you can take advantage of the fact that the prototype method can now see local variables of the constructor, you will quickly shoot yourself in the foot as soon as you have more than one instance of your object. Imagine this circumstance:
var Counter = function(initialValue){
var value = initialValue;
// product is a JSON object
Counter.prototype.get = function() {
return value++;
}
};
var c1 = new Counter(0);
var c2 = new Counter(10);
console.log(c1.get()); // outputs 10, should output 0
Demonstration of the problem: http://jsfiddle.net/jfriend00/c7natr3d/
This is because, while it looks like the get method forms a closure and has access to the instance variables that are local variables of the constructor, it doesn't work that way in practice. Because all instances share the same prototype object, each new instance of the Counter object creates a new instance of the get function (which has access to the constructor local variables of the just created instance) and assigns it to the prototype, so now all instances have a get method that accesses the local variables of the constructor of the last instance created. It's a programming disaster as this is likely never what was intended and could easily be a head scratcher to figure out what went wrong and why.
While the other answers have focused on the things that are wrong with assigning to the prototype from inside the constructor, I'll focus on your first statement:
Stylistically, I prefer this structure
Probably you like the clean encapsulation that this notation offers - everything that belongs to the class is properly "scoped" to it by the {} block. (of course, the fallacy is that it is scoped to each run of the constructor function).
I suggest you take at the (revealing) module patterns that JavaScript offers. You get a much more explicit structure, standalone constructor declaration, class-scoped private variables, and everything properly encapsulated in a block:
var Filter = (function() {
function Filter(category, value) { // the constructor
this.category = category;
this.value = value;
}
// product is a JSON object
Filter.prototype.checkProduct = function(product) {
// run some checks
return is_match;
};
return Filter;
}());
The first example code kind of misses the purpose of the prototype. You will be recreating checkProduct method for each instance. While it will be defined only on the prototype, and will not consume memory for each instance, it will still take time.
If you wish to encapsulate the class you can check for the method's existence before stating the checkProduct method:
if(!Filter.prototype.checkProduct) {
Filter.prototype.checkProduct = function( product ){
// run some checks
return is_match;
}
}
There is one more thing you should consider. That anonymous function's closure now has access to all variables inside the constructor, so it might be tempting to access them, but that will lead you down a rabbit hole, as that function will only be privy to a single instance's closure. In your example it will be the last instance, and in my example it will be the first.
Biggest disadvantage of your code is closing possibility to override your methods.
If I write:
Filter.prototype.checkProduct = function( product ){
// run some checks
return different_result;
}
var a = new Filter(p1,p2);
a.checkProduct(product);
The result will be different than expected as original function will be called, not my.
In first example Filter prototype is not filled with functions until Filter is invoked at least once. What if somebody tries to inherit Filter prototypically? Using either nodejs'
function ExtendedFilter() {};
util.inherit(ExtendedFilter, Filter);
or Object.create:
function ExtendedFilter() {};
ExtendedFilter.prototype = Object.create(Filter.prototype);
always ends up with empty prototype in prototype chain if forgot or didn't know to invoke Filter first.
Just FYI, you cannot do this safely either:
function Constr(){
const privateVar = 'this var is private';
this.__proto__.getPrivateVar = function(){
return privateVar;
};
}
the reason is because Constr.prototype === this.__proto__, so you will have the same misbehavior.
Stylistically, I prefer this structure:
var Filter = function( category, value ){
this.category = category;
this.value = value;
// product is a JSON object
Filter.prototype.checkProduct = function( product ){
// run some checks
return is_match;
}
};
To this structure:
var Filter = function( category, value ){
this.category = category;
this.value = value;
};// var Filter = function(){...}
Filter.prototype.checkProduct = function( product ){
// run some checks
return is_match;
}
Functionally, are there any drawbacks to structuring my code this way? Will adding a prototypical method to a prototype object inside the constructor function's body (i.e. before the constructor function's expression statement closes) cause unexpected scoping issues?
I've used the first structure before with success, but I want to make sure I'm not setting myself for a debugging headache, or causing a fellow developer grief and aggravation due to bad coding practices.
Functionally, are there any drawbacks to structuring my code this way?
Will adding a prototypical method to a prototype object inside the
constructor function's body (i.e. before the constructor function's
expression statement closes) cause unexpected scoping issues?
Yes, there are drawbacks and unexpected scoping issues.
Assigning the prototype over and over to a locally defined function, both repeats that assignment and creates a new function object each time. The earlier assignments will be garbage collected since they are no longer referenced, but it's unnecessary work in both runtime execution of the constructor and in terms of garbage collection compared to the second code block.
There are unexpected scoping issues in some circumstances. See the Counter example at the end of my answer for an explicit example. If you refer to a local variable of the constructor from the prototype method, then your first example creates a potentially nasty bug in your code.
There are some other (more minor) differences. Your first scheme prohibits the use of the prototype outside the constructor as in:
Filter.prototype.checkProduct.apply(someFilterLikeObject, ...)
And, of course, if someone used:
Object.create(Filter.prototype)
without running the Filter constructor, that would also create a different result which is probably not as likely since it's reasonable to expect that something that uses the Filter prototype should run the Filter constructor in order to achieve expected results.
From a run-time performance point of view (performance of calling methods on the object), you would be better off with this:
var Filter = function( category, value ){
this.category = category;
this.value = value;
// product is a JSON object
this.checkProduct = function( product ){
// run some checks
return is_match;
}
};
There are some Javascript "experts" who claim that the memory savings of using the prototype is no longer needed (I watched a video lecture about that a few days ago) so it's time to start using the better performance of methods directly on the object rather than the prototype. I don't know if I'm ready to advocate that myself yet, but it was an interesting point to think about.
The biggest disadvantage of your first method I can think of is that it's really, really easy to make a nasty programming mistake. If you happen to think you can take advantage of the fact that the prototype method can now see local variables of the constructor, you will quickly shoot yourself in the foot as soon as you have more than one instance of your object. Imagine this circumstance:
var Counter = function(initialValue){
var value = initialValue;
// product is a JSON object
Counter.prototype.get = function() {
return value++;
}
};
var c1 = new Counter(0);
var c2 = new Counter(10);
console.log(c1.get()); // outputs 10, should output 0
Demonstration of the problem: http://jsfiddle.net/jfriend00/c7natr3d/
This is because, while it looks like the get method forms a closure and has access to the instance variables that are local variables of the constructor, it doesn't work that way in practice. Because all instances share the same prototype object, each new instance of the Counter object creates a new instance of the get function (which has access to the constructor local variables of the just created instance) and assigns it to the prototype, so now all instances have a get method that accesses the local variables of the constructor of the last instance created. It's a programming disaster as this is likely never what was intended and could easily be a head scratcher to figure out what went wrong and why.
While the other answers have focused on the things that are wrong with assigning to the prototype from inside the constructor, I'll focus on your first statement:
Stylistically, I prefer this structure
Probably you like the clean encapsulation that this notation offers - everything that belongs to the class is properly "scoped" to it by the {} block. (of course, the fallacy is that it is scoped to each run of the constructor function).
I suggest you take at the (revealing) module patterns that JavaScript offers. You get a much more explicit structure, standalone constructor declaration, class-scoped private variables, and everything properly encapsulated in a block:
var Filter = (function() {
function Filter(category, value) { // the constructor
this.category = category;
this.value = value;
}
// product is a JSON object
Filter.prototype.checkProduct = function(product) {
// run some checks
return is_match;
};
return Filter;
}());
The first example code kind of misses the purpose of the prototype. You will be recreating checkProduct method for each instance. While it will be defined only on the prototype, and will not consume memory for each instance, it will still take time.
If you wish to encapsulate the class you can check for the method's existence before stating the checkProduct method:
if(!Filter.prototype.checkProduct) {
Filter.prototype.checkProduct = function( product ){
// run some checks
return is_match;
}
}
There is one more thing you should consider. That anonymous function's closure now has access to all variables inside the constructor, so it might be tempting to access them, but that will lead you down a rabbit hole, as that function will only be privy to a single instance's closure. In your example it will be the last instance, and in my example it will be the first.
Biggest disadvantage of your code is closing possibility to override your methods.
If I write:
Filter.prototype.checkProduct = function( product ){
// run some checks
return different_result;
}
var a = new Filter(p1,p2);
a.checkProduct(product);
The result will be different than expected as original function will be called, not my.
In first example Filter prototype is not filled with functions until Filter is invoked at least once. What if somebody tries to inherit Filter prototypically? Using either nodejs'
function ExtendedFilter() {};
util.inherit(ExtendedFilter, Filter);
or Object.create:
function ExtendedFilter() {};
ExtendedFilter.prototype = Object.create(Filter.prototype);
always ends up with empty prototype in prototype chain if forgot or didn't know to invoke Filter first.
Just FYI, you cannot do this safely either:
function Constr(){
const privateVar = 'this var is private';
this.__proto__.getPrivateVar = function(){
return privateVar;
};
}
the reason is because Constr.prototype === this.__proto__, so you will have the same misbehavior.
In Introduction to Object-Oriented JavaScript, a formal description is given on how to use javascript in an object oriented fashion. Your code for functions inside objects would like along the lines of:
$(function() {
var oPerson = new cPerson("Florian");
alert("Hi! My name is " + oPerson.sMyNameIs());
});
function cPerson(sSetName)
{
var sName= sSetName;
var oPersonInst = this;
this.sMyNameIs = function () {
return sName;
};
}
With a bit more experience, you probably want a more clearcut reference to the instantiated class, so you modify the class code as such (and I add another function too):
function cPerson(sSetName)
{
var sName= sSetName;
var oPersonInst = this;
this.sMyNameIs = function () {
return oPersonInst.sName;
};
this.sMyFullNameIs = function () {
return oPersonInst.sMyNameIs();
};
}
Now we have come accross three different ways of referring to function or variables from within class functions:
return sName;
return this.sName;
return oPersonInst.sName;
Suppose I want to call the sName variable in the instantiated class very specifically, and these example functions will get more and more and even more complex and in depth as development goes on.
I think that the first option ('return sName;') is uncertain, as you are not quite sure whether you are referring to the variable in the right targeted instantiated class scope. It could be an accidental local var that you are calling.
The second, using this, IMHO, is also not perfect as this apparently changes depending on situations, and you can't (?) rely on that you are calling the right variable in the instantiated class specifically.
So the third reference, is IMHO, the best looking reference. Very specifically defined right at instantiation of the class. How can there be any doubt that the var sName of the class is meant.
Q1: Why are functions in the class defined with this.? Can it not better be defined with oPersonInst.something = function () { //... }; ?
Q2: why does, in code that I have given, alert(oPersonInst.sMyNameIs()); work, but alert(oPersonInst.sName); does not (at least, not within $.each( something, function() { //right here }) ), but alert(sName); DOES work (not favored IMHO, because of the above mentioned reasons)?
Q3: Can someone pot some exemplary code, or maybe even change this sample code, where solid out-of-local-scope references are used, that will work outside as well as inside $.each(...) callback functions (or other callback related functions) ?
Forgive my confusion, we're all learners, and I feel a hole in my brain. This article did not explain my concerns over this very well.
this doesn't change randomly at all.. it always means the current closure (function):
if you are in function_1() -- this means function_1
if you are in function_1>function_2 -- function_2 is the current closure and this means function_2
IF you need function_1's this in function_2 you have to capture it while in function_1: meaning var function1This = this;
and the way to reference a var by using the functions name before it means static access. It has different semantics
so use this.var to be sure you get the INSTANCE's variable
use a 'captured this pointer' to access your parents INSTANCE's variable
and only use name.var if you want to get the static, shared (between all instances) value
I'm trying to get under the covers a little bit and get to understanding and not regurgitating code. I'm aware that bind, call and apply change the execution context by modifying what this points to. What I do not understand, is are arenas in which these methods are indispensable and/or lead to much shorter code. Consider the following:
var person = {
firstName: 'john',
lastName: 'doe',
fullName: function () {
console.log(this.firstName + " " + this.lastName);
}
}
//#1, binder is an html button
$('#binder').click(person.fullName.bind(person)); //john doe
//#2, anonymous is an html button
$('#anonymous').click(function () {
person.fullName(); //john doe
});
//seems strange I see this application a lot 'borrowing' a method
//why?
var o = { firstName: 'obj', lastName: 'ect' };
person.fullName.call(o); //obj ect to console
I would like to know some general paradigms about when it's good practice and/or a huge time saver to use call and apply (and bind outside of the not using anonymous functions a la function #1)
To focus on where each of these features are indispensable, I would say
apply is most useful when dealing with variadic functions. It lets you convert an array of values into an argument list.
function logwrapper(f){
return function(){
console.log("called");
return f.apply(this, arguments);
}
}
var bar = function(){ ... }
var foo = logwrapper(bar);
bind is most useful when you want to pass a method into some code that expects just a function. A common example is settimeout and other functions that expect callbacks:
setTimeout(function(){ obj.meth(); }, 100); //handwritten callback
setTimeout(obj.meth.bind(obj), 100); //Function.prototype.bind
setTimeout(bind(obj, "meth"), 100); //Some JS libraries have functions that
//let you write the object only once.
Just keep in mind that IE <=8 does not support the native Function.prototype.bind. You might need to use a polyfill or helper library in that case.
call is mostly useful for borrowing methods, as you already noticed. If this is going to be useful or not is going to depend a lot on your particular use case but an important use that is very common is using array methods on the arguments. For historical reasons, arguments doesn't have any of the usual array methods (slice, map, etc) so you need to borrow them:
function myvariadic(x){
var rest = [].slice.call(x, 1);
}
Another example you might see is the hasOwnProerty method:
for(k in obj){
if(Object.prototype.hasOwnProperty.call(obj, k)){
....
}
}
This lets you call the real hasOwnProperty method even if the object shadows it with a hasOwnProperty key of its own.
Frankly I don't give a twopenny toss about good or bad practices.
If your aim is to understand anything at all, you'd better forget about them.
This being said, to understand when it is appropriate to use call/apply or bind, what you have to understand is closures, and the specific closure of this.
I use a broad definition of closure here. Not the one you will usually get in JavaScript technical chats, where we usually talk about lexical closures.
For the purpose of this little post, let's say a closure will be anything that provides a value for any variable (this included) that lives outside the current scope of the function you're focusing on.
bind, call and apply are basically there to supply a value for this (and some other arguments as an option).
It is only useful for two things:
invoke functions or methods of a given class to an object of a different class (or no class at all).
more on that later
supply a value for this in case the current closure does not suit your needs.
For instance, passing a reference to a method loses the connection to the underlying object instance. Or using a class prototype function. Or being called in the context of an event handler where JS has set this to the DOM element that caught the event.
call & apply
call will simply set this to the value of its first argument for this particular execution of the function.
Since creating objects is so easy in JS, you might want to do something like:
Worker = function ()
{
this.things_done = 0;
}
Worker.prototype = {
do_something: function (count)
{
this.things_done += count;
}
}
var worker= new Worker(); // Worker object
var wanabee_worker = { things_done: 100 }; // classless object
Et voilà! You've just created something that has no class relation with Worker but still can use Worker methods, since it has all the required properties defined.
worker.do_something.call (wanabee_worker, 10);
allows wanabee_worker to borrow unrelated object Worker's methods.
The opposite can also be used:
function reset_work_count ()
{
this.things_done = 0;
}
reset_work_count.call (worker);
Here we have a plain function that does not have anything to do with Worker, except it uses the same properties. call allows to apply it to a Worker object.
apply does exactly the same as far as this is concerned. The only difference is the way other arguments are passed.
bind
bind will create an internal closure and return a new wrapper function that will use the parameter passed to bind as a value for this.
Typical example: bind an event handler to a specific object.
$('#binder').click(person.fullName.bind(person));
Beneath the JQuery goo, what the code does eventually is
binder.addEventListener ('click', person.fullName.bind(person), false);
If the handler was simply defined as person.fullName, it would be called with this set to the DOM element that caught the event.
In that particular case, the closure of this provided by the JS engine does not suit our needs, so we provide an alternative one using bind.
Instead of person.fullName.bind(person), you could have used:
function() { person.FullName(); }
except that
the lambda function is cumbersome and obfucates the code,
bind is an internal construct that does the closure a bit more efficiently.
You could also imagine that the object used to handle the event will be dynamically allocated/computed by some proxy function. In that case, using bind would be useless since what we want is access to the methods that will allow us to use a lambda object as one of a working class.
function event_handler (param)
{
var obj = compute_lambda_obj ();
Worker.prototype.do_something.call (ojb, param);
}
Is this code idomatic, or should I just acess the properties directly?
self.isAlive = function() {
return self.alive;
}
It all depends on implementation.
If you feel the property is always going to be the value, accessing the property is adequate. If you feel like there's going to be some logic that determines returning a "properly formatted" value, I would use a method (or if the value could possibly be dynamic based on other factors, a method is a good idea).
To go a step further, other languages like C# have properties making it safe to expose values, but not necessarily alter them. JS doesn't have such a method of protecting it, so often get<Var> is used to expose the property, but in a read-only fashion.
It's all about how you would like the data, while also trying to anticipate what the worst-case scenario could be if you expose the property directly vs. through a method.
It seems that you are speaking of properties in the classical OOP sense, i.e., properties of classes. In the current version of Javascript, simulating this behavior is not completely clean. Consider the following example:
var Widget = function() {
var private = 'private';
}
'Widget' is a constructor function, and 'private' will be instantiated in the scope of just the constructor function. That means there is only one way to get access to 'private' from outside the constructor function scope:
var Widget = function() {
var private = 'private';
this.getPrivate = function() {
return private;
}
}
This will hide the private variable for each instance of Widget, but unfortunately, 'getPrivate' must now be added to each instance of Widget. You can see this occurring in the constructor function by the statement this.getPrivate = .... Every time you make an instance of Widget using var widget1 = new Widget(), that specific instance will have a new function, 'getPrivate', added to it.
The normal way to make reusable components in Javascript is to use its implementation of Prototypical Inheritance. You assign a prototype object to the constructor function that will have shared methods and properties across all instances of the component. I will provide an example below to explain, but there are caveats to prototypical inheritance that you should become aware of if you are doing object-oriented javascript. A great resource.
Here's an example of how this might come in to play for your example:
var Widget = function() {
this.alive = true;
}
Widget.prototype.isAlive = function() {
return this.alive;
}
var widget1 = new Widget();
widget1.isAlive(); // returns true
The problem here is that the property alive is being added to the object, and thus, it is publicly available, i.e., any user of your Widget can simply look through the DOM in their favorite variation of FireBug and see (as well as freely modify) this property.
Consider a variation where you attempt to hide alive to external users. Because alive is a property of Widget instances, you would want to include the code to hide it in the constructor, as shown below:
var Widget = function() {
var alive = true;
}
However, as stated at the beginning of this post, alive in this case is only exposed to the constructor function's scope; therefore, it would not be accessible to methods on the prototype. The reason for this is that each of those methods do not have the same scope as the constructor function, since Javascript only has function scope.
In conclusion, if you're trying to hide data in a reusable component, javascript does not provide a clean way to do it. If you don't mind having new memory allocated on each component instance for the same methods, then you can use my second code example in this post. However, if you prefer to have your methods allocated in memory only once, then you will need to expose properties on the object instance, e.g., this.alive = true.
That's subjective. Use of getters and setters is very discussed. Some people (like me) say you should always use getters and setters to follow the encapsulation principle, while others say that you shouldn't since your application would become unmaintainable.
This is good practice if you don't want outside js code to modify your property. If this is the desired effect you might consider assigning that property using var instead of making it a property of that object. That way your code within the object can modify it but it can only be accessed through your getter
var alive = false;
function isAlive(){ return alive;}
You can use:
function isAlive(){
return arguments.callee.alive;
}
isAlive.alive=true;
This appears to be ok still in strict mode.
Another way to accomplish this is
function isAlive(){
return isAlive.alive;
}
isAlive.alive=true;
But the problem is that someone can use the name as a string, or rename the function etc... and you can loose the status.