better structuredClone support

[jimmywarting]

I have created this page to test out how good some packages are at mimicing structuredClone and also testing out how fast and efficent they are

https://jimmywarting.github.io/3th-party-structured-clone-wpt

Maybe you want imporove the score...?

[rvagg]

oh, very interesting! I think I can slightly improve the score with an encode option: { mapSorter: null } to override the default CBOR map sorting function; other than that the other items in the list are outside of the design goals of this library since its primary purpose is deterministic encoding forms and making novel CBOR tags pluggable (i.e. if you want Date, RegExp etc. then you bring your own tag plugin). Maybe something to work on because I export some basic tag plugins here; I just don't have the need for it.

Thanks for doing this though, perhaps I'll add a link on the README to it.

[jimmywarting]

I'm just wondering how come that when running decode(encode(1n)) equals to 1 and not 1n?

[jimmywarting]

Also if i would like to add a own Blob/File tag plugin then it would have to read the file in a async manner...
is there any possibility to encode/decode things in a async manner and await a result?

everything looks pretty sync to me in this package

[jimmywarting]

i think that cbor also has references support? no?

i mean this example:

var input = Array(2).fill({})
var clone = decode(encode(input))
console.assert(clone => clone !== input)
console.assert(clone => clone[0] === clone[1])
console.assert(clone => clone[0] !== input[0])

it should pass?

[rvagg]

I'm going to leave this open for now but with this note: this problem set is out of scope for core cborg functionality where we are focusing on content addressing style data, not JS round-trip fidelity (we're actually aiming for cross platform compatibility more than the JS focus). i.e. this is not designed for full JavaScript object serialisation, it's designed for a much more restricted data model.

But, getting closer to structuredClone style round-tripping would not be too much of a stretch for a side package, or extra module, like the json export here that is a full JSON encoder/decoder using cborg internals. We could have a structured clone style export that wraps cborg in the necessary tag handlers to do a fairly good JS object round-trip.

I'm not sure about the reference preservation though, that seems like a bit too much of a stretch. Achievable and there's a tag for it but I don't love the idea.

[rvagg]

Couldn't help it, here's a go at adding extended types and getting closer to a structured clone style support: #168, and the linked test page was quite helpful at narrowing some of the finer details so thanks for that @jimmywarting. cborg/extended would get a healthy 363 score on there.

Going to sit on that PR for a bit, it's got a breaking change that I'm not sure yet if I'm comfortable with.