react-native-macos/React/Base/RCTReloadCommand.h

39 строки
1.2 KiB
C
Исходник Обычный вид История

/*
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*/
#import <Foundation/Foundation.h>
#import <React/RCTDefines.h>
Deprecate bridge reload API [1/n] Summary: Testing the waters with an idea for unifying RN lifecycle with/without bridge. ### Motivation/Background RN bridge is being reloaded from [several different places](https://fburl.com/codesearch/ae3zeatt). When this happens, the bridge does a bunch of things: 1. Post `RCTBridgeWillReloadNotification` (RCTSurfacePresenter listens to this and reloads) 2. Invalidate batched bridge, which does: a. invalidate display link b. post `RCTBridgeWillInvalidateModules/RCTBridgeDidInvalidateModules` (TurboModuleManager listens to this and reloads modules) c. clear js thread state d. clear some local caches 3. Set up (reload bundle and batched bridge) In a bridgeless world, there isn't one thing which owns all these peices of infra, and can reload them. ### Plan Use `RCTReloadCommand` to handle reloads. This light class previously only handled CMD+R. The new workflow looks like this: 1. Anything which cares about reloads can register itself as a listener. (RCTBridge, RCTSurfacePresenter, TurboModuleManager...) 2. Anything that previously called `bridge reload` now calls `RCTTriggerReloadCommandListeners`. 3. Delete old notifications ### Alternate Plan Use yet another NSNotification. I like `RCTReloadCommand` better. ### Unknowns Looks like we log the reason for bridge reloading [here](https://fburl.com/diffusion/lc9jj8la), do we want to save this behaviour? Does anyone look at why bridge is being reloaded cc/Rick? If so, I can add back that functionality to `RCTReloadCommand`. It should be possible to customize the order/priority of what gets reloaded first. There may be some racy behaviour that I haven't thought about yet. Changelog: [iOS][Deprecated] Deprecate [bridge reload] API - prefer RCTReloadCommand Reviewed By: shergin Differential Revision: D17869635 fbshipit-source-id: 81f39eaa2c3ce08ea1bc6f2193684c2630d81a2d
2019-10-30 22:20:29 +03:00
/**
* A protocol which should be conformed to in order to be notified of RN reload events. These events can be
* created by CMD+R or dev menu during development, or anywhere the trigger is exposed to JS.
* The listener must also register itself using the method below.
*/
@protocol RCTReloadListener
- (void)didReceiveReloadCommand;
@end
Deprecate bridge reload API [1/n] Summary: Testing the waters with an idea for unifying RN lifecycle with/without bridge. ### Motivation/Background RN bridge is being reloaded from [several different places](https://fburl.com/codesearch/ae3zeatt). When this happens, the bridge does a bunch of things: 1. Post `RCTBridgeWillReloadNotification` (RCTSurfacePresenter listens to this and reloads) 2. Invalidate batched bridge, which does: a. invalidate display link b. post `RCTBridgeWillInvalidateModules/RCTBridgeDidInvalidateModules` (TurboModuleManager listens to this and reloads modules) c. clear js thread state d. clear some local caches 3. Set up (reload bundle and batched bridge) In a bridgeless world, there isn't one thing which owns all these peices of infra, and can reload them. ### Plan Use `RCTReloadCommand` to handle reloads. This light class previously only handled CMD+R. The new workflow looks like this: 1. Anything which cares about reloads can register itself as a listener. (RCTBridge, RCTSurfacePresenter, TurboModuleManager...) 2. Anything that previously called `bridge reload` now calls `RCTTriggerReloadCommandListeners`. 3. Delete old notifications ### Alternate Plan Use yet another NSNotification. I like `RCTReloadCommand` better. ### Unknowns Looks like we log the reason for bridge reloading [here](https://fburl.com/diffusion/lc9jj8la), do we want to save this behaviour? Does anyone look at why bridge is being reloaded cc/Rick? If so, I can add back that functionality to `RCTReloadCommand`. It should be possible to customize the order/priority of what gets reloaded first. There may be some racy behaviour that I haven't thought about yet. Changelog: [iOS][Deprecated] Deprecate [bridge reload] API - prefer RCTReloadCommand Reviewed By: shergin Differential Revision: D17869635 fbshipit-source-id: 81f39eaa2c3ce08ea1bc6f2193684c2630d81a2d
2019-10-30 22:20:29 +03:00
/**
* Registers a weakly-held observer of RN reload events.
*/
RCT_EXTERN void RCTRegisterReloadCommandListener(id<RCTReloadListener> listener);
Deprecate bridge reload API [1/n] Summary: Testing the waters with an idea for unifying RN lifecycle with/without bridge. ### Motivation/Background RN bridge is being reloaded from [several different places](https://fburl.com/codesearch/ae3zeatt). When this happens, the bridge does a bunch of things: 1. Post `RCTBridgeWillReloadNotification` (RCTSurfacePresenter listens to this and reloads) 2. Invalidate batched bridge, which does: a. invalidate display link b. post `RCTBridgeWillInvalidateModules/RCTBridgeDidInvalidateModules` (TurboModuleManager listens to this and reloads modules) c. clear js thread state d. clear some local caches 3. Set up (reload bundle and batched bridge) In a bridgeless world, there isn't one thing which owns all these peices of infra, and can reload them. ### Plan Use `RCTReloadCommand` to handle reloads. This light class previously only handled CMD+R. The new workflow looks like this: 1. Anything which cares about reloads can register itself as a listener. (RCTBridge, RCTSurfacePresenter, TurboModuleManager...) 2. Anything that previously called `bridge reload` now calls `RCTTriggerReloadCommandListeners`. 3. Delete old notifications ### Alternate Plan Use yet another NSNotification. I like `RCTReloadCommand` better. ### Unknowns Looks like we log the reason for bridge reloading [here](https://fburl.com/diffusion/lc9jj8la), do we want to save this behaviour? Does anyone look at why bridge is being reloaded cc/Rick? If so, I can add back that functionality to `RCTReloadCommand`. It should be possible to customize the order/priority of what gets reloaded first. There may be some racy behaviour that I haven't thought about yet. Changelog: [iOS][Deprecated] Deprecate [bridge reload] API - prefer RCTReloadCommand Reviewed By: shergin Differential Revision: D17869635 fbshipit-source-id: 81f39eaa2c3ce08ea1bc6f2193684c2630d81a2d
2019-10-30 22:20:29 +03:00
/**
* Triggers a reload for all current listeners. Replaces [_bridge reload].
Deprecate bridge reload API [1/n] Summary: Testing the waters with an idea for unifying RN lifecycle with/without bridge. ### Motivation/Background RN bridge is being reloaded from [several different places](https://fburl.com/codesearch/ae3zeatt). When this happens, the bridge does a bunch of things: 1. Post `RCTBridgeWillReloadNotification` (RCTSurfacePresenter listens to this and reloads) 2. Invalidate batched bridge, which does: a. invalidate display link b. post `RCTBridgeWillInvalidateModules/RCTBridgeDidInvalidateModules` (TurboModuleManager listens to this and reloads modules) c. clear js thread state d. clear some local caches 3. Set up (reload bundle and batched bridge) In a bridgeless world, there isn't one thing which owns all these peices of infra, and can reload them. ### Plan Use `RCTReloadCommand` to handle reloads. This light class previously only handled CMD+R. The new workflow looks like this: 1. Anything which cares about reloads can register itself as a listener. (RCTBridge, RCTSurfacePresenter, TurboModuleManager...) 2. Anything that previously called `bridge reload` now calls `RCTTriggerReloadCommandListeners`. 3. Delete old notifications ### Alternate Plan Use yet another NSNotification. I like `RCTReloadCommand` better. ### Unknowns Looks like we log the reason for bridge reloading [here](https://fburl.com/diffusion/lc9jj8la), do we want to save this behaviour? Does anyone look at why bridge is being reloaded cc/Rick? If so, I can add back that functionality to `RCTReloadCommand`. It should be possible to customize the order/priority of what gets reloaded first. There may be some racy behaviour that I haven't thought about yet. Changelog: [iOS][Deprecated] Deprecate [bridge reload] API - prefer RCTReloadCommand Reviewed By: shergin Differential Revision: D17869635 fbshipit-source-id: 81f39eaa2c3ce08ea1bc6f2193684c2630d81a2d
2019-10-30 22:20:29 +03:00
*/
RCT_EXTERN void RCTTriggerReloadCommandListeners(NSString *reason);
/**
* This notification fires anytime RCTTriggerReloadCommandListeners() is called.
*/
RCT_EXTERN NSString *const RCTTriggerReloadCommandNotification;
RCT_EXTERN NSString *const RCTTriggerReloadCommandReasonKey;
RCT_EXTERN NSString *const RCTTriggerReloadCommandBundleURLKey;
RCT_EXTERN void RCTReloadCommandSetBundleURL(NSURL *URL);