If classes contain all the "super powers" and their instance handle their
own states it's straight forward to serialize JS these days following basic
conventions (easy to do with poisoned objects)
```js
class Serializable {
// usable as JSON.parse(str, Serializable.fromJSON)
static fromJSON(key, value) {
if (value.hasOwnProperty('__proto__')) {
const Class = value.__proto__.split('.').reduce(
(o, k) => o[k],
typeof global === 'object' ? global : window
);
delete value.__proto__;
return Object.create(Class.prototype, value);
}
return value;
}
// provide a way to retrieve your class back
// from a namespace
static toJSON() {
return this.name;
}
// serialize any instance
toJSON() {
return Object.defineProperty(
Object.getOwnPropertyDescriptors(this),
'__proto__',
{
enumerable: true,
value: this.constructor.toJSON()
}
);
}
}
```
Assuming the class is somehow reachable, something that is an issue with
any other language too (the class must be available to properly unserialize)
```js
window.Anything = class Anything extends Serializable {
constructor(pub, acc) {
super();
this.public = pub;
this.accessor = acc;
}
get accessor() {
return this._private;
}
set accessor(value) {
Object.defineProperty(this, '_private', {
configurable: true,
value
});
}
};
```
you can serialize and unserialize instances with ease:
```js
const before = new Anything(123, 456);
const serialized = JSON.stringify(before);
const after = JSON.parse(serialized, Anything.fromJSON);
console.log(
after.public,
after.accessor
);
```
There are also battle tested utilities to make recursive properties
serializable too (CircularJSON to name one).
Yet, what everyone serliazes and unserializes instead, is some data any
instance could eventually consume so having full classes/instances there
doesn't apparently bring much value.
Serialization is IMO one of those things when you come from capable
langauges you apparently cannot live without, but you forget on your way
with JS and its debugging ability across various environments.
Regards
On Mon, Nov 27, 2017 at 8:17 PM, Florian Bösch <pya...@gmail.com> wrote:
> On Thu, Nov 2, 2017 at 4:43 AM, kai zhu <kaizhu...@gmail.com> wrote:
>
>> > the primary reason is because traditional oop skills gained from
>> c#/c++/java/python/etc translate poorly to javascript.
>>
> I've never found that to be the case.
>
> >in javascript, class-instantiated objects are inferior to plain-objects,
>> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
>> classes require needless extra serialization/deserialization routines which
>> can easily double your codebase or more (as real-world javascript-code is
>> heavily i/o based). i would say many people burn-out from
>> frontend-programming because they can’t cope with debugging all the i/o
>> edge-cases serializing/deserializing their custom classes.
>> >
>> >javascript and frontend-programming is essentially about efficiently
>> managing the program-state like a baton, constantly passing it
>> back-and-forth between the browser’s ui and various backend-servers /
>> persistent-storage. plain json-objects utilizing idiot-proof
>> JSON.stringify/JSON.parse, are naturally better at this baton-passing
>> business than writing classes with custom serializers.
>>
> I dislike many things about JS, and I've been writing JS since 2002. It
> never occured to me, not once, until 3 minutes ago, that this was in any
> way, shape or form some significant JS disadvantage, primary concern of
> anything or even any sort of impediment.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
