Adds option for non-ABI TurboModule provider #12383
Conversation
rozele
force-pushed
the
nonAbiTurboModuleProvider
branch
3 times, most recently
from
40d3f4c
to
68dc99a
Compare
| std::shared_ptr<implementation::HostObjectWrapper> m_hostObjectWrapper; | ||
| std::shared_ptr<facebook::jsi::HostObject> m_nonAbiHostObject; |
There was a problem hiding this comment.
Up for debate, but we could presumably just have one shared_ptr here, since implementation::HostObjectWrapper derives from facebook::jsi::HostObject
| "alternate interface to type check against.") | ||
| interface IJsiNonAbiHostObject { | ||
| DOC_STRING("Gets a value indicating whether the object has a value. This is just a dummy method to avoid issues with empty interfaces in C++/WinRT.") | ||
| Boolean HasValue { get; }; |
There was a problem hiding this comment.
@acoates-ms do you have any pointers to where I should add a GUID to avoid this dummy property?
Also, do you have any suggestions for how we can shove a C++ TurboModule into an IInspectable (to match the IReactModuleBuilder delegate type) and be able to query some interface to decide that it's actually a JsiNonAbiHostObject? If so, we won't need this IDL. Bear in mind that IReactNonAbiValue is already "taken" for NM2 modules.
There was a problem hiding this comment.
How to add a guid, to remove the dummy property:
https://github.com/microsoft/react-native-windows/blob/20a4c9b10681bef32c245066c1bb170e0d60dd5e/vnext/Microsoft.ReactNative/CompositionSwitcher.idl#L25C8-L25C8
rozele
force-pushed
the
nonAbiTurboModuleProvider
branch
from
68dc99a
to
089e540
Compare
marlenecota
force-pushed
the
nonAbiTurboModuleProvider
branch
from
089e540
to
abee2eb
Compare
For react-native-windows apps that bypass the JsiAbiApi when initializing a JS runtime, it would be useful to use the same module provider infrastructure used for other modules in react-native-windows. Today the only two options are: 1. Use attributed native modules 2. Use C++ TurboModules wrapped in JsiHostObjectWrappers This adds a third option: 3. Use C++ TurboModules wrapped in an IJsiNonAbiHostObject The main reason for creating IJsiNonAbiHostObject and not repurposing IReactNonAbiValue is that there is already a baked in assumption in the TurboModule provider that assumes all IReactNonAbiValues are attributed native modules, so a new interface is needed.
rozele
force-pushed
the
nonAbiTurboModuleProvider
branch
from
609ffd0
to
ce29f05
Compare
Description
Type of Change
Erase all that don't apply.
Why
For react-native-windows apps that bypass the JsiAbiApi when initializing a JS runtime, it would be useful to use the same module provider infrastructure used for other modules in react-native-windows.
Today the only two options are:
What
This adds a third option:
3. Use C++ TurboModules wrapped in an IJsiNonAbiHostObject
The main reason for creating IJsiNonAbiHostObject and not repurposing IReactNonAbiValue is that there is already a baked in assumption in the TurboModule provider that assumes all IReactNonAbiValues are attributed native modules, so a new interface is needed.
Testing
Integrated this change into our React Native Windows app, and we were able to use IJsiNonAbiTurboModule instances.
Changelog
Should this change be included in the release notes: no
Microsoft Reviewers: Open in CodeFlow