Commit Graph

8 Commits

Author SHA1 Message Date
Ramanpreet Nara 6de3fffc37 Memoize repeated calls to getConstants() in MP Home, and Search
Reviewed By: fkgozali

Differential Revision: D21899206

fbshipit-source-id: 44ab118dc49697c1270d3c3f164c1ddf7bef0be4
2020-06-05 11:35:09 -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
Eli White e362470305 Convert easy files to flow strict-local
Summary:
This diff was generated by this script used by WWW
https://our.intern.facebook.com/intern/diffusion/WWW/browse/master/scripts/flow/upgrade_to_flow_strict_local.sh?lines=0

Changelog:
[Internal] Upgrade flow to flow strict-local

Reviewed By: zackargyle, rickhanlonii

Differential Revision: D18833630

fbshipit-source-id: e64d4e9a49a0db5e6bf70a0c489567862b578d7f
2019-12-05 16:06:46 -08:00
Kevin Gozali fb627dac6a TM JS: Revert to import from TurboModuleRegistry.js
Summary:
Changelog: [Internal]

Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.

Reviewed By: yungsters

Differential Revision: D18383893

fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
2019-11-08 11:44:16 -08:00
Kevin Gozali dd06f85bd0 TM JS: cleaned up TurboModuleRegistry types [2]
Summary:
Changelog: [Internal]

Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078

Reviewed By: yungsters

Differential Revision: D18262538

fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
2019-11-04 18:51:05 -08:00
Ramanpreet Nara dc12676e3a Make RCTStatusBarManager TurboModule-compatible
Summary:
See title.

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

Reviewed By: shergin

Differential Revision: D18130374

fbshipit-source-id: 3ec226bcff17e47ffd9eba05e32c1eb68d6135b2
2019-11-01 12:06:20 -07:00
Ramanpreet Nara a257083d2b Split NativeStatusBarManager into NativeStatusBarManager{Android,IOS}
Summary:
The `StatusBarManager` NativeModule does not have a uniform API on iOS and Android. In particular, the `setStyle` and the `setHidden` methods have an additional parameter on iOS:

```
/**
 *  - statusBarStyles can be:
 *    - 'default'
 *    - 'dark-content'
 *    - 'light-content'
 */
+setStyle: (statusBarStyle?: ?string, animated: boolean) => void;
/**
 *  - withAnimation can be: 'none' | 'fade' | 'slide'
 */
+setHidden: (hidden: boolean, withAnimation: string) => void;
```

If we keep the NativeModule spec the same between the two platforms, we'd have to keep the second parameter optional for both methods. This works for `setHidden`, because the second parameter is a string, and optional strings are allowed. However, for `setStyle`, the second parameter is a number, and we don't support optional numbers/booleans on Android in the NativeModule system. If we keep the optional number, then the following check triggers in our RedBox tests on iOS, which makes them fail: https://fburl.com/diffusion/b7adezd9.

So, since the two specs are sufficiently different, I figured that the easiest path forward is to split them apart.

Changelog:
[iOS][Changed] - Separated NativeStatusBarManager into NativeStatusBarManager{IOS,Android}

Reviewed By: PeteTheHeat

Differential Revision: D18214161

fbshipit-source-id: 6fd8b8c5f576244b5b90ee47faa7f50508c5e1d3
2019-11-01 12:06:20 -07:00