Add BindingsInstaller for TurboModules on iOS

[Kudo]

Summary:

Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
Re-create from #43110 but for iOS

Changelog:

[IOS] [ADDED] - Add BindingsInstaller for TurboModules

Test Plan:

Added test in RN-Tester TurboModule test case

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	19,495,560	-45,615
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	22,867,614	-44,415
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: 26fc40d
Branch: main

[RSNara]

@Kudo, I think there might be another way to accomplish this.

What if we could initialize c++ modules with (application or react native)-provided java/objc dependencies? Would that be enough to fulfill your use-case? Also, to confirm, is this your use-case: We need to expose a jsi::HostFunction to javascript, that allows us to reach into java objects, and do java things, right?

There is a way to extend the C++ turbomodule infra, like how I described:

1. Everyone registers their C++ turbomodules using CxxReactPackages (java <-> c++ hybrid objects).
2. We extend auto-linking to pick up, coalesce, and register CxxReactPackages (like how it does ReactPackages).

This makes registering c++ only modules a bit harder. Right now, you just drop them into your code-base. But, c++ modules are already an advanced feature, that we only expect advanced users to use. So, maybe it's fine.

[philIip]

i think we have to be careful on this one, if requiresMainQueueSetup is true, then this might not be safe. we can use the callInvoker but that won't block. we can also document and just say this API is incompatible with main thread set up modules. what do you think?

[philIip]

so this is probably the thing i'm the most iffy about. the thing is in the new arch code is that we never capture the runtime pointer, and this now will break that paradigm. i realized looking at your PR that android can avoid this bc they actually do their installation via runtime executor

instead of capturing this, what about passing it down through provideTurboModule? that flow is triggered via installJSBindings. that way we don't have to have an additional strong reference to the runtime here

the thing is, the callstack for _createAndSetupObjCModule is kinda complex. but i looked into this - i think ultimately at every path, we have thread safe access to the runtime pointer.

in _invalidateModules, we only initialize the module to finish any side effects, i believe to avoid some races with invalidation. this seems like a pretty extreme edge case?

[Kudo]

good catching @philIip! i've passed runtime to provideTurboModule: without storing the runtime in the class. also moving the installation earlier and right after getTurboModule:. that's a point to ensure running on js thread, even requiresMainQueueSetup is true.

aside from that, i think on ios and android implementation now still passing runtime pointer (android / ios). do you think whether this would be a concern? at least at provideTurboModule: and createTurboModuleProvider(), this is when people call TurboModuleRegistry.get() from js, so runtime should be valid at this point.
we could maybe turn RuntimeExecutor into BindingsInstaller without passing runtime, but we would at least need an UnbufferedRuntimeExecutor. Otherwise it may be too late to install the js bindings.

[philIip]

@Kudo, I think there might be another way to accomplish this.

What if we could initialize c++ modules with (application or react native)-provided java/objc dependencies? Would that be enough to fulfill your use-case? Also, to confirm, is this your use-case: We need to expose a jsi::HostFunction to javascript, that allows us to reach into java objects, and do java things, right?

There is a way to extend the C++ turbomodule infra, like how I described:

1. Everyone registers their C++ turbomodules using CxxReactPackages (java <-> c++ hybrid objects).
2. We extend auto-linking to pick up, coalesce, and register CxxReactPackages (like how it does ReactPackages).

This makes registering c++ only modules a bit harder. Right now, you just drop them into your code-base. But, c++ modules are already an advanced feature, that we only expect advanced users to use. So, maybe it's fine.

i think everyone is aligned with you on this being a nice north star for C++ TM, but this native hook can be seen as an intermediate step. and if implemented properly, this native hook should add minimal surface to our API surface area, and as u said it's an advanced use case - so is it worth all of the effort to build autolinking, etc. for < 10 libs? not sure yet

i also responded to ur internal WP comment ! let's chat further if needed :)

[Kudo]

apply review comments to the pr and split android implementation to #44526 as requested.
though GH doesn't support stacked prs, the two commits are cloned:

• 82bc87c
• f34d530

[facebook-github-bot]

@philIip has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@philIip merged this pull request in bed487e.

[github-actions]

This pull request was successfully merged by @Kudo in bed487e.

^{When will my fix make it into a release? | How to file a pick request?}