JavaScript reference to underlying native object in a Turbo Module

[Zach-Dean-Attractions-io]

Hi,

Suppose I am implementing a Turbo native module and as part of this I create some instance of a class in Kotlin(/Objective-C++)

class MyNativeClass(val name: String)

I also have a TypeScript representation of this class

export class MyJSClass {
    constructor(name: string) {}
}

Then if I had some function in in TypeScript that returned MyJSClass via a turbo native module, I could just return MyNativeClass.name from the native code and then in TypeScript wrap it in a new instance of MyJSClass.

However, this would then mean that the underlying instance of MyNativeClass that was created would be garbage collected since nothing is holding a reference to the instance of that class as only the name property was returned.

How would I go about maintaining the reference of the underlying MyNativeClass in TypeScript so that only when the reference is garbage collected in TypeScript does the underlying native value get garbage collected?

Do I need to implement a HostObject in the C++ layer to maintain the reference?

If this is possible I assume that this is only supported in the new architecture and the legacy architecture wouldn't support this? (Maybe it might on Android). (For React Native 0.76.0+)

Is there any documentation I can find on this?

[cortinico]

However, this would then mean that the underlying instance of MyNativeClass that was created would be garbage collected since nothing is holding a reference to the instance of that class as only the name property was returned.

Your native module should hold a reference to MyNativeClass (and so manage its lifecycle) so it doesn't get garbage collected.

[Zach-Dean-Attractions-io]

We've had a couple of thoughts about this. The methodology we will probably go with is a reference tracking system where the native code would generate some id, when creating a native object instance we want to prevent from being destroyed, and store that id alongside the native object instance created and pass that id back into TypeScript. Then when the TypeScript object is garbage collected it would return that id back into the native code where it could remove that id from it's reference tracking system and allow the native object instance to be destroyed if no other references to that object existed. I think this should work independent of the chosen architecture.

However, we were also thinking about a methodology where the TypeScript class instance created would hold a reference to the underlying native object instance preventing it from being destroyed until the TypeScript instance was garbage collected. I am still early on in my research for this but I think we would have a C++ HostObject, which I could then return to JavaScript using a JavaScript object. This would hold a reference to the C++ HostObject instance created (possibly we would utilise a shared_ptr when attaching the HostObject instance to the JavaScript object). Then when the JavaScript object is garbage collected, that reference to the HostObject would be lost and then the HostObject instance created would have no more references and so the HostObject instance would be deallocated. If this methodology is possible then it would abstract away the manual memory management of the reference tracking system. There would also need to be some glue in the HostObject to maintain a strong reference to Java/Kotlin & Objective-C classes it would create (I've not thought that far yet).

I think this idea is mentioned in this talk Phillip Pan – React Native under the hood | App.js Conf 2024 between 9:14 and 9:56.