feat: make RNScreens compatible with bridgeless mode #1990
Conversation
kkafar
added
Feature impl
| RCTModuleRegistry *moduleRegistry = | ||
| (RCTModuleRegistry *)[[appDelegate valueForKey:@"_reactHost"] valueForKey:@"_moduleRegistry"]; |
There was a problem hiding this comment.
@WoLewicki, this is very interesting!
I don't understand the full code. But, why do we have to rely on the bridge/module registry for this use-case? Do you think there's any way to re-structure this so that we don't have to rely on the bridge or the module registry?
I'm asking to know if we need to provide a better api for this. (We definitely shouldn't be doing [[appDelegate valueForKey:@"_reactHost"] valueForKey:@"_moduleRegistry"]).
There was a problem hiding this comment.
What we need here is the RCTImageLoader module so if there is another way to get it then we could remove it from here for sure.
There was a problem hiding this comment.
So, from what I can gather:
- RNSScreenStackHeaderConfig is a component.
- And it needs access to a native module: RCTImageLoader.
As far as I'm aware, fabric components do not have access to native modules. (I think this was also the case with legacy components). And... I think there's been some hesitation about giving components access to native modules.
Let me follow up internally!
There was a problem hiding this comment.
Ok, thanks for information and waiting for follow up 🚀
There was a problem hiding this comment.
@WoLewicki, the recommended approach is to follow the footsteps of the < Image/> component.
Create a hand-written ComponentDescriptor. ComponentDescriptors have access to the contextContainer. The contextContainer contains the RCTImageLoader.
You'll also need to write a custom ShadowNode. The component descriptor will attach some c++ object to the shadow node that calls into [RCTImageLoader imageForUrl...]. And this Fabric component will be given access to the shadow node. From that shadow node, it can grab that c++ object and call the method that eventually triggers [RCTImageLoader imageForUrl...].
| - (void)dispatchEventForAnimatedObserver:(id<RCTEvent>)event | ||
| { | ||
| auto eventDispatcher = [[RCTBridge currentBridge] eventDispatcher]; | ||
| if (eventDispatcher) { | ||
| [eventDispatcher sendEvent:event]; | ||
| } else { | ||
| id appDelegate = [[UIApplication sharedApplication] delegate]; | ||
| RCTModuleRegistry *moduleRegistry = | ||
| (RCTModuleRegistry *)[[appDelegate valueForKey:@"_reactHost"] valueForKey:@"_moduleRegistry"]; | ||
| if (moduleRegistry) { | ||
| id<RCTEventDispatcherProtocol> legacyEventDispatcher = [moduleRegistry moduleForName:"EventDispatcher" | ||
| lazilyLoadIfNecessary:YES]; | ||
|
|
||
| [legacyEventDispatcher notifyObserversOfEvent:event]; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
@WoLewicki, the event dispatcher just calls a javascript module method.
Instead of using the event dispatcher, could you instead dispatch a fabric event? And then, on the javascript side, if necessary, just call the JavaScript module there?
|
Closing this PR in favor of changes that are already on |
Description
PR enabling bridgeless mode in
FabricTestExampleso we can check if the library is compatible with it. The only problem I encountered was the usage ofcurrentBridgewhich now returnsniloniOS. I made a dirty hack to get the needed module from some private fields. It would be nice to find a better solution for this, but we have to start with something 🚀Changes
Test code and steps to reproduce
Test1802.tsxwhere we use theheaderHeightevent withAnimated. For now you have to comment the code using RNGH and Reanimated to test it since they are not yet compatible with bridgeless mode.