Summary:
This diff switches the native codegen over to the flow parser
It does this by:
- Creating a new e2e directory
- Migrating the schema.js fixtures to flow types in e2e/
- Updating the buck tests to use the flow type fixtures
- Finally, updating the rest of rn_codegen to use *NativeComponent instead of *Schema.js
Removing all of the schemas in the next diff to keep this one clean
Reviewed By: cpojer
Differential Revision: D15960603
fbshipit-source-id: 3df28b31e618491301578ab7f6e28a80f55404b2
Summary:
Metro symbolication can be expensive in large apps. However, there is no need to symbolicate _runtime stacks from compile errors_. Those are pretty much useless anyway.
This will reduce the workload on Metro workers, and the delays when iterating with Fast Refresh, as the server will be busy much less often.
So I'm special-casing them and not sending the symbolication request anymore.
Reviewed By: rickhanlonii
Differential Revision: D16030087
fbshipit-source-id: 41f83ac01780c0a60cca777014e4ed95c0f3d14b
Summary: This bumps the dependency so I can get a new export I added.
Reviewed By: rickhanlonii
Differential Revision: D16030064
fbshipit-source-id: 2b539f04d4fbc21c097c0f1d1d1e7b59f376a894
Summary:
On `textContentType` `newPassword` on ios, there is another property called `passwordRules` on ios 12 that can give hints to the os to generate a password with specific requirements like [here](https://developer.apple.com/password-rules/).
This is useful for apps that have a "register" screen with `emailAddress`/`username` and a `newPassword` fields, to let ios make a password that will satisfy the requirements and not one that might be not accepted after the user presses "register".
## Changelog
[iOS] [Added] - PasswordRules for new password textContentType input fields
Pull Request resolved: https://github.com/facebook/react-native/pull/25407
Test Plan: This is a bit harder, but to test you need to make an app that has associated domains with an apple-app-site-association file on that domain, enable iCloud Keychain on the test device, and then iOS will suggest a password, otherwise you will just get a warning on Xcode saying "Couldn't suggest password because of: blabla".
Differential Revision: D16028684
Pulled By: cpojer
fbshipit-source-id: d22426e07f1db45d1f79f5dad81f1465a9701f0b
Summary:
`TimePickerAndroid` has been merged With `DatePickerIOS` and `DatePickerAndroid` as part of Lean Core. See [repo](https://github.com/react-native-community/react-native-datetimepicker)
## Changelog
[General] [Deprecate] - Warning for `TimePickerAndroid`
Pull Request resolved: https://github.com/facebook/react-native/pull/25409
Test Plan: Warning prints when user imports `TimePickerAndroid`
Differential Revision: D16028676
Pulled By: cpojer
fbshipit-source-id: 5dfdb6d7cc144f7a171892ebd1f6b6b9b6334b56
Summary: The metheod viewIsDescendantOf is not used anymore, this diff removes it from Android code
Reviewed By: fkgozali
Differential Revision: D16014664
fbshipit-source-id: e189be38a02cdf5c07ceab13454d52ab842fd0ca
Summary: The method 'viewIsDescendantOf' is not used in JS, to prevent future usages of this method we just remove it.
Reviewed By: JoshuaGross
Differential Revision: D16014666
fbshipit-source-id: da623a455df04851ce286427fb54849e4e9e720a
Summary: This view exists on RNTester for iOS. It appears to not be registered.
Reviewed By: PeteTheHeat
Differential Revision: D16010940
fbshipit-source-id: b30b347b688352f74a596eb2f75bedae70be80c2
Summary: For consistency, we use the files checked in to github.
Reviewed By: JoshuaGross
Differential Revision: D15993128
fbshipit-source-id: 1e9fdd6b4111284c84cbd5a63d384ef481659b01
Summary: Now that the Pods/ directory is excluded by ShipIt from GitHub, we can move the Pods/ directory into react-native-github.
Reviewed By: fkgozali
Differential Revision: D15944730
fbshipit-source-id: b8165abbb4e6fef5ad4311da3885187b84ad1b20
Summary: In some cases, we cannot retrieve the "committed" state because no one state was mounted yet. The whole concept of "confirmed" or "legit at the moment" is kinda overstatement. The actual meaning of this is "the last vision of the state to which we advanced so far"; it does not have any relation to the actual "commit" phase or "mounting" process.
Reviewed By: sammy-SC
Differential Revision: D16002127
fbshipit-source-id: 95465e632525f873ae67f6db320a89562b62ba29
Summary:
ScrollView doesn't handle the scrollEnabled property using dpad. When set to false, the directionnal pad still allows to scroll in the view.
## Changelog
[ANDROID] [ADDED] - Prevent scrollView to scroll with dpad when scrollEnabled property is set to false.
Pull Request resolved: https://github.com/facebook/react-native/pull/25309
Test Plan:
Add P67680731 to Playground.js and start the Catalyst Android app:
```buck install -r catalyst```
Send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_LEFT```
```adb shell input keyevent DPAD_RIGHT_RIGHT```
Make sure the ScrollView doesn't scroll to the left and right.
Add ```horizontal={true}``` to ScrollView and send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_TOP```
```adb shell input keyevent DPAD_RIGHT_BOTTOM```
Make sure the ScrollView doesn't scroll to the top and bottom.
Reviewed By: mdvacca
Differential Revision: D15983785
Pulled By: makovkastar
fbshipit-source-id: 678cc801a168531d71c8651b986c99ecd9da400e
Summary: `ReactPackageTurboModuleManagerDelegate.getLegacyCxxModule` isn't called from Java. Therefore, ProGuard will strip this method to reduce code size. To prevent this, we need to add the `DoNotStrip` annotation to this method. This annotation isn't necessary for the `getModule` method, since `getModule` is used in `TurboModuleManager.getJavaModule`.
Reviewed By: fkgozali
Differential Revision: D15996432
fbshipit-source-id: d34a7d28f7678e2dfc917f52d5cacc286bc33a0a
Summary:
Right now JS triggers a view manager command with the following code:
```
UIManager.dispatchViewManagerCommand(
nullthrows(this.scrollResponderGetScrollableNode()),
UIManager.getViewManagerConfig('RCTScrollView').Commands.scrollTo,
[x || 0, y || 0, animated !== false],
);
```
As we want to get rid of calls to UIManager, we need to stop looking for the integer defined in native from JavaScript. We will be changing methods like this to be:
```
UIManager.dispatchViewManagerCommand(
nullthrows(this.scrollResponderGetScrollableNode()),
'scrollTo',
[x || 0, y || 0, animated !== false],
);
```
We need to support ints and Strings to be backwards compatible, but ints will be deprecated.
This is the same change as made for Android here: https://github.com/facebook/react-native/commit/3cae6fa950eed54bccccf61a28c0e85d5a004c6c
Reviewed By: PeteTheHeat
Differential Revision: D15983041
fbshipit-source-id: 6cb0f3001553d1f9d26e7e8fb5481e16fbca6847
Summary:
Continuing https://github.com/facebook/yoga/pull/791
nokia6686 is a former member of our team, so we are trying to pick up what he left and carry out the pull request.
# Solution
Improved from previous solution with jpap's suggestions.
2. Passing ```gDepth``` and ```gCurrentGenerationCount``` (renamed to **_depth_** and **_generationCount_** respectively) between function calls that stem from ```YGNodeCalculateLayout```.
In ```YGNodeCalculateLayout```, pass ```depth``` as value 0, to indicate the root depth.
Pull Request resolved: https://github.com/facebook/yoga/pull/852
Reviewed By: SidharthGuglani
Differential Revision: D15537450
Pulled By: davidaurelio
fbshipit-source-id: 338f51383591ba27702ebe759f6c47c2dede3530
Summary:
Cleans up the implementation of `AndroidPicker` and the Flow types for the native components to almost work with `codegenNativeComponent`.
The remaining blocker is that the `items` prop is an array of objects: https://fburl.com/km8uj8x2
Reviewed By: rickhanlonii
Differential Revision: D15805611
fbshipit-source-id: 34bea83db8dbaaf6eb23b00e73e0c7ce292e8a32
Summary:
Note: iOS only.
This spec file (.h/.mm) was generated via FB internal codegen tool for TurboModule. The tool itself is not yet ready to be opensourced, but at least the generated file is. The output is based on all the Flow types added via https://github.com/facebook/react-native/issues/24875.
This file can be used by each ObjC NativeModule to be TurboModule compliant.
Reviewed By: rickhanlonii
Differential Revision: D15978911
fbshipit-source-id: 9e97495287bc406e0ed0ccf89cf370753b538772
Summary: This util is used for TurboModule codegen system - it's not used anywhere else for now.
Reviewed By: JoshuaGross
Differential Revision: D15971956
fbshipit-source-id: 3cb1c3df7fa96fd51d420abff1fbfd07b18fdae6
Summary:
TurboModuleManager was initialized in `ReactInstanceManager.setupReactContext`, which is executed on the NativeModule thread after we call `ReactInstanceManager.createReactContext` on a new thread. `NativeModuleRegistry` is initialized in `ReactInstanceManager.createReactContext`, so if someone requests a TurboModule after `ReactInstanceManager.createReactContext` is called and before `ReactInstanceManager.setupReactContext` fully finishes executing, that TurboModule won't be found.
This diff moves TurboModuleManager initialization into `ReactInstanceManager.createReactContext`
Reviewed By: fkgozali
Differential Revision: D15978486
fbshipit-source-id: 734e83eced414e545fe275e9a124d0df35204c40
Summary:
We should remove all usages of React's legacy context API because it'll be removed from React at some point, it prevents some performance optimizations in updates and can cause conflicts between different context providers (like mixins).
This creates a new Context for `rootTag` (this granularity is intentional) so users that are consuming it via the legacy context API can start migrating away from it.
I didn't create a more generic context (like ReactRootContext, ReactApplicationContext) because having a more granular context makes it easier to track and remove it if we want to, and prevents re-rendering when users only care about certain values.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D14941918
fbshipit-source-id: 7ceea62727d10a591367b7ed7c447309b286758d
Summary:
When starting a React Native app, one gets to see the message in the image.
I propose to remove it, because it provides little information to the developer and is noisy.
```
Initializing <RCTCxxBridge: 0x7fded270fbf0> (parent: <RCTBridge: 0x600001b95570>, executor: (null))
```
## Changelog
[iOS] [Fixed] - Debug message was logging to the console
Pull Request resolved: https://github.com/facebook/react-native/pull/25381
Test Plan: -
Differential Revision: D15983841
Pulled By: cpojer
fbshipit-source-id: 27f7d25ee0c580640d03f0db9adcd3c2a205b270
Summary:
`DatePickerIOS` and `DatePickerAndroid` have been merged as part of Lean Core. See [repo](https://github.com/react-native-community/react-native-datetimepicker)
## Changelog
[General] [Deprecate] - Warning for `DatePickerIOS` and `DatePickerAndroid`
Pull Request resolved: https://github.com/facebook/react-native/pull/25374
Test Plan: Warning prints when user imports `DatePickerIOS` or `DatePickerAndroid`
Differential Revision: D15983829
Pulled By: cpojer
fbshipit-source-id: dfa35e204bb133a1b8de67c25abaa4338b956901
Summary:
Updated the `code of conduct` within TOC in order to point to the respective section.
## Changelog
[General] [Fixed] - Minor markdown fix
Pull Request resolved: https://github.com/facebook/react-native/pull/25385
Test Plan: N/A
Differential Revision: D15983819
Pulled By: cpojer
fbshipit-source-id: 3530dce8a6be0b6d3bc411f03b37a0cd05da5f53
Summary: `Target` inside the Stage can be empty; in this case, we should not try to extract `ShadowNode` from it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15982479
fbshipit-source-id: 83a4bebadc88b59d7fe77acbdf07e8ce9f2f6be1
Summary: The method ReactChoreographer.postFrameCallbackOnChoreographer should be private and it should be called from a context that contains the lock mCallbackQueuesLock
Reviewed By: JoshuaGross
Differential Revision: D15891758
fbshipit-source-id: fedba0db663aade25dbad1ef7151df1e340e05f6
Summary: This diff extends the ReactChoreographer to allow the execution of FrameCallbacks that removes another FrameCallback from the mCallbackQueues.
Reviewed By: ejanzer
Differential Revision: D15891759
fbshipit-source-id: 62bc2b6afac45c50ac18771b0821742b4f7fc10e
Summary: The schema for these view commands is lifted wholesale from the schema for TurboModules: P67239314
Reviewed By: rickhanlonii
Differential Revision: D15943109
fbshipit-source-id: a0ccd4e47067b62970218df6a32527c15868c4a5
Summary:
Right now JS triggers a view manager command with the following code:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
UIManager.getViewManagerConfig('RCTView').Commands.hotspotUpdate,
[destX || 0, destY || 0],
);
```
As we want to get rid of calls to UIManager, we need to stop looking for the integer defined in native from JavaScript. We will be changing methods like this to be:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
'hotspotUpdate',
[destX || 0, destY || 0],
);
```
We need to support ints and Strings to be backwards compatible, but ints will be deprecated.
Reviewed By: shergin
Differential Revision: D15955444
fbshipit-source-id: d1c488975ae03404f8f851a7035b58a90ed34163
Summary: This fixes a crash happened in Image component caused by a race between recycling a component and image loading event are being delivered asynchronously.
Reviewed By: mdvacca
Differential Revision: D15977418
fbshipit-source-id: ac6f4b3d2b995af2afd56e551380a32d0f14ab15
Summary: The app crashed on assert which was not actually legit. See the comment in the code.
Reviewed By: JoshuaGross
Differential Revision: D15976177
fbshipit-source-id: 612bbbd510187ffdc86369aa943d4b652b748694
Summary: If you make a syntax error while there is a redbox while Fast Refresh is on, we should dismiss that redbox. Otherwise there is no way for you to tell why your code is not working.
Reviewed By: rickhanlonii
Differential Revision: D15970337
fbshipit-source-id: 1ca6c9a1b2269d198ae726d3b64e5c51506503db
Summary: This updates the renderer and Fresh packages to pull in the new error handling behavior. The new feature is that roots that errored on last save get remounted after an edit. This allows much faster iteration in the Fast Refresh mode as you don't need to do a full reload after typos.
Reviewed By: bvaughn
Differential Revision: D15967396
fbshipit-source-id: 96a82e6a4e00a8cb636d7bca037a1a43552a4cd2
Summary:
If the error doesn't come in direct response to a user action, I think a redbox is too severe. I think we don't want to associate turning on Fast Refresh with a higher frequency of redboxes. So this downgrades these messages to warnings.
If you manually try to turn it off and on again, we'll still show a redbox to remind why it's not working.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D15958952
fbshipit-source-id: bd144c98e87a9836871391ac583c268dca8009b3
Summary:
We have too many options in the Dev Menu, and they're really hard to pick from. They're also somewhat conflicting. This replaces two menu choices that have a similar purpose (faster iteration cycle) with one.
"Fast Refresh" tries to only update the affected modules, but falls back to doing a full reload if the update can't be handled by the React components.
If for some reason you prefer the "Reload-on-Save" behavior, please:
- Reach out to me so I can learn more about your use case.
- As a workaround, you can add `if (__DEV__) require.Refresh.forceFullRefresh = true` to your app's entry point to always do a full refresh.
Also note that I only removed the user-facing part of "Reload-on-Save". So if you have automation depending on it, that's gonna keep working.
I moved it above Systrace since it's a more generic feature.
As a total aside nit, I renamed "Enable Inspector" and "Disable Inspector" to "Show Inspector" and "Hide Inspector" because... that's what those options do, really.
Reviewed By: rickhanlonii
Differential Revision: D15958697
fbshipit-source-id: 20e856d56f661fe4d39b5ab47d8c44754bf70f67
Summary: The onRefresh event is a DirectEvent not a BubblingEvent
Reviewed By: PeteTheHeat
Differential Revision: D15969475
fbshipit-source-id: 049a6ffc74306246e8dbc3acdce5b0b26e849fc7
Summary:
Since we always create `module.hot` objects, the `module.hot` checks were unnecessary. They give a false impression that we're checking for a Hot Reloading mode. However, they're just Flow refinements and always exist in DEV. I made that explicit by throwing early.
Similarly, I removed a `module.hot` check inside `setupReactRefresh`, as it is always truish in DEV.
Finally, I'm adding a new mechanism as an escape hatch. It lets you do:
```
if (__DEV__) {
require.Refresh.forceFullRefresh = true;
}
```
in your entry point and opt into full refreshes on every edit. This sounds similar to "Reload-on-Save". That is because in the next diff, I plan to remove "Reload-on-Save" from user-visible options (but it'll stay for automated workflows).
So this workaround is intended for people who for one reason or another don't want to opt into Hot Reloading as an alternative. We'll need to talk to them and find out why.
Reviewed By: rickhanlonii
Differential Revision: D15958475
fbshipit-source-id: 674187ddf86a4e286dfae28f4182555a8b5d7396
Summary:
As we saw in D15947985, and later traced down to D5623623, the `hot` option isn't used by Metro anymore. The relevant transforms _always_ run in DEV regardless of the option.
Given that, it doesn't make sense that enabling or disabling Hot Reloading forces a full refresh. This significantly raises the usage barrier because **currently, you might have to wait ~20 seconds (on a large app) to just start using Hot Reloading when you're already in the middle of some screen.** So you just end up not using it.
This diff changes enabling/disabling Hot Reloading to be _instant_.
Here's how it works:
1. Now we always send the necessary info to the client via the new `HMRClient.setup()` function. It creates a Metro HMR client instance, but only actually sets up the socket if Hot Reloading is on.
2. The "Enable Hot Reloading" menu no longer forces a reload. Instead, it calls `HMRClient.enable()` which lazily sets up a socket (at most once).
3. The "Disable Hot Reloading" menu also doesn't trigger a refresh now. Instead, it calls `HMRClient.disable()`. We don't actually tear down the socket here because it's a pain to deal with race conditions and such. Instead, we keep the connection — but we _ignore the updates_ that come in while we're disabled.
4. As a result, it is possible to enable and disable it many times during a single session. (Updates while disabled would be ignored — which has a risk of making your running app inconsistent — but I'd argue it's expected and is worth it. You can always save a particular file to force it to update once the mode is on.)
5. In order to support "ignoring" updates, Metro's `HMRClient` (not to be confused with RN's module) now supports a `shouldApplyUpdates` field. The RN module uses it to disable handling updates when the mode is off.
6. In case there is an error that makes hot reloading unavailable (such as the server disconnecting), we surface the error only if the mode is on. If the mode is off, we stash the error message in the `_hmrUnavailableReason` variable, and display it next time you try to enable Hot Reloading.
Reviewed By: rickhanlonii
Differential Revision: D15958160
fbshipit-source-id: 8256fc4d5c2c3f653a78edf13b8515a5671953e4
Summary: Passing whether layout cache or measure cache was used or not
Reviewed By: davidaurelio
Differential Revision: D15920937
fbshipit-source-id: a6728e7af07ea228a285f824fbdfddc8130c5990
Summary:
Added event NodeLayoutEnd and this is being used now instead of NodeLayout
It will be used later to add more information about caches
Reviewed By: davidaurelio
Differential Revision: D15920935
fbshipit-source-id: c9f5e193bc8cc70d26ff5d84882d483c9b09f67d
Rick Hanlon
Dan Abramov
Pavlos Vinieratos
Luis Miguel Alvarado
soh335
Panagiotis Vekris
David Vacca
Eli White
Kevin Gozali
Héctor Ramos
Valentin Shergin
aamalric
Ramanpreet Nara
dattc2
Tim Yung
Rubén Norte
Jonny Burger
James George
Marco Zandonadi
Sidharth Guglani
