Summary:
Changelog:
* Rename `ENABLE_PACKAGER_CONNECTION` macro to a more appropriate name `RCT_DEV_SETTINGS_ENABLE_PACKAGER_CONNECTION` to reflect this is only used in RCT_DEV_SETTINGS
* Introduce `RCT_PACKAGER_LOADING_FUNCTIONALITY` that can be separate from `RCT_DEV_MENU`, by default, it equals to `RCT_DEV_MENU`
Reviewed By: fkgozali
Differential Revision: D30546025
fbshipit-source-id: f409c02dc1486041d7db5abdbf7eb482520fa171
Summary:
When you reload React Native surfaces via the CMD + OPT + R keystroke, this is the actual code that executes:
https://www.internalfb.com/code/fbsource/[9c79fc6a17b7738b391a605412abf1cb15ef8ea1]/xplat/js/react-native-github/React/CoreModules/RCTDevSettings.mm?lines=172-175%2C179-183
It's only executed when RCTDevSettings is instantiated by the bridge. So, if only bridgeless surfaces are loaded, then CMD + OPT + R doesn't work.
## Fix
In this diff, I ensure that
1. We set up the reload listener when RCTDevSettings is *first* instantiated
2. We clear the reload listener when all instances of RCTDevSettings are invalidated.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29437952
fbshipit-source-id: 9f2ff8340575c0ed881df26249433b2075bbd2ac
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
This diff migrated RCTDevSettings to the RCTBundleManager, which works both in bridge/bridgeless mode. RCTDevSettings is the last TurboModule that synthesizes the bundleURL. So, after this diff, we can get rid of the RCTBundleHolderModule protocol.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232320
fbshipit-source-id: ab53278fea0ea7e025cf748be62bc5d610593e7f
Summary:
`RCTDevSettings` uses the API `bridge.isInspectable` to understand if the runtime can be debugged. In bridgeless mode, let's use `RuntimeExecutor` to check the same property.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D27095935
fbshipit-source-id: 93785774b175bd7da17269e1590b5d92eba2b0cf
Summary:
Changelog: [Internal]
This moves enabling/disabling fast refresh off of `bridge.enqueueJSCall` in bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D26290378
fbshipit-source-id: ed8a3389b9812cedf7181971656dacd98ff7ecfd
Summary:
Changelog: [Internal]
This diff allows `RCTDevSettings` to access bundleURL directly instead of relying on the bridge.
Reviewed By: RSNara
Differential Revision: D26289592
fbshipit-source-id: e22e583e51323bfe66f6e424d9f47edf71b1ed9f
Summary:
Ran xbgs `.devMenu`, and found all the NativeModules that used the bridge to access DevMenu. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499960
fbshipit-source-id: 70478616d44808f3788dd0b194da155db0877db9
Summary:
This is an extension of D25449795. I searched for all usages of .eventDispatcher within NativeModules, and migrated them all to the Venice-compatible RCTModuleRegistry API.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25473844
fbshipit-source-id: 2b8deec236e019f3adfb59fadd745c249ff822f4
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue.
Changelog:
[iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue
Reviewed By: RSNara
Differential Revision: D23821741
fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f
Summary:
Disabling Fast Refresh won't be persisted when restarting the app.
I believe this regressed with https://github.com/facebook/react-native/commit/824e1711172d14a9373209bbae63d1ae50601625. In this commit `HMRClient.setup` will always be called with `enabled` being set true. This PR loads the _enabled_ state from the user defaults (as it was done before).
## Changelog
[iOS] [Fixed] - Enable Fast Refresh gets persisted across app launches
Pull Request resolved: https://github.com/facebook/react-native/pull/29880
Test Plan:
Without this change Fast Refresh is enabled on every app restart.
Tested with this change:
- Disabling Fast Refresh
- Restarting App -> Fast Refresh still disabled
- Enabled Fast Refresh again
- Restarting App -> Fast Refresh still enabled again
Reviewed By: sammy-SC
Differential Revision: D23686435
Pulled By: PeteTheHeat
fbshipit-source-id: 42c31b22060d3dc4b1d4cb8f41792b303fc7fce8
Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D20784270
fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd
Summary:
This refactors some logic which sets up HMRClient in JS. The logic should live in RCTDevSettings, so it is shared in bridge/bridgeless mode.
This also means the logic will be compiled out when `RCT_DEV_MENU` is false.
Reviewed By: RSNara
Differential Revision: D19563629
fbshipit-source-id: 5c2553be9fd686a2a178f03bb5eed7a82cbadb1b
Summary: As titled. The work to write the spec and make this module compatible were done in D18148890.
Reviewed By: RSNara
Differential Revision: D19442016
fbshipit-source-id: 369bb4247d6590d41ec414f93c79d98d4a6bed88
Summary:
In https://github.com/facebook/react-native/issues/25427, radex added initial support for running React Native projects on macOS via Catalyst. However, `RCTWebSocket` was disabled for that target because of some compilation issues. This meant that running projects via a connection to the packager wasn't possible: no live reload, and projects must be run in "Release" mode. It also meant making manual changes to Xcode projects deploying to macOS and scattering a number of conditional checks throughout the codebase.
In this change, I've implemented support for `RCTWebSocket` on the macOS target and re-enabled the affected features. Live reload and the inspector now work for macOS targets. Manual modifications of Xcode build settings are no longer necessary for react-native projects running on macOS.

### Limitations
There's no binding which displays the developer menu (since there's no shake event on macOS). We'll probably want to add one, perhaps to the menu bar.
I've chosen not to commit the modifications to RNTester which enable macOS support, since that would imply more "official" support for this target than I suspect you all would like to convey. I'm happy to add those chunks if it would be helpful.
## Changelog
[iOS] [Added] - Added web socket support for macOS (Catalyst), enabling debug builds and live reload
Pull Request resolved: https://github.com/facebook/react-native/pull/27469
Test Plan:
* Open RNTester/RNTester.xcodeproj with Xcode 11.2.1, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
* Select "My Mac" as device target, and run. You may need to configure a valid development team to make signing work.
* RNTester should run fine with no additional configuration. Modify a file in RNTester, note that live reload is now working.
* Test the developer inspector. To display the developer menu, you'll need to manually show it; here's an example diff which does that:
```
diff --git a/RNTester/js/RNTesterApp.ios.js b/RNTester/js/RNTesterApp.ios.js
index 8245a68d12..a447ad3b1b 100644
--- a/RNTester/js/RNTesterApp.ios.js
+++ b/RNTester/js/RNTesterApp.ios.js
@@ -19,6 +19,8 @@ const React = require('react');
const SnapshotViewIOS = require('./examples/Snapshot/SnapshotViewIOS.ios');
const URIActionMap = require('./utils/URIActionMap');
+import NativeDevMenu from '../../Libraries/NativeModules/specs/NativeDevMenu';
+
const {
AppRegistry,
AsyncStorage,
@@ -143,6 +145,7 @@ class RNTesterApp extends React.Component<Props, RNTesterNavigationState> {
UNSAFE_componentWillMount() {
BackHandler.addEventListener('hardwareBackPress', this._handleBack);
+ NativeDevMenu.show();
}
componentDidMount() {
```
Reviewed By: sammy-SC
Differential Revision: D18945861
Pulled By: hramos
fbshipit-source-id: edcf02c5803742c89a845a3e5d72bc7dacae839f
Summary:
The diff moves an invocation of `_synchronizeAllSettings` from the constructor to `setBridge`. The side-effects of `_synchronizeAllSettings` rely on a bridge not being nil, so we need to ensure that the bridge is assigned to the instance before calling `_synchronizeAllSettings`.
Before the fix, enabling JavaScript debugger caused a stale and opening many copies of a debugger in Chrome.
Changelog: [Internal] Fixed race and possible stale in RCTDevSettings
Reviewed By: RSNara
Differential Revision: D18379596
fbshipit-source-id: 9f64b9bc5426720948113de61bc9ccc8c39193b4
Summary:
Revert some changes from D18148890 as they broke loading of RN surfaces with following error
``Invariant Violation: Expected HMRClient.setup() call at startup`
Changelog: [internal]
Reviewed By: mmmulani
Differential Revision: D18324764
fbshipit-source-id: f1b4af630f8330444f70a4d93be2b53f6d8e31c2