Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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
- Loading branch information