Summary:
{emoji:26a0} This is a follow up to https://github.com/facebook/react-native/issues/25425 -- which isn't merged yet… See https://github.com/facebook/react-native/pull/25919/files/2a286257a6553a80a34e2b1f1ad94fc7bae36ea3..125aedbedc234c65c8d1b2133b79e926ad6cf145 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:
Changelog: [Internal]
Use LayoutContext to pass `fontSizeMultiplier` down to ParagrapShadowNode.
Reviewed By: shergin
Differential Revision: D20184596
fbshipit-source-id: 3965a127069a21328ed19cb3f9732f0a2d1c4d58
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
As discussed in https://github.com/facebook/react-native/issues/27863, the following changes were made to modernize the internal default logging function:
- `RCTDefaultLogThreshold` is now set to `RCTLogLevelTrace` in both release and debug builds—the Apple logging system will discard uncollected log entires, while allowing for collection when needed
- `RCTLogLevel` is translated to the appropriate log type
- The log subsystem is "com.facebook.react.log"
- `RCTLogSource` translates to the appropriate category ("native"/"javascript")
- Log the provided message using `os_log_with_type`
Closes https://github.com/facebook/react-native/issues/27863
## Changelog
[iOS] [Changed] - Use Apple unified logging API (os_log)
Pull Request resolved: https://github.com/facebook/react-native/pull/27892
Test Plan:
## From Original PR
Ran a test app in the iOS simulator, and verified that logs are correctly displayed in Console.app as well as using the following command:
```sh
/usr/bin/xcrun simctl spawn booted log stream --level debug --style compact --predicate 'process=="ReactNativeTesterApp" && subsystem=="com.facebook.react.log"'
```
## Peter's Test Plan
1. Apply P125583473
2. Verify log output in Xcode P125583504
3. Apply this diff
4. Verify log output in Xcode P125583597
These appear unchanged, after digging into why, I realized that FB doesn't even use the default log function, we inject a custom one [here](https://fburl.com/diffusion/887a1axs). So this PR shouldn't affect us at all. :)
Differential Revision: D19605414
Pulled By: PeteTheHeat
fbshipit-source-id: 1d70fb702c337a759905d4a65a951a31353ce775
Summary:
Re-landing the reverted change:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: sammy-SC
Differential Revision: D19411136
fbshipit-source-id: ec0a957dc57819f0ee7d138c858209cabe3e5102
Summary:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: hramos
Differential Revision: D19271321
fbshipit-source-id: 424ad7e2161261d148cb436cc20b4c531a4ba5b7
Summary:
This is a backout of the temporary workaround.
A proper fix was landed as D19249490.
Original commit changeset: 53d19e90e080
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19252609
fbshipit-source-id: 4a6239944440f392ef8a0e85a5038ee5f4d774f0
Summary:
This fix should stop T59424871 from bleeding. This is just an ugly workaround, I need some time to figure out a proper solution for that.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19244682
fbshipit-source-id: 53d19e90e080d6c3816c78869826ed2ec0c982eb
Summary:
Problem: Certain turbo modules use the bridge to access JS directly by calling something like `[_bridge enqueueJSCall:]`. In a bridgeless world, this API no longer works.
Solution: These turbo modules can implement the new protocol defined here. This protocol provides a block during module init which can be used to call JS directly (using `ReactContext`) instead of going through the bridge.
Changelog: [Internal][iOS] - Introducing RCTJSInvokerModule, a new protocol for turbo modules which call js
Reviewed By: RSNara
Differential Revision: D18941933
fbshipit-source-id: 8d581df06be59debf83575124e7d221145c5afb8
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:
Fixes https://github.com/facebook/react-native/issues/26830 by removing version gating around `RCTUserInterfaceStyleDidChangeNotification` sent by `RCTRootView` and observing that notif for `Dimensions` changes.
Also centralizes `RCTUserInterfaceStyleDidChangeNotification` constant definition in new `RCTConstants` file.
Changelog:
[iOS] [Fixed] - `Dimensions` module now updates on initial split screen
Reviewed By: sammy-SC
Differential Revision: D18931098
fbshipit-source-id: e9784be3f544f3b10360fbc2d6ad0324273b1a8f
Summary:
Since extensions does not have access to sharedApplication, give them an option to set the presentedViewController.
This will allow modules such as RCTAlertsManager to function correctly in extensions.
Changelog: [General] [Added] - Added RCTUtilsUIOverride as a way to shortcut obtaining presentedViewController from sharedApplication to a supplied view controller for extensions.
Reviewed By: PeteTheHeat
Differential Revision: D18620886
fbshipit-source-id: c752a6e328588f388e23be5270bf7da277182cca
Summary:
Extracts a new `RCTFormatStackTrace` function from `RCTFormatError`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18114387
fbshipit-source-id: 4466f52d75d9da3a257cd1cc7067492a0c19a7d5
Summary:
In D17880909 I migrated `[bridge reload]` to RCTReloadCommand.
One thing I didn't consider too much is the plethora of things which trigger a reload, and the `RCTAssertMainQueue()` constraint. I'd rather use locking (to protect listeners list) than requiring reloads be called from main thread.
Changelog: [iOS][Fixed] Fix potential assert firing in RCTReloadCommand
Reviewed By: rodrigos-facebook
Differential Revision: D18353156
fbshipit-source-id: d20b851fc5fe6c3518dfa3db8f1fc075cf7edee9
Summary:
This will allow us to catch cases where we use iOS 10-only APIs on iOS 9
Changelog: [Internal]
Reviewed By: TheSavior, mmmulani
Differential Revision: D18275225
fbshipit-source-id: dc9c515415208db40750be997173ce5bd6eb494f
Summary:
A very common pattern I've seen in RN codebase:
- (instancetype) init {
[[NSNotificationCenter defaultCenter] addObserver:self ...]
}
- (void) dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self ...]
}
From Apple:
https://developer.apple.com/documentation/foundation/nsnotificationcenter/1413994-removeobserver?language=objc
> If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
RN targets iOS9+
Changelog: [Internal][Cleanup] Remove unneeded NSNotification center removeObserver
Reviewed By: shergin
Differential Revision: D18264235
fbshipit-source-id: 684e5f5555cec96b055b13cd83daaeb393f4fac9
Summary:
This diff adds back RN reload reason, which was removed earlier in the stack. cc/Rick
For callsites which already had a reason, I kept the string exactly the same. For callsites which didn't have a reason, I made up something reasonable.
Changelog: [Internal][Fixed] Re-implemented bridge reload reason text.
Reviewed By: RSNara
Differential Revision: D18074478
fbshipit-source-id: 64a3cd7718674a7ba7228a80e34791ce9f153f9f
Summary:
`RCTBridgeWillReloadNotification` has one job: whenever bridge reloads - trigger a reload in `RCTSurfacePresenter`.
Diff 1/2 deprecated bridge reloading APIs, and replaced them with `RCTReloadCommand`. Use that in `RCTSurfacePresenter` instead .
Changelog: [iOS][Deprecate] Deprecate RCTBridgeWillReloadNotification
Reviewed By: shergin
Differential Revision: D17880926
fbshipit-source-id: 00adc4d56d11d40ab371d81bb17a05609c184769
Summary:
Motivation described in diff 1/N.
This diff replaces calls to `[bridge reload]` with calls to `RCTReloadCommand`. This shouldn't have any change in behaviour since RCTBridge listens to RCTReloadCommand and calls `[bridge reload]` [here](https://fburl.com/diffusion/kemzkrei).
It will allow us to customize who listens and reacts to RN lifecycle.
Changelog: [Internal][Changed] - Migrated [bridge reload] calls to RCTReloadCommand
Reviewed By: shergin
Differential Revision: D17880909
fbshipit-source-id: 80b26c6badd4b216656fed6dd04554e9877f4bb7
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
Summary:
The private API isPackagerRunning is useful. Rather than duplicating it, I am exposing it here so that I can make use of it in future PRs, and so others can do the same.
## Changelog
[iOS] [Changed] - Expose the isPackagerRunning methods on RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/27012
Test Plan: This change doesn't impact any runtime code, though it does impact build. I used a vanilla test app (react-native init) and built it using xcode as well as react-native run-ios.
Differential Revision: D18174316
Pulled By: cpojer
fbshipit-source-id: 523d134882303f68a1f69521e31f29d7dbfb666c
Summary:
This diff introduces a new broadcasting event for Bridge that communicates that the bridge is being invalidated. This notification can be used by interested parties as a signal to start tearing down all bridge-dependant processes.
The biggest difference between the new event and `RCTBridgeWillInvalidateModulesNotification` is that the latter is being called asynchronously on the JavaScript thread, whereas the new one is being called on whatever thread caused the Bridge invalidation (deallocation) *synchronously*. In most cases that happens on the main thread that allows destroying strictly-main-threaded infra (mostly UI) synchronously and avoids races.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18050889
fbshipit-source-id: 9364c820ea2b0358edf45f0e2b3e16a13d730a9c
Summary:
* Fabric surface hosting view should emit the same event as RCTRootView
* Before emitting to JS, make sure to check if the color scheme really changed to avoid unnecessary re-render in JS
Changelog: [Internal]
Reviewed By: mdvacca, mmmulani
Differential Revision: D18100700
fbshipit-source-id: 451199beac07cdfb3833131ee429cc151391d8dd
Summary:
Renders frames in RedBox in a greyed-out style when their `collapse` field is set to `true`. This avoids outright hiding information in the stack trace while still drawing attention to frames that are likely to be more meaningful.
Changelog: [General] [Changed] - Render collapsed JavaScript frames in RedBox
Reviewed By: rickhanlonii
Differential Revision: D18039438
fbshipit-source-id: 527588f11c0bff495842be7036cd1293bab65eb9
Summary: I made a mistake earlier and somehow prevented RCTRedBox showing up. Not sure why this didn't prevent them from showing up in dev mode.
Reviewed By: RSNara
Differential Revision: D17798516
fbshipit-source-id: 48bf0523124ad3fd96d626281390bbafc62f3390
Summary:
This diff adds server side logging for all log levels in development (some levels sampled)
There are two new mobile analytic event pipelines (that pipe to scuba table)
- rn_dev_logs ([pigeon](https://our.intern.facebook.com/intern/marauder/event/?name=rn_dev_logs) [scuba](https://fburl.com/scuba/pqxl6mf5))
- rn_dev_logs_sampled ([pigeon](https://our.intern.facebook.com/intern/marauder/event/?name=rn_dev_logs_sampled) [scuba](https://fburl.com/scuba/oqz6b5x3))
Notes:
- All React Native logs from JS and Native on iOS go through this path to be printed to the console, so everything will be caputured even though native errors/warnings do not necessarily show a red/yellow box
- All errors and warnings are logged
- Log level info is sampled
Reviewed By: sammy-SC
Differential Revision: D17789494
fbshipit-source-id: dea6359237dbd91f267949f5185a0c79bb4083b8
Summary:
This changes RCTLog to look for RCTRedBox at runtime and if so, send a log message to it.
This allows people to add their own redbox customizations that could be present at non-debug time.
Reviewed By: PeteTheHeat
Differential Revision: D17718913
fbshipit-source-id: e4545e112af2ff2ad197a0a82551ae4c6911ece9
Summary: Moves the reason to a constant because APPARENTLY this is a best practice in this establishment
Reviewed By: sammy-SC
Differential Revision: D17627819
fbshipit-source-id: 328fad8b7482d0e379a41b5f8c841f71db2bb5ac
Summary: This diff adds a method to call whenever a fast refresh happens. Right now this is only useful for reporting.
Reviewed By: cpojer
Differential Revision: D17528033
fbshipit-source-id: 17e82abe7a3e2bab6829de5adecda853fe5335c5
Summary:
This diff adds a new reloading method reloadWithReason that allows callers to provide a reason for why a reload was requested.
This reason is useful for understanding why users are reloading, and why Fast Refresh is bailing out to a full reload. I also updated the places we reload with the reasons listed below.
**Standard native reasons:**
- Redbox
- Command
- Global hotkey
- Profiling controls
- Dev menu - reload
- Dev menu - reset to default
- Dev menu - apply changes
**From JavaScript (added in a later diff):**
- Fast Refresh - Unrecoverable
- Fast Refresh - No root boundary
- Fast Refresh - Invalidated boundary
- Fast Refresh - Invalidated root boundary
**Misc reasons and fallback for when a reason is unavailable:**
- Unknown from JS
- Uncategorized from JS
- Unknown from bridge
- Unknown from cxx bridge
- Requested from bridge
- Custom executor class reset
Reviewed By: cpojer
Differential Revision: D17499339
fbshipit-source-id: 12a21ffa05708c9b921d93911f190cdffc5c78d5
Summary: The OSS change in this diff allows `RCTDisplayLink` to call out to an observer, even if the `RCTModuleData` isn't well formed. This is the case in bridgeless RN.
Reviewed By: ejanzer
Differential Revision: D17438647
fbshipit-source-id: 00d4d61d9126902180a7a77fc702f4221cf4d779
Summary: The OSS file touched in this diff is just a styling change.
Reviewed By: ejanzer
Differential Revision: D17400387
fbshipit-source-id: e51884d8942ba01e7da1662ac24429070e53a504
Summary:
Instead of relying on the bridge to do module setup, allow for regular initialization.
Instead of relying on the bridge to execute timers, allow for a delegate to do the work.
Reviewed By: RSNara
Differential Revision: D17375924
fbshipit-source-id: 83adabf8c962a5d90a4ea623618903cd9fb79a99
Summary: Previously, the `_scheduler` method in `RCTSurfacePresenter` was implemented as a lazy getter. The only problem with that is that Scheduler instance might be (re)created in the middle of the hot-reloading process (e.g. external request to relayout some Surface might trigger that). Since it does not make any sense to create an empty Scheduler during the reloading process, now the Scheduler creation only happens in constructor and right after the VM is reloaded.
Reviewed By: JoshuaGross
Differential Revision: D17299441
fbshipit-source-id: 273451bbb03e8cdf532131adfdf3bc60c34e997e
Summary:
For now, disable TM completely in test environment, like RNTester integration/unit tests. See details in T53341772
This also fixes the failure discussed in https://github.com/facebook/react-native/pull/26151
Reviewed By: PeteTheHeat
Differential Revision: D17147915
fbshipit-source-id: 1c48ebb9c3b81fc08bc33606dcc38c29297d6010
Valentin Shergin
Logan Daniels
radex
Samuel Susla
Tom Underhill
Mihai
Tommy Nguyen
Leo Natan
Kevin Gozali
Jiawei Lv
Peter Argany
Andy Matuschak
Spencer Ahrens
Chunlok Lo
Moti Zilberman
Ramanpreet Nara
Adam Foxman
Andres Suarez
Mehdi Mulani
Rick Hanlon
Oleksandr Padalko
