Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary: This is a re-land of 66e0258885 after fixing internal build failures.
Reviewed By: mdvacca
Differential Revision: D15764832
fbshipit-source-id: f4fb347a9c6c02fb146b24ba395436bd31a37deb
Summary: D15753278 brokes the build on the armv7 arch. Just backing out this diff and the build works again.
Reviewed By: rzito
Differential Revision: D15758272
fbshipit-source-id: 4e3d3f5322346d31d6160b66b8fef15963baec83
Summary: An attempt to integrate the module flow types with internal codegen infra. Nothing of interest here, other than minor tweak on a spec (we don't support tupples...).
Reviewed By: mdvacca
Differential Revision: D15753278
fbshipit-source-id: b91d564fdbe8f72b90bea725779a9684993472b5
Summary:
Solve #25016
Use `OK` as default text for the affirmative button if no text is specified. When setting an alert on android with button configuration, and no `text` field specified no button is shown on the alert. This makes it impossible to dismiss. An example of how this can happen is creating a simple button where a `onPress` callback is used but no text is specified:
```
Alert.alert(
'title',
'message',
[ { onPress: () => console.log('onPress') } ],
)
```
Does not change the current behavior of no text button configurations on iOS. On iOS at least one button is always shown, and buttons with no text can be displayed.
Behavior on setting multiple buttons is a little wonky, but this PR does not aim to solve it. I did test these cases and included some examples below.
## Changelog
[Android] [Fixed] - Use OK as default text on Android Alert if button configuration specified without text
Pull Request resolved: https://github.com/facebook/react-native/pull/25033
Differential Revision: D15502780
Pulled By: cpojer
fbshipit-source-id: 505a9940f4588f4c10e25b67bfed8b8a1e610c69
Summary:
In D15367312, I deprecate `$Enum<...>` in favour of `$Keys<...>` (the functionality is identical). Codemod existing usages in xplat and fbcode.
bypass-lint
Reviewed By: samwgoldman
Differential Revision: D15378084
fbshipit-source-id: 251c6b9ac07cb50139a8f03e3a45a5fac0d91812
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
By default, an alert is `cancelable` on Android but not on iOS.
This PR changes the behavior so that the Alert is not dismissable on Android by default.
The motivation is that many developers develop on iOS and test on Android, and do forget to consider the case that the alert is dismissable.
Consistent behavior by default makes it easier to develop cross-platform apps in general.
---
For context and for your consideration, I have started a discussion here with the topic of whether React Native should try to use OS defaults or be consistent between platforms:
https://github.com/react-native-community/discussions-and-proposals/issues/121
---
If this PR gets merged, the docs should be updated as well:
https://github.com/facebook/react-native-website/blob/master/docs/alert.md#android
[Android] [Changed] - By default, alerts are not dismissable
Pull Request resolved: https://github.com/facebook/react-native/pull/24541
Differential Revision: D15044798
Pulled By: cpojer
fbshipit-source-id: 762b2ace69eb7ec79cd6ebec916e473348b9cafe
Summary:
In the past, Alert and AlertIOS were separate modules and both were shipped on Android even though only Alert can be used there. We unified the two modules but it meant that the code for both was still shipped on both platforms.
This diff changes it so that platform specific code is gated in a `Platform.OS` block, which means that the unnecessary code per platform is being stripped out. I'm not looking to win a beauty contest with the code in this module - we have barely touched it in years and I don't think we will touch it anytime soon, so I just merged the sub-classes (which only had static methods anyway) directly into the main class. I'm aware I could make two separate files with platform extensions but that ends up being more code here and it seems straightforward enough to me.
Reviewed By: TheSavior
Differential Revision: D14057404
fbshipit-source-id: 1ae1d227a39d76de9779b3db62960cca46e9b75c
Summary:
Itwas merged AlertIOS into Alert and removed type parameter from Alert.alert line 60 at Alert.js
[AlertIOS] [Change and Replace] - Merge AlertIOS into Alert.
Pull Request resolved: https://github.com/facebook/react-native/pull/23318
Reviewed By: mjesun
Differential Revision: D14031421
Pulled By: cpojer
fbshipit-source-id: 98db173adeb65aa90d309f8a583993bc0cddb6e1
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Summary:
Hi! I would like to contribute to React Native, and I am just starting out. I forked the repo and found that it has quite a lot of ESLint warnings – many of which were automatically fixable. This PR is simply the result of running `yarn lint --fix` from the root folder.
Most changes are removing trailing spaces from comments.
Haven't really done any manual testing, since I haven't done any code changes manually. `yarn test` runs fine, `yarn flow` runs fine, `yarn prettier` is satisfied.
N/A
[INTERNAL][MINOR][] - Fix ESLint warnings
Closes https://github.com/facebook/react-native/pull/18047
Differential Revision: D7054948
Pulled By: hramos
fbshipit-source-id: d53e692698d1687de5821c3fb5cdb76a5e03b71e
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
On Android it's generally expected that alerts are dismissible by tapping outside the alert box. This is the default behavior for React Native, but until now there has been no means to listen for the dismiss event.
`Alert.alert` already takes an `options` object, so this pull request simply adds an additional option `onDismiss`, a callback function that will be called when an Alert is dismissed (rather than being closed as a result of a button press).
**Test plan**
Simply pass an `options` object to `Alert.alert` with the `onDismiss` property set to a function.
e.g. Run the following on Android, dismiss the alert by tapping outside the alert view, and monitor console output.
```
Alert.alert(
'Alert Title',
'My Alert Msg',
[
{text: 'Ask me later', onPress: () => console.log('Ask me later pressed')},
{text: 'Cancel', onPress: () => console.log('Cancel Pressed'), style: 'cancel'},
{text: 'OK', onPress: () => console.log('OK Pressed')},
],
{ onDismiss: () => console.
Closes https://github.com/facebook/react-native/pull/12594
Differential Revision: D4619862
Pulled By: ericvicenti
fbshipit-source-id: fdd351a7b8e673dab331f0e22dc5ea2e84f24375
Summary:
In the 8e2906ae89 commit there was implemented a cancelable option for Alerts. It wasn't clear from the docs about this option and the additional Alert method's parameter.
Closes https://github.com/facebook/react-native/pull/11292
Differential Revision: D4342707
Pulled By: lacker
fbshipit-source-id: dc243b868106e705040e77bc90d4d9b8c2dc26eb
Summary:
after adding new parameter options in alert method, parameter type is the 5th.
Closes https://github.com/facebook/react-native/pull/10370
Differential Revision: D4021511
Pulled By: javache
fbshipit-source-id: 09476162b879d2081f0c0ac95260e673327871b8