[Feature Request] API for `jsi::Symbol::wellKnown(...)` - e.g. `Symbol.dispose`

[mrousavy]

Problem

Currently it's super hard to expose a native property using a Symbol as a name. Symbols are generally pretty impossible to work with on the native side.

For example, in ES2023 (ES14) the Symbol.dispose (and the using ... syntax) was introduced in JS. In Nitro I actually have dispose() methods for every HybridObject, but they are literally just methods exposed under a property that has the string key "dispose".

I would want to expose them using the Symbol.dispose key, which is a well-known symbol.

In JSI, there is no way to achieve this unless you use eval or global().
This would be the current solution in JSI:

auto symbol = runtime.global().getPropertyAsObject(runtime, "Symbol");
auto dispose = symbol.getProperty(runtime, "dispose").asSymbol(runtime);

Solution

Would be super useful if we could add jsi::Symbol::wellKnown(...), which would be a more convenient way of looking up well-known Symbols, and potentially also a faster, cached way of doing so.

auto dispose = jsi::Symbol::wellKnown(runtime, "dispose");

Additional Context

There's many well known Symbols in JS - with this new API, overriding some of those symbols on native objects would be much easier - e.g. Symbol.toStringTag (for toString()), Symbol.iterator (for loops), Symbol.hasInstance (for instanceof), and more.

[tmikov]

Interesting. This seems like a good idea, but I am not actually sure how much faster wellKnown() would be in practice. Is this more about convenience or performance?

Also, should it support symbols that are not builtin? We don't support Symbol.dispose yet, so I am assuming that it is being added by a polyfill. Should this method be able to return that?

If the answer is yes, then the implementation would literally have to be the code you already wrote or something very close to it.

[mrousavy]

Is this more about convenience or performance?

I guess both. Convenience would be easy to achieve with a simple helper method (and some enums) I can create myself.
This isn't a super hot-path in my code anyways, it's only hit for prototype creation.

the implementation would literally have to be the code you already wrote or something very close to it

Yea I figured that Symbol.dispose will probably be polyfilled and therefore looked up from JS anyways.
We could do that as a fallback/slow-path if Hermes doesn't have it builtin? And if that fails too, we throw an error.

I'll let you decide if you want to have this in JSI/Hermes, I can help with adding this to JSI in react-native

[mrousavy]

On another note; We do have jsi::Object::create, jsi::Object::setPrototype, but we do not have jsi::Object::defineProperty - that one seems like it could benefit from a native/C++ implementation (both from a convenience perspective, and from a performance perspective since it involves getting Object from global, getting the defineProperty function and creating a jsi::Object for the third argument (descriptor))

I use defineProperty quite a lot in Nitro.

Wdyt?

[tmikov]

FWIW, Symbol.dispose is not part of the spec yet, but it will be soon.

This is simple enough feature that would be perfect for a simple non-controversial PR that we would gladly accept, as long we agree on the API first. Let me discuss this with the team.

I agree about Object::defineProperty() too. It should be very simple to implement.

[wcandillon]

I can concur that it will be nice to have Symbol.dispose available instead of us or the user needing to define it. We implement explicit resource management in Skia.

[mrousavy]

You don't need eval - just get Symbol from global(), then .dispose.