Develop Reference

Disable property mutation in JS

I was creating a component and was trying to break my implementation. The idea is to not allow user to manipulate the exposed properties.
The implementation was like this:
function MyClass(){
var data = [];
Object.defineProperty(this, 'data', {
get: function(){ return data; },
set: function(){ throw new Error('This operation is not allowed'); },
configurable: false,
});
}
var obj = new MyClass();
try {
obj.data = [];
} catch(ex) {
console.log('mutation handled');
}
obj.data.push('Found a way to mutate');
console.log(obj.data)
As you see, setting the property is handled but user is still able to mutate it using .push. This is because I'm returning a reference.
I have handled this case like:
function MyClass(){
var data = [];
Object.defineProperty(this, 'data', {
get: function(){ return data.slice(); },
set: function(){ throw new Error('This operation is not allowed'); },
configurable: false,
});
}
var obj = new MyClass();
try {
obj.data = [];
} catch(ex) {
console.log('mutation handled');
}
obj.data.push('Found a way to mutate');
console.log(obj.data)
As you see, I'm returning a new array to solve this. Not sure how it will affect performance wise.
Question: Is there an alternate way to not allow user to mutate properties that are of type object?
I have tried using writable: false, but it gives me error when I use it with get.
Note: I want this array to mutable within class but not from outside.

Your problem here is that you are effectively blocking attempts to modify MyClass. However, other objects members of MyClass are still JavaScript objects. That way you're doing it (returning a new Array for every call to get) is one of the best ways, though of course, depending of how frequently you call get or the length of the array might have performance drawbacks.
Of course, if you could use ES6, you could extend the native Array to create a ReadOnlyArray class. You can actually do this in ES5, too, but you lose the ability to use square brackets to retrieve the value from a specific index in the array.
Another option, if you can avoid Internet Explorer, is to use Proxies (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy).
With a proxy, you can trap calls to get properties of an object, and decide what to return or to do.
In the example below, we create a Proxy for an array. As you see in the handler, we define a get function. This function will be called whenever the value of a property of the target object is accessed. This includes accessing indexes or methods, as calling a method is basically retrieving the value of a property (the function) and then calling it.
As you see, if the property is an integer number, we return that position in the array. If the property is 'length' then we return the length of the array. In any other case, we return a void function.
The advantage of this is that the proxyArray still behaves like an array. You can use square brackets to get to its indexes and use the property length. But if you try to do something like proxyArray.push(23) nothing happens.
Of course, in a final solution, you might want decide what to do based on which
method is being called. You might want methods like map, filter and so on to work.
And finally, the last advantage of this approach is that you keep a reference to the original array, so you can still modify it and its values are accessible through the proxy.
var handler = {
get: function(target, property, receiver) {
var regexp = /[\d]+/;
if (regexp.exec(property)) { // indexes:
return target[property];
}
if (property === 'length') {
return target.length;
}
if (typeof (target[property]) === 'function') {
// return a function that does nothing:
return function() {};
}
}
};
// this is the original array that we keep private
var array = [1, 2, 3];
// this is the 'visible' array:
var proxyArray = new Proxy(array, handler);
console.log(proxyArray[1]);
console.log(proxyArray.length);
console.log(proxyArray.push(32)); // does nothing
console.log(proxyArray[3]); // undefined
// but if we modify the old array:
array.push(23);
console.log(array);
// the proxy is modified
console.log(proxyArray[3]); // 32
Of course, the poblem is that proxyArray is not really an array, so, depending on how you plan to use it, this might be a problem.

What you want isn't really doable in JavaScript, as far as I'm aware. The best you can hope for is to hide the data from the user as best you can. The best way to do that would be with a WeakMap
let privateData = new WeakMap();
class MyClass {
constructor() {
privateData.set(this, {
data: []
});
}
addEntry(entry) {
privateData.get(this).data.push(entry);
}
getData() {
return privateData.get(this).data.concat();
}
}
So long as you never export privateData don't export from the module, or wrap within an IIFE etc.) then your MyClass instances will be able to access the data but external forces can't (other than through methods you create)
var myInstance = new MyClass();
myInstance.getData(); // -> []
myInstance.getData().push(1);
myInstance.getData(); // -> []
myInstance.addEntry(100);
myInstance.getData(); // -> [100]

Flaws with the following implementation of private state of instance objects

