mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Ramanpreet Nara
4c5182c1cc
Summary: ## Context A React Native application can configure its RCTNetworking by initializing it with id<RCTURLRequestHandler> objects. Therefore, RCTNetworking supports this initializer: ``` - (instancetype)initWithHandlersProvider:(NSArray<id<RCTURLRequestHandler>> * (^)(void))getHandlers ``` Right now, all id<RCTURLRequestHandler> are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager. ## Problem The method [that constructs RCTNetworking](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1471) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the request handlers: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean. ## Changes In this refactor, RCTNetworking gives its _handlersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows the _handlersProvider to load id<RCTURLRequestHandler> from correct infra, in both contexts. Changelog: [iOS][Changed] - Give RCTNetworking handler provider block RCTModuleRegistry Reviewed By: PeteTheHeat Differential Revision: D28013000 fbshipit-source-id: 956d660771ab18f5e7f24fcc28792f9a217146e7