Develop Reference

How to serialize a javascript object into json file that include all Class methods? [duplicate]

I am new to "object-oriented" JavaScript. Currently, I have an object that I need to pass across pages. My object is defined as follows:
function MyObject() { this.init(); }
MyObject.prototype = {
property1: "",
property2: "",
init: function () {
this.property1 = "First";
this.property2 = "Second";
},
test: function() {
alert("Executing test!");
}
}
On Page 1 of my application, I am creating an instance of MyObject. I am then serializing the object and storing it in local storage. I am doing this as shown here:
var mo = new MyObject();
mo.test(); // This works
window.localStorage.setItem("myObject", JSON.stringify(mo));
Now, on Page 2, I need get that object and work with it. To retrieve it, I am using the following:
var mo = window.localStorage.getItem("myObject");
mo = JSON.parse(mo);
alert(mo.property1); // This shows "First" as expected.
mo.test(); // This does not work. In fact, I get a "TypeError" that says "undefined method" in the consol window.
Based on the outputs, it looks like when I serialized the object, somehow the functions get dropped. I can still see the properties. But I can't interact with any of my functions. What am I doing wrong?

JSON doesn't serialize functions.
Take a look at the second paragraph here.
If you need to preserve such values, you can transform values as they are serialized, or prior to deserialization, to enable JSON to represent additional data types.
In other words, if you really want to JSONify the functions, you can convert them to strings before serializing:
mo.init = ''+mo.init;
mo.test = ''+mo.test;
And after deserializing, convert them back to functions.
mo.init = eval(mo.init);
mo.test = eval(mo.test);
However, there should be no reason to do that. Instead, you can have your MyObject constructor accept a simple object (as would result from parsing the JSON string) and copy the object's properties to itself.

Functions can not be serialized into a JSON object.
So I suggest you create a separate object (or property within the object) for the actual properties and just serialize this part.
Afterwards you can instantiate your object with all its functions and reapply all properties to regain access to your working object.
Following your example, this may look like this:
function MyObject() { this.init(); }
MyObject.prototype = {
data: {
property1: "",
property2: ""
},
init: function () {
this.property1 = "First";
this.property2 = "Second";
},
test: function() {
alert("Executing test!");
},
save: function( id ) {
window.localStorage.setItem( id, JSON.stringify(this.data));
},
load: function( id ) {
this.data = JSON.parse( window.getItem( id ) );
}
}

To avoid changing the structure, I prefer to use Object.assign method on object retrieval. This method merge second parameter object in the first one. To get object methods, we just need an empty new object which is used as the target parameter.
var mo = window.localStorage.getItem("myObject");
// this object has properties only
mo = JSON.parse(mo);
// this object will have properties and functions
var completeObject = Object.assign(new MyObject(), mo);
Note that the first parameter of Object.assign is modified AND returned by the function.

it looks like when I serialized the object, somehow the functions get dropped... What am I doing wrong?
Yes, functions will get dropped when using JSON.stringify() and JSON.parse(), and there is nothing wrong in your code.
To retain functions during serialization and deserialization, I've made an npm module named esserializer to solve this problem -- the JavaScript class instance values would be saved during serialization on Page 1, in plain JSON format, together with its class name information:
var ESSerializer = require('esserializer');
function MyObject() { this.init(); }
MyObject.prototype = {
property1: "",
property2: "",
init: function () {
this.property1 = "First";
this.property2 = "Second";
},
test: function() {
alert("Executing test!");
}
}
MyObject.prototype.constructor=MyObject; // This line of code is necessary, as the prototype of MyObject has been overridden above.
var mo = new MyObject();
mo.test(); // This works
window.localStorage.setItem("myObject", ESSerializer.serialize(mo));
Later on, during the deserialization stage on Page 2, esserializer can recursively deserialize object instance, with all types/functions information retained:
var mo = window.localStorage.getItem("myObject");
mo = ESSerializer.deserialize(mo, [MyObject]);
alert(mo.property1); // This shows "First" as expected.
mo.test(); // This works too.

That's because JSON.stringify() doesn't serialize functions i think.

You're right, functions get dropped. This page might help:
http://www.json.org/js.html
"Values that do not have a representation in JSON (such as functions and undefined) are excluded."

