Support for structuredClone

[Andarius]

Problem

To deep clone an object today, one can either use JSON.stringify or lodash.cloneDeep. There is no dedicated way of creating a deep copy in an efficient manner.

Solution

A solution could be implementing: structuredClone (see https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)

[ljharb]

structuredClone isn’t part of the language; but it may be in the medium term. Currently, it’s a web api, so I’m not sure it makes sense for Hermes to have it.

[tmikov]

I think one way to look at this is, is it provided by the engine or the browser? For example, is it available in Node?

[ljharb]

node does not provide it currently. If they did, it'd be like setTimeout, where they're mirroring the browser without a spec compelling them to do so.

[migueldaipre]

Hey guys, In node v17 it is already present, doesn't it make sense to have it in Hermes too?
https://nodejs.org/en/blog/release/v17.0.0/

[joe-sam]

structuredClone is now supported in the facebook/jest and facebook/lexical repository.
Right now the only way is 3d party libs which often don't work correctly or the spread operator which only does a shallow copy.

[cjshearer]

I'd love to see this in react-native. structuredClone is available in the majority of other environments and provides significant performance advantages over js implementations that don't have direct memory access.

[tmikov]

Note that in each case structuredClone() doesn't seem to be provided by the engine itself, instead it is provided by the integration (the browser, etc). At least my experiments with all the engines available for mac64arm from jsvu show that it isn't available in any.

People commonly confuse the browser with the engine itself. This has been a common topic in several issues submitted here, where users are requesting APIs that are not part of the EcmaScript spec. I have suggested that it might make sense to create community "integration" repository for such extensions, but there has been no interest.

With all that said, admittedly, an implementation of structuredClone() based on JSI would likely be significantly slower than one using internal Hermes APIs. So, theoretically there would be some value in a built-in implementation. The problem is that builtin APIs change all the time and increasing the usage area increases the maintenance cost.

Since Hermes will have a stable release schedule starting with the next release, it might make sense to allow external users of internal APIs, and a way to package and distribute them conveniently. In this way it would be possible to maintain efficient Hermes-specific extensions, with some cost per-release, without making them part of Hermes itself.

[tmikov]

FYI #1072