DBMS for IndexedDB engine, based on Rx principles (type safety, resilience, backpressure, user friendly (reduces all Idb CRUD features to 4 API methods)
Any class that extends js.Any can be serialised to IndexDB, as pointed out by @sjrd on the scalajs mailing list Structured Cloning thread.
upickle is quite inefficient regarding structured cloning at present, and is problematic for serialising special objects like opaque objects produced by WebCrypto: see issue 127 of upickle and issue #3 in this rep. It seems unlikely that upickle will be changed soon to change that, as it would require quite a lot of rewrite of the macro library, which is not easy to do.
One answer is to only allow JS classes to be serialised to disk, that is classes that extend js.Any. That would reduce the dependence on upickle, and make the code a lot simpler. For a programmer that may mean building special classes for serialisation or writing a mapper to map scala classes (ie. ones that do not extend js.Any) The programmer could then choose what library to use: upickle being in many cases a very good choice.
Any class that extends
js.Any
can be serialised to IndexDB, as pointed out by @sjrd on the scalajs mailing list Structured Cloning thread.upickle is quite inefficient regarding structured cloning at present, and is problematic for serialising special objects like opaque objects produced by WebCrypto: see issue 127 of upickle and issue #3 in this rep. It seems unlikely that upickle will be changed soon to change that, as it would require quite a lot of rewrite of the macro library, which is not easy to do.
One answer is to only allow JS classes to be serialised to disk, that is classes that extend
js.Any
. That would reduce the dependence on upickle, and make the code a lot simpler. For a programmer that may mean building special classes for serialisation or writing a mapper to map scala classes (ie. ones that do not extendjs.Any
) The programmer could then choose what library to use: upickle being in many cases a very good choice.