I have read that private state of instance objects is generally not advised, and I would appreciate the help in pointing out the flaws/shortcomings of the following implementation.
Any advise/critique is greatly appreciated.
var namespace = {};
namespace.parent = {
parent_method1 : function () {},
parent_method2 : function () {}
};
namespace.child = function (properties) {
var private="secret";
this.prototype = {
create : function () {
this.unique = 'base';
this.unique += this.properties;
return this.unique;
},
get_private: function () {
console.log(private);
},
set_private: function (val) {
private = val;
}
};
var proto = Object.create(namespace.parent);
var instance = Object.create(proto);
for (var property in this.prototype) {
if (this.prototype.hasOwnProperty(property)) {
proto[property] = this.prototype[property];
}
}
instance.properties = properties;
return instance;
};
var a = namespace.child("a");
console.log(a.create());
a.get_private();
a.set_private("new_a_secret");
a.get_private();
var b = namespace.child("b");
console.log(b.create());
b.get_private();
a.get_private();

I would appreciate the help in pointing out the flaws/shortcomings of the following implementation.
I don't see anything wrong with your implementation of the var private, provided that it does what you expect it to do.
However, the big flaw of the code is: I don't understand it. What is your implementation supposed to do? It does not follow any of the standard patterns. This might be a shortcoming of the pseudo-methods and clear up when implementing a real world model; however as it stands it's quite confusing. Some documentation comments would help as well.
Specifically:
What does namespace.child do? It looks like a factory function, but I'm not sure what "childs" it does produce.
Also, for some reason it does set the namespace.prototype property to a new object on every invocation, which is then mixed into the instance object proto object. However, it leaves the internals (get_private, set_private) of the last created instance in global scope.
Are a and b supposed to be classes? Why do they have .create() methods, that initialise the class (instance?) - and should rather be called .init() if at all? Why do they return the .unique property value?
Why doesn't the child method initialize those factored objects right away?
What is that .properties field that holds a string value?
Why are you using two-level inheritance for those instance objects? Object.create(namespace.parent) is understandable, it inherits from a static object that is shared. But why is then Object.create(proto) used, copying some properties (create, get_private, set_private) on the proto and some properties (properties, unique) on the instance? Why distinguish between them?

Can javascript constructor function and object.create be combined?

Update
If this is not possible, please feel free to provide an answer explaining why. I'd be happy to mark as it accepted.
I'd like to slightly simplify the following code (two steps for an object "declaration", I'd like to have one):
var Masher = function(opts) {
this._name = opts.name;
};
Masher.prototype = Object.create(Object.prototype, {
_name: { writable: true },
name: { get: function() { return this._name; }}
});
// Note: (new Masher({name: 'bar'})).name == 'bar'
I would to create the entire function prototype in one shot with the constructor function appearing somewhere in the Object.create. Perhaps, something like this:
var Basher = Object.create(Function.prototype, {
_name: { writable: true },
name: { get: function() { return this._name; }},
constructor: { value: function(opts) { this._name = opts.name; }}
});
However, when I call new Basher(), I get: 'TypeError: object is not a function'.
Although I realize I could do this with syntactic sugar (a helper library), my goals here are to keep things as simple as possible and pick up some understanding of the JS object, prototype, constructor internals. I've tried to read as much on this as possible: SO related questions, Crockford, Ben Nadel, Joost Diepenmaat.
Perhaps I haven't found the correct formulation, or I'm fighting the design philosophy of Object.create, or the language doesn't allow this. Perhaps, this is really just a stylistic thing, and therefore, a conceit.
Of course, I can live with the two step process (Masher). There's something about packaging it all in one shot that feels right (Basher).
Is there a way to do this? Thanks.

If you want to use the class-based approach where you can call a constructor function with new, you will always have two parts:
The constructor function itself (to initialise instances)
The prototype object (for shared properties)
If you don't want to drop the prototype entirely, there is no JavaScript syntax to do both the function creation and the prototype setup in one go (apart from the new ES6 class syntax, of course) while still maintaining the .prototype link from the function to the prototype object. Of course, a trivial helper function (doesn't need to be a complete library) would do:
function Class(p) {
return (p.constructor.prototype = p).constructor;
}
var Casher = Class({
constructor: function(opt) { this._name = opt.name },
get name() { return this._name }
});
var foo = new Casher({name:'bar'});
This patterns doesn't really have a lot to do with Object.create at all (except you want your prototype inherit from another one).
So yes, maybe you are trying to fight the philosophy of Object.create, which is to use only objects and derive other objects from these (read the Wikipedia article on it and make sure to check out some example from languages other than JS). You would not have a constructor, and not a new operator - rather you'd call a create method on your object:
var Proto = { // some helper methods (usually native in more prototype-focused languages)
clone: function() {
return Object.create(this);
},
create: function(opt) {
var derived = this.clone();
derived.init(opt);
return derived;
},
init: function(opt) {
Object.getOwnPropertyNames(opt).forEach(function(p) {
Object.defineProperty(this, p, Object.getOwnPropertyDescriptor(opt, p));
}, this);
}
};
var Pasher = Proto.create({ // "subclass" Proto
init: function(opt) {
if ("name" in opt) this._name = opt.name;
},
_name: "",
get name() { return this._name; }
});
var foo = Pasher.create({name:'bar'});

