- From: Brett Zamir <notifications@github.com>
- Date: Wed, 02 Oct 2024 00:45:24 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/224/2387829791@github.com>
> I think it would be bad to base this on json when indexeddb can store so much more than json types. So importing/exprting databases would be problematic for dates, blob/files, typedarrays, BigInts, Infinity, circular refs, and everything else that can be strucutred structural cloned. FWIW, [`typeson-registry`](https://github.com/dfahlander/typeson-registry) uses, through its structured cloning preset, a form of JSON, [`typeson`](https://github.com/dfahlander/typeson), to encode structured cloning data, supporting cyclic data and all of the above-mentioned structured cloning types and more (though a handful of the newer types at https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#webapi_types are indeed not presently supported). As @inexorabletash suggested, this indeed requires a particular serialization of JSON with an out-of-band section (within the JSON itself, in the case of typeson) tracking which parts correspond to which types. This doesn't address the smaller size or greater performance that a binary format could provide, but just a FYI on how the structured types issue can at least be overcome by a form of JSON. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/224#issuecomment-2387829791 You are receiving this because you are subscribed to this thread. Message ID: <w3c/IndexedDB/issues/224/2387829791@github.com>
Received on Wednesday, 2 October 2024 07:45:28 UTC