Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
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:
Live reloading has been deprecated in favor of fast refresh for years, this diff removes remaining references to it.
Changelog: [iOS] Delete deprecated "live reloading" setting
Reviewed By: fkgozali
Differential Revision: D26983596
fbshipit-source-id: c7f86e7ec511f80e53659bccd8f40ac4f0cac27c
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:
Changelog: [Internal]
This removes a couple dependencies on bridge in dev menu native module. So far reloading works, will get inspector and other options working in follow ups.
Reviewed By: sammy-SC
Differential Revision: D26240391
fbshipit-source-id: 7c9d585f4efa6cc9db995ef8a33865831bc8d526
Summary:
Live reload was removed as a user facing feature in 2019 in favour of fast refresh. The native code was left in case "automation" relied on it. I'm quite sure no automation is using this dev feature. Remember, the dev feature made it so that hitting save in a text editor auto reloaded in metro.
Cleanup the native implementation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26239628
fbshipit-source-id: 7f61c7204727bb2d739600a459f69c72842265c5
Summary:
IIUC `isDebuggingRemotely` will never be set when `isDeviceDebuggingAvailable` is true. This was just a failsafe so that noone was trapped in an intermediate state.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26239570
fbshipit-source-id: 8db6b022a0ea581216a1fa97b9d41f5ab6160562
Summary:
In bridegless mode, `setBridge` is never called on native modules. This diff refactors out some setup logic into the module's init method.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26211620
fbshipit-source-id: 7a9910198852dea5ac679762aa93dfea6fc47d70
Summary: Changelog: [iOS] Only show Dev Menu on shake if RN view is visible
Reviewed By: fkgozali
Differential Revision: D26138659
fbshipit-source-id: e2db287728675c7ead5fcbf569ed591638e2187e
Summary:
## Description
Suppose this was the codegen declaration before:
```
rn_library(
name = "FooModule",
native_module_spec_name = "FBReactNativeSpec",
codegen_modules = True,
# ...
)
```
Previously, this would generate the following BUCK targets:
- generated_objcpp_modules-FooModuleApple
- generated_java_modules-FooModuleAndroid
- generated_java_modules-FooModule-jniAndroid
## Changes
We will now generate:
- FBReactNativeSpecApple
- FBReactNativeSpecAndroid
- FBReactNativeSpec-jniAndroid
This matches the naming scheme of the old codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25680224
fbshipit-source-id: 617ac18fd915f3277f6bd98072d147f20fb193e5
Summary:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
Summary:
Ran `xbgs .accibilityManager`, and found all the NativeModules that used the bridge to access AccessibilityManager. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25504726
fbshipit-source-id: fcfb1fffbeedc136ee160d043949d9859300b1e3
Summary:
Ran `xbgs .redBox`, and found all the NativeModules that used the bridge to access RedBox. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25507829
fbshipit-source-id: 91033ca4c57d5be5e8e6fa904b636960ec12c584
Summary:
Ran `xbgs .devSettings`, and found all the NativeModules that used the bridge to access DevSettings. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503402
fbshipit-source-id: 26afc45cd1bc63d5de99ea331e7b2949b66be7ce
Summary:
All NativeModules that access the _bridge from self to require the DevSettings NativeModule now instead get the DevSettings NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503289
fbshipit-source-id: ebd1fd45d40aca37c0ead83bbaab59fa99d45044
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:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (0ed81b28d3).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
`RCTAlertController` creates a new window, and presents itself in that window.
RCTAlertController strongly retains the window, and the window strongly retains RCTAlertController when presenting it.
This adds a new method to break that cycle once alert is dismissed.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25312413
fbshipit-source-id: e4048922aa697eb42c4c149827bac61bc7bc5528
Summary:
According to the crash, RCTEventEmitter is being asked to emit events before RN is set up {emoji:1f928}. Neither the bridge, nor bridgeless mode is ready to send events.
In this scenario, drop the events on the floor instead of crashing.
Changelog: [Internal]
Reviewed By: naftaly
Differential Revision: D24634701
fbshipit-source-id: 933e5dfd15e5ee7c2215489305c71de46e78a9e5
Summary:
To unify with Android, this uses the target off the same BUCK file.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24522269
fbshipit-source-id: 5aa0c08962890b884081faeb1ec801aebec9c2dd
Summary:
Removes the generated FBReactNativeSpec files from source control.
## Generating FBReactNativeSpec files
The files will be generated automatically by CocoaPods when the `RNTesterPods` Xcode workspace is generated:
```
cd packages/rn-tester
pod install
```
The spec files can be re-generated by invoking the script directly:
```
./scripts/generate-native-modules-specs.sh
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24261167
fbshipit-source-id: acb7ac856e5e519932e4f587f79e24f49cd84a91
Summary:
Although the interface for both NativeModules is the same, we'd like to enforce 1 `TurboModuleRegistry.get` call per NativeModule spec file. Therefore this diff splits the one spec into two.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24325260
fbshipit-source-id: f18718e4235b7b8ccbfc44a7e48571ecf483a36c
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:
shergin added a new assert to dimensions calculations in D24038911 (e853722981). This crashes in bridgeless mode b/c no bridge.
This diff uses `turboModuleRegistry` as a bridge workaround. The registry is a [weak property](https://www.fburl.com/diffusion/sunv3bx9) so retain cycles shouldn't be an issue here, let me know if that's incorrect.
As a nice bonus, this fixes dynamic font sizing in bridgeless mode. It was broken before since it relied on the bridge.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24256338
fbshipit-source-id: 141d36239ac6a6e9e87ca96eea7aeec56729095d
Summary:
This PR attempts to fix issue https://github.com/facebook/react-native/issues/28278 and https://github.com/facebook/react-native/issues/29525
On Crashlytics, the following error occurs in file `RCTWebSocketModule.m` at method `-[RCTWebSocketModule webSocket:didFailWithError:]` when a nil value is inserted into a dictionary as a value.
```
Fatal Exception: NSInvalidArgumentException
*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]
```
This PR is following the suggestion of this: https://github.com/facebook/react-native/issues/28278#issuecomment-597461650 and it replaces the values of any property if it is nil. In detail:
- it converts `error` to empty NSString if the original value is nil
- it converts `socketID` to a NSNumber object, which stores `-1` if the original value is nil
## Changelog
[iOS] [Fixed] - A crash in WebSocket module
Pull Request resolved: https://github.com/facebook/react-native/pull/30066
Test Plan: We were not able to reproduce the crash, but the report itself provided enough information to find a solution for this issue.
Reviewed By: shergin
Differential Revision: D24241147
Pulled By: sammy-SC
fbshipit-source-id: d5d632b49ca77b5d8be8b9c32358bef68f17d30a
Summary:
At this point, I think we are ready to enable validation
Changelog: [INTERNAL]
Differential Revision: D24062829
fbshipit-source-id: c82dcd2c376e5cdeb164451e16b6fb3a666106f4
Summary: We need this checks to make the results of those function more reliable.
Reviewed By: sammy-SC
Differential Revision: D24038911
fbshipit-source-id: 3b54fe3056c9508cde84ea157beebea57e7e49b6
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
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 824e171117. 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:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
RCTKeyboardObserver only uses the bridge to avoid sending events during a reload. See D6573855 (d9c658566a) for reference.
In bridgeless mode, the bridge is expected to always be nil, as the module uses `invokeJS` block to send events instead.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23176990
fbshipit-source-id: 7946c9c2684d7d9ea0a606bad375309a5530a719
Summary:
Logbox inside bridgeless surfaces was crashing and not able to open, this diff should fix it.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23043773
fbshipit-source-id: 6e584f97e53e626b9bfedd6dc997ba6ba8c08b8f
Summary:
This should fix https://github.com/facebook/react-native/issues/29082 and https://github.com/facebook/react-native/issues/10471
Currently when an alert is being shown while a modal is being dismissed, it causes the alert not to show and In some cases it causes the UI to become unresponsive. I think this was caused by using RCTPresentedViewController to try and display the Alert the currently presented view. The View the Alert was going to be shown on is dismissed and the modal doesn't show. I implemented a new RCTAlertController to show the alert on top of the view, the modal being dismissed should now not interfere with the alert being shown.
## Changelog
[iOS] [Fixed] - Fixed showing Alert while closing a Modal
Pull Request resolved: https://github.com/facebook/react-native/pull/29295
Test Plan:
To recreate the bug:
1. npx react-native init Test --version 0.63.0-rc.1
2. Paste the following code into App.js
```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow strict-local
*/
import React from 'react';
import {
SafeAreaView,
StyleSheet,
View,
Text,
StatusBar,
Modal,
Alert
} from 'react-native';
const App: () => React$Node = () => {
const [visible, setVisible] = React.useState(false)
const onShowModal = () => {
setVisible(true)
}
onCloseBroken = () => {
setVisible(false)
Alert.alert('Alert', 'Alert won\'t show')
}
onCloseWorking = () => {
setVisible(false)
setTimeout(() => Alert.alert('Alert', 'Works fine'), 10)
}
return (
<>
<StatusBar barStyle="dark-content" />
<SafeAreaView style={styles.container}>
<Text onPress={onShowModal}>Show modal</Text>
</SafeAreaView>
<Modal animationType="fade" visible={visible} onRequestClose={onCloseWorking} >
<View style={styles.container}>
<Text onPress={onCloseBroken}>Close modal immediately</Text>
<Text onPress={onCloseWorking}>Close modal with delay</Text>
</View>
</Modal>
</>
)
}
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: 'center',
justifyContent: 'space-around',
},
})
export default App
```
3. cd Test && npx react-native run-ios
4. Show the modal and click the `Close modal immediately` button
The first button doesn't show the alert, the second does because it gets rendered after the modal view is dismissed. After this commit, the alert always shows on top of every view properly. You can test by pointing the react native package to my branch by modifying the package json file like this
```
"react-native": "https://github.com/devon94/react-native.git#fix-ios-modal"
```
I was unable to reproduce the case where it causes the UI to be responsive in the test app but was able to reproduce it in our react native app at work. I can provide a video later if needed but the code is too complex to simplify into a test case.
Reviewed By: sammy-SC
Differential Revision: D22783371
Pulled By: PeteTheHeat
fbshipit-source-id: 3e359645c610074ea855ee5686c59bdb9d6b696b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29453
Problem Statement: A native module needs to call a function on `ReactInstance` (in this case `loadScript`). Typically, this is handled by the bridge.
Current Bridgeless Solution: Create a new protocol (in this case `RCTJSScriptLoaderModule`) which lets a block be passed in TM init to forward the method call to `ReactInstance`. This is the best thing I could think of right now.
Changelog:[Internal]
Reviewed By: RSNara
Differential Revision: D22512748
fbshipit-source-id: e6559279b6e299e17d1199407129ad3902c41e6b
Summary:
## Why?
1. RCTTurboModuleLookupDelegate sounds a bit nebulous.
2. In JS and Java, we use a `TurboModuleRegistry` interface to require TurboModules. So, this diff will make JS, Java, and ObjC consistent.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22405754
fbshipit-source-id: 30c85c246b39d198c5b8c6ca4432a3196ca0ebfd
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary:
If a NativeModule requires main queue setup, its `getConstants()` method must be executed on the main thead. The legacy NativeModule infra takes care of this for us. With TurboModules, however, all synchronous methods, including `getConstants()`, execute on the JS thread. Therefore, if a TurboModule requires main queue setup, and exports constants, we must execute its `getConstants()` method body on the main queue explicitly.
**Notes:**
- The changes in this diff should be a noop when TurboModules is off, because `RCTUnsafeExecuteOnMainQueueSync` synchronously execute its block on the current thread if the current thread is the main thread.
- If a NativeModule doens't have the `requiresMainQueueSetup` method, but has the `constantsToExport` method, both NativeModules and TurboModules assume that it requires main queue setup.
## Script
```
const exec = require("../lib/exec");
const abspath = require("../lib/abspath");
const relpath = require("../lib/relpath");
const readFile = (filename) => require("fs").readFileSync(filename, "utf8");
const writeFile = (filename, content) =>
require("fs").writeFileSync(filename, content);
function main() {
const tmFiles = exec("cd ~/fbsource && xbgs -n 10000 -l constantsToExport")
.split("\n")
.filter(Boolean);
const filesWithoutConstantsToExport = [];
const filesWithConstantsToExportButNotGetConstants = [];
const filesExplicitlyNotRequiringMainQueueSetup = [];
tmFiles
.filter((filename) => {
if (filename.includes("microsoft-fork-of-react-native")) {
return false;
}
return /\.mm?$/.test(filename);
})
.map(abspath)
.forEach((filename) => {
const code = readFile(filename);
const relFilename = relpath(filename);
if (!/constantsToExport\s*{/.test(code)) {
filesWithoutConstantsToExport.push(relFilename);
return;
}
if (!/getConstants\s*{/.test(code)) {
filesWithConstantsToExportButNotGetConstants.push(relFilename);
return;
}
if (/requiresMainQueueSetup\s*{/.test(code)) {
const requiresMainQueueSetupRegex = /requiresMainQueueSetup\s*{\s*return\s+(?<requiresMainQueueSetup>YES|NO)/;
const requiresMainQueueSetupRegexMatch = requiresMainQueueSetupRegex.exec(
code
);
if (!requiresMainQueueSetupRegexMatch) {
throw new Error(
"Detected requiresMainQueueSetup method in file " +
relFilename +
" but was unable to parse the method return value"
);
}
const {
requiresMainQueueSetup,
} = requiresMainQueueSetupRegexMatch.groups;
if (requiresMainQueueSetup == "NO") {
filesExplicitlyNotRequiringMainQueueSetup.push(relFilename);
return;
}
}
const getConstantsTypeRegex = () => /-\s*\((?<type>.*)\)getConstants\s*{/;
const getConstantsTypeRegexMatch = getConstantsTypeRegex().exec(code);
if (!getConstantsTypeRegexMatch) {
throw new Error(
`Failed to parse return type of getConstants method in file ${relFilename}`
);
}
const getConstantsType = getConstantsTypeRegexMatch.groups.type;
const getConstantsBody = code
.split(getConstantsTypeRegex())[2]
.split("\n}")[0];
const newGetConstantsBody = `
__block ${getConstantsType} constants;
RCTUnsafeExecuteOnMainQueueSync(^{${getConstantsBody
.replace(/\n/g, "\n ")
.replace(/_bridge/g, "self->_bridge")
.replace(/return /g, "constants = ")}
});
return constants;
`;
writeFile(
filename,
code
.replace(getConstantsBody, newGetConstantsBody)
.replace("#import", "#import <React/RCTUtils.h>\n#import")
);
});
console.log("Files without constantsToExport: ");
filesWithoutConstantsToExport.forEach((file) => console.log(file));
console.log();
console.log("Files with constantsToExport but no getConstants: ");
filesWithConstantsToExportButNotGetConstants.forEach((file) =>
console.log(file)
);
console.log();
console.log("Files with requiresMainQueueSetup = NO: ");
filesExplicitlyNotRequiringMainQueueSetup.forEach((file) =>
console.log(file)
);
}
if (!module.parent) {
main();
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21797048
fbshipit-source-id: a822a858fecdbe976e6197f8339e509dc7cd917f
Summary:
Was looking at removing logbox from CoreModules, realized it had a bunch of extra deps.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D21535374
fbshipit-source-id: 2427cc66fa34635b49ac4b4fafaf0b6481f5687d
Summary:
This diff updates the loading banner to respect the RCTAppearance dev mode setting.
Changelog: [General] [iOS] Add dark mode support to loading banner
Reviewed By: fkgozali
Differential Revision: D21429148
fbshipit-source-id: d7d9e778245112a19accf813dcff693f0d187a38
Summary: This enables redbox in bridgeless mode, by removing a dep on the bridge. It also disables full screen logbox, since I couldn't figure out how to get it working without the bridge.
Reviewed By: rickhanlonii, ejanzer
Differential Revision: D21440233
fbshipit-source-id: cb1730fefe1639135fdf06039031975d53f95229
Summary:
This diff removes the hostname from the loading bar and shrinks it down so it's inside the margins of the safe area view, never blocking app content inside the safe area.
Changelog: [General] [iOS] Shrink loading bar down to not cover safe area.
Reviewed By: shergin
Differential Revision: D21339480
fbshipit-source-id: e8416af63b7e06bcc21c7b6277d5d01d61eb3f73
Summary:
This diff reduces the minimum loading banner time and animation time to make the locating banner faster.
Changelog: [General] [iOS] Speed up loading banner animations
Reviewed By: PeteTheHeat
Differential Revision: D21290517
fbshipit-source-id: 111dff41df53b0246548e1da1db80c2188498a9c
Summary:
This diff fixes an issue where the initial "Loading from Metro..." message is flashed for a few milliseconds before the download progress kicks in. It's just jarring enough to be noticed and is ~600ms too fast to be read.
This diff adds a delay so that if the loading progress starts within 200ms we go straight to the progress.
Changelog: [Fixed] [iOS] Delay loading banner message to prevent flashing messages
Reviewed By: PeteTheHeat
Differential Revision: D21281870
fbshipit-source-id: d28c1eae01c2ac9d79f356f1870f17dbb22a9d84
Summary:
This diff fixes an issue where the loading banner message could update while the banner hide animation is going, catching your eye for no reason.
Changelog: [Fixed] [iOS] Do not update loading banner message while hiding
Reviewed By: PeteTheHeat
Differential Revision: D21280786
fbshipit-source-id: a10b33cd72f263d08eea6d8e94963514affbe24d
Summary:
This diff adds a hostname to the loading banner on iOS so it's clear which server you're loading from.
Changelog: [Added] [iOS] Added hostname to loading banner.
Reviewed By: PeteTheHeat
Differential Revision: D21280252
fbshipit-source-id: d7733c056f5fb63e32b247a4fa1476ab42c7da17
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:
Calling `-[RCTRedBox showErrorMessage]` twice causes a crash
We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented.
But from the documentation:
> A Boolean value indicating whether the view controller is being presented.
Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc#
---
So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown.
```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.'
```
Changelog: Fix crash caused by presenting view controller twice from RCTRedBox
Reviewed By: PeteTheHeat
Differential Revision: D20946645
fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81
Summary:
## Problem
For some reason, D20831545 broke the `use_frameworks!` build of RNTester.
## Building RNTester
```
pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd;
```
## Error
I built RNTester locally, and the error was this:
```
Undefined symbols for architecture x86_64:
"facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
"facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
ld: symbol(s) not found for architecture x86_64
```
## Fix
It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi":
```
arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version'
```
This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do?
Changelog:
[iOS][Fixed] - Fix Cocoapods builds of RNTester
Reviewed By: fkgozali, hramos
Differential Revision: D20905465
fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: scottrice
Differential Revision: D20495655
fbshipit-source-id: a57b72f694c533e2e16dffe74eccb8fdec1f55f5
Summary:
Logbox has a retain cycle (see linked task for my deeper investigation).
This diff doesn't fix the retain cycle, but it's just good practice to not retain self strongly in blocks.
Changelog: [iOS][Internal] Fix retaining self in block in LogBox implementation
Reviewed By: shergin
Differential Revision: D20630693
fbshipit-source-id: cf399495e9bcd1917932fcc0e9c9d2d2a32bf6f0
Summary:
The new name is get_preprocessor_flags_for_build_mode.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D20351718
fbshipit-source-id: 67628ce81e7244f0f72af2d00d92842a649ff619
Summary:
All `NSNumber *` arguments of NativeModules need to be marked with `__nonnull`. Otherwise, when TurboModules are disabled, we run into a RedBox.
Changelog:
[iOS][Fixed] - Fix RCTDevLoadingView RedBox on Reload
Reviewed By: PeteTheHeat
Differential Revision: D20292188
fbshipit-source-id: a8a5d0b2070575d7728b6308b129196242671fe6
Summary:
{emoji:26a0} This is a follow up to https://github.com/facebook/react-native/issues/25425 -- which isn't merged yet… See 2a286257a6..125aedbedc for actual diff
Currently, StatusBar native module manages the status bar on iOS globally, using `UIApplication.` APIs. This is bad because:
- those APIs have been deprecated for 4 years
- Apple really, really wants you to have an explicitly defined view controller, and control the status bar there
- it [breaks external native components](https://github.com/facebook/react-native/issues/25181#issuecomment-506792819)
- it's [not compatible with iPadOS 13 multi window support](https://github.com/facebook/react-native/issues/25181#issuecomment-506690818)
for those reasons I we should transition towards view controller-based status bar management.
With that, there is a need to introduce a default React Native root view controller, so I added `RCTRootViewController`. Using it is completely opt-in and there is no breaking change here. However I believe this should be a part of the template for new RN iOS apps.
Additionally, I added `RCTRootViewControllerProtocol` with hooks needed for RCTStatusBarManager to control the status bar. This means apps that want to have total control over their view controller can still opt in to react native VC-based status bar by conforming their root view controller to this protocol.
## Changelog
[iOS] [Added] - Added `RCTRootViewController` and `RCTRootViewControllerProtocol`
[iOS] [Fixed] - `UIViewControllerBasedStatusBarAppearance=YES` no longer triggers an error as long as you use `RCTRootViewController`
[iOS] [Fixed] - Status bar style is now correctly changed in multi-window iPadOS 13 apps if you use `RCTRootViewController` and set `UIViewControllerBasedStatusBarAppearance=YES`
Pull Request resolved: https://github.com/facebook/react-native/pull/25919
Test Plan: - Open RNTester → StatusBar → and check that no features broke
Reviewed By: fkgozali
Differential Revision: D16957766
Pulled By: hramos
fbshipit-source-id: 9ae1384ee20a06933053c4404b8237810f1e7c2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28058
I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: https://github.com/facebook/react-native/issues/25181#issuecomment-505612941
The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork.
- [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window
- [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: https://github.com/facebook/react-native/issues/25181#issuecomment-506690818
- [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13
- [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window
Next steps: Add VC-based status bar management (if I get the OK on https://github.com/facebook/react-native/issues/25181#issuecomment-506690818 ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass
## Changelog
[Internal] [Changed] - Modernize Modal to use RootTagContext
[iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support)
[iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg
[Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property
Pull Request resolved: https://github.com/facebook/react-native/pull/25425
Test Plan:
- Open RNTester and:
- go to Modal and check if it still works
- Alert → see if works
- ACtionSheetIOS → see if it works
- StatusBar → see if it works
- Share → see if it works
Reviewed By: PeteTheHeat
Differential Revision: D16957751
Pulled By: hramos
fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary:
This is a redo of D16969764, with a few extensions.
## Changes
1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}`
2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`.
3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView`
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D18642554
fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary: This diff reverts the iOS LogBox module back to the UIWindow strategy used by Redbox.
Reviewed By: sammy-SC
Differential Revision: D19941390
fbshipit-source-id: 4aea09137ea9e8bfc166a733272647a79102bf35
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
Scott Kyle
Peter Argany
Héctor Ramos
Ramanpreet Nara
Andres Suarez
Aditya Kumar
generatedunixname89002005325676
Luke Walczak
Kevin Gozali
Lulu Wu
Mark Sinkovics
Dustin Shahidehpour
Valentin Shergin
simek
Ullrich Schäfer
Eloy Durán
Devon Deonarine
Christoph Nakazawa
Rick Hanlon
Samuel Susla
Scott Wolchok
Hein Rutjes
generatedunixname89002005287564
Adam Ernst
Logan Daniels
radex
Arjan Zuidema
Mo Gorhom
Tommy Nguyen
Rachel Nabors
Janette Cheng
Josh Leibsly
Nicolas Charpentier
