Summary:
Not a API change, but this may break the layout of exisitng apps that
uses NavigationHeader.
For now, NavigationHeader uses absolute position, which makes it hard for
NavigationCardStack to determine the height of the scenes.
Theoretically, the height of the scenes would be the height of the cards
stack minus the height of the header.
That said, if we want to support the headers with different height (e.g.
MyIOSHeader or MyAndroidHeader), we're forced to expose the height of the
headers and manually compute the height of the scenes.
Alternatively, if the header does not use absolute position, the height
of the scenes can adjust automatically with flex box, and that's what this
commit is about to do.
Reviewed By: ericvicenti
Differential Revision: D3671119
fbshipit-source-id: 26e48f801da3661c5d7dce4752ba927621172f4a
Summary:
Adds support for `Animated.Value#addListener` for native driven nodes on Android. This is based on work by skevy in the exponent RN fork. Also adds a UIExplorer example.
** Test plan **
Run unit tests
Tested that by adding a listener to a native driven animated node and checked that the listener callback is called properly.
Also tested that it doesn't crash on iOS that doesn't support this yet.
Closes https://github.com/facebook/react-native/pull/8844
Differential Revision: D3670906
fbshipit-source-id: 15700ed7b93db140d907ce80af4dae6be3102135
Summary:
NavigationCardStack is a custom component, and its API should be explicit, not
too generic..
In NavigationCardStack, the prop `renderOverlay` is actually used to render
the NavigationHeader, and we uses absolute position to build the layout for
the header and the body.
One of the problem with using absolute postion and fixed height to build the
layout that contains the header is that the header can't have variant height
easily.
Ideally, if the layout for the header used flex-box, we'd ve able to be more
adaptive to deal with the header that has variant height.
That said, let's rename `renderOverlay` to `renderHeader`, then build the
proper layout that explicitly works better with the header.
If we to need to support overlay in navigation, we may consider add
`renderOverlay` later, if it's really necessary.
Reviewed By: ericvicenti
Differential Revision: D3670224
fbshipit-source-id: ff04acfe9dc995cb57117b3fd9b07d5f97b9c6ee
Summary:
The animation shown in the UIExplorer example for NavigationExperimental's NavigationHeader is not working correctly. Due to an incomplete use of the `renderTitleComponent()` callback, interpolation is not working correctly in this example.
Even if the animation error is subtle, since the examples are followed by developers quite closely, the bug may multiply if not corrected in the sample code.
This is a really *tiny* modification that fixes that particular animation.
Closes https://github.com/facebook/react-native/pull/9067
Differential Revision: D3669140
Pulled By: javache
fbshipit-source-id: 6dab36a9132da2f704e9a074ae26e744c3420cde
Summary:
Sometimes is handy to check if a React node is a descendant of another node or not. For instance, I want to check if the focused `TextInput` is descendant of an specific `ScrollView`:
```js
const currentlyFocusedField = TextInput.State.currentlyFocusedField()
UIManager.viewIsAncestorOf(
currentlyFocusedField,
this.getInnerViewNode(),
(isAncestor) => {
if (isAncestor) {
console.log('The focused field is a descendant of this ScrollView!')
}
}
)
```
This function uses the same strategy as the `measureLayout` method to check if one node is an ancestor of other node. As the `measureLayout` method, this is performed outside the main thread.
By now I've only implemented the iOS version and its tests, but if this function is going to be merged I'll implement the Android version too. I have objc experience but no Java or Android, so I prefer to validate this functionality before jumping into developing the Android part.
Closes https://github.com/facebook/react-native/pull/7876
Differential Revision: D3662045
Pulled By: javache
fbshipit-source-id: b9668e8ea94fd01db76651f16243926cf9c2566f
Summary:
**This is the first part of `React.createClass` -> ES2015 classes migration.
1. Rewritten UI Explorer ActivityIndicator example to ES2015 classes
2. Removed TimerMixin from example.
Motivation:
- ES2015 classes do not support mixins so due to the classes / pure functions as "best practices" it would be better to avoid mixins in examples.
- TimerMixin is covered later and is out of scope of current example.
Closes https://github.com/facebook/react-native/pull/8342
Differential Revision: D3659349
fbshipit-source-id: e1c6f1a3091d60c589303fe6da55b8d132adedc3
Summary:
On iOS, if `TextInput` is used with prop `multiline={true}`, the backend view is `UITextView`. Sometimes we need `UITextView.dataDetectorTypes` to detect clickable url in the text view. The PR add this prop to `TextInput`, so we can use it like this:
`<TextInput`
` defaultValue="Detect phone number: 88888888."`
` editable={false}`
` multiline={true}`
` dataDetectorTypes="all"`
` />`
Similar as #8743 .
Closes https://github.com/facebook/react-native/pull/8863
Differential Revision: D3648027
fbshipit-source-id: 987bd4f46fb5be74099b62988135a32115d9269c
Summary:
**motivation**
Previously, size can only accept either 'small' or 'large'. And to obtain a custom size, scale transformation is used. This is to let users to possibly pass number value directly to define ActivityIndicator's size.
**Test plan**
I have also modified the current example to reflect the new size prop in action.
Closes https://github.com/facebook/react-native/pull/8935
Differential Revision: D3637910
fbshipit-source-id: 6b8e1d4504964916df327b2d3eaaef1bb8cd5112
Summary: Mirrors Android's support for multiple sources for Image, allowing us to fetch new images as the size of the view changes.
Reviewed By: mmmulani
Differential Revision: D3615134
fbshipit-source-id: 3d0bf2b75f63a4379e0e49f2dab9aea351b31d5f
Summary:
lineBreakMode only in rc so I think we can replace property without any deprecation warnings. satya164
Closes https://github.com/facebook/react-native/pull/9008
Differential Revision: D3614901
fbshipit-source-id: 724227c0a89192825a24850b930b80884571a51f
Summary:
revision of https://github.com/facebook/react-native/pull/5476
It has only one method `shareTextContent` and next will be`shareBinaryContent`.
In Android, Promise can't receive a result, because `startActivityForResult` is not working with `Intent.ACTION_SEND`. Maybe we can use `createChooser(Intent target, CharSequence title, IntentSender sender)` which requires API level 22.
Closes https://github.com/facebook/react-native/pull/5904
Differential Revision: D3612889
fbshipit-source-id: 0e7aaf34b076a99089cc76bd649e6da067d9a760
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
Summary: Add support for top, bottom, and center layout gravity to ToastAndroid
Reviewed By: AaaChiuuu
Differential Revision: D3590224
fbshipit-source-id: 84dbbcfbe4133f291d62723c5c261acd7b32b46e
Summary:
I thought it would be useful to help clear out references to no longer used styles and also catch typos on style names to have flow error when we try to access a style that isn't defined.
Example:
```javascript
export default class AuthenticationScreen extends React.Component {
render() {
// This throws an error because `continer` is misspelled
return (
<View style={styles.continer} />
)
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
},
}
```
```javascript
export default class AuthenticationScreen extends React.Component {
render() {
// This throws an error because no fancyContainer style is defined
return (
<View style={[styles.container, styles.fancyContainer]} />
)
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
},
}
```
All credit goes to jeffmo in this tweet: https://twitter.com/lbljeffmo/status/755179096271888385
Also included in the PR is some cleanup on styles that
Closes https://github.com/facebook/react-native/pull/8876
Differential Revision: D3584983
Pulled By: yungsters
fbshipit-source-id: 0ee0e12ff3d976c137d932688e323c26690e0a52
Summary:
Files were moved to the js/ directory so UIExplorer did not work anymore on iOS, this fixes the path.
Closes https://github.com/facebook/react-native/pull/8841
Differential Revision: D3576752
fbshipit-source-id: 921ddc2e158ee0c74dcf691a32504900c5d79e1d
Summary:
This changes the JS location of the examples (2048, UIExplorer, Movies, and TicTacToe) to be set from RCTBundleURLProvider instead.
This also makes the example apps run the bundle script, which makes the build time longer.
Reviewed By: javache
Differential Revision: D3516371
fbshipit-source-id: 70e53c62feb81c067df4e2298e7d1f1458777490
Summary: When pasting text longer than maxlenght, the textDidChange: call we did would end calling back into textView:shouldChange: because we saw an unexpected multi-character change. Since this is an expected mutation, update predictedText appropriately.
Reviewed By: majak
Differential Revision: D3561524
fbshipit-source-id: 07bb78d830ccfa3aed6ee274dc30adeadce9e1f8
Summary:
iOS follow up to #8569. This currently depends on the Android PR since it contains the JS implementation, only review the last commit. Just putting this out here for visibility, don't merge this before the Android PR.
**Test plan**
Tested by running a background task that burns all remaining idle time (see UIExplorer example).
Tested that native only calls into JS when there are pending idle callbacks.
Tested that timers are executed before idle callback.
Closes https://github.com/facebook/react-native/pull/8734
Differential Revision: D3560818
fbshipit-source-id: a28d3092377a7fd4331647148d40fe69e4198c7e
Summary:
This is a follow up of the work by brentvatne in #5052. This addresses the feedback by astreet.
- Uses ReactChoreographer with a new callback type
- Callback dispatch logic moved to JS
- Only calls into JS when needed, when there are pending callbacks, it even removes the Choreographer listener when no JS context listen for idle events.
** Test plan **
Tested by running a background task that burns all remaining idle time (see new UIExplorer example) and made sure that UI and JS fps stayed near 60 on a real device (Nexus 6) with dev mode disabled. Also tried adding a JS driven animation and it stayed smooth.
Tested that native only calls into JS when there are pending idle callbacks.
Also tested that timers are executed before idle callback.
```
requestIdleCallback(() => console.log(1));
setTimeout(() => console.log(2), 100);
burnCPU(1000);
// 2
// 1
```
I did *not* test with webworkers but it should work as I'm using executor tokens.
Closes https://github.com/facebook/react-native/pull/8569
Differential Revision: D3558869
Pulled By: astreet
fbshipit-source-id: 61fa82eb26001d2b8c2ea69c35bf3eb5ce5454ba
Summary:
NavigationCardStack has a race condition when replacing routes quickly (like on keystrokes).
This change reverts some capability of the UIExplorerList but makes it feel nice for the meantime while we fix the issue in NavigationTransitioner. If we used flux/redux for UIExplorer, this issue would have been avoided.
Reviewed By: javache
Differential Revision: D3556035
fbshipit-source-id: 36b3e7b5abb1ec11cd68acda40db588920ff7e11
Summary:
In preparation for Blob support (wherein binary XHR and WebSocket responses can be retained as native data blobs on the native side and JS receives a web-like opaque Blob object), this change makes RCTNetworking aware of the responseType that JS requests. A `xhr.responseType` of `''` or `'text'` translates to a native response type of `'text'`. A `xhr.responseType` of `arraybuffer` translates to a native response type of `base64`, as we currently lack an API to transmit TypedArrays directly to JS. This is analogous to how the WebSocket module already works, and it's a lot more versatile and much less brittle than converting a JS *string* back to a TypedArray, which is what's currently going on.
Now that we don't always send text down to JS, JS consumers might still want to get progress updates about a binary download. This is what the `'progress'` event is designed for, so this change also implements that. This change also follows the XHR spec with regards to `xhr.response` and `xhr.responseText`:
- if the response type is `'text'`, `xhr.responseText` can be peeked at by the JS consumer. It will be updated periodically as the download progresses, so long as there's either an `onreadystatechange` or `onprogress` handler on the XHR.
- if the response type is not `'text'`, `xhr.responseText` can't be accessed and `xhr.response` remains `null` until the response is fully received. `'progress'` events containing response details (total bytes, downloaded so far) are dispatched if there's an `onprogress` handler.
Once Blobs are landed, `xhr.responseType` of `'blob'` will correspond to the same native response type, which will cause RCTNetworking to only send a blob ID down to JS, which can then create a `Blob` object from that for consumers.
Closes https://github.com/facebook/react-native/pull/8324
Reviewed By: javache
Differential Revision: D3508822
Pulled By: davidaurelio
fbshipit-source-id: 441b2d4d40265b6036559c3ccb9fa962999fa5df
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?
UIExplorer example doc fix.
**Test plan (required)**
Unnecessary.
**Code formatting**
Just fix comment, not related to code
Fix pre-bundle doc
Closes https://github.com/facebook/react-native/pull/8733
Differential Revision: D3554930
fbshipit-source-id: 76ed3da17df840f90987f7468cea7cd65741313f
Summary: Move all JS to a js/ subfolder so we get some overview of this folder again.
Reviewed By: bestander
Differential Revision: D3542598
fbshipit-source-id: 7637133fe4152f4d39e461b443b38510272d5bc8
Summary:
This adds proper support for tracking a TextInput content size as discussed in #6552 by adding a new callback that is called every time the content size changes including when first rendering the view.
Some points that are up for discussion are what do we want to do with the onChange callback as I don't see any use left for it now that we can track text change in onChangeText and size changes in onContentSizeChange. Also a bit off topic but should we consider renaming onChangeText to onTextChange to keep the naming more consistent (see [this naming justification](https://twitter.com/notbrent/status/709445076850597888)).
This is split in 2 commits for easier review, one for iOS and one for android.
The iOS implementation simply checks if the content size has changed everytime we update it and fire the callback, the only small issue was that the content size had several different values on initial render so I added a check to not fire events before the layoutSubviews where at this point the value is g
Closes https://github.com/facebook/react-native/pull/8457
Differential Revision: D3528202
Pulled By: dmmiller
fbshipit-source-id: fefe83f10cc5bfde1f5937c48c88b10408e58d9d
Summary:
Add an example for Pager built with NavigationTransitioner & Animated.View
This example demostrates how to apply pre-defined gesture handling and
animation styles to the <Animated.View /> to build a Pager navigator.
Reviewed By: ericvicenti
Differential Revision: D3495807
fbshipit-source-id: 08e275010888925bc9fd1840e7052f975c95ad63
Summary: Add support inlining images into text inputs. For now this is only available on Android.
Reviewed By: andreicoman11
Differential Revision: D3470805
fbshipit-source-id: 14db05ec4d5af549bf314b903654314f39bf73ea
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
This adds support for a text field that the user can click-and-drag to select text (which can then be copied using the native selected-text-hover-widget).
I'd love to add this to iOS too, but iOS appears to draw glyphs directly to the screen for its <Text> widget (versus using UITextField), so it might be too difficult to support there. But at least I can support my Android users with this change.
Let me know if/what kind of "demonstrate the code is solid" you would like for this. A screenshot of selected text with this property set?
Closes https://github.com/facebook/react-native/pull/8028
Differential Revision: D3474196
Pulled By: bestander
fbshipit-source-id: 8d3656681265a0e6229bfa13ff2ae021e894d3cd
Hedger Wang
Janic Duplessis
Eric Vicenti
sam
G. Grau
alvaromb
Artyom Trityak
Pieter De Baets
yueshuaijie
Fadil Sutomo
David Goldman
Ben Alpert
Sokovikov
SangYeob Bono Yu
Emil Sjolander
Don Yu
Tobias Ritzau
sasaki takeru
Brent Vatne
Ernest Walzel
Nathan Azaria
Philipp von Weitershausen
弘树
Skotch Vail
Jeff Morrison
Ian Childs
Jing Chen
Konstantin Raev
Tucker Connelly
Martín Bigio
Mike Lambert
