Summary: ImageCropper is broken on iOS. Can not scroll up and down
Differential Revision: D3413397
fbshipit-source-id: 75096fc1d5dd14764c0ddd4fd3888a9576c1d1ce
Summary:
Remove prop `onNavigate` from these views.
- NavigationAnimatedView
- NavigationCardStack
- NavigationCard
Also, the `sceneProps` onject that is passed to the `renderScene` function
no longer contains `onNavigate`.
The contract that `onNavigate` expects has been vague. Different data flow
system may expect complete different params for such function
For instance,
* onNavigate({type: 'back'});
* onNavigate({type: 'BACK'});
* onNavigate('back'});
We have no intention to unify such generic API since it's more likely to be
constrained by the data flow frameworks such as redux or flux.
Also, passing the prop `onNavigate` all the way down to the component that
invokes the navigation action can be really tedious. We'd expect developer
to either pass such callback (onNavigate) via context or just set up some
kind of static actions that any component can call directly.
`onNavigate` was previously added as a part of (redux-like) reducers-friendly
feature but that's no longer the case.
This new prop `onNavigateBack` is used to explicitly handle the case when the back button or back gesture
is performed.
Reviewed By: ericvicenti
Differential Revision: D3410873
fbshipit-source-id: a703cf0debd474cff33d6610e858b9c4bb3ecbf5
Summary:
The documentation currently list a few but not all of the steps required. This changes completes that list of required project changes.
This addresses #5612
Closes https://github.com/facebook/react-native/pull/7985
Differential Revision: D3414576
Pulled By: nicklockwood
fbshipit-source-id: 2c7ea6598ee4cd8b6945d9bb229bed5b592a68f6
Summary:
Currently on iOS animations are being performed on the JS thread. This ports animations over to the native thread and performs them natively. A lot of this work has already been done on Android, but this PR enables a few animation nodes that Android doesn't yet support such as Transform, Multiplication, and Addition nodes.
Also there is a demo of the native animations added to the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/7884
Reviewed By: javache
Differential Revision: D3409179
Pulled By: nicklockwood
fbshipit-source-id: ef2d8840032e0c32f49e4a16ba86d448662e1751
Summary:
Under rare and as-yet-to-be determined circumstances, images can sometimes fail to load/download and get "stuck", without producing an error.
Because the `RCTNetworkTask` for these images is stuck in the "in progress" state, they clog up the RCTImageLoader task queue, which has a limit of 4 concurrent in-progress tasks.
This was previously masked by the fact that we automatically cancelled image requests when the RCTImageView moved offscreen, but we no longer do that.
This diff adds logic to detect some types of stuck task and remove them, thereby unblocking the queue. I've also restored the functionality of cancelling downloads for offscreen images (but not unloading the image itself) so that stuck images will be cancelled when you move to another screen, instead of using up space in the queue forever.
Reviewed By: fkgozali
Differential Revision: D3398105
fbshipit-source-id: 75ee40d06a872ae8e1cb57f02f9cad57c459143c
Summary:
Returns a promise-like object with a new cancel function that will dig through the queue
and remove relevant tasks before they are executed. Handy when tasks are scheduled in react
components but should be cleaned up in unmount.
Reviewed By: devknoll
Differential Revision: D3406953
fbshipit-source-id: edf1157d831d5d6b63f13ee64cfd1c46843e79fa
Summary:
== API Breaking Change ==
- Add unit tests to ensure that NavigationStateUtils does the right thing.
- Remove the logics that lets NavigationStateUtils accept empty value as input
and return a new state.
- Remove the method `NavigationStateUtils.getParent`, `NavigationStateUtils.set`. These methods are rarely used and they can be replaced by other methods.
Reviewed By: ericvicenti
Differential Revision: D3374934
fbshipit-source-id: 0fdf538d014d7c5b4aa1f15a0ee8db9dc91e33cd
Summary:
`rootTag` is a lie, it's passed around but never actually used. IIRC
`findInstanceByNativeTag` needed it but seems like not anymore.
Reviewed By: spicyj
Differential Revision: D3382144
fbshipit-source-id: eb96870a3848333e66bf045e78e95c7763812cc4
Summary:
`renderApplication` is cluttered with unrelated Dev-only stuff
with duplicate code across iOS and Android. This is the first
diff in series of refactorings, with the end goal of making element
inspector work on Modals.
Reviewed By: spicyj
Differential Revision: D3381956
fbshipit-source-id: 4ac6525633e7482628d2b064eb894da2806daf8c
Summary:
For navigation actions at high level, reducers from NavigationReducers does not
know anything about the app-specific state thus people won't use these reducers.
Instead, people should build their own reducers.
There are a lot of good libraries available that help people to reducing things if that's
what they really need.
At the low level, for navigation state changes that don't involve app-specific state,
`NavigationStateUtils` should server that kind of need.
`NavigationReducers` serves little benefit cause it does not know the app state, it does
not know how to traverse the navigation states which can be a tree, a list or a map.
That said, we hold no interest in owning in the core navigation library.
Reviewed By: ericvicenti
Differential Revision: D3372910
fbshipit-source-id: 797382b46e7d64b7ad578b51dd37e2b941faa83d
Summary: Fixed ART views, which were broken by the zIndex diff
Reviewed By: wwjholmes
Differential Revision: D3403679
fbshipit-source-id: cc3cdccd19c21223ce6bddeda3d914937ecb73b6
Summary:
Currently on iOS animations are being performed on the JS thread. This ports animations over to the native thread and performs them natively. A lot of this work has already been done on Android, but this PR enables a few animation nodes that Android doesn't yet support such as Transform, Multiplication, and Addition nodes.
Also there is a demo of the native animations added to the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/7884
Differential Revision: D3401811
Pulled By: nicklockwood
fbshipit-source-id: 709e533243130153febef03ddd60d39e9fe70e3e
Summary:
Currently on iOS animations are being performed on the JS thread. This ports animations over to the native thread and performs them natively. A lot of this work has already been done on Android, but this PR enables a few animation nodes that Android doesn't yet support such as Transform, Multiplication, and Addition nodes.
Also there is a demo of the native animations added to the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/7884
Differential Revision: D3401811
Pulled By: nicklockwood
fbshipit-source-id: c8d750b75e4410923e17eaeb6dcaf079a09942e2
Summary:
This PR adds the ability to export videos to the CameraRoll on both Android and iOS (previously only photos were possible, at least on iOS). The API has changed as follows:
```
// old
saveImageWithTag(tag: string): Promise<string>
// new
saveToCameraRoll(tag: string, type?: 'photo' | 'video'): Promise<string>
```
if no `type` parameter is passed, `video` is inferred if the tag ends with ".mov" or ".mp4", otherwise `photo` is assumed.
I've left in the `saveImageWithTag` method for now with a deprecation warning.
**Test plan (required)**
I created the following very simple app to test exporting photos and videos to the CameraRoll, and ran it on both iOS and Android. The functionality works as intended on both platforms.
```js
// index.js
/**
* Sample React Native App
* https://github.com/facebook/react-native
* flow
*/
import React, { Component } from 'react';
import {
AppRegistry,
StyleSheet,
Text,
View,
CameraRoll,
} from 'react-native';
import FS fro
Closes https://github.com/facebook/react-native/pull/7988
Differential Revision: D3401251
Pulled By: nicklockwood
fbshipit-source-id: af3fc24e6fa5b84ac377e9173f3709c6f9795f20
Summary:
The type key for a layout animation config must be supplied otherwise the app crashes (on Android). I added a isRequired check in JS as well as an explicit exception in java otherwise it crashed at a very hard to debug place. The crash happens when passing null to `Animation.setInterpolator` so this makes sure it never happens.
**Test plan (required)**
Tested that the error is caught properly in JS when passing an invalid animation config like
```
LayoutAnimation.configureNext({
duration: 250,
update: { type: undefined }, // or LayoutAnimation.Types.easeInEastOut in my case haha :)
});
```
Also tested the java exception.
Closes https://github.com/facebook/react-native/pull/7958
Differential Revision: D3401760
Pulled By: nicklockwood
fbshipit-source-id: 83c019d863c2b2294405b60e87297c562add0f49
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
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 the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/mas
Closes https://github.com/facebook/react-native/pull/7974
Differential Revision: D3401208
Pulled By: nicklockwood
fbshipit-source-id: 7c807339ba512e05f848036fb40840cf3fee8df6
Summary: So users can know how to use
Reviewed By: hedgerwang
Differential Revision: D3399028
fbshipit-source-id: 5ce97c5464f1975145aba1bcf4b79550394859ae
Summary:
KeyboardAvoidingView is a component we built internally to solve the common problem of views that need to move out of the way of the virtual keyboard.
KeyboardAvoidingView can automatically adjust either its position or bottom padding based on the position of the keyboard.
Reviewed By: javache
Differential Revision: D3398238
fbshipit-source-id: 493f2d2dec76667996250c011a1c5b7a14f245eb
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
Summary:
Now that we no longer have a separate NetworkImageView implementation, we can remove that code path from Image.js
I've also moved the prefetch method into RCTImageViewManager for consistency with the getImageSize method, which means we no longer need to export the RCTImageLoader module to js.
Reviewed By: javache
Differential Revision: D3398157
fbshipit-source-id: fbbcf90a61549831ad28bad0cb3b50c375aae32c
Summary:
This diff refactors the view update process into two stages:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
Reviewed By: wwjholmes
Differential Revision: D3396594
fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Summary:
It's annoying and inefficient to create styles like
```
wrapper: {
position: 'absolute',
left: 0,
right: 0,
top: 0,
bottom: 0,
},
```
all the time, so this makes a handy constant for reuse and a helper method to create customized
styles.
Reviewed By: devknoll
Differential Revision: D3389612
fbshipit-source-id: 88fbe9e8ca32a0bc937bf275cf5ae0739ee21302
Summary: Allow some right swipe so users know swiping is a possibility, with some bounceback.
Reviewed By: fkgozali
Differential Revision: D3388836
fbshipit-source-id: 596a6be3c641ff0ee6ac32d7c0d798478edef72b
Summary:
RCTShadowText currently explicitly defaults to black text color:
https://github.com/facebook/react-native/blob/d46ac11/Libraries/Text/RCTShadowText.m#L204
However, the UITextView used by RCTTextInput doesn't explicitly default to black text color.
This causes issues when RCTTextInput is in rich text editing mode (i.e. when the <TextInput> element uses child <Text> nodes to provide extra styling info) and the client doesn't provide us with any explicit color info. In this case, the following series of badness occurs:
1. -[UITextView attributedText] will return an attributed string without the NSColor property set.
2. -[RCTShadowText attributedString] will return an attributed string with NSColor equal to blackColor.
3. The `[_textView.attributedText isEqualToAttributedString:_pendingAttributedText]` check in -performPendingTextUpdate will fail and causes -[UITextView setText:] to be called.
4. -setText: clears the marked text range in the text view, which breaks multi-character autocomplete (e.g. QWERTY input methods for CJK languages).
The easiest fix for now is to just make sure RCTUITextView and RCTShadowText default to the same text color.
Reviewed By: nicklockwood
Differential Revision: D3368726
fbshipit-source-id: a92cb188c60bac80d963af6b1f2a09f27ae084f5
Summary:
Reduce the public surface area of TextInput. It only exposes a secureTextEntry property, but on Android was also accepting password as a prop.
This removes that.
Reviewed By: javache
Differential Revision: D3392223
fbshipit-source-id: 67c36fbe16fe493e2841d5d9deb78e3be2209ebd
Summary:
_(This is a remake of #6907, which I botched pretty good with a rebase.)_
This returns an `Array` of Local Notifications that have been scheduled to be delivered.
Available attributes on return Notification object (if set in the local notification itself):
`alertAction`
`alertBody`
`applicationIconBadgeNumber`
`category`
`fireDate`
`soundName`
`userInfo`
More could be added to this but I just matched what was available in the `Object` passed to `presentLocalNotification` and `scheduleLocalNotification`.
**Motivation**
I needed to determine the number and other details about local notifications that were already scheduled. There is an API for this in iOS but one hadn't been built yet for React Native.
I created the Obj-C method and updated the documentation in `PushNotificationIOS.js` as well.
**Usage:**
```js
PushNotificationIOS.getScheduledLocalNotifications( (notifications) => {
console.log(notifications);
});
```
**Sample Output:**
```js
[
Object {
aler
Closes https://github.com/facebook/react-native/pull/7937
Differential Revision: D3392476
Pulled By: javache
fbshipit-source-id: d83f419bfcfbdaf9b955724dcf5cfe26834895fb
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary:
**Motivation**
Today it's hard to build a good flow around requesting permissions if we don't know when the user rejects the push notification permission.
With this PR I wrap `PushNotificationIOS#requestPermission` in a promise. The promise will return with the updated permissions when the user accepts, rejects or has previously rejected the permission.
An example flow of how an app should handle push notifications with the change proposed:
1) Show user an explanation of push notification permissions with a button to enable,
2) User presses the enable push notifications button,
3) If the user accepts -> take them into the app,
4) if the user rejects -> explain how to enable permission in the settings app.
5) My app will now store some state about how it has asked permissions for push notifications so that the next time the user is taken through this flow they will go straight to step 4.
Without this change we could listen to the `register` event that PushNotificationIOS fires on the success sc
Closes https://github.com/facebook/react-native/pull/7900
Differential Revision: D3387424
Pulled By: nicklockwood
fbshipit-source-id: e27df41e83216e4e2a14d1e42c6b26e72236f48c
Summary:
RFC 6454 section 7 defines the Origin: header syntax, and it's a
scheme, host, and optional port, not a URL.
Section 6 defines serialization of the header, including omission of the
port.
Therefore, we need to omit the trailing slash in all cases, and omit
the port if it matches the default port for the protocol.
Closes https://github.com/facebook/react-native/pull/7920
Differential Revision: D3387619
fbshipit-source-id: 552756e63ad41463af357a5073fae56c96e58958
Summary:
Accessing the `responseText` property when `responseType` is not `''` or `'text'` should throw. Also, the property is read-only.
**Test Plan:** UIExplorer example, unit tests
Closes https://github.com/facebook/react-native/pull/7284
Differential Revision: D3366893
fbshipit-source-id: a4cf5ebabcd1e03d6e2dc9d51230982922746c11
Summary:
In several pervious diffs we have moved symbolication of JS stack traces
to the packeger. This lets us save a bunch of memory (~80MB) and CPU on device,
reduces dependency on JS after exception occured.
This diff cleans up a bunch of code that was used to do symbolication on client side.
Reviewed By: javache
Differential Revision: D3348676
fbshipit-source-id: 88baa5c502836c9ca892896e1ee5d83db37486d3
Summary:
Having a function that symbolicates any given stack trace
is convenient, e.g. in #7459
More cleanup to follow.
Reviewed By: davidaurelio
Differential Revision: D3348616
fbshipit-source-id: 6313ec837869c6080829c811345a06aa1b2dcd21
Summary:
Many RN devtools (inspector, source maps, etc.) rely on packager.
This refactors individual SourceCode.scriptURL parsing into one function
that will be easier to change in the future.
Reviewed By: javache
Differential Revision: D3348465
fbshipit-source-id: 5a55939ea59e1517cb63bcbe4963f57f02ab15f3
Summary:
The TextInput when configured with `multiline=true` has a minor issue due to which if the initial text doesn't fit in one line, the input won't span multiple lines. The root cause of the problem is that the `onChange` event is not fired for the initial render. This issue has been reported on open-source: 481f560f64
This is an attempt to fix this problem by moving the logic to fire the event to the method that updates the content size. This way we can guarantee that anytime the content size changes we'll trigger the JS event.
The downside of this approach is that it's possible that multiple events get fired for a single character change. As per the comment that was removed, this was already happening when adding a character that when rendered, would increase the content size. By moving the code to the new place, this can happen more often (twice per character tapped). Let me know if you think this is an issue.
I don't know this code much, so please be careful reviewing. I'm happy to add more test cases I may have missed to the test plan :).
Reviewed By: nicklockwood
Differential Revision: D3348218
fbshipit-source-id: 6b457624c9126e771c326eac61cd1cdd6496671d
Summary:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:
The propTypes of RCTDatePickerIOS do not fit with the propTypes of DatePickerIOS.
All dates (date, minimumDate, maximumDate) are a timestamp (check line 126), so they should have propType number.
OnDateChange function should not be required since it is called onChange in the iOS implementation.
The problem currently causes warnings that the given types are wrong, while they were added correctly.
Closes https://github.com/facebook/react-native/pull/7833
Differential Revision: D3371324
Pulled By: nicklockwood
fbshipit-source-id: bca5b2bbe7e9dd2e045288bfbd268578848c7bff
Summary:
The TextInput when configured with `multiline=true` has a minor issue due to which if the initial text doesn't fit in one line, the input won't span multiple lines. The root cause of the problem is that the `onChange` event is not fired for the initial render. This issue has been reported on open-source: 481f560f64
This is an attempt to fix this problem by moving the logic to fire the event to the method that updates the content size. This way we can guarantee that anytime the content size changes we'll trigger the JS event.
The downside of this approach is that it's possible that multiple events get fired for a single character change. As per the comment that was removed, this was already happening when adding a character that when rendered, would increase the content size. By moving the code to the new place, this can happen more often (twice per character tapped). Let me know if you think this is an issue.
I don't know this code much, so please be careful reviewing. I'm happy to add more test cases I may have missed to the test plan :).
Reviewed By: nicklockwood
Differential Revision: D3348218
fbshipit-source-id: d3da3c0da1a0da9b9960625441191497e91d322e
Summary: The DatePicker had a hard-coded width of 320 for no reason I can think of. Removing it allows the DatePicker to naturally scale to fit the width of the container, which is how the regular Picker works already.
Reviewed By: lexs
Differential Revision: D3371355
fbshipit-source-id: e06d31f7275de41bb00226232cf47ad022d25b4d
Summary:
XMLHttpRequest was sending the request before registering any listeners, resulting in a warning from the native event emitter.
Since we weren't seeing widespread problems with XHR missing data, this was probably working OK in practice because the queuing of events meant that the listener would have been registered before the message was actually delivered.
Still, this was working more through luck than design. This diff fixes it by registering the listeners *before* sending the request.
Reviewed By: lexs
Differential Revision: D3371320
fbshipit-source-id: c688d4053a61f856eaacccd0106905edbefcc86a
Summary:
The recent and upcoming API refactoring works makes maintaining
the examples harder and harder.
This removes the old examples that use too much deprecated APIs such as
Reducers, Animated View.
The new examples will be forcus on using new API with all-in-one sample
codes and detailed documentation.
Reviewed By: ericvicenti
Differential Revision: D3354711
fbshipit-source-id: ac6360b1573989eb075d91cb9bf1ae8357dce7fa
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary:
Makes compute call async from willReceiveProps and fixes crashes with proper bounds in render
function instead. This means that fast prop updates won't force rapid and synchronous row increments during
initial render.
Check `rowData` and `rowKey` explicitly so clients don't have to worry about preserving === rowData containers
around Relay data to prevent re-renders.
Also moves layout jump warning behind DEBUG since it's not a common issue any more.
Reviewed By: devknoll
Differential Revision: D3357710
fbshipit-source-id: ee2e5be04261d5722abd07a063b345960b0c5cbe
Summary:
In UI explorer, the route is made of an object which look like this.
```
{key: 'AppList', filter: 'query string from the search box'}
```
When a new search query is enter, a new `filter` value is applied, and the key `AppList`
remains the same.
In NavigationScenesReducer, we should compare the routes with both their keys and references.
The current implementation only compares the keys, which unfortunately depends on the a weak
assumption that all routes immutable and keys are unique.
In UI Explore, the route key is always 'AppList', which makes sense since we use the key
to match the scene, and whenever a new search query is provides, a new route will be created.
Reviewed By: nicklockwood
Differential Revision: D3357023
fbshipit-source-id: a3c9e98092f5ce555e5dbb4cc806bab2e67d8014
Summary:
NavigationState is composed of many things such as `index`, `routes`.
The only way to effectively compare navigation states is to assume their immutability
and simply compare their references.
That said, `navigationState.key` does not really serves anything useful. The key does
not make a navigation state more unique or comparable.
This diff makes `navigationState.key` irrelevant thus we could make NavigationState
simpler.
Reviewed By: ericvicenti
Differential Revision: D3351915
fbshipit-source-id: 75d5fa432d2a693f999a91b11e3bff1fdd42e61d
Summary:
The API for `ActivityIndiatorIOS` and `ProgressBarAndroid` is very similar and can be merged in a cross platform component that displays a circular indeterminate loading indicator.
This deprecates `ActivityIndiatorIOS` and non-horizontal `ProgressBarAndroid` in favor of this new component.
**Test plan (required)**
Tested with the ActivityIndicator example in UIExplorer on android and ios. Also made sure that `ActivityIndicatorIOS` still works and displays a deprecation warning. Also tested that `ProgressBarAndroid` with `indeterminate == true` and `styleAttr != 'Horizontal'` displays a deprecation warning.
Closes https://github.com/facebook/react-native/pull/6897
Differential Revision: D3351607
Pulled By: dmmiller
fbshipit-source-id: b107ce99d966359003e8b3118cd97b90fa1d3d7d
Summary:
Update mapWithSeparator so that Flow can reason about the arguments and return
type. For simplicity, it is expected that the type of the separator will be the
same as that of the mapped item.
Reviewed By: vjeux
Differential Revision: D3323557
fbshipit-source-id: 75b59e928d4e8c309b5933499a14744370ee5660
Summary:
Autocorrect was broken for controlled TextInput components by a change to batch event handling in React Native:
9f11f8c263
For example, a TextInput like this would be affected by this bug:
```javascript
<TextInput
autoCorrect={true}
style={{height: 26, width: 100}}
onChangeText={(text) => this.setState({ text })}
value={this.state.text}
/>
```
This fix uses the same approach as
0cd2904b23
The problem is that TextInput's _onChange handler relied on this.props.value being updated synchronously when calling this.props.onChangeText(text). However, this assumption was broken when React Native event handling started being batched.
The fix is to move the code that relies on this.props.value being up-to-date to componentDidUpdate.
**Test plan (required)**
Tested autocorrect now works on iOS in a small app and a large app. Also tested t
Closes https://github.com/facebook/react-native/pull/7676
Differential Revision: D3346221
Pulled By: nicklockwood
fbshipit-source-id: 715df3e8a03aa58cb0a462de4add02289d42782f
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
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 the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/mas
Closes https://github.com/facebook/react-native/pull/7770
Differential Revision: D3352007
fbshipit-source-id: eedb964d245445b61fed79245380f0803473c455
Summary:
- Address the issues reported at 7db7f78dc7 (commitcomment-17575647)
- Fix the logic that reduces the scenes.
- Fix the logic that computes the active scene for `renderOverlay`.
Reviewed By: ericvicenti
Differential Revision: D3344716
fbshipit-source-id: 3fce517ff1de212f412a77936012695bd2dcfc3c
Summary: The decoded image cache was previously static, meaning that cached images could persist beyond the lifetime of the module. This resulted in some flakiness in the RCTImageLoaderTests due to the loader returning cached image instanced from previous tests instead of the correct instance.
Reviewed By: bestander
Differential Revision: D3346329
fbshipit-source-id: 375af8894cef1c5b6303c6cdfd7eb57ebcfe3251
Summary:
This allows React Native apps to instrument their own code via Systrace.measureMethod() and the like.
**Test Plan:** Used require('react-native').Systrace in my own app successfully to instrument my own code.
Closes https://github.com/facebook/react-native/pull/7734
Differential Revision: D3346222
Pulled By: javache
fbshipit-source-id: 08ffc781a1187db89c6e9a0714d644dbc485724c
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: bestander
Differential Revision: D3346129
fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: When we're profiling, we want to load Systrace immediately and profile all the startup and initial render code. The code here used to load Systrace during startup only if `__DEV__` but would always start profiling once Systrace was otherwise required. That seems pretty hard to reason about, so I'm switching to always requiring Systrace during the startup path and enabling profiling if appropriate. In actual production that'll always be false, of course.
Reviewed By: javache
Differential Revision: D3338216
fbshipit-source-id: f173e82f34e110d83e7ff04f11af9b302a54b859
Summary:
The Framework is inconsistent in how listeners are removed in certain classes. This issue has been discussed in https://github.com/facebook/react-native/issues/6493.
For example,
**DeviceEventEmitter**
```javascript
/* Current */
this.keyboardHideObserver = DeviceEventEmitter.addListener('keyboardWillHide', this.keyboardWillHide);
this.keyboardHideObserver.remove();
/* Expected (maybe in addition to the current API) */
DeviceEventEmitter.addListener('keyboardWillHide', this.keyboardWillHide);
DeviceEventEmitter.removeListener('keyboardWillHide', this.keyboardWillHide);
```
**AppStateIOS**
```javascript
AppStateIOS.addEventListener('change', this.handleAppStateChange);
AppStateIOS.removeEventListener('change', this.handleAppStateChange);
```
The API should be consistent, and preferably should allow both ways of removing the listeners.
Currently, developers who tried to use the second way of removing the listeners get an error for function not found. Due to the lack of documenta
Closes https://github.com/facebook/react-native/pull/6884
Differential Revision: D3341235
Pulled By: nicklockwood
fbshipit-source-id: 87431e8b667f46ad002d4a6e3ca07cbc1e6b4007
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary:
Some apps are complaining about flashing images when performing navigation transitions. An example issue would be:
1. Load a master list view with many images
2. Click on an image to go to a detail view
3. Go back to the master list view
At step (3), users see a number of images flash from a placeholder image back to the final image because `-[RCTImageView didMoveToWindow]` calls `clearImage` when the image view exits the view hierarchy between (1) and (2) and calls `reloadImage` (which sets the image property asynchronously) when the image view re-enters the view hiearchy between (2) and (3).
This diff fixes the issue by being less aggressive about clearing image contents. It only clears image contents when the app receives a memory warning or the app goes into the background.
For comparison, CKNetworkImageComponent in ComponentKit doesn't have this purging behavior at all.
Reviewed By: javache
Differential Revision: D3325009
fbshipit-source-id: efca10099cdfdb49afbb3f550854d4b8a40511d0
Summary:
Reuses the original property descriptor when overwriting / polyfilling globals to ensure enumerability and writability are the same
Closes https://github.com/facebook/react-native/pull/7704
Differential Revision: D3338119
Pulled By: davidaurelio
fbshipit-source-id: ab456324a3346cd3ec8b2c3e3a2378408c92087c
Summary:
Removes the deprecated APIs that were replaced by `RefreshControl`. Those API have been deprecated for a while already so I think it's fine to remove them at this point. Also ported the `SwipeRefreshLayoutTestModule` test to use `RefreshControl` instead of `PullToRefreshViewAndroid`.
**Test plan (required)**
Made sure no references are left in the codebase to `PullToRefreshViewAndroid`, `onRefreshStart` and `endRefreshing`.
Tested that `ScrollView` examples in UIExplorer still work properly.
Check that the `SwipeRefreshLayoutTestModule` passes on CI.
Closes https://github.com/facebook/react-native/pull/7447
Reviewed By: mkonicek
Differential Revision: D3292391
Pulled By: bestander
fbshipit-source-id: 27eb2443861e04a9f7319586ce2ada381b714d47
Summary:
NavigationCard is wrapped in a container, which breaks statics so apply the statics to the wrapped class instead.
Closes https://github.com/facebook/react-native/pull/7483
Differential Revision: D3336226
Pulled By: ericvicenti
fbshipit-source-id: ae28e7be7a6227700c2c11081c5605f3667d1494
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
In RN we cache image data after loading/downloading an image, however the data we store is the compressed image data, and we decode this asynchronously each time it is displayed.
This can lead to a slight flicker when reloading image components because the decoded image is discarded and then re-decoded.
This diff adds a small (5MB) cache for decoded images so that images that are currently on screen shouldn't flicker any more if the component is reloaded.
Reviewed By: bnham
Differential Revision: D3305161
fbshipit-source-id: 9969012f576784dd6f37d9386cbced2df00c3e07
Summary:
[Experimental API breaking changes]
The notion of `parent` or `children` in navigaton is misleading. We have no intention to maintain or
build the nested or hierarchical navigation states. To be clear, rename `navigationState.children` to
`navigationState.route`.
Reviewed By: ericvicenti
Differential Revision: D3332115
fbshipit-source-id: c72ed08acaf030fb9c60abf22fb15cc0f44b3485
Summary:
[public / experimental API breaking change]
The data type of `scene.navigationState` is `NavigationRoute`. Rename `scene.navigationState` to
`scene.route` to avoid confusion such as treating `scene.navigationState` as the actual global navigation
state (type: NavigationState).
Reviewed By: ericvicenti
Differential Revision: D3331076
fbshipit-source-id: 3ed989cc8492d398cbeb1b12186459deb261d1fb
Summary:
The default itemPositioning is `automatic` (referred to `auto` in this pull request) - you can check its behaviour in the docs attached.
Sometimes that value has to be modified to have more predictable appearance as described in #4136.
Closes https://github.com/facebook/react-native/pull/7217
Differential Revision: D3220958
Pulled By: mkonicek
fbshipit-source-id: d4bf648b16e71825cd31c06d6b6396479767d19f
Summary:
This is the first step to clarify and simplify the type definations about navigation state.
For now, `NavigationParentState` is actually used as the real navigation state and `NavigationState` is used
as a route in navigation, which has been confusion among the APIs.
To be clear, our APIs has no intention and interest in dealing with nested or hierarchical navigation states,
and we should avoid have the name like `ParentState` or `children`.
To fully migrate the types, theer will be a lot of code changes and this is just the first step to rename.
= What's Next?
1. rename `navigationState.children` to `navigationState.routes` (breaking change!)
2. remove `navigationState.key` from its type defination.
Reviewed By: ericvicenti
Differential Revision: D3321403
fbshipit-source-id: 3e39b60f736c1135bc85d8bf2b89027d665e28d4
Summary:
See "D3291793 Symbolicate JS stacktrace using RN Packager" for the background
of why this matters. TLDR - saving tons of memory by moving symbolication from
JSC into server and cleaning up old hacks.
Before this change: a redbox causes +73MB JSC size
{F60869250}
{F60869249}
After this change: a redbox causes +1MB JSC size
{F61005061}
{F61005062}
Next step – replace JS implementation by native to show better progress and
clean up even more old APIs (ExceptionsManager.updateExceptionMessage).
Reviewed By: davidaurelio
Differential Revision: D3319151
fbshipit-source-id: 48ff4df27642ea4e1bc2414f48a8dd4d32adee50
Summary: - Removed some styling from `SwipeableRow` that wasn't doing much and made slide out view full height
Reviewed By: fkgozali
Differential Revision: D3322849
fbshipit-source-id: 811eee9032c142c61d303ae7e966d8ef7903adaf
Summary:
Before:
- Android had the slideout row flash upon render due to it being rendered first
- iOS had the left side of each row load first, then rerender to show entire row when `scrollViewWidth` is available
Reason:
- Android was loading the slideout view first without an opacity check
- iOS was loading the swipeable view with width 0 first then stretching to `scrollViewWidth` when it was available via `onLayout`
Fix:
Render swipeable view with `flex: 1` then render slideout view
Reviewed By: fkgozali
Differential Revision: D3321466
fbshipit-source-id: 92a3b5e22034e06d05986ddb8c348796bafbbf34
Summary:
- Replace some fixes that were accidentally lost in local rebase that prevent jumpiness when incremental is disabled.
- Require each row to have a key specified by the caller to prevent jumping because of accidental duplicates or unneeded/problematic row re-rendering because of legit re-ordering.
Reviewed By: steveluscher
Differential Revision: D3322006
fbshipit-source-id: 0019aab07cb1fe2b148a14b5818de53aa373eb50
Summary:
Incremental rendering is a tradeoff between throughput and responsiveness because it yields. When we have plenty of
buffer (say 50% of the target), we render incrementally to keep the app responsive. If we are dangerously low on buffer
(say below 25%) we always disable incremental to try to catch up as fast as possible. In between, we only disable
incremental while actively scrolling since it's unlikely the user will try to press a button while scrolling.
This also optimizes some things then incremental is switching back and forth.
I played around with making the render window itself adaptive, but it seems pretty futile to predict - once the user
decides to scroll quickly in some direction, it's pretty much too late and increasing the render window size won't help
because we're already limited by the render throughput at that point.
Reviewed By: ericvicenti
Differential Revision: D3250916
fbshipit-source-id: 930d418522a3bf3e20083e60f6eb6f891497a2b8
Summary: Default image icon size for Quick Actions could cause slideout view to bleed over the slideable view. All styling has been removed and must now be passed in, thus allowing every caller to control size for best fit.
Reviewed By: furdei
Differential Revision: D3315696
fbshipit-source-id: 8f8b3d2cf7a005d42a18d434d9e0080c64597be0
Summary:
- Fork NavigationAnimatedView to NavigationTransitioner
- NavigationAnimatedView will soon be deprecated and we'd ask people to use NavigationTransitioner instead.
Difference between NavigationTransitioner and NavigationAnimatedView
- prop `applyAnimation` is removed.
- new prop `configureTransition`, `onTransitionStart`, and `onTransitionEnd` are added.
tl;dr;
In NavigationAnimatedView, we `position` (an Animated.Value object) as a proxy of the
transtion which happens whenever the index of navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that changes the navigation state
without changing the index.
Also, we believe that the name `Transitioner` is a better name for this core component
that focuses on transitioning. Note that the actual animation work is done via
`<Animated.View />` returnd from the `renderScene` prop.
Reviewed By: ericvicenti
Differential Revision: D3302688
fbshipit-source-id: 720c3a4d3ccf97eb05b038baa44c9e780aad120b
Summary:
... used as both a shape and plain object.
this splits them out so both parts can be used as needed.
NavigationPropTypes.SceneRenderer is a PropTypes shape
NavigationPropTypes.SceneRendererProps is the plain object that makes up the shape.
Closes https://github.com/facebook/react-native/pull/7518
Differential Revision: D3317322
Pulled By: ericvicenti
fbshipit-source-id: e8a31e05130e6647b63f68dbef31bc874550948c
Summary:
This works with D3305161 to minimize image flashing. After D3305161, the completion handler passed to `-[RCTImageLoader loadImageWithoutClipping:size:scale:resizeMode:progressBlock:completionBlock:]` may be called back on the main queue in the case of a cached image. In this case, we want to set the image view's image property synchronously rather than on the next runloop iteration via dispatch_async. This minimizes the amount of image flashing the user sees when displaying a cached image.
The exception to this case is for blurred images. A blur can be an expensive (taking multiple ms on the CPU), so we always make sure to perform the blur off the main queue even if the image is cached and the callback came back on the main queue.
Reviewed By: nicklockwood
Differential Revision: D3310176
fbshipit-source-id: 6820782527b65e4956879cf06e8ed2c09c622a58
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary:
This fixes an issue where animations for values near zero could end up formatted
with exponents (e.g. `1.452e-10`), which is not valid for an `rgba` color spec.
This commit arbitrarily rounds it to the nearest thousandth to prevent this type
of formatting while still maintaining high-enough resolution in the alpha channel.
One way this could bubble up to the user is as PropType validation failures:
```
Failed propType: Invalid prop `backgroundColor` supplied to `RCTView`: rgba(0, 0, 0, 9.838983123336224e-7)
```
Closes https://github.com/facebook/react-native/pull/7597
Differential Revision: D3310941
Pulled By: vjeux
fbshipit-source-id: 0c95facaef5b69c021662af9fb6f268d890ecc3e
Summary:
- Removed unnecessary rerending of `SwipeableListView` by properly managing `SwipeableListViewDataSource`
- Simplified `SwipeableRow` logic and improved swiping performance
- Added bounce effect
- Locked `ListView` from being scrollable when `SwipeableRow` is being swiped; behaviour mirrors that of Android on iOS and significantly improves framerates
Reviewed By: fkgozali
Differential Revision: D3307599
fbshipit-source-id: 168b6b72ef1f9e47d0145cf9e1baecbab3564b84
Summary:
Sometimes list view row components(even the ones unseen) have a frame but its x and y is 0 or uninitialized at view loading time, which will lead to _updateVisibleRows firing for all the row components incorrectly at loading time.
This is to make the code more defensive.
Reviewed By: sahrens
Differential Revision: D3308515
fbshipit-source-id: 0e30fdf10345629bfd9de3fe0ad641bb1903fe00
Summary:
The function should have optional arguments, but not nullable types.
Closes https://github.com/facebook/react-native/pull/7580
Differential Revision: D3304994
Pulled By: davidaurelio
fbshipit-source-id: 9918817429126ea16dd3076b61a3493c3a3a8388
Summary:
The `EmitterSubscription.remove()` method was previously calling `this.subscriber.removeSubscription(this)` directly, bypassing the mechanism in `NativeEventEmitter` that keeps track of the number of subscriptions.
This meant that native event modules (subclasses of `RCTEventEmitter`) would keep sending events even after all the listeners had been removed. This wasn't a huge overhead, since these modules are singletons and only send one message over the bridge per event, regardless of the number of listeners, but it's still undesirable.
This fixes the problem by routing the `EmitterSubscription.remove()` method through the `EventEmitter` so that `NativeEventEmitter` can apply the additional native calls.
I've also improved the architecture so that each `NativeEventEmitter` uses its own `EventEmitter`, but they currently all still share the same `EventSubscriptionVendor` so that legacy code which registers events via `RCTDeviceEventEmitter` still works.
Reviewed By: vjeux
Differential Revision: D3292361
fbshipit-source-id: d60e881d50351523d2112473703bea826641cdef
Summary:
Further describe the methods available on NetInfo.
Question: How do I update the docs on the website?
Closes https://github.com/facebook/react-native/pull/7375
Differential Revision: D3303300
fbshipit-source-id: 4343d490f65e4e47b93f2c98a645cb675d2cf708
Summary:
For now, we emit `didFocus` event before fully resetting the transition and
hiding the stale scenes, so handler for `didFocus` event does not get the right
scenes in place. We should emit the didFocus event after resetting the transition and
hiding the stale scenes.
Reviewed By: ericvicenti
Differential Revision: D3299002
fbshipit-source-id: 6a79528097aabc4f61d4dba322820c228c889a84
Summary:
We want to give people the ability to log scroll performance (including Fb).
This adds an interface that can be enabled and disabled from the react scroll views.
This is a prerequisite to implementing the actual framerate logger that will log dropped
frames while scrolling in prod.
Reviewed By: astreet
Differential Revision: D3283588
fbshipit-source-id: ed9736cb9ed3f441511647f36b1460092bd91e56
Summary:
= Breaking Change (for experimental features) =
Major API changes in NavigationAnimatedView
= New prop `transition` for scene renderer
In NavigationAnimatedView, we should not use `position` as a proxy of the
transtion which happens whenever navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that replace navigation state
without changing the index.
This diff introduces an abstract prop `transition` that is exposed to the scene
renderers.
= Replace `applyAnimation` with `configureTransition`.
Expose a new optional prop `configureTransition` that allows people to configure
transitions easily.
For instance, to configure the transition, do this:
```
function configureTransition() {
return {
dutation: 123,
easing: Easing.easeInOut,
};
}
```
<NavigationAnimatedView configureTransition={configureTransition) />
```
Reviewed By: ericvicenti
Differential Revision: D3278698
fbshipit-source-id: b790b92e0fabb42488ff1135b1c37a3f0e9420f7
Summary: Center align text on Android
Reviewed By: fkgozali
Differential Revision: D3295222
fbshipit-source-id: c707d1102c8aa86aa04dc9b34a4746b1ff1543bc
Summary:
= Breaking Change (for experimental features) =
Major API changes in NavigationAnimatedView
= New prop `transition` for scene renderer
In NavigationAnimatedView, we should not use `position` as a proxy of the
transtion which happens whenever navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that replace navigation state
without changing the index.
This diff introduces an abstract prop `transition` that is exposed to the scene
renderers.
= Replace `applyAnimation` with `configureTransition`.
Expose a new optional prop `configureTransition` that allows people to configure
transitions easily.
For instance, to configure the transition, do this:
```
function configureTransition() {
return {
dutation: 123,
easing: Easing.easeInOut,
};
}
```
<NavigationAnimatedView configureTransition={configureTransition) />
```
Reviewed By: ericvicenti
Differential Revision: D3278698
fbshipit-source-id: 25ebad286d8b41f46c35c0f32d6023ebd01f19e7
Summary:
- Implemented a quick actions template to allow children buttons to be rendered in the slideout of `SwipeableListView`
- Implemented `QuickActionsButton` to allow buttons to be used in the slideout view
Reviewed By: fkgozali
Differential Revision: D3271946
fbshipit-source-id: b7c7412f44be64dea7084ca36c4b0f4f3842b008
Summary:
This is a nice feature to have.
I've tested this by copying and renaming the ViewPager java and javascript files from the react-native repo and including them in a project. Whats the best way to test this directly from the repo?
Closes https://github.com/facebook/react-native/pull/5968
Differential Revision: D3240651
Pulled By: mkonicek
fbshipit-source-id: 5f1d157216df4f3314915496188a92aec1b85e91
Summary:
= Breaking Change (for experimental features) =
<NavigationView /> serves no obvious benefit and it's costly to maintain it.
- its features could be completely replaced by NavigationAnimatedView without
enabling the transtion animation.
- it could also be replaced with a simple view and normal scene renderer.
Reviewed By: ericvicenti
Differential Revision: D3280547
fbshipit-source-id: 4ac3dbe92ceb9107a1f6e77a78bd6021485e78a9
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:
- getScrollResponder returns a...ScrollView!
- no more var
- no more string refs
Reviewed By: spicyj
Differential Revision: D3286596
fbshipit-source-id: d9e6e0a318eadd2521c9f5c69d2ec368f1d7b626
Summary:
- Updated SwipeableListView to be much more performant by checking `rowHasChanged` more vigorously
- New `SwipeableListViewDataSource` used to mask implementation details from caller
Reviewed By: fkgozali
Differential Revision: D3272172
fbshipit-source-id: 02f66ed7fce7d587118ad7d82b20f8e78db44b7b
Summary:
React.PropTypes.oneOf accepts array as parameter, non-array given. this make the app throw a warning.
Closes https://github.com/facebook/react-native/pull/7498
Differential Revision: D3285737
fbshipit-source-id: 3d86b4b36d696e054f9225d7e3a9eddf91477813
Summary:
`tintColor`, even in style, works on Android; this must be some old comment but that confused me when reading the docs.
**Test plan:**
- Launched website locally
Closes https://github.com/facebook/react-native/pull/7465
Differential Revision: D3278166
fbshipit-source-id: 4e986e0f2a9ba05de4404b93d28687596fbb4fad
Summary:
The XMLHttpRequest jest tests were attempting to call a private method in XMLHttpRequestBase.js (denoted by an _ prefix).
JS doesn't actually have any language-level support for private methods, the use of _ prefix is just a convention. But to prevent casually calling private methods externally, we have a transform that mangles the names of prefixed methods so that that attempting to call them will fail.
Using a double _ bypasses this name-mangling mechanism, while still making it clear that the method is intended to be private.
Reviewed By: javache
Differential Revision: D3276261
fb-gh-sync-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
fbshipit-source-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
Summary: Move all requires of UIManager to UIManager.js, so we can load the view manager configuration lazily when UIManager is required.
Reviewed By: majak
Differential Revision: D3270147
fb-gh-sync-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
fbshipit-source-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
Summary: Fixed a crash where making a network request with unrecognized/unsupported scheme would crash by attempting to insert a nil RCTNetworkTask into an array.
Reviewed By: javache
Differential Revision: D3275810
fb-gh-sync-id: be208c6bf87d882209901b850dcc25da4ba79a08
fbshipit-source-id: be208c6bf87d882209901b850dcc25da4ba79a08
Summary:
Currently the Modal component on Android is rendered below the Status Bar, which changes it's color to grey, and in the UIExplorer example the backdrop is just formatted to look the same color. In some scenarios users may want to preserve the color of their status bar and make it look as though the modal is appearing on top. This PR allows for that.
This GIF shows current behavior and new behavior with the translucentStatusBar prop set to true.
I've updated the UIExplorer app to demonstrate and the docs as shown below
Thanks!
Closes https://github.com/facebook/react-native/pull/7157
Differential Revision: D3264497
Pulled By: dmmiller
fb-gh-sync-id: 61346d99414d331d3420f44a4c5f6341b0973be6
fbshipit-source-id: 61346d99414d331d3420f44a4c5f6341b0973be6
Summary:
Add the possibility to define a progress view top offset to RefreshControl on android. As i comment in #6740, contentInset does the trick on IOS.
Looking android documentation seems that exists a possible solution:
http://developer.android.com/reference/android/support/v4/widget/SwipeRefreshLayout.html#setProgressViewOffset(boolean, int, int)
This pull request implement that but keeping it simple, only a top offset.
For example, now we could put navigation bar over the scrollview (or listview) and define a progressViewOffset on RefreshView in order to start behind the navigation. At this point we could make some kind of coordinator layout to hide/show navigation on scroll.
To maintain the default behavior, start point is equal to start point minus progress circle diameter in order to create that progress circle before the start point.
Closes https://github.com/facebook/react-native/pull/6759
Differential Revision: D3240664
Pulled By: mkonicek
fb-gh-sync-id: ccf866272e871811c1c6dcc2a34f5c217967feee
fbshipit-source-id: ccf866272e871811c1c6dcc2a34f5c217967feee
Summary:
There was an issue with the way we made `RefreshControl` a controlled component when react doesn't render synchronously. This fixes the issue by using the same technique used in the commit 0cd2904b23 for`PickerAndroid`
**Test plan (required)**
Tested normal behaviour and tested that if not setting the `refreshing` prop to `true` during the `onRefresh` callback that the `RefreshControl` stops refreshing immediately. Also made sure that `setNativeProps` is only called if needed when the native refreshing state is not in sync with JS.
Fix#7414
Closes https://github.com/facebook/react-native/pull/7445
Differential Revision: D3274981
fb-gh-sync-id: a1b9d46329f552984e33d11fa0e29ad6da689511
fbshipit-source-id: a1b9d46329f552984e33d11fa0e29ad6da689511
Summary:
Previously, the back swipe navigation gesture would be enabled when the navigation bar is shown and disabled when the navigation bar is hidden.
This change enables developers to control the back swipe gesture independently of the visibility of the navigation bar. An example use case would be that an app wants to render a custom navigation bar so it sets `navigationBarHidden` to true and it wants to enable the back swipe gesture so it sets `interactivePopGestureEnabled` to true.
**Test plan (required)**
- Created a test app to verify setting `interactivePopGestureEnabled` to `true` and `false` with the navigation bar both hidden and shown.
- Verified prop works in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7369
Differential Revision: D3269304
Pulled By: javache
fb-gh-sync-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
fbshipit-source-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
Summary:
The containers in NavigationExperimental are not appropraite because the state should be held by the app's architecture, be it redux, flux, or simple component state.
This diff moves the examples over to simple component state, but there are several other examples of how to use NavigationAnimatedView and the navigation reducers with redux:
- https://github.com/jlyman/RN-NavigationExperimental-Redux-Example
- Switching the f8 app with redux to navigation experimental: https://github.com/fbsamples/f8app/pull/14
Reviewed By: hedgerwang
Differential Revision: D3219911
fb-gh-sync-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
fbshipit-source-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
Summary:
This code change allows changing the transition velocity of the navigator
when switching views.
Whats the use case? If you have different types of
animations your animations might also need different transition velocities.
Closes https://github.com/facebook/react-native/pull/5439
Differential Revision: D3264719
Pulled By: ericvicenti
fb-gh-sync-id: 1bc0a1191ed3bd51b624acd161c3ee77fd748d72
fbshipit-source-id: 1bc0a1191ed3bd51b624acd161c3ee77fd748d72
Summary:
This should simplify the renderScene usage a bit because the react key is required and this will make sure they are rendered with the right key automatically.
It changes the string to make sure people do not rely on this API for anything else.
Reviewed By: javache
Differential Revision: D3033933
fb-gh-sync-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
fbshipit-source-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
Summary:
the prop type check for NavigationCard -> SceneView -> sceneRendererProps is wrong.
Fix it.
Reviewed By: ericvicenti
Differential Revision: D3265049
fb-gh-sync-id: 16e89c932f0f962db4b6a647d62d255ba98f6156
fbshipit-source-id: 16e89c932f0f962db4b6a647d62d255ba98f6156
Summary:
NavigationLegacyNavigator was originally created to help people to migrate to the new
navigation library without API changes. Therefore we'd have to port all the old APIs that
don't necessarily seem align well with the new navigation library.
Consider the production usage of NavigationLegacyNavigator does not exist, it's better
to kill it and we'd just rename the `Navigator` to `NavigatorDeprecated` later instead.
Reviewed By: ericvicenti
Differential Revision: D3263704
fb-gh-sync-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
fbshipit-source-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
Summary:
This adds support for pagingEnabled to the HorizontalScrollView.
This is an initial implementation.
Because Android doesn't provide great details about what is happening with a scroll view after you are done touching it, we have some post touch handling. This is kicked off either by touch up or a fling call.
Once we are doing that handling, we start a runnable that basically checks if we are still scrolling. If we are, we just schedule that runnable again and check a frame later. If we are done scrolling (no onScrollChanged since we last fired), we could be in one of two states, the fling is done or we are done snapping to the page boundary. If we are in the fling done case, we then check if we need to scroll to a page boundary. If so, we call smoothScrollTo and schedule ourself to check onScroll events again until done with that scroll. If we are done with both (either we only did momentum scroll or we did that and then snapped to page), we can then fire the final event and stop checking. This logic is all in handlePostTouchScrolling.
Because of the decision to only do page scrolling after momentum ends, we do allow you to scroll through with momentum a number of pages and the transition can be a little strange where it stops a sec and then slides to be page aligned. As a follow up, we can probably smooth that up by changing the value we pass to super.fling() that would adjust it to be let momentum carry it to the page boundary.
Reviewed By: weicool
Differential Revision: D3207608
fb-gh-sync-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
fbshipit-source-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
> From the existing documentation, it's not clear how one would make use of the highlightRow attribute of ListView.renderRow. Special thanks to halilb for his assistance.
Example: When "Adding a function to do X", explain why it is necessary to have a way to do X.
**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.
> Here's a screenshot of the UIExplorer with a row highlighted (using the FB Blue Color)
> <img width="466" alt="2016-03-16_1944" src="https://cloud.githubusercontent.com/assets/1640318/13835020/49b5b38c-ebb1-11e5-98fa-17201fd3db92.png">
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/CONTRIBUTIN
Closes https://github.com/facebook/react-native/pull/6495
Differential Revision: D3264092
Pulled By: nicklockwood
fb-gh-sync-id: 9608e8a66387f527b872928a3595ca4d17736b82
fbshipit-source-id: 9608e8a66387f527b872928a3595ca4d17736b82
Summary:
Allow changing distanceFilter after _locationManager has been initialized.
There is 2 reasons for this PR:
- When calling `getCurrentPosition`, `_observerOptions` is possibly not set properly ( as it is set only in `startObserving`), in this case it would have default values so `distanceFilter` will be 0 in this case ( which can be the right value but we should be more explicit about it, `kCLDistanceFilterNone` or `RCT_DEFAULT_LOCATION_ACCURACY`):
<img width="961" alt="screen shot 2016-04-14 at 8 44 09 pm" src="https://cloud.githubusercontent.com/assets/159813/14551465/6aa8791a-0288-11e6-9c98-1687357f8c2a.png">
- Another issue is that `distanceFilter` is cached so it can't be changed afterwards:
```javascript
let options;
options = {
enableHighAccuracy: true,
distanceFilter: 20,
};
this.watchId = this.geolocation.watchPosition(
() => { },
() => { },
options,
);
// => sets distanceFilter to 20
this.geolocation.clearWatch(this.watchId);
options = {
enableHighAccuracy:
Closes https://github.com/facebook/react-native/pull/6987
Differential Revision: D3258956
fb-gh-sync-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
fbshipit-source-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
Summary:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
Summary:
This change fixes an issue with calling `setValue` for natively driven nodes. As of now an attempt to call this method from JS would trigger an error "Attempting to run JS driven animation on animated". That is because for natively animated nodes we don't allow for `setNativeProps` to be executed and method `_flush` is now responsible for triggering that call. To fix the issue we add extra flag to `_updateValue` method that indicates if we should be "flushing" updated values using `setNativeProps` and we pass an appropriate value depending on the status of the node (native/non-native). Note that in animation callback we always pass `true` - that is because natively driven animations will never call into that callback.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Closes https://github.com/facebook/react-native/pull/7138
Differential Revision: D3257696
fb-gh-sync-id: 13ec26bc36b56b3208f4279a95532bbe60551087
fbshipit-source-id: 13ec26bc36b56b3208f4279a95532bbe60551087
Summary:
NSMutableURLRequest appears to be running `[headerValue count]` on every value of the NSDictionary that `allHTTPHeaderFields` is set to, meaning that any `null` values passed to headers in an XHR throw an exception. This differs from the implementation of XHR in browsers, which just ignore any `null` values for headers.
PR doesn't currently include tests, happy to add those if this is something you'd consider merging
Closes https://github.com/facebook/react-native/pull/6903
Differential Revision: D3256727
fb-gh-sync-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
fbshipit-source-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
Summary: This adds a new SceneView with a shouldComponentUpdate policy of only re-rendering when the scene's state changes. This allows avoidance of extra re-renders. Results in a much smoother back-swipe gesture because we no longer re-render scenes as we transition from gesture to animation.
Reviewed By: hedgerwang
Differential Revision: D3219545
fb-gh-sync-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
fbshipit-source-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
Summary:
This pull request corrects a bug found in `RCTAssetsLibraryRequestHandler` which used the asset UTI as the mimeType.
The code for finding the mimeType is based on the implementation used in `RCTImageLoader` and `RCTImageUtils`.
Closes https://github.com/facebook/react-native/pull/7349
Differential Revision: D3252796
Pulled By: nicklockwood
fb-gh-sync-id: b9303a99333e4744dfe23045f4a2755307305772
fbshipit-source-id: b9303a99333e4744dfe23045f4a2755307305772
Summary:
Hi,
This PR Solves this issue #3083.
This PR solves the problem of default color on TabBar being always grey. Which looks great if the barTintColor is unchanged. However if we set the barTintColor to something else (like blue in example) text and icons become quite unreadable.
Commit (c206417) - Enable setting color of unselected tabs
Solves this issue with a prop (unselectedTintColor) on TabBarIOS to which you just pass a color like you can for barTintColor and tintColor.
This leaves us with a result that is on second picture. Notice the color of text on tabs.
Or change it to yellow for demonstrating purposes
.
Run the Movies example (UIExplorer is broken atm) and make sure there are no errors.
Closes https://github.com/facebook/react-native/pull/6255
Differential Revision: D3037227
Pulled By: mkonicek
fb-gh-sync-id: bcf1350ae7a6e92c77d3a87fc9d6e42eb93cb9b9
fbshipit-source-id: bcf1350ae7a6e92c77d3a87fc9d6e42eb93cb9b9
Summary:
transformMatrix only worked on iOS and there is an equivalent API that (mostly)
works cross platform.
decomposedMatrix could technically be passed on Android but it wasn't document and explicitly flagged as not working.
My goal is to deprecate both uses and then the only supported API is the `transform: [{ matrix: ... }]` form.
The only difference is that on Android the matrix gets decomposed.
Currently there is some special cased magic that renames transform -> transformMatrix or decomposedMatrix depending on platform.
https://github.com/facebook/react/blob/master/src/renderers/native/ReactNative/ReactNativeAttributePayload.js#L50
Therefore I'm adding an alias for both native platforms called just "transform".
Next I'll swap over the JS to always target the name "transform". The only difference is how the value is marshalled over the bridge in processTransform.
To do this, I have to clean up a few callers. Mostly that's just swapping to the new API.
For buildInterpolator this is a bit trickier but this fixes it for all our use cases (which is only the Navigator in AdsManager).
Reviewed By: vjeux
Differential Revision: D3239960
fb-gh-sync-id: 838edb6644c6cdd0716834f712042f226ff3136f
fbshipit-source-id: 838edb6644c6cdd0716834f712042f226ff3136f
Summary:
Reduce re-renders by only looking at `props.data` that we're actually going to render and tracking if `this._rowFrames`
is dirty.
Differential Revision: D3195163
fb-gh-sync-id: 1e17ab410a312a37d4a93b84ea51ca32c3ede839
fbshipit-source-id: 1e17ab410a312a37d4a93b84ea51ca32c3ede839
Summary:
Added support for setting an optional badge icon number and alert action when using local notifications.
Closes https://github.com/facebook/react-native/pull/2931
Differential Revision: D3212448
Pulled By: mkonicek
fb-gh-sync-id: 063efcdd259b2a43f39812f57a71e8489ab33653
fbshipit-source-id: 063efcdd259b2a43f39812f57a71e8489ab33653
Summary: This adds support for UIManager.setChildren on Android like D2757388 added for iOS.
Reviewed By: andreicoman11
Differential Revision: D3235369
fb-gh-sync-id: b538556ec4abdb606f9be26d1b74734046bca0cd
fbshipit-source-id: b538556ec4abdb606f9be26d1b74734046bca0cd
Summary:
Useful to know what the default value without having to dig into the library code.
Closes https://github.com/facebook/react-native/pull/7247
Differential Revision: D3228728
Pulled By: mkonicek
fb-gh-sync-id: 433ca41d5395bbfb0c4887641a9e8b99c87b5e2b
fbshipit-source-id: 433ca41d5395bbfb0c4887641a9e8b99c87b5e2b
Summary:
So far, XHR only supports a few `onfoo` event handlers, not the entier `EventTarget` interface (`addEventListener`, `removeEventListener`). It also doesn't support the `upload` object on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.
Fortunately, adding proper `EventTarget` support is very easy thanks to `event-target-shim`. We already use it in our WebSocket implementation. It transparently handles the `addEventListener('foo', ...)` as well as `onfoo` APIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so that `event.target` is set properly. Basically, it's a super easy way to make us conform to the spec.
Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
**T
Closes https://github.com/facebook/react-native/pull/7017
Reviewed By: fkgozali
Differential Revision: D3202021
Pulled By: martinbigio
fb-gh-sync-id: 2b007682074356c75c774fab337672918b6c4355
fbshipit-source-id: 2b007682074356c75c774fab337672918b6c4355
Summary: Using customDirectEventTypes or customBubblingEventTypes causes a viewmanager to be initialized at app start. This diff deprecates those methods and removes their usage from RCTScrollViewManager.
Reviewed By: majak
Differential Revision: D3218973
fb-gh-sync-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
fbshipit-source-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
Summary: We always define these globals in InitializeJavaScriptAppEngine, so the fallback mechanism here is never required as far as I can tell.
Reviewed By: davidaurelio
Differential Revision: D3235061
fb-gh-sync-id: 92007f87c84073e32bfa946df8ee81083f6842ec
fbshipit-source-id: 92007f87c84073e32bfa946df8ee81083f6842ec
Summary:
event-target-shim versions before 1.1.0 do not support taking an array for `EventTarget`. react-native requires `^1.0.5`, so this fixes compatibility with those earlier versions.
**Test Plan:** ran WebSocket UIExplorer example with earlier version of event-target-shim.
Closes https://github.com/facebook/react-native/pull/7261
Differential Revision: D3230881
Pulled By: martinbigio
fb-gh-sync-id: 6a22d58841a4b401a200fece64d13a70043fb09a
fbshipit-source-id: 6a22d58841a4b401a200fece64d13a70043fb09a
Summary:
This avoids requiring things that may never be used at all by the application such as WebSocket or Geolocation. It also stops us from asking for native modules
before we actually start the application enabling us to potentially be more lazy in the future.
Reviewed By: davidaurelio
Differential Revision: D3212802
fb-gh-sync-id: 70cf0d1a85f39fedc47758e5eb5df789a511bc9b
fbshipit-source-id: 70cf0d1a85f39fedc47758e5eb5df789a511bc9b
Summary:
This only works for the new cxx bridge (hopefully open sourcing soon!).
This diff allows Java native modules to expose synchronous hooks to JS via the ReactSyncHook annotation. The methods will appear in JS on the native module object (e.g. you would do `require('UIManager').mySyncHook('foo');`) which allows us to enforce that required native modules are installed at build time. In order to support remote debugging, both the args and return type must be JSON serializable (so that we can go back across to the device to resolve synchronous hooks).
Follow ups will be integration tests, adding support for return types besides void, and adding support for remote debugging.
Reviewed By: mhorowitz
Differential Revision: D3218794
fb-gh-sync-id: 7e3366a8254276f5a55eb806287419287ca9182b
fbshipit-source-id: 7e3366a8254276f5a55eb806287419287ca9182b
Summary: Creating a view instance just to get the default view size is quite expensive, and affects startup time for the bridge as it must be done on the main thread. I've removed these cases and simply hard-coded the sizes in the JS file. This will need to be updated if the view sizes ever change, but in practice that's very unlikely.
Reviewed By: javache
Differential Revision: D3218917
fb-gh-sync-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
fbshipit-source-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
Summary:
Previously, `InteractionManager` was baked in at the lowest level to all touches via `ResponderEventPlugin`,
which meant that any time a finger was touching the screen, `InteractionManager` would be locked. This included while
doing 100% native scrolls, and thus would block progress from Relay, Incremental, or anything else scheduling events
through `InteractionManager`.
This diff switches to only bake it into `PanResponder` (and it remains hooked into `Animated` as before) which are the
main two cases where we need 60fps JS execution and want to queue up slower tasks.
This is done with a reusable higher-order-responder `InteractionManager.createResponderClass`.
Depends on FYI https://github.com/facebook/react/pull/6587, https://github.com/facebook/react/pull/6584
Reviewed By: sebmarkbage
Differential Revision: D3210951
fb-gh-sync-id: 682d21ac5cff704673b63d5942a903a3d8912835
fbshipit-source-id: 682d21ac5cff704673b63d5942a903a3d8912835
Summary:
Kudos to frantic for this amazing idea! Works really well (yet so simple!)
Basically we had a discussion with vjeux and frantic and others in the PR #7033 how to handle platform-specific stylesheets in a similar to F8 app way.
There were quite a few nice ideas there, however that one seems to be the smallest yet the most powerful.
Basically there's a `Platform.select` method that given an object, will select a `obj[Platform.OS]` value.
It works with styles:
`Platform.select({ ios: {}, android: {} })`
with messages:
`<Text>{Platform.select({ ios: 'Check the App Store', android: 'Check Google Play' })}</Text>`
and also works well with components (similar to Wallmart idea of <PlatformSwitch />) - relevant example included in diff.
Closes https://github.com/facebook/react-native/pull/7220
Differential Revision: D3221709
Pulled By: vjeux
fb-gh-sync-id: 0a50071f2dcf2273198bc6e2c36e19bca97d7be9
fbshipit-source-id: 0a50071f2dcf2273198bc6e2c36e19bca97d7be9
Summary:
The initial layout used to render scenes does not contain the actual
width and height measured and causes the issue as described at
https://github.com/ericvicenti/navigation-rfc/issues/61
The fix is to update the layout and re-render scenes once layout
is modified. Also scenes renderer should also consider the case that
when the layout is not measured yet.
Reviewed By: ericvicenti
Differential Revision: D3203245
fb-gh-sync-id: 4de89b9b43bc993d7c970c831458bd31c094073e
fbshipit-source-id: 4de89b9b43bc993d7c970c831458bd31c094073e
Summary: To prevent layout popping, when inserting images inside text we would render a blank placeholder image while the real image was loading. It turns out that this isn't necessary, as we can just specify the size of the image without having an actual image to display.
Reviewed By: javache
Differential Revision: D3212766
fb-gh-sync-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
fbshipit-source-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
Summary:This adds support for delete view animations in LayoutAnimation for iOS. It supports the same properties as the create animation (alpha, scale).
This allows making simple animations when removing a view which is normally hard to do in React since we need to not remove the view node immediately.
**Test plan**
Tested add/removing views in the UIExample explorer with and without setting a LayoutAnimation. Also tested that the completion callback still works properly. Tested that user interation during the animation is properly disabled.
I also plan to work on improving the doc for LayoutAnimation as well as making this PR for android too.
Closes https://github.com/facebook/react-native/pull/6779
Differential Revision: D3215525
Pulled By: sahrens
fb-gh-sync-id: 526120acd371c8d1af433e8f199cfed336183775
fbshipit-source-id: 526120acd371c8d1af433e8f199cfed336183775
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: AaaChiuuu
fb-gh-sync-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
fbshipit-source-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
Summary:Fixes #5408 as per ide and vjeux suggestions here https://github.com/facebook/react-native/issues/529#issuecomment-107328799
Could've been probably done in a single `if` clause, but this is more explicit and leaves potential place for future implementation (if we ever decide to do so)
Closes https://github.com/facebook/react-native/pull/7197
Differential Revision: D3217740
Pulled By: vjeux
fb-gh-sync-id: aa08a5c42e43c1abe17b72a424ee96146f2667f6
fbshipit-source-id: aa08a5c42e43c1abe17b72a424ee96146f2667f6
Summary:Fixes #5855
Tested with `UIExplorer`, first <Text> is the `onPress`, second is the `onLongPress`.
Closes https://github.com/facebook/react-native/pull/7099
Differential Revision: D3212436
Pulled By: mkonicek
fb-gh-sync-id: 0a1cbcd4eaf39ad4fe67d861c3be2e042e1acb27
fbshipit-source-id: 0a1cbcd4eaf39ad4fe67d861c3be2e042e1acb27
Summary:This change adds native animated support for Animated.interpolate
Animated.interpolate allows for defining nodes that outputs an interpolated value of their input node based on the interpolation node configuration. For now native animated implementation only supports a linear interpolation for a given input and output ranges (ranges can consists of multiple segments). Native interpolation node is compatible with the JS implementation with the exception that not all attributes that can be used in JS are supported. Before we migrate interpolation node from JS->native we verify that only supported props are used.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Run java tests: `buck test ReactAndroid/src/test/java/com/facebook/react/animated`
Closes https://github.com/facebook/react-native/pull/7141
Differential Revision: D3216546
fb-gh-sync-id: 29876e33956615c6370ca4d332abe048f8dba5b8
fbshipit-source-id: 29876e33956615c6370ca4d332abe048f8dba5b8
Summary:We no longer forward React onto this object. We only forward the ReactNative
module onto it.
We also deprecated the addons so they'll all warn. We'll remove it
completely soon.
Closes https://github.com/facebook/react-native/pull/7136
Reviewed By: gabelevi
Differential Revision: D3211809
Pulled By: sebmarkbage
fb-gh-sync-id: 77aaa909dca5e2522cfaa7b4ca361fabc614be58
fbshipit-source-id: 77aaa909dca5e2522cfaa7b4ca361fabc614be58
Summary: We only measure text at the root node, we shouldn't be trying to build a text storage later on for tree lower in the shadow node tree.
Reviewed By: nicklockwood
Differential Revision: D3212614
fb-gh-sync-id: 574fa7f2c029ca9ad2d5fabe7bbb148157f85ca7
fbshipit-source-id: 574fa7f2c029ca9ad2d5fabe7bbb148157f85ca7
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: mkonicek
fb-gh-sync-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
fbshipit-source-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
Summary:**Motivation:** In my app, I'm using a WebView that loads content from my mobile site. What I want to do is when a user presses a link on the loaded page, I want to stop the WebView's request, hijack the URL and open the URL in a new WebView, pushed to the top of the navigator stack. To me, this gives the overall app a more native feel, instead of implementing a rudimentary navbar on the main WebView to go back.
**Attempted Workarounds:** I've attempted to get similar functionality by capturing the onNavigationStateChange event in the WebView, and then within calling goBack + pushing the new view to the navigator stack. From a functionality standpoint, this works. However, from a UI standpoint, the user can clearly see the webview change states to a new page + go back before having the new view pushed on top of their nav stack.
Closes https://github.com/facebook/react-native/pull/6886
Differential Revision: D3212447
Pulled By: mkonicek
fb-gh-sync-id: 05911e583d9ba54ddbd54a772153c80ed227731e
fbshipit-source-id: 05911e583d9ba54ddbd54a772153c80ed227731e
Summary:This change extends animated native module API with `stopAnimation` method that is responsible for interrupting actively running animation as a reslut of a JS call. In order for the `stopAnimation` to understand `animationId` argument I also had to add `animationId` to `startAnimation` method. As JS thread runs in parallel to the thread which executes the animation there is a chance that JS may call `stopAnimation` after the animation has finished. Because of that we are not doing any checks on the `animationId` parameter passed to `stopAnimation` in native and if the animation does not exists in the registry we ignore that call.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Run java tests: `buck test ReactAndroid/src/test/java/com/facebook/react/animated`
Closes https://github.com/facebook/react-native/pull/7058
Differential Revision: D3211906
fb-gh-sync-id: 3761509651de36a550b00d33e2a631c379d3900f
fbshipit-source-id: 3761509651de36a550b00d33e2a631c379d3900f
Summary: Similar to ScrollView, adds ability to set scrollEnabled={false}, which prevents dragging. Paging is still possible by updating initialPage.
Reviewed By: AaaChiuuu
Differential Revision: D3209743
fb-gh-sync-id: ce4140323a03f2257a9bb310c7285418b01abae7
fbshipit-source-id: ce4140323a03f2257a9bb310c7285418b01abae7
Tucker Connelly
Fabian Eichinger
Paul Shen
Wenjing Wang
Hedger Wang
Kevin Smith
Kasim Tan
Fred Liu
Brandon Withrow
Nick Lockwood
Spencer Ahrens
Alex Kotliarskyi
Konstantin Raev
Kyle Corbitt
Janic Duplessis
Jon Lebensold
Maarten Schumacher
Nathan Azaria
Geoff Lawson
Sokovikov
Ben Nham
Dave Miller
Joshua Pinter
Pieter De Baets
dragonwong
Ricky Reusser
James
Kasim Tan
Pieter De Baets
Marco Bonaldo
Jonathan Stanton
Ewan Mellor
sheparddw
Igor Avramovic
Jake Murzy
Christian Ost
Basil Hosmer
Philipp von Weitershausen
Martín Bigio
Adam Comella
Jakob Kerkhove
Emil Sjolander
Jim Remsik
Gabe Levi
Sean Kinsey
taelimoh
Ben Alpert
Rahul Jiresal
David Aurelio
James Ide
Corné Dorrestijn
Mike Grabowski
dmueller39
Alexander Blom
Joe Noon
Alex Kotliarskyi
Sean Kelley
Yu Huang
Tore Hanssen
Naman Goel
Yao Bin Then
Jimmy Mayoukou
Nathan Spaun
Olivier Notteghem
Kevin Johnson
nemothecapt
Eric Vicenti
Jesse Sessler
UnoDeTantos
Alessandro Nadalin
wusuopu
Sebastian Gronewold
Chris Geirman
Jean-Richard Lai
David Aurelio
Krzysztof Magiera
Griffin Smith
Yedidya Kennard
Urban Cvek
Jason Prado
Sebastian Markbage
Charles Dick
alvaromb
Christoph Pojer
Howard Yeh
Philipp von Weitershausen
Andy Street
Steven Luscher
Scott Foggo
Christian Meunier
Jeff Chien
Ian MacLeod
Felix Oghina
Andrew Gray
glevi@fb.com
Angela Hess
