Realised last night that JavaScript Database (JSDB) doesn’t run the constructor on persisted custom objects (https://codeberg.org/small-tech/jsdb#custom-data-types) when deserialising them because I didn’t know that you apparently have to define your constructor manually when using Object.create().
Will fix it today but it’s something to watch out for if you’re using Object.create() directly.
For more info, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create
#JSDB #customObjects #constructor #bug #JavaScript #NodeJS #SmallTech #SmallWeb
jsdb
A zero-dependency, transparent, in-memory, streaming write-on-update JavaScript database for the Small Web that persists to a JavaScript transaction log.Codeberg.org
This entry was edited (3 weeks ago)
Aral Balkan
in reply to Aral Balkan • • •Just a quick update on this: after some experimentation and further thought, I feel the way JSDB works currently is the right trade-off.
While it could run the constructor of persisted custom objects when loading them back in, that would impose a rigid authoring flow that would sacrifice ease of use for simple use cases. I find the latter more important in this case.
(I’m off to document this ‘feature’ now as it is currently undocumented and that’s not good.) :)
More: https://codeberg.org/small-tech/jsdb/issues/12
Custom objects: constructors are not being run
Codeberg.orgCat Herder
in reply to Aral Balkan • • •a
Aral Balkan
in reply to Aral Balkan • • •I’ve thought a bit more on this and decided:
1. Persisting custom classes _is_ an advanced feature.
2. Implementing these changes would mean that custom classes can extend base classes (e.g., EventEmitter, so we can, for example, listen for events on sessions in Kitten)
3. The con of dictating the constructor signature for custom classes is outweighed by the pros.
So I just implemented this, plus pseudo-private property support, etc., and will be releasing a new major version of JSDB soon.