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
|
As we've been day in day out been dealing with the complexity of JSI ABI in our integrations from core... I'm hesitant to expand the support matrix to yet another configuration. Is this something you think other app developers would make use of, or is it fine to have as a fork for yours? Of the options you listed, we assume #1 is the vast majority of consumers, and #2 is a bit more niche, and the new #3 is maybe too niche? |
chrisglein
added
the
Needs: Author Feedback
microsoft-github-policy-service
bot
added
the
no-recent-activity
|
This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment. |
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