Knockout mapping - difference between objects and observables in class being mapped to

This is driving me absolutely insane, and I just cannot see what I have done wrong. Please help before I start bibbling and gnawing my colleagues leg off. He doesn't deserve that.
I have an object I am mapping, which has a property that can or cannot contain an object of that same type. That is the only level of nesting there is. It is very simple; it is complicated only by the fact that the object is calling a base class constructor to set some default behaviour.
This base class sets up all the fields that can appear in the model (it is a generated file) and then maps the datasource, if it has one.
The mapping of the nested field to the correct constructor works if the field is set up initially as an observable. It does not if it is set up as a plain object.
var NS = {};
var _itest = 0;
NS.FieldModelBase = function(data, mapping)
{
var _this = this;
this.Text = ko.observable();
// DOES NOT WORK
this.AlternateField = {};
// WORKS
//this.AlternateField = ko.observable();
ko.mapping.fromJS(data, mapping, _this);
};
// =====================================================================
NS.FieldModel = function(data, mapping, parent)
{
var _this = this;
window.console && console.log('CREATING FIELD', data);
var _mapping = $.extend({}, mapping, {
'include': [ 'Test' ],
'AlternateField': {
create:
function(o)
{
window.console && console.log('FOUND SUBFIELD', o.data);
return o.data ? new NS.FieldModel(o.data) : null;
}
}
});
this.Test = ko.observable(_itest++);
NS.FieldModelBase.call(_this, data, _mapping);
}
// =====================================================================
var model = new NS.FieldModel({
Text: "Main option",
AlternateField: {
Text: "Alternate option",
AlternateField: null
}
}, { include: [ 'Test' ] });
ko.applyBindings(model);
https://jsfiddle.net/whelkaholism/fkr0w98u/
So, when setup as an object, printing model out after running the code gives:
{"Test":0,"Text":"Main option","AlternateField":{"Text":"Alternate option","AlternateField":null}}
There is no Test property on the alternate field. If you check the console, what happens is that the mapping create is in fact called, but the o.data property is null.
Change to an observable, and the output is, as expected:
{"Test":0,"Text":"Main option","AlternateField":{"Test":1,"Text":"Alternate option","AlternateField":null}}
So, what is the mapping plugin doing here? It was my understanding that it would map everything in source data, regardless of the existence or type of any existing properties on the object?
EDIT: I have solved my immediate problem with this change:
NS.FieldModel = function(data, mapping, parent)
{
var _this = this;
var _mapping = {
copy: [ 'AlternateField' ]
};
NS.FieldModelBase.call(_this, data, _mapping);
this.AlternateField = data.AlternateField ? new NS.FieldModel(data.AlternateField, null, _this) : null;
}
This manually creates the correct object type for the alternate field after the mapping. The copy directive in the mapping is absolutely required, or the newly created object has no properties mapped.
I don't now why this is, so I'm still looking for the answer on why the mapping plugin works differently depending on the content of pre-existing variables, because I despise having code that I don't know exactly why it works!

The mapping plugin maps only values, not objects e.g.
"myString" => ko.observable("myString")
null => ko.observable(null)
{ myStringProperty: "myString" } => { myStringProperty: ko.observable("myString") }
{ myProperty: null } => { myPropery: ko.observable(null) }
{} => {}

Declaring variables on a backbone model without setting defaults

I'm just starting out with backbone.js and I'm looking for a way of declaring fields on a model without having to provide defaults. It's really just for reference, so that when I start creating instances, I can see what fields I need to initialize.
With something like java I'd write
public class CartLine{
StockItem stockItem;
int quantity;
public int getPrice(){
return stockItem.getPrice() * quantity;
}
public int getStockID(){
//
}
}
However with backbone models, I'm referencing the fields in my method's but I'm not actually declaring them - It looks like I could easily create a CartLine object that doesn't contain a stockItem attribute or a quantity attribute. It feels strange not to mention the fields when I declare the object. Particularly as the object is supposed to represent an entity on the server.
var CartLine = Backbone.Model.extend({
getStockID: function(){
return this.stockItem.id;
},
getTotalPrice: function() {
return this.quantity * this.StockItem.get('price');
}
});
I guess I can add some sort of reference by using validate -
CartLine.validate = function(attrs){
if (!(attrs.stockItem instanceof StockItem)){
return "No Valid StockItem set";
}
if (typeof attrs.quantity !== 'number'){
return "No quantity set";
}
}
But my question is - am I missing something? Is there an established pattern for this?