Object.create() returns an object, not a function, with a specific prototypal inheritance chain defined.
var Basher = Object.create(Function.prototype, {
_name: { writable: true },
name: { get: function() { return this._name; }},
constructor: { value: function(opts) { this._name = opts.name; }}
});
> undefined
Basher
> Object {_name: undefined, name: (...)}_name: undefinedconstructor: function (opts) { this._name = opts.name; }name: (...)get name: function () { return this._name; }__proto__: function Empty() {}
> typeof Basher
"object"
You can, however, combine Object.create() and constructor functions to let you reuse object literals as APIs, which makes the code look a bit cleaner:
var basherAPI = {
name: function () {
return this._name;
}
};
function Basher(name) {
var inst = Object.create(basherAPI);
// assign instance *state* here; the API is
// reusable but each object needs its own state
inst._name = name;
return inst;
}
var basher = new Basher('Tom');
basher.name() // Tom
EDIT: In this case, using the new keyword is purely convention; it has NO bearing on what happens within the constructor function. One could also write: var basher = Basher('Tom');.

I'm putting an answer in here, but I'm not sure this fully answers my question, so I won't be marking it as the answer as I don't believe I completely understand this part of the JS language.
The closest I believe I can get to this is the following:
var Lasher;
(Lasher = function (opts) {
this._name = opts.name;
}).prototype = Object.create(Object.prototype, {
_name: { writable: true },
name: { get: function() { return this._name; }},
});
This formulation exposes part of what is going on, something to which #Bergi alluded, albeit briefly. First, note that it does not answer my question as it still requires two steps (Variable declaration and then Value assignment). It does get to the heart of my stylistic issue, which is to co-locate all of the object's declaration code. It does this by capturing the anonymous function definition (constructor) in Lasher, then referencing the prototype property in order to assign it the prototype object (the rest of the "class" declaration).
Although grouped together as one computational unit, visually it's harder to parse and fairly ugly, quite frankly. Also, the anonymous function might even capture Lasher in its scope (I'm not sure).
Incidentally, I tried this flawed approach. It's one statement, although still a bit ugly:
(function Crasher(opts) {
this._name = opts.name;
}).prototype = Object.create(Object.prototype, {
_name: { writable: true },
name: { get: function() { return this._name; }},
});
Too bad it doesn't work. Crasher is scoped to the first () and doesn't live in the outer scope, which is why the earlier code had to declare Crasher as a variable in order to capture the anonymous function.
The thing is, Lasher is not really simpler than Masher (above) from a line count or readability perspective. So, the original formulation stands as the best (so far).
Also, although I understand why Object.create cannot be used as it creates an Object, I guess I don't understand how the internal JS interpreter creates functions vs. Objects. What I mean is, a Function is an Object, but I guess there's no way to create a function that can be returned directly from Object.create. That's the primary problem.
In addition, whatever is going on inside of the prototype assignment and the constructor assignment within that, adding a constructor property in the Object.create doesn't work. We can see that with this bit of code:
var Masher = function(){ console.log("default");};
Masher.prototype = Object.create(Object.prototype, {
_name: { writable: true },
name: { get: function() { return this._name; }},
constructor: { value: function(opts) {
console.log("ctor");
this._name = opts.name;
return this;
}}
});
// "new Masher()" outputs:
// default
// undefined
So, if I understand some of this correctly, function creation and prototype creation on top of that have some deep relationships within the JS interpreter/compiler and the language does not provide a means to do what I am trying to do.

Backbone: annoying behaviour of prototype object

I understand this is a problem (or behaviour) of javascript itself rather than Backbone's extend method, but I'd like to know what is the best strategy to avoid it.
Let's better put it in code:
var MyModel = Backbone.Model.extend({
value: 0,
values: []
});
var myFirstModel = new MyModel();
myFirstModel.value // 0, as expected
myFirstModel.values // [], as expected
var mySecondModel = new MyModel();
mySecondModel.value = 2;
mySecondModel.values.push(2)
mySecondModel.value // 2, as expected
mySecondModel.values // [2], as expected
myFirstModel.value // 0, as expected
myFirstModel.values // [2], ... WAT!!!
I do understand that the problem is I'm not assigning a new value to mySecondModel.values I'm just operating on the values variable that is in the prototype, that is MyModel.prototype.values (same problem with any other object, of course)
But it's very easy to mess with that. The most intuitive thing is to just think of those as INSTANCE variables, and not variables common to every instance (static or class variables in class based languages).
So far now the general solution I've found is to initialize every variable in the initialize method, like this:
var MyModel = Backbone.Model.extend({
initialize: function() {
this.value = 0;
this.values = [];
}
});
That way everything works as expected, and even though it wouldn't be neccesary for a simple value (like this.value) I find it much easier to just stick to this prnciple in every case.
I'm wondering if there's some better (more elegant, clearer) solution to this problem

