Commit Graph

12 Commits

Author SHA1 Message Date
Andres Suarez 8bd3edec88 Update copyright headers from Facebook to Meta
Reviewed By: aaronabramov

Differential Revision: D33367752

fbshipit-source-id: 4ce94d184485e5ee0a62cf67ad2d3ba16e285c8f
2021-12-30 15:11:21 -08:00
Paige Sun 60e60a9b3d Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.

Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging

Reviewed By: fkgozali

Differential Revision: D32889043

fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
2021-12-08 14:51:04 -08:00
Ramanpreet Nara ddc4225dd4 Move NativeModule initialization logic outside of setModuleRegistry
Summary:
## Context
A while ago, we introduced a new initialization API in NativeModules via RCTInitializing.h (diff: D28435078 (https://github.com/facebook/react-native/commit/9b45df1fced066f40034b0a58be6f4caafd5f785)).

## Problem
A number of our NativeModules still use setModuleRegistry to perform initialization.

## Changes
This diff migrates those NativeModules to instead use the initialize API.

## Motivation
In bridgeless mode each NativeModule object is [created and decorated by the RCTInstance](https://www.internalfb.com/code/fbsource/[89f6c0df78e453a20555975e06bc46b4e0d2bbe9]/fbobjc/Apps/Internal/Venice/Core/RCTInstance.mm?lines=180-189), while [holding the TurboModuleManagerDelegate mutex](https://www.internalfb.com/code/fbsource/[c50ce2bb3fb078d28e1f9afdef5e8793f1413472]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModuleManager.mm?lines=429%2C431). After D30753286, setModuleRegistry will be called in RCTInstance getModuleInstanceForClass, which means that we'll start calling setModuleRegistry while holding the TurboModuleManagerDelegate lock. This leads to a deadlock, because calling setModuleRegistry on RCTDeviceInfo [creates RCTAccessibilityManager](https://www.internalfb.com/code/fbsource/[89f6c0df78e453a20555975e06bc46b4e0d2bbe9]/xplat/js/react-native-github/React/CoreModules/RCTDeviceInfo.mm?lines=50), which tries to acquire the TurboModuleManagerDelegate lock again. The NativeModule initialize method isn't called while holding the TurboModuleManagerDelegate lock. That's why moving all initialization logic to the initialize method mitigates this deadlock hazard.

In general, we shouldn't do any sort of initialization inside setters for these bridge/bridgeless APIs. No other NativeModules do initialization outside of initialize.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D30754870

fbshipit-source-id: 7c2d50f995cba6f58ee2dfebfabd36f640579bcb
2021-09-08 12:46:35 -07:00
Ramanpreet Nara 3f38186b78 Codemod: Give legacy cxx and ObjC-only NativeModules a getTurboModule: method
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
2021-04-08 21:15:52 -07:00
Ramanpreet Nara 41929eb9c5 Codemod: Migrate from bridge.devSettings to RCTModuleRegistry
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
2020-12-12 19:02:03 -08:00
Ramanpreet Nara e1fea9d152 Manual: Migrate from bridge.devMenu to RCTModuleRegistry
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
2020-12-12 19:02:03 -08:00
Hein Rutjes e2c417f7cf Fix crash when enabling Performance Monitor on iOS 13.4 (#28512)
Summary:
This PR fixes a crash when opening the Performance Monitor on iOS 13.4.
Detailed info: https://github.com/facebook/react-native/issues/28414

## Changelog

`[iOS] [Fixed] - Fix crash when enabling Performance Monitor on iOS 13.4`

## How

This PR prevents the JavaScriptCore option from being set altogether.
This ensures that the performance monitor keeps working, but on iOS 13.4 and higher, it will no longer crash trying to show the GC usage.
Pull Request resolved: https://github.com/facebook/react-native/pull/28512

Test Plan:
Tested on iOS 13.4 (simulator):

![image](https://user-images.githubusercontent.com/6184593/77903803-c6370c00-7283-11ea-8b71-b6b6546c82f6.png)

Tested on iOS 13.1 (simulator)

![image](https://user-images.githubusercontent.com/6184593/77903499-41e48900-7283-11ea-9d14-83f67a3b7b77.png)

- Verified that the `setOption` was called, but the Performance Monitor didn't show any GC usage regardless.
- Identical PR https://github.com/expo/react-native/pull/21 has been shipped and tested in Expo Client 37

Fixes https://github.com/facebook/react-native/issues/28414

Reviewed By: PeteTheHeat

Differential Revision: D20851131

Pulled By: TheSavior

fbshipit-source-id: ff96301036e8487db59f95947bbe6841fe230e1e
2020-04-03 20:44:20 -07:00
Valentin Shergin d0871d0a9a Clang format for all React Native files
Summary:
Buckle up, this enables clang-format prettifier for all files in React Native opensource repo.

Changelog: [Internal] Clang-format codemod.

Reviewed By: mdvacca

Differential Revision: D20331210

fbshipit-source-id: 8da0f94700be0c35bfd399e0c48f1706de04f5b1
2020-03-08 23:01:17 -07:00
Logan Daniels b85cb0cf7a Back out "Moving towards UIWindowScene support"
Summary:
Original commit changeset: ae2a4478e2e7

Changelog: [Internal]

Reviewed By: hramos

Differential Revision: D20289851

fbshipit-source-id: 1167ce8f5135411b80630b523c91c10e2b7eece1
2020-03-05 15:58:44 -08:00
radex b58e176af0 Moving towards UIWindowScene support (#28058)
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
2020-03-04 14:25:12 -08:00
Mo Gorhom 576ddfb3a8 Dark mode support for RCTPerfMonitor (#28130)
Summary:
Hi There 👋,

While I'm developing on iOS with dark appearance enabled, i notice that `Pref Monitor` view doesn't support dark mode yet, so here is the PR to fix it :)

## Changelog

[iOS] [Fixed] - Fix Pref Monitor in dark appearance
Pull Request resolved: https://github.com/facebook/react-native/pull/28130

Test Plan:
Run any React Native app on iOS > Turn on dark appearance
### Before
![Before](https://user-images.githubusercontent.com/4061838/74872974-8b75b600-535e-11ea-8550-763a598547ec.png)
### After
![After](https://user-images.githubusercontent.com/4061838/74872978-8ca6e300-535e-11ea-9862-4d3014e849f7.png)

Reviewed By: RSNara

Differential Revision: D20080019

Pulled By: PeteTheHeat

fbshipit-source-id: 9365daa3f7193a11760bc1372b8de2c3896def5c
2020-02-27 17:31:23 -08:00
Ramanpreet Nara 809d01095e Make RCTPerfMonitor TurboModule-compatible
Summary:
See title.

Changelog:
[iOS][Added] - Make RCTPerfMonitor TurboModule-compatible

Reviewed By: shergin

Differential Revision: D18145947

fbshipit-source-id: df2f0d60a4924f094cc4ec311b6bf570fb9fb7e1
2019-11-01 12:06:21 -07:00