The defaults are really for "fields" or data that is transferred back and forth from the server as part of the json.
If you just want to create some member variables as part of the Model, which are proprietary and not going to be sent back and forth to the server, then you can declare them a) on the object itself or b) in the initialize method (called during construction), and they can be passed in as part of opts:
var Widget = Backbone.Model.extend({
widgetCount: 0,
defaults: {
id: null,
name: null
}
initialize: function(attr, opts) {
// attr contains the "fields" set on the model
// opts contains anything passed in after attr
// so we can do things like this
if( opts && opts.widgetCount ) {
this.widgetCount = opts.widgetCount;
}
}
});
var widget = new Widget({name: 'the blue one'}, {widgetCount: 20});
Keep in mind that if you declare objects or arrays on the class, they are essentially constants and changing them will modify all instances:
var Widget = Backbone.Model.extend({
someOpts: { one: 1, two: 2},
initialize: function(attr, opts) {
// this is probably not going to do what you want because it will
// modify `someOpts` for all Widget instances.
this.someOpts.one = opts.one;
}
});

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: []
}
}
});

Difference between knockout View Models declared as object literals vs functions

In knockout js I see View Models declared as either:
var viewModel = {
firstname: ko.observable("Bob")
};
ko.applyBindings(viewModel );
or:
var viewModel = function() {
this.firstname= ko.observable("Bob");
};
ko.applyBindings(new viewModel ());
What's the difference between the two, if any?
I did find this discussion on the knockoutjs google group but it didn't really give me a satisfactory answer.
I can see a reason if I wanted to initialise the model with some data, for example:
var viewModel = function(person) {
this.firstname= ko.observable(person.firstname);
};
var person = ... ;
ko.applyBindings(new viewModel(person));
But if I'm not doing that does it matter which style I choose?

There are a couple of advantages to using a function to define your view model.
The main advantage is that you have immediate access to a value of this that equals the instance being created. This means that you can do:
var ViewModel = function(first, last) {
this.first = ko.observable(first);
this.last = ko.observable(last);
this.full = ko.computed(function() {
return this.first() + " " + this.last();
}, this);
};
So, your computed observable can be bound to the appropriate value of this, even if called from a different scope.
With an object literal, you would have to do:
var viewModel = {
first: ko.observable("Bob"),
last: ko.observable("Smith"),
};
viewModel.full = ko.computed(function() {
return this.first() + " " + this.last();
}, viewModel);
In that case, you could use viewModel directly in the computed observable, but it does get evaluated immediate (by default) so you could not define it within the object literal, as viewModel is not defined until after the object literal closed. Many people don't like that the creation of your view model is not encapsulated into one call.
Another pattern that you can use to ensure that this is always appropriate is to set a variable in the function equal to the appropriate value of this and use it instead. This would be like:
var ViewModel = function() {
var self = this;
this.items = ko.observableArray();
this.removeItem = function(item) {
self.items.remove(item);
}
};
Now, if you are in the scope of an individual item and call $root.removeItem, the value of this will actually be the data being bound at that level (which would be the item). By using self in this case, you can ensure that it is being removed from the overall view model.
Another option is using bind, which is supported by modern browsers and added by KO, if it is not supported. In that case, it would look like:
var ViewModel = function() {
this.items = ko.observableArray();
this.removeItem = function(item) {
this.items.remove(item);
}.bind(this);
};
There is much more that could be said on this topic and many patterns that you could explore (like module pattern and revealing module pattern), but basically using a function gives you more flexibility and control over how the object gets created and the ability to reference variables that are private to the instance.

I use a different method, though similar:
var viewModel = (function () {
var obj = {};
obj.myVariable = ko.observable();
obj.myComputed = ko.computed(function () { return "hello" + obj.myVariable() });
ko.applyBindings(obj);
return obj;
})();
Couple of reasons:
Not using this, which can confusion when used within ko.computeds etc
My viewModel is a singleton, I don't need to create multiple instances (i.e. new viewModel())