Summary:
We had a classic integer underflow problem here. Before we would let you type endlessly when the text already exceeded the TextInput maxLength, now we only let you erase characters.
There is still a small problem with the TextInput: how do you handle when the value (set from JS) exceeds the maxLength? This could happen pragmatically, just by passing in a very large value or when changing maxLength (e.g. when changing from 4 to 3 digits in the case of a AMEX security code -> VISA security code).
Me and achen1 discussed firing onChange in these cases and truncating the number manually (to ensure JS's data model) was aware of the change but it seemed fraught with bugs and general weirdness in what the caller would expect to happen.
Reviewed By: javache
Differential Revision: D3991210
fbshipit-source-id: dc401c4a7aefe09fa749cd1168d36343d39dc196
Summary:
- Consolidate common code in iOS and tvOS test scripts
- Start the packager before starting tests, to improve reliability
- Increase timeout value in RCTTestRunner.m
Closes https://github.com/facebook/react-native/pull/10378
Differential Revision: D4028364
Pulled By: bestander
fbshipit-source-id: 24c2124a1c62643a02f0668b60a67b971e08d1a3
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10413
Differential Revision: D4028108
fbshipit-source-id: 99a864dfda578d640f582b296583591415ba26cd
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
This test wasn't being run externally (it's not added to the xcode project) or internally.
It doesn't even test anything related to RN.
Reviewed By: javache
Differential Revision: D4021791
fbshipit-source-id: fee3fd5e1c3ef47f5bc8480cdc98a10b4da21815
Summary: Fixes remaining references to `ReactElement` that did not already have `React` in scope.
Reviewed By: bestander, vjeux
Differential Revision: D4022022
fbshipit-source-id: 4aeacee0cdbb2c825feba10282208316d064c578
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary:
Button is an important component to help the community get onboarded with RN quickly, so the first few minutes of a developer's experience is not spent formatting a simple button component.
In my opinion, `<Button />` should be seen as a "lowest common demoniator" component, rather than "the one button to rule them all". In other words, we should only support features in Button that will work on any platform. We should encourage people to fork Button if they need to add specific features to it, rather than trying to twist and bloat this component until it supports everything.
These platform imitations may not have the perfect constants just yet, but they are good enough to make a user feel at home in the app, without any modification. The community can help tweak the final formatting to make them look just right- PRs are welcome!
Reviewed By: frantic
Differential Revision: D3929041
fbshipit-source-id: 3785fb67472a7614eeee0a9aef504c0bdf62ede7
Summary:
* Motivation *
Second PR for Apple TV support.
* Test plan *
Apple TV tests have been added to scripts/objc-test.sh
Closes https://github.com/facebook/react-native/pull/10227
Differential Revision: D3974064
Pulled By: javache
fbshipit-source-id: 36dffb4517efa489e40fa713a30655d1d76ef646
Summary:
Packager can take a long time to load and the progress is usually displayed in another window (Terminal). I'm adding support for showing a UI inside React Native app for packager's progress when loading a bundle.
This is how it will work:
1. React Native sends request to packager with `Accept: multipart/mixed` header.
2. Packager will detect that header to detect that client supports progress events and will reply with `Content-Type: multipart/mixed`.
3. While building the bundle it will emit chunks with small metadata (like `{progress: 0.3}`). In the end it will send the last chunk with the content of the bundle.
4. RN runtime will be receiving the events, for each progress event it will update the UI. The last chunk will be the actual bundle which will end the download process.
This workflow is totally backwards-compatible -- normally RN doesn't set the `Accept` header.
Reviewed By: mmmulani
Differential Revision: D3845684
fbshipit-source-id: 5b3d2c5a4c6f4718d7e5de060d98f17491e82aba
Summary:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
Summary:
This adds support for `Animated.event` driven natively. This is WIP and would like feedback on how this is implemented.
At the moment, it works by providing a mapping between a view tag, an event name, an event path and an animated value when a view has a prop with a `AnimatedEvent` object. Then we can hook into `EventDispatcher`, check for events that target our view + event name and update the animated value using the event path.
For now it works with the onScroll event but it should be generic enough to work with anything.
Closes https://github.com/facebook/react-native/pull/9253
Differential Revision: D3759844
Pulled By: foghina
fbshipit-source-id: 86989c705847955bd65e6cf5a7d572ec7ccd3eb4
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
Pulled By: fred2028
fbshipit-source-id: d346068734c5b987518794ab23e13914ed13b5c4
Summary:
since #9456 has been landed, it's the time to add ListViewPagingExample to the example list for Android
Closes https://github.com/facebook/react-native/pull/9930
Differential Revision: D3871517
fbshipit-source-id: dafa8ab2d704bcc5e7bc25b5fcec18a1a6cfa28a
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
fbshipit-source-id: cab044cfdbe2ccb98e1ecd3e02ed3ceaa253eb78
Summary:
We've enabled getters in .flowconfig, so Flow will now understand react-native.js. We no longer need to maintain a separate file for Flow.
cc bestander
Closes https://github.com/facebook/react-native/pull/9892
Differential Revision: D3862560
Pulled By: bestander
fbshipit-source-id: 9efb66bc885dbac80c18b4b5e3cf5362495928a9
Summary:
This is an updated version of #2336 and #7694.
---
This adds a `registrationError` event that is emitted by `PushNotificationIOS` whenever an application receives a registration error from APNS (APNS service failure, running on simulator, etc). This event fires to the exclusion of the `register` event (and vice versa).
**How to use**
Add the following to your `AppDelegate.m`:
```obj-c
- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error
{
[RCTPushNotificationManager didFailToRegisterForRemoteNotificationsWithError:error];
}
```
And register an event handler for the event:
```js
PushNotificationIOS.addEventListener('registrationError', function({ message, code }) {
// Complete your registration process in error.
});
```
**Test plan**
Added support for this event (and `register`) to UIExplorer as a proof of concept. Navigating to the push notifications example on a simulator is an easy way to reproduce this e
Closes https://github.com/facebook/react-native/pull/9650
Differential Revision: D3822142
Pulled By: javache
fbshipit-source-id: a15ed8941b74dc3eed2c44c658deccbcaf39ce3d
Summary:
Currently, when reloading uiexplorer, it does not go back to the last visited
component. This fixes it, by only storing the state (which contains the last
visited component), after it has been set.
Reviewed By: bestander
Differential Revision: D3821288
fbshipit-source-id: 5b9ba10765ce402c20016519a3b7f6b5211cc623
Summary:
Similar to iOS, send device orientation changes events. This does not have the
`getCurrentOrientation` method, because it's not used. If necessary, we'll
add it separately.
This also adds a simple example for testing.
We listen to orientation changes in `onGlobalLayout`, and check if the rotation of the device has changed. If it has, we emit the event.
But:
- `onGlobalLayout` (and `onConfigurationChanged` - which is the method usually used for checking for device orientation changes) is *not* called when the device goes from landscape
to reverse landscape (same with portrait), as that is not a relayout / configuration change. We could detect if this happens with the help of an `OrientationEventListener`. However, this listener notifies you if the degree
of the phone changes by a single degree, which means that you need to know by how many degrees the phone needs to change in order for the orientation to change. I haven't looked into how accurate this could be, but I suspect that in practice it would cause a lot of bugs. A simple `abgs` and google search reveals that everybody uses a different margin for detecting a rotation change (from 30 to 45 degrees), so I suspect that this won't work
as expected in practice. Therefore, we're not using this here, and we're sticking to what android provides via `onConfigurationChanged`. If we find that we have issues because users need to know when the user goes
from landscape to reverse landscape, then we'll have to revisit this.
Reviewed By: foghina
Differential Revision: D3797521
fbshipit-source-id: 62508efd342a9a4b41b42b6138c73553cfdefebc
Summary:
Android PR for TextInput selection, based on the iOS implementation in #8958.
** Test plan **
Tested using the text selection example in UIExplorer.
Closes https://github.com/facebook/react-native/pull/8962
Differential Revision: D3819285
Pulled By: andreicoman11
fbshipit-source-id: 9a2408af2a8b694258c88ab5c46322830c71452a
Summary:
This adds cookie clearing support for iOS to match the existing support on Android. Helpful for resetting the app to a clean state (say, when logging a user out).
Closes https://github.com/facebook/react-native/pull/9264
Differential Revision: D3776492
Pulled By: javache
fbshipit-source-id: 59ae19ac09d3cf0d0e229cd9e8e30865e65ca96c
Mehdi Mulani
dlowder-salesforce
leeight
Jacob Parker
Konstantin Raev
Jan Kassens
Timur Gibadullin
Martin Kralik
Tim Yung
Alex Kotliarskyi
Satyajit Sahoo
Eric Vicenti
Andrei Coman
Pieter De Baets
Emil Sjolander
Janic Duplessis
Neo
Spencer Ahrens
Ian MacLeod
Andrei Coman