This is an effect of JavaScript's prototypical inheritance and the fact that Array objects are reference types. The key/value pairs of the object you pass to extend are copied onto the prototype of MyModel, so they will be shared by all instances of MyModel. Because values is an array, when you modify it, you modify the array for every instance.
What you are doing by setting values inside initialize is called shadowing the prototype, and it is the correct way to solve this issue.
That said, in the case of Backbone.Model, if you are attempting to deal with the model's attributes, you can use the defaults function to provide defaults like this:
var MyModel = Backbone.Model.extend({
defaults: function() {
return {
value: 0,
values: []
}
}
});
Again, this is only for attributes of an instance.
var inst = new MyModel();
// The defaults will be created for each new model,
// so this will always return a new array.
var values = inst.get('values');
For what you are doing, where you are specifying properties on the model itself, it is up to you to set the defaults inside of initialize, as you have done.

Are you intentionally not setting value and values as backbone attributes? If you set attributes on an instance, instead of putting them in the extended backbone model definition, it might work how you expect.
var MyModel = Backbone.Model.extend();
var myFirstModel = new MyModel({
value: 0,
values: []
});
console.log(myFirstModel.get('value'); // 0
console.log(myFirstModel.get('values'); // []
var mySecondModel = new MyModel({
value: 2,
values: [2]
});
//mySecondModel.value = 2;
//mySecondModel.values.push(2)
console.log(mySecondModel.get('value'); // 2
console.log(mySecondModel.get('values'); // [2]
console.log(myFirstModel.get('value'); // 0
console.log(myFirstModel.get('values'); // []
jsFiddle, check the console log.

I too had stumbled across this problem some time back and solved it by defining a defaults method in the model.
var MyModel = Backbone.Model.extend({
defaults: function() {
return {
value: 0,
values: []
}
}
});

How to reset na object property to the default one?

I am using jQuery and I am still pretty new to JavaScript. I am implementing an object as the following:
MyObject = {
properties : [{}],
resetProperties: function resetProperties() { this.properties = [{}] }
};
As you can see in the above code I can reset the properties by running MyObject.resetProperties() but, in order to do that, I state two times the [{}] variable. How should I accomplish the same thing without repeating that code?
Update
I tried to do the following:
MyObject = {
properties : this.propertiesDefault,
resetProperties : function resetProperties() { this.properties = [{}] },
propertiesDefault: [{}]
};
but I get "TypeError: invalid 'in' operand MyObject.properties" and I am not sure that is the right way to proceed.

It seems to me that it would be impossible to avoid having your default / reset properties as a separate object to the one that will be modified.
I would recommend having a default value, and cloning it in your initialisation and reset function. Since you tagged your question with jQuery, I assume you are happy to clone the object with that:
MyObject = {
defaultProperties : [{}],
properties : jQuery.extend(true, {}, this.defaultProperties),
resetProperties: function() {
this.properties = jQuery.extend(true, {}, this.defaultProperties);
}
};
See this Stack Overflow question for more information on cloning objects:
What is the most efficient way to deep clone an object in JavaScript?
This is the documentation for jQuery.extend:
http://docs.jquery.com/Utilities/jQuery.extend

From what I know this isn't possible. You're going to have to hard-code the property reset. I tried setting a variable cache outside the object, but when I reset the property it unfortunately maintains its value.
var obj = {
p: [ {} ],
r: function() { this.p = this.cache; }
};
obj.cache = obj.p; // attempt to set to original
obj.p[0].m = 5; // modify
obj.r(); // reset
--------
>>> obj.p[0].m; // 5
We can assume the the cache property is being modified in the same way as p is. Therefore, we can't reset like that.

Depends on what you want. Since you're new to javascript, you may be unfamiliar with using functions to create custom objects, which is the general javascript "OOP" kinda way to do it.
function MyObjectClass() {
this.properties = null;
this.resetProperties();
}
MyObjectClass.prototype.resetProperties = function () { this.properties = [{}] };
var MyObject= new MyObjectClass();
But we don't really know that function MyObject needs to fulfill. There may be a requirement that it NEEDs to be a plain old javascript object. Or maybe not, and you're done.
Of course, you can always directly:
MyObject = {
properties : null,
resetProperties: function () { this.properties = [{}];}
};
MyObject.resetProperties();