Summary:
We run into this timeout virtually every live-reload now, which I believe is just a function of the size of our React Native code base. Looking at the code, right now the prepare JS call is run and retried 3 times, with a wait/timeout of 1s each. On android, it's done 3 times with a wait/timeout of 5s on each. For consistency, I've updated it to be the same timeout as on android. Trying this with our project, we no longer get red-boxes when we live-reload for the first time.
I've run this on our project locally, and it fixed the issue. It's a very simple change, so I don't believe any additional testing should be needed.
[IOS][BUGFIX][RCTWebsocketExecutor] - Increased timeout to prevent false-positive redbox during development of large RN code base
Closes https://github.com/facebook/react-native/pull/16794
Differential Revision: D6387545
Pulled By: shergin
fbshipit-source-id: c6e58fb82e072c01f9e1277a58d2640d6140a8c7
Summary:
I was confused by the current documentation, as it was requesting me to pass the previously received `end_cursor` into the next fetch but it was declared as a boolean. I checked in the debugger and it's just mislabeled in the docs, so this PR fixes the docs.
I tried to push this change back in #15472 but wasn't able to undo the borked rebase, so I'm submitting a new PR.
This is a change to documentation only.
[DOCS] [BUGFIX] [Libraries/CameralRoll/CameraRoll.js] - Corrected return type in the documentation for the `start_cursor` and `end_cursor` values.
Closes https://github.com/facebook/react-native/pull/16830
Differential Revision: D6371585
Pulled By: hramos
fbshipit-source-id: 5038041e95a04ea4c2de8d2b535a8a4e019289f6
Summary:
Improve the error message shown when you try to nest components in an
`<Image>` component by referencing the `<ImageBackground>` component.
It would be helpful if the error message displayed when you try to nest components in an `<Image>` component mentioned the `<ImageBackground>` component. Especially since this component is not yet well documented.
[IOS][MINOR][Libraries/Image/Image.ios.js] - Surfaced `<ImageBackground>` in error message
[ANDROID][MINOR][Libraries/Image/Image.android.js] - Surfaced `<ImageBackground>` in error message
Closes https://github.com/facebook/react-native/pull/16880
Differential Revision: D6369396
Pulled By: shergin
fbshipit-source-id: c4ae4dbb77d0fce6cbd7a42d1957d16112b24549
Summary:
Now that the Component and API docs are no longer auto-generated, we need to consolidate on a new format for our jsdoc comments. Any help from the community will be appreciated.
In this initial pull request, we'll be tackling the following docs:
- `AccessibilityInfo`, an API doc.
- `ActivityIndicator`, a Component doc.
- `View`, a Component doc.
This top comment will serve as a style guide, and when in doubt, please refer to the individual commits in this PR.
Each commit should update a single component or API, along with any relevant markdown files.
- Documentation in the JavaScript source files should be succinct. Any verbosity should be moved over to the markdown docs in the website...
- ...by adding a link to the relevant method/prop on the website to every comment block.
- Avoid markdown style links in JavaScript source files, opt for plain old URIs.
Let code document itself:
- If a method is Flow typed, the comment block does not need to repeat this information.
- If a param can be one of several values, and the type definition is easily determined from the code, the values should not be repeated in the comment block. Again, move this to the markdown doc if not present already.
Closes https://github.com/facebook/react-native/pull/16790
Differential Revision: D6353840
Pulled By: hramos
fbshipit-source-id: 9712c459acc33092aae9909f3dd0b58a00b26afc
Summary:
1. file:// may get prepended to an http:// source URL during dev mode, making an invalid URL
2. the logic to detect `isLoadedFromFileSystem()` should've checked for file:// protocol to not get confused by http:// URL
Reviewed By: zahanm
Differential Revision: D6307187
fbshipit-source-id: e7e7a41bf721dd0601b0c1877e278e1e435ef5e2
Summary:
Pass scriptURL to RCTTestRunner.
If the scriptURL passed to RCTTestRunner is not nil, then RCTTestRunner will use it.
else, RCTTestRunner will use whatever it has before.
Differential Revision: D6215186
fbshipit-source-id: c3a5643021d60579fc8e60a69de150f6a4a39237
Summary:
RCTSurfaceBackedComponent is ComponentKit component represents a React Native Surface created
(and stored in the state) with given `bridge`, `moduleName`, and `properties`.
Differential Revision: D6217103
fbshipit-source-id: 2849f68e1975562cd47851bda232e389705b4229
Summary:
Nice addition of the recent Flow types for style props in 9c29ee1504, however I think there are some slight issues in the definition.
`type Styles = {[key: string]: Object}` makes sense, as it's referring to the set of named style groups a user creates a `StyleSheet` from, e.g.
```javascript
const styles: StyleSheet = StyleSheet.create({
container: {
height: 20
},
text: {
color: '#999',
fontSize: 12,
},
}: Styles)
```
However `type StyleValue = {[key: string]: Object}` doesn't make sense. You actually want only the `Object` portion of that definition, presuming it's meant to be used like below:
```javascript
type MyTextProps = {
style: StyleProp,
}
<MyText style={{ color: '#999', fontSize: 12 }}>Hello</Text>
```
---
I've also added `void` to the `StyleValue`, as undefined seems to be handled fine, and can be a useful shorthand in JSX.
---
And finally, I've allowed nesting of style prop arrays, by making StyleProp self-referencing, as RN seems to flatten those without issue. This can be important if you're passing in a style prop quite high up the component tree, and sticking it in an array with other styles at several points while it's passed down.
N/A (These types aren't referenced anywhere else)
[INTERNAL] [MINOR] [StyleSheet] - Refine Flow types
Closes https://github.com/facebook/react-native/pull/16741
Reviewed By: frantic
Differential Revision: D6278010
Pulled By: TheSavior
fbshipit-source-id: 0170a233ab71d29f445786f5e695463f9730db3a
Summary:
Found this minor issue while reading the docs.
n/a
[DOCS] [BUGFIX] [Libraries/Text/Text.js] - Add return to example
Closes https://github.com/facebook/react-native/pull/16752
Differential Revision: D6274215
Pulled By: hramos
fbshipit-source-id: ef735eb9179ab69d2ed1bc4a8b5e921d42d88fb0
Summary:
The documentation for `KeyboardAvoidingView` was pretty thin. Tried to fill it out more and corrected a couple words.
n/a
[DOCS] [ENHANCEMENT] [KeyboardAvoidingView] - Improve the documentation for the props for KeyboardAvoidingView
* **Who does this affect**: Users that are manually calling the methods on KeyboardingAvoidingView.
* **How to migrate**: Add an underscore before the name of the method
* **Why make this breaking change**: These methods are not meant to be public. For example, the exposed `onLayout` function is not a prop that accepts a function like is typical of the rest of React Native but is the internal method that is called when the component's onLayout is triggered.
* **Severity (number of people affected x effort)**: Low
Closes https://github.com/facebook/react-native/pull/16479
Differential Revision: D6261005
Pulled By: hramos
fbshipit-source-id: 7e0bcfb0e7cb6bb419964bd0b02cf52c9347c608
Summary:
I find it easier to understand the behavior of a component when there is a simple example showing its usage. I recently used the CheckBox component and noticed that it doesn't have a code example. This PR adds an example to the CheckBox documentation.
N/A
[DOCS][ENHANCEMENT][CheckBox] - Added example to documentation
Closes https://github.com/facebook/react-native/pull/16489
Differential Revision: D6260998
Pulled By: hramos
fbshipit-source-id: 7c6f9677741a4c0483eb1f5405cd05f8bbdd83aa
Summary:
This commit adds documentation to two methods of BackHandler API, addEventListener and removeEventListener. Despite being a simple change, it helps to keep the documentation consistent.
I have tested the `./website` locally, the changes look similar to some other components such as `NetInfo`.
[DOCS][ENHANCEMENT][BackHandler] - Improve BackHandler documentation (addEventListener and removeEventListener)
Closes https://github.com/facebook/react-native/pull/16618
Differential Revision: D6260935
Pulled By: hramos
fbshipit-source-id: ab04a9fca89ddaa1925844b5754caf1c355a9329
Summary:
It's currently possible to crash React Native on iOS when using XMLHTTPRequest with onreadystatechange by having the server send a bunch of bad unicode (we found the problem when a bad deploy caused this to happen).
This is due to an integer overflow when handling carryover data in decodeTextData.
Create Express server with mock endpoint:
```js
var express = require('express');
var app = express();
app.get('/', function(req, res) {
res.writeHead(200, {'content-type': 'text/plain; charset=utf-8'});
res.flushHeaders();
res.write(new Buffer(Array(4097).join(0x48).concat(0xC2)));
res.write(new Buffer([0xA9]));
res.end();
});
app.listen(3000);
```
Create React Native application which tries to hit the endpoint:
```js
export default class App extends Component<{}> {
componentDidMount() {
const xhr = new XMLHttpRequest()
xhr.open('get', 'http://localhost:3000', true);
xhr.onreadystatechange = function () {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.warn(xhr.responseText);
}
};
xhr.send();
}
render() {
return null;
}
}
```
Observe that the application crashes when running master and doesn't when including the changes from this pull request.
[IOS] [BUGFIX] [RCTNetworking] - |Check against integer overflow when parsing response|
Closes https://github.com/facebook/react-native/pull/16286
Differential Revision: D6060975
Pulled By: hramos
fbshipit-source-id: 650e401a3bc033725078ea064f8fbca5441f9db5
Summary:
Allow end users to access the YellowBox API so that warnings can be properly ignored via the API first introduced in a974c140db. Based on that API, you should be able to do the following:
```
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Warning: ...']);
```
However, if you actually try this today, it results in a broken import error.
Verified using an expo instance. First tried without the YellowBox import, observed a failure to import. Then I added the import statement, and observed no warning on my device.
```
import React from 'react';
import { StyleSheet, Text, View, YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['hey']);
export default class App extends React.Component {
render() {
console.warn('hey!');
return (
<View style={styles.container}>
<Text>Open up App.js to start working on your app!</Text>
<Text>Changes you make will automatically reload.</Text>
<Text>Shake your phone to open the developer menu.</Text>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
backgroundColor: '#fff',
alignItems: 'center',
justifyContent: 'center',
},
});
```
[GENERAL] [ENHANCEMENT] [YellowBox] - Export YellowBox API so warnings can be ignored using a non-deprecated API.
Closes https://github.com/facebook/react-native/pull/16709
Differential Revision: D6254819
Pulled By: hramos
fbshipit-source-id: ff92f32e4dedfb01f6902f54fabc62eb64468554
Summary:
This pr adds documentation for the tintColor addition of #4590
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
The tintColor was missing from the documentation but works perfectly fine.
Added a tintColor to showActionSheetWithOptions and showShareActionSheetWithOptions in the app i am building right now.
[DOCS][MINOR][ActionSheetIOS] - Added documentation for tintColor in ActionSheet.
Closes https://github.com/facebook/react-native/pull/16679
Differential Revision: D6248070
Pulled By: shergin
fbshipit-source-id: a2276f50b42ff2c5858008f3641c9607f248744a
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
While building a React Native application, I've come across the use case of wanting to set a specific locale for DatePickers irrespective of the users OS region setting. Since this is a feature available to native DatePicker components, I think it would be helpful to expose this in React Native as well.
Testing can be done by passing a `locale` prop to a DatePickerIOS. Example:
```
<DatePickerIOS
date={this.state.date}
mode="date"
locale="fr_FR"
onDateChange={date => this.setState({ date: date })}
/>
```
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAl ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[IOS][ENHANCEMENT][DatePickerIOS] - Adding a locale prop.
Closes https://github.com/facebook/react-native/pull/16639
Differential Revision: D6241981
Pulled By: hramos
fbshipit-source-id: 77b1b85c09f3e12d6b3e103b3d1ffd1f12e2cea9
Summary:
There are a number of $FlowFixMe statements in TarBarIOS.ios.js as a result of recent Flow upgrades introducing new errors/warnings. I had a stab at removing these statements and introducing what are hopefully sensible types.
Only types were changed so `yarn flow` should be sufficient.
[INTERNAL] [MINOR] [TarBarIOS] - |Fix $FlowFixMes|
Closes https://github.com/facebook/react-native/pull/16365
Differential Revision: D6200713
Pulled By: TheSavior
fbshipit-source-id: ecbd58d5831dd04250e794812ea03d202f777d12
Summary:
It would be great to have examples in the documentation of all components. I have created a PR to add an example for `CheckBox`, and now I am adding an example for the `Slider` component.
The PR changes documentation. No further test is required.
[DOCS][ENHANCEMENT][Slider] - Added example to documentation
Closes https://github.com/facebook/react-native/pull/16588
Differential Revision: D6197329
Pulled By: hramos
fbshipit-source-id: 91d1b20fc2d4bae15f9706ac4c155411d91af290
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
I want to animate `shadowOpacity` style property with Native Animated (`useNativeDriver: true`). This is useful for example in an ios-like navigation transition where the shadow fades in with the view that is sliding in from the side. Code comment for `STYLES_WHITELIST` says:
_In general native animated implementation should support any numeric property that doesn't need to be updated through the shadow view hierarchy (all non-layout properties)._
so I just added `shadowOpacity` (and `shadowRadius` too because why not?).
Before this change, setting `shadowOpacity` (or `shadowRadius`) to an `AnimatedValue` (with `useNativeDriver: true`) would throw the error: `Style property 'shadowOpacity' is not supported by the native animated module`.
After adding `shadowOpacity` (and `shadowRadius`), there is no error. The animation looks correct so it seems to be working. I also tried setting a ridiculously large `shadowRadius` and could see that working too.
Please advice on any further testing I should do.
[IOS] [ENHANCEMENT] [NativeAnimated] - Allow `shadowRadius` and `shadowOpacity` as NativeAnimated style properties.
Closes https://github.com/facebook/react-native/pull/16603
Differential Revision: D6195364
Pulled By: hramos
fbshipit-source-id: a55630df43df3c8f9db9921dab0bfbf925b6a09f
Summary: Moves initialization of `Map` and `Set` polyfills to the top of `InitializeCore` to avoid problems with JSC versions that don’t accept (or silently ignore) iterables as constructor arguments.
Reviewed By: mjesun
Differential Revision: D6185632
fbshipit-source-id: 3abe4baeb3a08c328d8c6b3bb1b2e01716c2c95c
Summary:
Xcode 9 has compiler settings that are more strict. This can occur if someone updates there project to use the default settings.
This patch declares the default type instead of allowing the compiler to determine it. Instead of `()` we now say `(void)` in a block call.
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
It was just annoying me, and it has no side effects. If there are side effects, then we should fix the type and not go with empty to represent void.
Update project settings in Xcode. This code doesn't have any known side effects since the compiler assumes the type is void when not declared.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAl ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[DOCS] - Fixed potential compiler build issue on Xcode 9 after updating settings in project.
Closes https://github.com/facebook/react-native/pull/16554
Differential Revision: D6184949
Pulled By: shergin
fbshipit-source-id: 23083248a39c56f5cf50b5ff4390629dd6335f84
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
oss-typos DC workshop: rid the world of typos.
Manual spell checker reporting duty.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAl ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[DOCS][MINOR][JSTimers.js] Fixed "constants" typo
Closes https://github.com/facebook/react-native/pull/16559
Differential Revision: D6184938
Pulled By: shergin
fbshipit-source-id: d16822d3885c6439239102df2790f5dbf5271a19
Summary:
Got frustrated for a minute trying to figure out why the code I copy pasted from the docs wasn't working
The link I replaced the broken one with is the one used in the iOS device example next to the sample code. It can be found at https://facebook.github.io/react-native/img/favicon.png
[DOCS] [MINOR] [Libraries/Image/Image.ios.js] - Broken image link in the example code at
Closes https://github.com/facebook/react-native/pull/16569
Differential Revision: D6174048
Pulled By: hramos
fbshipit-source-id: 8c008ab06e8719dfca6a9964d553248c4f088882
Summary:
Fixed spelling error in comments.
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Help fix typo in comments.
Did not make any code changes
[DOCS][MINOR][RCTImageView.m] Typo fixes in comments
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAl ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/16560
Differential Revision: D6173389
Pulled By: shergin
fbshipit-source-id: f3fd8ea686a882f1543922655498dcc7210d8cb8
Summary:
It makes possible to just specify remote url for the <Image> and it will work.
`<Image source={{uri: 'https://facebook.github.io/react/img/logo_og.png'}} />`
Reviewed By: javache
Differential Revision: D5196055
fbshipit-source-id: aaf139c4518cc35d1f4cf810bbf0305aad73a55b
Summary:
Now intrinsic content size of <Image> is implemented natively on iOS and now it is actually
`intrinsicContentSize`, not just overrided `height` and `width` styles (which was incorrect and hacky).
This change also removes support of nested content inside <Image>.
This is a first commit in the row where we improve <Image> implementation.
Reviewed By: mmmulani
Differential Revision: D5189017
fbshipit-source-id: eab3defa3d86a5d4219b4f4925ab7460b58d760f
Summary:
This usage of `...` currently causes BackHandler to silently become non-functional when a `Symbol` polyfill is used.
Why?
- The `[...obj]` operator implicitly calls the object's iterator to fill the array
- react-native's internal `Set` polyfill has a load order issue that breaks it whenever a project uses a `Symbol` polyfill
- This means that when `BackHandler` tries to `[...set]` a `Set` of subscriptions the result is always an empty array instead of an array of subscriptions
Additionally it's worth noting that the current code is also wastefully inefficient as in order to reverse iterate over subscriptions it:
- Clones the `Set` (which fills it by implicitly running the set's iterator)
- Uses `[...set]` to convert the cloned set into an array (which also implicitly runs the iterator on the clone)
- Finally reverses the order of the array
----
This code fixes this problem by replacing the use of multiple Set instance iterators with a simple `.forEach` loop that unshifts directly into the final array.
I've tested this by opening the repo's RNTester app on Android and tvOS ensuring that the back handler works before changes, the application crashes when I introduce an error (to verify my code changes are being applied to the app), the back handler works and after changes.
Fixes#11968
Closes https://github.com/facebook/react-native/pull/15182
Differential Revision: D6114696
Pulled By: hramos
fbshipit-source-id: 2eae127558124a394bb3572a6381a5985ebf9d64
Summary:
The relevant changes in the PR are to Libraries/StyleSheet/EdgeInsetsPropType.js; the rest are just removals of FlowIgnores.
The definition of the relevant types is [here](https://github.com/facebook/flow/blob/master/lib/react.js#L262-L271).
The long and short of it is that for whatever reason, Flow is unable to realize that `ReactPropsChainableTypeChecker` is a subtype of `ReactPropsCheckType` unless we assert it. Once we explicitly hint this to the typechecker, it realizes that `EdgeInsetsPropType` is indeed a valid React PropType, and stops complaining that it isn't.
Closes https://github.com/facebook/react-native/pull/16437
Differential Revision: D6109742
Pulled By: sahrens
fbshipit-source-id: e4e10720b68c912d0372d810409f389b65d7f4b1
Summary:
Touch cancel events are currently being ignored by the ScrollView component. Currently scrollview responds both to scroll events and touchStart/touchMove/touchEnd events.
The reason why ScrollView listens to touchStart/touchEnd is so that it can update its `state.isTouching` param. This parameter then is used in `scrollResponderHandleScrollShouldSetResponder` to make the decision if scrollview should set the responder or not. So if `isTouching` is true (we've received touchStart) then ScrollView want to became a JS responder. This in turn is important for the case where we receive scroll events that does not necessarily need to trigger responder change, e.g. we don't want Scrollview to become JS responder if scroll events have been triggered by `scrollTo` in which case setting responder would put the whole responder system in a bogus state (note that responder can be released only by touchEnd or touchCancel, so if there is no touchEnd that follows scroll event then ScrollView will remain the responder and this would break next touch interaction).
It is therefore crucial for the ScrollView to reset `isTouching` state when touchCancel arrives, as otherwise the next scroll event would incorrectly trigger responder change.
On top of that ScrollView seems to be the only component in RN's core that registers to handle touchEnd but ignores touchCancel, which stands agains the comment added to `RCTRootView.cancelTouches` [here](https://github.com/facebook/react-native/commit/c14cc123d#diff-9cd70243bd2af75c613e29972bb1b41cR127).
This problem is difficult to test with a pure RN native app, as on Android it does not surface because of the `responderIgnoreScroll` flag that is being added to every scroll event, and it essentially makes the responder system ignore scroll events so they would never trigger responder change. On the other hand on iOS the cancel events are pretty rare. With pure RN app they can only be triggered by a "system" level interaction (e.g. when system alert dialog appears or when home button is clicked and there is a touch interaction happening). This issue becomes more prominent when RN app is embedded in a more sophisticated application that may use [`RCTRootView.cancelTouches`](1e8f3b1102/React/Base/RCTRootView.h (L130)) method to block RNs gesture recognizers in some cases or with third-party libraries that deals with touch events like [react-native-gesture-handler](https://github.com/kmagiera/react-native-gesture-handler) that also calls into the method when native touch interaction is detected.
Closes https://github.com/facebook/react-native/pull/16004
Differential Revision: D6003063
Pulled By: shergin
fbshipit-source-id: f6495ffc57a5f996117b5bd80478bb1a58d2d799
Summary:
Test suite for React Native version check relies on `ReactNativeVersion.js` file that is modified on a release branch (it contains values of a real version, not zeros).
That makes it impossible for the build to pass: https://circleci.com/gh/facebook/react-native/23494
This PR mocks it with zero values, just like we mock it in other suites. I am not sure if that is desired, but works for now.
CC ide
Closes https://github.com/facebook/react-native/pull/16464
Differential Revision: D6100285
Pulled By: hramos
fbshipit-source-id: 784f7e14f5283403f3fa518940565e1ef19dd398
Summary:
**Motivation**
Give `TouchableOpacity` and `Button` the same TV focus support as is already present in `TouchableHighlight`.
**Test plan**
Manual testing on TV simulator and devices.
Closes https://github.com/facebook/react-native/pull/15561
Differential Revision: D5665976
Pulled By: hramos
fbshipit-source-id: 0d5c588e1c82471f23617a3df1b77abc589a7c63
Summary:
Change the header description and example code.
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
Clarify extra requirements for a Component.
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
Go to documentation, see changes.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/13829
Differential Revision: D5661106
Pulled By: hramos
fbshipit-source-id: 39736c05f8017009cdd637930c9f89ae6c2ee7c3
Summary:
- The version check that ensures the JS and native versions match is now in its own module for two reasons: it is easier to test and it allows react-native-windows to override just this module to implement its own version check (ex: more advanced checks for RNW-specific code).
- Added unit tests for the version checking to specify its behavior more clearly, including parity between dev and prod to avoid prod-only behavior and mitigate SEVs.
- Prefixed the Obj-C `#define` with `RCT_` to conform with other RN globals.
Closes https://github.com/facebook/react-native/pull/16403
Differential Revision: D6068491
Pulled By: hramos
fbshipit-source-id: 2b255b93982fb9d1b655fc62cb17b126bd5a939a
Summary:
In the current implementation of the `VirtualizedList` the `onViewableItemsChanged` callback wouldn't trigger if the underlying list data changes. (see example snack https://snack.expo.io/Hk5703eBb)
I added a method in the `ViewabilityHelper` to invalidate the cached viewableIndices, which gets triggered when the list-data changes.
Closes https://github.com/facebook/react-native/pull/14922
Differential Revision: D5864537
Pulled By: sahrens
fbshipit-source-id: 37f617763596244208548817d5b138dadc12c75d
Summary:
The title speaks for itself. Docs regarding secureTextEntry of TextInput were not descriptive enough. Owing to that, it took me more than an hour of debugging to find the issue of why the TextInput in my app was not hiding the input with secureTextEntry.
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/16272
Differential Revision: D6060614
Pulled By: ericnakagawa
fbshipit-source-id: 419ad6956e67b9adefae8d789b3fd76181c4194b
Summary:
References #7070
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Docs are incomplete, start filling them out
N/A
Closes https://github.com/facebook/react-native/pull/16346
Differential Revision: D6057501
Pulled By: hramos
fbshipit-source-id: c30d3369fa1a73ef6a93c2ed8f8c53af5a1af7ee
Summary:
The first code block already uses the new `connectionChange` event instead of
the deprecated `change` event, so change this example code block as well to use
the new event.
I came across this while upgrading my RN version. In the debug-console I saw a deprecation warning, despite I was using the example-code. Looking at the source, I saw the example code block still used the deprecated event, so update it to use the new one.
Closes https://github.com/facebook/react-native/pull/16357
Differential Revision: D6054428
Pulled By: hramos
fbshipit-source-id: 72ef1a79ece7494cda3773461a740dbbdf383e7e
Summary:
Doc update to clarify how to prevent `Animated.loop` and other animations from pre-empting `VirtualizedList` rendering as discussed in #16092.
Closes https://github.com/facebook/react-native/pull/16136
Differential Revision: D6057466
Pulled By: hramos
fbshipit-source-id: 946bcde97b364c623b48ddaeb643309630c072c9
Summary: When we built packager asset system we were mostly concerned about images. However, this system can also be used to work with videos, animations and other binary resources. The code that sorts assets into Android resource folders currently just shoves all non-drawable resources under `drawable-mdpi`, which is not ideal. Talking to Android experts on the team, `raw` seems like a much better place for other resources.
Reviewed By: jeanlauliac
Differential Revision: D6026633
fbshipit-source-id: cc2199f60da411ea432972a02f52c459ff5c490a
Summary:
We're spreading this in via `...ViewPropTypes` also. Having both confuses
flow when you try to pass style (even though they're identical), when the
types are defined via `React.ElementProps`
Reviewed By: jingc
Differential Revision: D6028659
fbshipit-source-id: 203e29682d34f1648a47d9ddbaef0c9630fbcb99
Summary:
`visible-password` represents a very basic keyboard, typically only
letters and numbers. Backed by InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD,
it is useful for things like password and code entry fields. It can also be more
effective than autoCorrect={false} for disabling autocompletion on some keyboards
(like Gboard).
Note `secureTextEntry` also affects `TYPE_TEXT_VARIATION_*` flags internally, so there
may be some undefined behavior when combining `secureTextEntry` with
`keyboardType="visible-password"`
Also, while here, improve the documentation on TextInput to explicitly enumerate
which keyboardType applies to Android vs. iOS (since this is the first android-specific)
Reviewed By: shergin
Differential Revision: D6005353
fbshipit-source-id: 13af90c96353f714c0e106dd0fde90184a476533
Summary:
Easier to understand how to use this component. A quick example helps to beginners.
Closes https://github.com/facebook/react-native/pull/16110
Differential Revision: D6017956
Pulled By: shergin
fbshipit-source-id: 82a340dfe8551cc8d7b692b9c71237e2b4421aba
Summary:
RCTImageStoreManager and RCTBlobManager have the same priority, hence in certain cases, both are able to handle the request, but this causes non-deterministic behavior. Hence increased ImageStoreManager's Priority to 1 and thereby increasing RCTImageLoader's Priority to 2 to prevent similar issue of same priorities.
Issue: #16159
Closes https://github.com/facebook/react-native/pull/16160
Differential Revision: D6017931
Pulled By: shergin
fbshipit-source-id: 91f2737af4f2f97197734b696105e1cdc5683365
Summary:
CI is currently failing because of a lint issue, this fixes it and a bunch of other warnings that are auto-fixable.
**Test plan**
Quick manual test, cosmetic changes only.
Closes https://github.com/facebook/react-native/pull/16229
Differential Revision: D6009748
Pulled By: TheSavior
fbshipit-source-id: cabd44fed99dd90bd0b35626492719c139c89f34
Summary:
RCTWrapper is a library that allows turn any UIView/UIViewController-based widget into React Native component
which will respect layout constrains of native (wrapped) view.
So, you don't need to explicitly specify width and hight in styling.
Take a look at examples to see how to use RCTWrapper.
Reviewed By: mmmulani
Differential Revision: D5868763
fbshipit-source-id: 0a503b42be166d547ca6cbf0829eea9c75a8e364
Summary:
Now RCTTextInput relies on ivar to detect should it reconstruct inputAccessoryView or not.
Previously we checked `inputAccessoryView` directly which breaks some 3rd party libs.
See https://github.com/facebook/react-native/issues/16071 for more details.
cc douglasjunior
Reviewed By: javache
Differential Revision: D5994798
fbshipit-source-id: c086efdd24f5528393a4c734ff7c984e0ed740d1
Summary:
`CheckBox` component was introduced in v0.49.0 and not implemented on iOS.
Users who are trying to use `CheckBox` on iOS will get a warning that
> Native component for "AndroidCheckBox" does not exist
We should declare in the document that this component is Android only and use `UnimplementedView` for iOS.
- Use `react-native init` new project
- Apply pull request changes
- Add `<Checkbox />` after welcome text in `App.js`
- Run the app in iOS simulator
Closes https://github.com/facebook/react-native/pull/16211
Differential Revision: D6005393
Pulled By: hramos
fbshipit-source-id: 1c9b68b5e1c933496c4d7c2f487f0500264b603a
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Tests were failing due to not updated snapshot about TouchableHighlight.
Run `npm test`.
Closes https://github.com/facebook/react-native/pull/16185
Differential Revision: D6005399
Pulled By: hramos
fbshipit-source-id: eda5009b68ca121250817de448424105aec6f685
Summary:
I don't think a test plan is required here! 😛
Closes https://github.com/facebook/react-native/pull/16243
Differential Revision: D6005196
Pulled By: hramos
fbshipit-source-id: 3b46346e57e0d9971078c4807a4fa0045a8366b1
Summary: Remove RCTWebSocketObserver as it's not used anywhere in the project.
Reviewed By: shergin
Differential Revision: D5960354
fbshipit-source-id: a5b9d128f7cf9384a9fa9ed20e869801023e1d57
Summary:
YellowBox currently assumes the first arg is a printf like format string, this adds support for any arguments so it works more like console in the browser. This also adds `stringifySafe` to format arguments when using printf style.
The main annoyance that this fixes is when trying to log a single object it will currently print [object Object] instead of the fully stringified version.
**Test plan**
Tested a bunch of different log combinations.
```js
console.warn({test: 'a'}); // {"test":"a"} (was [object Object] before this patch)
console.warn('test %s %s', 1, {}); // test 1 {}
console.warn('test %s', 1, {}); // test 1 {}
console.warn({}, {}, {}, {}); // {} {} {} {}
```
Closes https://github.com/facebook/react-native/pull/16132
Differential Revision: D5973125
Pulled By: yungsters
fbshipit-source-id: fc17105a79473a11c9b1c4728d435fc54fb094bb
Summary: In some enviroments PlatformConstants native module may not be presented in a project, which results in a call to undefined property and a RedBox
Reviewed By: javache
Differential Revision: D5960879
fbshipit-source-id: 80aecbe2f2a61cb410abd5f0dce8ba855e166991
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
My first contribution 👍
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/16155
Differential Revision: D5962399
Pulled By: shergin
fbshipit-source-id: b7a44d53d875b32d04c1b876eb7ec2f30a9d0d80
Summary:
This is required for D5874536, wherein I'll be introducing direction-aware props for borders.
When a view's border changes due to a direction update, only the frames of its children update. Therefore, only the children `UIView`s get a chance to be re-rendered. This is incorrect because the view that's had its borders changed also needs to re-render. So, I keep a track of the layout direction in a property on all shadow views. Then, when I update that prop within `applyLayoutNode`, I push shadow views into the `viewsWithNewFrames` set.
Reviewed By: mmmulani
Differential Revision: D5944488
fbshipit-source-id: 3f23e9973f3555612920703cdb6cec38e6360d2d
Summary:
Currently, only `Text` supports the `allowFontScaling` prop. This commit adds support for it on `TextInput`.
As part of this change, the TextInput setters for font attributes (e.g. size, weight) had to be refactored. The problem with them is that they use RCTFont's helpers which create a new font based on an existing font. These helpers lose information. In particular, they lose the scaleMultiplier.
For example, suppose the font size is 12 and the device's font multiplier is set to 1.5. So we'd create a font with size 12 and scaleMultiplier 1.5 which is an effective size of 18 (which is the only thing stored in the font). Next, suppose the device's font multiplier changes to 1. So we'd use an RCTFont helper to create a new font based on the existing font but with a scaleMultiplier of 1. However, the font didn't store the font size (12) and scaleMultiplier (1.5) separately. It just knows the (effective) font size of 18. So RCTFont thinks the new font has a font size of 18 and a scaleMultiplier of 1 so its effective font size is 18. This is incorrect and it should have been 12.
To fix this, the font attributes are now all stored individually. Anytime one of them changes, updateFont is called which recreates the font from scratch. This happens to fix some bugs around fontStyle and fontWeight which were reported several times before: #13730, #12738, #2140, #8533.
Created a test app where I verified that `allowFontScaling` works properly for `TextInputs` for all values (`undefined`, `true`, `false`) for a variety of `TextInputs`:
- Singleline TextInput
- Singleline TextInput's placeholder
- Multiline TextInput
- Multiline TextInput's placeholder
- Multiline TextInput using children instead of `value`
Also, verified switching `fontSize`, `fontWeight`, `fontStyle` and `fontFamily` through a bunch of combinations works properly.
Lastly, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14030
Reviewed By: TheSavior
Differential Revision: D5899959
Pulled By: shergin
fbshipit-source-id: c8c8c4d4d670cd2a142286e79bfffef3b58cecd3
Summary:
The Android ViewManager already has disabled set to false by default. When setting it in defaultProps we send it over for every text view, which is unnecessary.
On platforms that don't support disabled this may also cause unnecessary log noise.
Closes https://github.com/facebook/react-native/pull/16139
Differential Revision: D5944334
Pulled By: javache
fbshipit-source-id: 54c4b65f345cd284759d01d075522f5aa2f74298
Summary:
/**
* param {number} value
* param {number} min
* param {number} max
* return {number}
*/
should be:
/**
* param {number} min
* param {number} value
* param {number} max
* return {number}
*/
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/16077
Differential Revision: D5938021
Pulled By: shergin
fbshipit-source-id: 3a6e4ff5ab39a657bc0d9271ae2a2600998b2ddf
Summary: Allows handling the case of wanting to scroll beyond the measured window.
Reviewed By: TheSavior
Differential Revision: D5915331
fbshipit-source-id: 329927632f4d04f213567ce4bbe547b04b8ea86d
Summary:
Basic implementation of the proposal in #15271
Note that this should not affect facebook internally since they are not using OSS releases.
Points to consider:
- How strict should the version match be, right now I just match exact versions.
- Wasn't able to use haste for ReactNativeVersion because I was getting duplicate module provider caused by the template file in scripts/versiontemplates. I tried adding the scripts folder to modulePathIgnorePatterns in package.json but that didn't help.
- Redscreen vs. warning, I think warning is useless because if the app crashes you won't have time to see the warning.
- Should the check and native modules be __DEV__ only?
**Test plan**
Tested that it works when version match and that it redscreens when versions don't before getting other errors on Android and iOS.
Closes https://github.com/facebook/react-native/pull/15518
Differential Revision: D5813551
Pulled By: hramos
fbshipit-source-id: 901757e25724b0f22bf39de172b56309d0dd5a95
Summary:
Currently `TextInput.autoCapitalize` is defaulting to 'none' on Android. This PR sets the default to 'sentences', to match iOS and the PropTypes documentation.
Fixes#14846
Closes https://github.com/facebook/react-native/pull/14853
Differential Revision: D5918196
Pulled By: shergin
fbshipit-source-id: d0d00e75d44a410c6821b4ff8910099aae2b2c7c
Summary: Because `RCTUIManager` is already overcomplicated and that stuff deserves separate file and header.
Reviewed By: javache
Differential Revision: D5856653
fbshipit-source-id: 7001bb8ba611976bf3b82d6a25f5619810a35b34
Summary:
The previous example only showed where to add the optional "listener" but didn't show how to make use of it.
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15576
Differential Revision: D5911716
Pulled By: shergin
fbshipit-source-id: 60023470d23c2cbbde47ab9aa82c7ecef73be467
Summary: Now it does not clipped on iPhone X.
Reviewed By: yungsters
Differential Revision: D5907527
fbshipit-source-id: 10d05e4ac5d16a9e257efa78795bff9f14f4c0bb
Summary:
Instead of preventing events from working when not on the UI Thread we can just dispatch to it instead.
**Test plan**
Tested manually that animated events still work in RNTester
Closes https://github.com/facebook/react-native/pull/15953
Differential Revision: D5909816
Pulled By: shergin
fbshipit-source-id: 48d02b6aa9f2bc3bcb638e8852fccaac3f205276
Summary:
As of v1.4.0, a new devtools hook is used that is hosted within `relay-devtools` instead of `relay-runtime`. That allows debugging of production relay apps, and reduces byte size of Relay.
As a result, relay-debugger-react-native-runtime and RelayDebugger can be removed.
Reviewed By: kassens
Differential Revision: D5904296
fbshipit-source-id: 2b215f5a25ecb2922b00cdf86f7d31415d8d1328
Summary: NaN values can not be compared directly, so we have to use `isnan` function.
Reviewed By: mmmulani
Differential Revision: D5859761
fbshipit-source-id: bf99a1ae574cd820265bef0c2bd255b194c5dc3c
Summary:
Now it does not clipped on iPhone X.
{F74889000}
Reviewed By: mmmulani
Differential Revision: D5894101
fbshipit-source-id: 5dc91583aa38bb14607421e5afc2ae796e35cce0
Summary:
<SafeAreaView> renders nested content and automatically applies paddings reflect the portion of the view
that is not covered by navigation bars, tab bars, toolbars, and other ancestor views.
Moreover, and most importantly, Safe Area's paddings feflect physical limitation of the screen,
such as rounded corners or camera notches (aka sensor housing area on iPhone X).
Reviewed By: mmmulani
Differential Revision: D5886411
fbshipit-source-id: 7ecc7aa34de8f5527c4e59b0fb4efba3aaea28c8
Summary:
Previously, the example MyListItem never referenced the selected prop, leaving ambiguity about the intention of the demo.
By adding a concrete implementation with coloring based on the selected prop, we can see that this is a demo of a multi-select list for batch actions instead of, say, a click-to-navigate nested list.
Here is a working Snack demo for future reference:
https://snack.expo.io/BkRMRTGB-
References #14872
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/14957
Differential Revision: D5892186
Pulled By: sahrens
fbshipit-source-id: c7b46b5f6eae8f36bd4bda7cbbd354cc22108b42
Summary:
- Enable logging so `console.log` shows up in Xcode console (and CI?)
- Allow loading from bundler for rapid JS iteration.
- Add option to enable JS debugging, although it's a little ghetto.
Reviewed By: mmmulani
Differential Revision: D5869085
fbshipit-source-id: 9c4831859f1491f7f75786f730d8549d69623888
Summary: Adds an onDismiss so that navigation events can be chained to the dismissing of a modal.
Reviewed By: sahrens
Differential Revision: D5852953
fbshipit-source-id: a86e36fdd5b0b206c2dd9fa248e2a88da22efa31
Summary: Apple changed what messages get logged when a web socket connection fails. Lets hide them to make life better for engineers.
Reviewed By: javache
Differential Revision: D5879306
fbshipit-source-id: cde06405b4af251159269218bf922916a79ac840
Summary:
As a new user it took me a while to figure out you can import these examples directly. The import statement completes the example for new users like me who have no idea these components can be imported. It is a very important piece of information and it is hard to find otherwise.
I think this should be added to all the other component examples as well.
Documentation only.
Closes https://github.com/facebook/react-native/pull/15501
Differential Revision: D5882436
Pulled By: hramos
fbshipit-source-id: 2da0fe4c7c41e2fdb6b13a945460e17e16442d62
Summary:
This change improves the documentation for `ActionSheetIOS.js`. It's a bit skimpy as is.
Closes https://github.com/facebook/react-native/pull/16030
Differential Revision: D5882446
Pulled By: hramos
fbshipit-source-id: b59ce299a9142ebf015ed674c59e1e435deb759a
Summary:
As I was working on mimicking iOS animations for my ongoing work with `react-navigation`, one task I had was to match the "push from right" animation that is common in UINavigationController.
I was able to grab the exact animation values for this animation with some LLDB magic, and found that the screen is animated using a `CASpringAnimation` with the parameters:
- stiffness: 1000
- damping: 500
- mass: 3
After spending a considerable amount of time attempting to replicate the spring created with these values by CASpringAnimation by specifying values for tension and friction in the current `Animated.spring` implementation, I was unable to come up with mathematically equivalent values that could replicate the spring _exactly_.
After doing some research, I ended up disassembling the QuartzCore framework, reading the assembly, and determined that Apple's implementation of `CASpringAnimation` does not use an integrated, numerical animation model as we do in Animated.spring, but instead solved for the closed form of the equations that govern damped harmonic oscillation (the differential equations themselves are [here](https://en.wikipedia.org/wiki/Harmonic_oscillator#Damped_harmonic_oscillator), and a paper describing the math to arrive at the closed-form solution to the second-order ODE that describes the DHO is [here](http://planetmath.org/sites/default/files/texpdf/39745.pdf)).
Though we can get the currently implemented RK4 integration close by tweaking some values, it is, the current model is at it's core, an approximation. It seemed that if I wanted to implement the `CASpringAnimation` behavior _exactly_, I needed to implement the analytical model (as is implemented in `CASpringAnimation`) in `Animated`.
We add three new optional parameters to `Animated.spring` (to both the JS and native implementations):
- `stiffness`, a value describing the spring's stiffness coefficient
- `damping`, a value defining how the spring's motion should be damped due to the forces of friction (technically called the _viscous damping coefficient_).
- `mass`, a value describing the mass of the object attached to the end of the simulated spring
Just like if a developer were to specify `bounciness`/`speed` and `tension`/`friction` in the same config, specifying any of these new parameters while also specifying the aforementioned config values will cause an error to be thrown.
~Defaults for `Animated.spring` across all three implementations (JS/iOS/Android) stay the same, so this is intended to be *a non-breaking change*.~
~If `stiffness`, `damping`, or `mass` are provided in the config, we switch to animating the spring with the new damped harmonic oscillator model (`DHO` as described in the code).~
We replace the old RK4 integration implementation with our new analytic implementation. Tension/friction nicely correspond directly to stiffness/damping with the mass of the spring locked at 1. This is intended to be *a non-breaking change*, but there may be very slight differences in people's springs (maybe not even noticeable to the naked eye), given the fact that this implementation is more accurate.
The DHO animation algorithm will calculate the _position_ of the spring at time _t_ explicitly and in an analytical fashion, and use this calculation to update the animation's value. It will also analytically calculate the velocity at time _t_, so as to allow animated value tracking to continue to work as expected.
Also, docs have been updated to cover the new configuration options (and also I added docs for Animated configuration options that were missing, such as `restDisplacementThreshold`, etc).
Run tests. Run "Animated Gratuitous App" and "NativeAnimation" example in RNTester.
Closes https://github.com/facebook/react-native/pull/15322
Differential Revision: D5794791
Pulled By: hramos
fbshipit-source-id: 58ed9e134a097e321c85c417a142576f6a8952f8
Summary:
Opening a new PR for #10946 (see discussion there).
This PR builds upon #14775 (iOS ViewManager inheritance) and #14261 (more extensible Android WebView).
**Motivation**
When `WebView.android.js` and `WebView.ios.js` use `requireNativeComponent`, they are hard-coded to require `RCTWebView`. This means if you want to re-use the same JS-logic, but require a custom native WebView-implementation, you have to duplicate the entire JS-code files.
The same is true if you want to pass through any custom events or props, which you want to set on the custom native `WebView`.
What I'm trying to solve with this PR is to able to extend native WebView logic, and being able to re-use and extend existing WebView JS-logic.
This is done by adding a new `nativeConfig` prop on WebView. I've also moved the extra `requireNativeComponent` config to `WebView.extraNativeComponentConfig` for easier re-use.
**Test plan**
jacobp100 has been kind enough to help me with docs for this new feature. So that is part of the PR and can be read for some information.
I've also created an example app which demonstrates how to use this functionality: https://github.com/cbrevik/webview-native-config-example
If you've implemented the native side as in the example repo above, it should be fairly easy to use from JavaScript like this:
```javascript
import React, { Component, PropTypes } from 'react';
import { WebView, requireNativeComponent, NativeModules } from 'react-native';
const { CustomWebViewManager } = NativeModules;
export default class CustomWebView extends Component {
static propTypes = {
...WebView.propTypes,
finalUrl: PropTypes.string,
onNavigationCompleted: PropTypes.func,
};
_onNavigationCompleted = (event) => {
const { onNavigationCompleted } = this.props;
onNavigationCompleted && onNavigationCompleted(event);
}
render() {
return (
<WebView
{...this.props}
nativeConfig={{
component: RCTCustomWebView,
props: {
finalUrl: this.props.finalUrl,
onNavigationCompleted: this._onNavigationCompleted,
},
viewManager: CustomWebViewManager
}}
/>
);
}
}
const RCTCustomWebView = requireNativeComponent(
'RCTCustomWebView',
CustomWebView,
WebView.extraNativeComponentConfig
);
```
As you see, you require the custom native implementation at the bottom, and send in that along with any custom props with the `nativeConfig` prop on the `WebView`. You also send in the `viewManager` since iOS requires that for `startLoadWithResult`.
**Discussion**
As noted in the original PR, this could in principle be done with more React Native components, to make it easier for the community to re-use and extend native components.
Closes https://github.com/facebook/react-native/pull/15016
Differential Revision: D5701280
Pulled By: hramos
fbshipit-source-id: 6c3702654339b037ee81d190c623b8857550e972
Summary:
Looks like `-[NSLayoutManager ensureLayoutForTextContainer:textContainer]` has a bug that cause infinite loop inside this method
during measuring some special characters AND when specified `width` equals NaN (which is useless anyways).
So, we cover this case in this diff.
Reviewed By: javache
Differential Revision: D5859767
fbshipit-source-id: 58a5910f21f282bf5b82494916b5b02ad72d357f
Summary:
This avoids a crash when we try to load a PHAsset with nil image url. Specifically, the following condition evaluates to true when `imageURL` is nil:
```objc
if ([imageURL.scheme caseInsensitiveCompare:@"assets-library"] == NSOrderedSame) {
assetID = [imageURL absoluteString];
results = [PHAsset fetchAssetsWithALAssetURLs:@[imageURL] options:nil];
}
```
The crash will be "attempt to insert nil object from objects[0]" when we build the `@[imageURL]` array literal.
We've seen this emerge as a very common crash among Expo users, so I wanted to at least provide a clear error message instead of terminating the app.
Load an image from the photo library with a nil request url.
Closes https://github.com/facebook/react-native/pull/15952
Differential Revision: D5835219
Pulled By: ericnakagawa
fbshipit-source-id: 7be00a15e674a0905cf5c27c526ce9085d1b308f
Summary:
Fixing https://github.com/facebook/react-native/issues/13578
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15419
Reviewed By: sahrens
Differential Revision: D5795844
Pulled By: tomasreimers
fbshipit-source-id: 4cdf97a2f5e83e38f4e12af771b512e7dddd212a
Summary:
**PR changes**
The RCTText class originally overrode the accessibilityLabel and returned the raw text of the class ignoring if the accessibilityLabel was set explicitly in code.
Example:
<Text accessibilityLabel="Example"> Hello World </Text> // returns "Hello World" instead of "Example" for the accessibility label
My update checks if the super's accessibilityLabel is not nil and returns the value else it returns the raw text itself as a default to mirror what a UIKit's UILabel does. The super's accessibilityLabel is nil if the accessibilityLabel is not ever set in code. I don't check the length of the label because if the value was set to an empty purposely then it will respect that and return whatever was set in code.
With the new changes:
<Text accessibilityLabel="Example"> Hello World </Text> // returns "Example" for the accessibilityLabel
This change doesn't support nested <Text> components with both accessibilityLabel's value set respectively. The parent's value will return.
Example:
// returns "Example" instead of "Example Test" for the accessibility label
<Text accessibilityLabel="Example">
Hello
<Text accessibilityLabel="Test">
World
</Text>
</Text>
The workaround is just to set the only the parent view's accessibilityLabel with the label desired for it and all its nested views or just not nest the views if possible.
I believe a bigger change would be needed to support accessibility for nested views, for now the changes I have made should satisfy the requirements.
Reviewed By: shergin
Differential Revision: D5806097
fbshipit-source-id: aef2d7cec4657317fcd7dd557448905e4b767f1a
Summary:
Previously type Options had excludeActivityTypes property, but in RCTActionSheetManager.m and docs this property is named excludedActivityTypes.
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Want to fix error in flow types
Actually, it seems there aren't any need for test plan for this PR. Just fix a mistyping error.
Closes https://github.com/facebook/react-native/pull/15881
Differential Revision: D5813539
Pulled By: ericnakagawa
fbshipit-source-id: 7d1269d4c177f920869bf6554f14af6db7a741ee
Summary:
This line accidentally became a no-op when the Map was converted to an Object.
Closes https://github.com/facebook/react-native/pull/15891
Differential Revision: D5811069
Pulled By: TheSavior
fbshipit-source-id: 43ac1835d15e2bee67ee45646bc238f917013836
Summary:
Hi guys,
A small typo found in the doc :)
Closes https://github.com/facebook/react-native/pull/15888
Differential Revision: D5809251
Pulled By: TheSavior
fbshipit-source-id: 7a2ca8f2cbca81aa2059ee619a8c6087256e39a6
Summary:
Use <ImageBackground> instead or (even better), implement it yourself using container <View> and nested <Image> with `position: absolute;` styling.
This diff was decoupled from D5189017 for more granularity.
Reviewed By: mmmulani
Differential Revision: D5779989
fbshipit-source-id: e0a724008e679426f61ed0841f9eff6d62fb943b
Summary:
This change only affects tests run with Jest. `require('/images/image1.png')` will be replaced with
```
Object {
"testUri": "relative/path/to/images/image1.png",
}
```
in the Jest snapshot instead of always being 1 returned by RelativeImageStub. This change makes it possible to test conditional asset loading in components.
The problem with this change is that it will probably break a lot of existing snapshots, but that should be easily fixed when a project updates to a new version of React Native by running `jest -u` to update all snapshots.
A component can have conditional asset loading based on its props, this logic would be nice to test with Jest snapshots. This problem has been discussed in https://github.com/facebook/jest/issues/2838.
* **Who does this affect**: Everyone using `Image` in Jest snapshots
* **How to migrate**: Running `jest -u` will update the snapshots, the snapshots should be reviewed that they are correct.
* **Why make this breaking change**: It enables testing of conditional asset loading.
* **Severity (number of people affected x effort)**: Low.
Closes https://github.com/facebook/react-native/pull/13319
Reviewed By: rafeca
Differential Revision: D5708180
Pulled By: mjesun
fbshipit-source-id: 16ac42004d597db08545a21d4fffe95c5ee7e21f
Summary: FlatList only supports one viewability configuration and callback. This change extends FlatList and VirtualizedList to support multiple viewability configurations and corresponding callbacks.
Reviewed By: sahrens
Differential Revision: D5720860
fbshipit-source-id: 9d24946362fa9001d44d4980c85f7d2627e45a33
Summary:
Otherwise, you're met with a bewildering blank page. :D
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15754
Differential Revision: D5768992
Pulled By: hramos
fbshipit-source-id: 39a9f7c208d635e089751015dcf2536144ec0176
Summary:
Fixed a typo in `ToastAndroid.js`'s comment.
No test plan. Just fix a typo.
Closes https://github.com/facebook/react-native/pull/15802
Differential Revision: D5767578
Pulled By: hramos
fbshipit-source-id: 4ccc708800f7d4259d266fba195981a85e6647a1
Summary:
Current Geolocation API docs do not mention using PermissionAndroid when working with API 23+. This updates the docs to reflect that requirement.
This a documentation change, so no testing is required.
Closes https://github.com/facebook/react-native/pull/14133
Differential Revision: D5767852
Pulled By: hramos
fbshipit-source-id: 25af70db864a50cdc5e3765eccdeecd49c084d9a
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
I was reading up on how to control the selected value of a `SegmentedControlIOS` component and noticed that the prop was written wrong in the description.
1. This PR changes only the content of a component description comment, and not any code.
Closes https://github.com/facebook/react-native/pull/15742
Differential Revision: D5757116
Pulled By: hramos
fbshipit-source-id: faccb95fb3a4ba2852c457c3559c066da09e6bb9
Summary:
Example for loading Media using CameraRoll getPhotos method
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
The cameraRoll API doesn't have a proper example of how to use the methods. So, I decided to provide a basic example with a use case.
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15647
Differential Revision: D5748965
Pulled By: hramos
fbshipit-source-id: df8ad50d597dcc745a7f6abcc52839695ffe452c
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
I am a web developer, who recently started coding for mobile apps using react-native. I was trying to use the `inlineImageLeft` props of TextInput, but I found that it's docs weren't sufficient. So a PR for it.
No code change. Updated the docs under website folder. Screenshot for the change below.
![screen shot 2017-08-30 at 4 39 32 pm](https://user-images.githubusercontent.com/6011865/29869747-e73d9dde-8da1-11e7-912a-16e3115b8296.png)
Closes https://github.com/facebook/react-native/pull/15708
Differential Revision: D5738795
Pulled By: hramos
fbshipit-source-id: b8b6cbac5c50abd4d8a6ef8089dc9d92bc0b7f6f
Summary: Expose webSocketDidOpen in RCTReconnectingWebSocket in order to get notified when the reconnecting websocket is opened to the endpoint.
Reviewed By: emilsjolander
Differential Revision: D5725547
fbshipit-source-id: e904c5a84d670ecf936993ec1739614f99fce09c
Summary:
gabelevi mroch: Can you make sure this flow config is also updated when upgrading flow, otherwise our Travis e2e tests fail.
Closes https://github.com/facebook/react-native/pull/15447
Differential Revision: D5601593
Pulled By: javache
fbshipit-source-id: 9dbaa3c1ff732b191452c2c2e56fcf0486fc44c8
Summary: Came across multiple calls to reload while we we're setting properties on the image. During the initial setup they should no-op pretty quickly, but this should avoid us making multiple requests when changing an image that's already visible.
Reviewed By: mmmulani
Differential Revision: D5536014
fbshipit-source-id: 3c2abb83cbb66f9d8928f20fc7f461562f666f43
Summary:
This change enables developers to tell the Geolocation module to skip its permissions requests so the app can manage the permissions requests on its own. React Native Android's Geolocation module already requires apps to request permissions on their own.
Currently, the Geolocation module automatically makes permissions requests for you based on what you've specified in your property list file. However, the property list file doesn't always represent what permissions the app wants right now. For example, suppose an app sometimes wants location when "in use" and sometimes wants location "always" depending on what app features the user has engaged with. The Geolocation API will request the "always" location permission even if that's not what the app wants for the current scenario.
This change enables developers to tell the Geolocation module to skip permission requests so that the app can explicitly ask for the appropriate permissions. By default, Geolocation will still ask for permissions so this is not a breaking change.
This change adds a method to Geolocation that is not supported by the web spec for geolocation (`setRNConfiguration`). This method includes `RN` in the name to minimize the chances that the web spec will introduce an API with the same name.
**Test plan (required)**
Verified that Geolocation requests permissions by default and when `skipPermissionRequests` is `false`. Verified the permission requests are skipped when `skipPermissionRequests` is `true`. Also, my team is using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15096
Differential Revision: D5725563
Pulled By: javache
fbshipit-source-id: fd23fedb7e57408fa0f0d0568e0f1ef2aea1cdd4
Summary:
Typo at line 513. "The simplest workflow for creating an animation is TO TO create an"
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15676
Differential Revision: D5719554
Pulled By: hramos
fbshipit-source-id: ccb220136dfbc4632c84ec58a13d95a03c864c2b
Summary:
AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports.
This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible.
Discussion points:
- Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally.
- We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that?
- Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook?
- Probably still related to web, we used some weird Set polyfill is that still needed?
Notes:
There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class.
<img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png">
**Test plan**
Tested that all Animated related examples still work in RNTester on iOS and Android.
Tested that the doc is still working
Ran unit tests
Closes https://github.com/facebook/react-native/pull/15485
Differential Revision: D5679886
Pulled By: sahrens
fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
Summary:
When the AppState module is initialized, it subscribes to the `appStateDidChange` event and sends an async native method call to the AppState native module. There is a small race condition window where the native module can read the current app state as `uninitialized` before calling the JavaScript callback, and then be interrupted by the underlying mechanism to trigger the `appStateDidChange` event. If the `appStateDidChange` event is processed before the JavaScript callback, the resulting value of `AppState.currentState` will be invalid.
FixesMicrosoft/react-native-windows#1300
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
I simulated (over-exaggerated) the race condition by injecting "thread sleep" calls in the native method call and the native mechanism for updating the app state.
I then ran the AppStateExample in the RNTester and found that the current app state was set to `uninitialized`, as opposed to the expected value of `active`.
Once I made this JavaScript change, the over-exaggerated race condition no longer resulted in an invalid app state.
Closes https://github.com/facebook/react-native/pull/15499
Differential Revision: D5660620
Pulled By: hramos
fbshipit-source-id: 47c0dca75d37f677191c48f2148a72edd9cdd0e2
Summary:
This commit enables state WebViewState before triggering reload on WebView. This will (if defined) trigger the loading screen again.
On iOS the LoadingIndicator will be called whenever you reload the WebView. On Android this feature is missing (see #11013). This PR adds this behaviour.
Important: One might think that "onLoadStart" is the right area to add this code, but on Android onLoadStart will also trigger for sub-resources -> the loading screen will also appear when loading iframes on the same page. I expect thats why this was not added in first place.
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15538
Differential Revision: D5653257
Pulled By: hramos
fbshipit-source-id: 908b82ddaf2c34048bcb833bc07e03ab68d09467
Summary:
**Motivation**
On Apple TV, pressing the menu button destroys the native view that backs the `Modal` component, causing an app using this component to get into a broken state. This fix implements `onRequestClose` for tvOS to have the same behavior as it does for the Android back button.
**Test plan**
Manually tested this with the `ModalExample` in the `RNTester` app. See also the test code in issue #15313.
Closes https://github.com/facebook/react-native/pull/15341
Differential Revision: D5651035
Pulled By: shergin
fbshipit-source-id: 54bf66887bbe85940567e63e90b437ac4a8daf9a
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15515
Differential Revision: D5648285
Pulled By: hramos
fbshipit-source-id: fc1e50ffd18cc234771c5f40f92549e7e87cd28e
Summary:
This is a workaround for missing PDF url support in Android WebView, which is a general known issue: when tapping a PDF url within WebView, instead of doing nothing, we just let android default intent handle it (e.g. it will open Chrome to load it).
This is basically to trick `shouldOverrideUrlLoading()` to return true for the specific url. The drawback is that product code needs to provide the whitelist.
The proper fix would be to use PdfRenderer in that method, but it seems like it's only for API >= 21...
Differential Revision: D5619383
fbshipit-source-id: f86b930f970dab9a5f57999df69ce94b9508edc9
Summary:
Flow syntax is wrong, instead of using `Array` author used syntax for [tuples](https://flow.org/en/docs/types/tuples/). Tested with flow 0.49.1.
1. Import `removeDeliveredNotifications` in your code and pass an array with more than one element.
2. Test with flow.
Closes https://github.com/facebook/react-native/pull/15490
Differential Revision: D5622949
Pulled By: ericnakagawa
fbshipit-source-id: f9ed35a178eebac1b26a6ec15c66dc14331f7d34
Summary:
This is a simple groundwork PR to allow options to be passed to the `WebSocket` constructor. It represents a minor change to an undocumented part of the API, moving `headers` to within `options`.
This will be a BC for anyone manually specifying headers other than `origin` but a) that's not a common use case with WebSockets and b) it's not documented even in code and wouldn't currently pass a flow check.
NB: The third argument to the WebSocket constructor isn't part of the W3C spec, so I think this is a good place for RN-specific named parameters, better than adding a fourth argument. `protocols` needs to stay where it is, in line with the spec.
If this goes through I'd like to build on it by adding an additional connection option for SSL certificate pinning, as already supported by the underlying `okhttp` and `RCTSRWebSocket`. It could later be expanded for various other uses.
Currently, there's no way for a `WebSocket` user to specify any connection options other than url, protocol and headers. The fact that `WebSocket` connects in its constructor means any options have to go in there.
Connect to a websocket server using iOS and Android, observe the connection headers:
1. Without specifying `origin`, the default header should be set
2. Specifying it in the old way `new WebSocket(url, protocols, { origin: 'customorigin.com' })`
3. Specifying it in the new way `new WebSocket(url, protocols, { headers: { origin: 'customorigin.com' }})`.
I've tested myself using the test app with iOS and Android.
Closes https://github.com/facebook/react-native/pull/15334
Differential Revision: D5601675
Pulled By: javache
fbshipit-source-id: 5959d03a3e1d269b2c6775f3e0cf071ff08617bf
Summary:
When you have a numeric non-multiline `TextInput` and a `returnKeyType` is `done` we automatically add an input accessory view ([implementation](603cc48ceb/Libraries/Text/RCTTextInput.m (L269)#L315)).
That view has a done button which triggers [handleInputAccessoryDoneButton](603cc48ceb/Libraries/Text/RCTTextInput.m (L317...L320)) which currently directly sends `endEditing:` to the text field / text view. As a consequence, the [textInputShouldReturn](603cc48ceb/Libraries/Text/RCTTextInput.m (L118...L121)) is not called and we dismiss the keyboard even if the `blurOnSubmit` value is `false`.
Confirm that the keyboard is not dismissed when you tap on Done button on this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit={false}
/>
```
and that the keyboard is dismissed for this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit
/>
```
Closes https://github.com/facebook/react-native/pull/15438
Differential Revision: D5601462
Pulled By: javache
fbshipit-source-id: 24e4048e2e66d1a42fa97d83b4a3eb61e5d817ea
Summary:
**Motivation**
Fix compile error in Apple TV caused by RCTWebSocket using fishhook library.
**Test plan**
objc-tvos Travis tests are currently breaking, this should fix it.
Closes https://github.com/facebook/react-native/pull/15416
Differential Revision: D5587637
Pulled By: hramos
fbshipit-source-id: f05e765d7044650caf6d500fe21249e3fdc4f181
Summary:
At present, there's no uniform way of determining whether you've received an Animated value node which can be attached to an animated prop.
You can attempt to use `instanceof Animated.Value`, but this fails for interpolated values. You can use `instanceof Animated.Interpolation`, but this fails for the values that are returned from the math functions (e.g., `Animated.Add`).
This commit exposes the base type from which all of these value nodes derive. As such, it is now possible to do the following:
```js
import React, { Component, PropTypes } from 'react';
import { Animated } from 'react-native';
class Widget extends Component {
static propTypes = {
progress: PropTypes.instanceOf(Animated.Node).isRequired,
}
// ...
}
```
Unnecessary for cosmetic change.
Closes https://github.com/facebook/react-native/pull/14688
Differential Revision: D5581539
Pulled By: shergin
fbshipit-source-id: 98f40e63a463241c7f91c72391c26c3b4153e4cd
Summary:
I just worked with a fellow dev who was switching to flatlist and ended up pretty surprised at the performance drop. The measurement had an exponential bridge saturation, causing flatlist to lose to a scrollview!
We knew something was up, but a little note in the docs would have helped.
Closes https://github.com/facebook/react-native/pull/15400
Differential Revision: D5579483
Pulled By: sahrens
fbshipit-source-id: 2cc2488b6332db4f4d644c67f180088d3a5874a8
Summary: Expose didCloseWithCode in RCTReconnectingWebSocket in order to get notified when the reconnecting websocket is closed by the end-point.
Reviewed By: javache
Differential Revision: D5573394
fbshipit-source-id: 78bffeb98c6bf32b059194fc07ffc1f0a7bf4aae
Summary:
When false, ScrollView disables use of pinch gestures to zoom in and out. This allows ScrollView's pinch gesture responder to be disabled to only allow zooming programmatically. The default value is ~false~ true.
**Test Plan**
Tested that pinch gesture responder is disabled when pinchEnabled=false.
/cc nicklockwood sahrens
🍺
Closes https://github.com/facebook/react-native/pull/10037
Differential Revision: D5491953
Pulled By: shergin
fbshipit-source-id: eae16f92ec616e415b4ddacfccb84c697582daf9
Summary:
Currently, since the alertTitle is not set in UILocalNotification, the notification displays just the notification body with no title. This commit sets the alertTitle for local notifications.
Issue: #14699
- In a sample RN app, created a component and added the following code to componentDidMount():
`PushNotificationIOS.scheduleLocalNotification({
fireDate: new Date(Date.now() + (30 * 1000)).toISOString(),
alertTitle: 'Incoming Message',
alertBody: 'Test message',
soundName: 'default'
})`
- On running the app, the notification appears with both body and title once the component is mounted.
![settitle_fix](https://user-images.githubusercontent.com/4279549/28995873-f62c9866-7a11-11e7-9f29-95dba50ef40b.jpg)
Closes https://github.com/facebook/react-native/pull/15381
Differential Revision: D5572606
Pulled By: shergin
fbshipit-source-id: ce5d98ed595eedf51ac3da7dfd94de52cf80be3d
Summary:
Several changes here. The `Text.md` and `PixelRatio.md` files were appended to the autodocs during site generation. This seemed excessive for just two files, so I've just merged the content into the autodocs themselves. It should help us simplify the website generation process in the future.
I've also merged IssueGuidelines.md and PullRequestGuidelines.md into the Contribution/Maintainers guidelines to improve their visibility.
Finally, I renamed Help to Community in the nav bar.
Ran the website locally, and verified every page rendered as expected: the Community page, Contributing page, Maintainers page.
Closes https://github.com/facebook/react-native/pull/15374
Differential Revision: D5567400
Pulled By: hramos
fbshipit-source-id: e06056edb12c9a17319fe1af46b2ef3a2e1b5854
Summary:
Hey!
So, I was interested to contibure, and started from todo
Thank
Closes https://github.com/facebook/react-native/pull/14823
Differential Revision: D5546610
Pulled By: javache
fbshipit-source-id: 58e1b67786cbafa20399ac12dde9fcc3920abe94
Summary:
I had fixed this locally but hadn't updated the original pull request, sorry. This commit is working for us in production.
Closes https://github.com/facebook/react-native/pull/14900
Differential Revision: D5539787
Pulled By: hramos
fbshipit-source-id: 6c826ada4a7f36607c65508ced6c9dce32002f74
Summary:
The next in my series of :atom: migrations.
Closes https://github.com/facebook/react-native/pull/15278
Differential Revision: D5526468
Pulled By: javache
fbshipit-source-id: 91511c69bc37a6f1382bcf0b0dd847adf10fd43a
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary:
The last in my series of :atom: migrations. More to come!
Closes https://github.com/facebook/react-native/pull/15279
Differential Revision: D5526467
Pulled By: javache
fbshipit-source-id: 02b37387c8c47af9ffe42b938ddcf17eb15b916f
Summary:
Documentation change only.
Filled out the Transforms docs a little more to indicate which props are now deprecated and to provide some guidance on the transform array since some values are expected to be strings and some are numbers
http://facebook.github.io/react-native/docs/transforms.html
Closes https://github.com/facebook/react-native/pull/15261
Differential Revision: D5518925
Pulled By: hramos
fbshipit-source-id: 9aacf2c23e85573e150feb8c34e8bed54ad565d5
Summary: We're focusing the React Native core on a set of high quality essential components and will be removing any modules that do not belong in that set. If you're currently using AdSuppportIOS, it will remain available in the react-native-deprecated-modules archive. There's also alternative implementations such as https://github.com/ptomasroos/react-native-idfa/.
Reviewed By: hramos
Differential Revision: D5388632
fbshipit-source-id: ce6204512b61242a0ba8c731836f3b3b7239b4b0
Summary:
This is the first PR from a series of PRs grabbou and me will make to add blob support to React Native. The next PR will include blob support for XMLHttpRequest.
I'd like to get this merged with minimal changes to preserve the attribution. My next PR can contain bigger changes.
Blobs are used to transfer binary data between server and client. Currently React Native lacks a way to deal with binary data. The only thing that comes close is uploading files through a URI.
Current workarounds to transfer binary data includes encoding and decoding them to base64 and and transferring them as string, which is not ideal, since it increases the payload size and the whole payload needs to be sent via the bridge every time changes are made.
The PR adds a way to deal with blobs via a new native module. The blob is constructed on the native side and the data never needs to pass through the bridge. Currently the only way to create a blob is to receive a blob from the server via websocket.
The PR is largely a direct port of https://github.com/silklabs/silk/tree/master/react-native-blobs by philikon into RN (with changes to integrate with RN), and attributed as such.
> **Note:** This is a breaking change for all people running iOS without CocoaPods. You will have to manually add `RCTBlob.xcodeproj` to your `Libraries` and then, add it to Build Phases. Just follow the process of manual linking. We'll also need to document this process in the release notes.
Related discussion - https://github.com/facebook/react-native/issues/11103
- `Image` can't show image when `URL.createObjectURL` is used with large images on Android
The websocket integration can be tested via a simple server,
```js
const fs = require('fs');
const http = require('http');
const WebSocketServer = require('ws').Server;
const wss = new WebSocketServer({
server: http.createServer().listen(7232),
});
wss.on('connection', (ws) => {
ws.on('message', (d) => {
console.log(d);
});
ws.send(fs.readFileSync('./some-file'));
});
```
Then on the client,
```js
var ws = new WebSocket('ws://localhost:7232');
ws.binaryType = 'blob';
ws.onerror = (error) => {
console.error(error);
};
ws.onmessage = (e) => {
console.log(e.data);
ws.send(e.data);
};
```
cc brentvatne ide
Closes https://github.com/facebook/react-native/pull/11417
Reviewed By: sahrens
Differential Revision: D5188484
Pulled By: javache
fbshipit-source-id: 6afcbc4d19aa7a27b0dc9d52701ba400e7d7e98f
Summary:
you don't need curly bracket. `{}`
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15198
Differential Revision: D5497867
Pulled By: javache
fbshipit-source-id: a09f06aabc6ea16f0b0eec12bf910ffcab804eb0
Summary:
Just a small typo in the docs, the suggested code uses a variable that doesn't exist and leads to a compile error.
Closes https://github.com/facebook/react-native/pull/15196
Differential Revision: D5490031
Pulled By: javache
fbshipit-source-id: cb1e15b22f0d8f282afb3943fb4f5d0dc5dad9e7
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Differential Revision: D5441491
Pulled By: shergin
fbshipit-source-id: 7b56ea290f7f6eca5f1d996ff8488f40b866c2e6
Summary:
Original PR: https://github.com/facebook/react-native/pull/12249
ImagePickerIOS saves photos to ImageStoreManager without meta information. So photo has wrong orientation.
**Test plan**
1. Take the 2 photos (in landspape and portrait orientation) with this code:
```
ImagePickerIOS.openCameraDialog(
{},
(uri) => CameraRoll.saveToCameraRoll(uri),
() => {}
);
```
2. Ensure that photos in Photos app have right orientation.
Closes https://github.com/facebook/react-native/pull/15060
Differential Revision: D5487595
Pulled By: shergin
fbshipit-source-id: ce1a47f4d5ba33e03070f318f3d6a8dd0df5ab88
Summary:
This change intends to fix 2 issues with the NetInfo API:
- The NetInfo API is currently platform-specific. It returns completely different values on iOS and Android.
- The NetInfo API currently doesn't expose a way to determine whether the connection is 2g, 3g, or 4g.
The NetInfo API currently just exposes a string-based enum representing the connectivity type. The string values are different between iOS and Andorid. Because of this design, it's not obvious how to achieve the goals of this change without making a breaking change. Consequently, this change deprecates the old NetInfo APIs and introduces new ones. Specifically, these are the API changes:
- The `fetch` method is deprecated in favor of `getConnection`
- The `change` event is deprecated in favor of the `connectionchange` event.
- `getConnection`/`connectionchange` use a new set of enum values compared to `fetch`/`change`. See the documentation for the new values.
- On iOS, `cell` is now known as `cellular`. It's worth pointing out this one in particular because the old and new names are so similar. The rest of the iOS values have remained the same.
- Some of the Android enum values have been removed without a replacement (e.g. `DUMMY`, `MOBILE_DUN`, `MOBILE_HIPRI`, `MOBILE_MMS`, `MOBILE_SUPL`, `VPN`). If desirable, we could find a way to expose these in the new API. For example, we could have a `platformValue` key that exposes the platform's enum values directly (like the old `fetch` API did).
`getConnection` and `connectionchange` each expose an object which has 2 keys conveying a `ConnectionType` (e.g. wifi, cellular) and an `EffectiveConnectionType` (e.g. 2g, 3g). These enums and their values are taken directly from the W3C's Network Information API spec (https://wicg.github.io/netinfo/). Copying the W3C's API will make it easy to expose a `navigation.connection` polyfill, if we want, in the future. Additionally, because the new APIs expose an object instead of a string, it's easier to extend the APIs in the future by adding keys to the object without causing a breaking change.
Note that the W3C's spec doesn't have an "unknown" value for `EffectiveConnectionType`. I chose to introduce this non-standard value because it's possible for the current implementation to not have an `effectiveConnectionType` and I figured it was worth representing this possibility explicitly with "unknown" instead of implicitly with `null`.
**Test Plan (required)**
Verified that the methods (`fetch` and `getConnection`) and the events (`change` and `connectionchange`) return the correct data on iOS and Android when connected to a wifi network and a 4G cellular network. Verified that switching networks causes the event to fire with the correct information. Verified that the old APIs (`fetch' and 'change') emit a deprecation warning when used. My team is using a similar patch in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14618
Differential Revision: D5459593
Pulled By: shergin
fbshipit-source-id: f1e6c5d572bb3e2669fbd4ba7d0fbb106525280e
Summary:
Platforms that plug in to react-native may require additional props that are specific to those platforms. For example, already in react-native there are props that are specific to Android (`accessibilityComponentType`, `needsOffscreenAlphaCompositing`, etc.), props that are specific to iOS (`accessibilityTraits`, `shouldRasterizeIOS`, etc.) and props that are specific to tvOS (`isTVSelectable`, `tvParallaxProperties`, etc.).
I need to add properties to `react-native-windows`, and I'd prefer not to override the entire `ViewPropTypes` file as it is a risk that things in react-native-windows fall out of sync with react-native.
Fixes#15173
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15175
Differential Revision: D5481444
Pulled By: hramos
fbshipit-source-id: 3da08716d03ccdf317ec447536eea3699dd7a760
Summary:
In the yet-to-be-released iOS 11, Apple has changed the way they notify the user of location services. (You can watch their session from WWDC about all the changes [here](https://developer.apple.com/videos/play/wwdc2017/713/).)
The current implementation of `RCTLocationObserver` uses the standard location services from Apple. When the user has granted `Always` location permission and the application uses the background location service, the user is presented with the *_Blue Bar of Shame_* (for more information check out [this blog post](https://blog.set.gl/ios-11-location-permissions-and-avoiding-the-blue-bar-of-shame-1cee6cd93bbe)):
![image](https://user-images.githubusercontent.com/15896334/28285133-281e425c-6af9-11e7-9177-61b879ab593c.png)
* Added `useSignificantChanges` boolean to the options passed.
* Added `_usingSignificantChanges` boolean based on user options. If `true`, then the CLLocationManager will use functions `startMonitoringSignificantLocationChanges`/ `stopMonitoringSignificantLocationChanges` rather than the standard location services.
* Changed method signature of `beginLocationUpdatesWithDesiredAccuracy` to include `useSignificantChanges` flag
* Added check for new `NSLocationAlwaysAndWhenInUseUsageDescription`
All unit tests passed.
Tested in simulator and on device, toggling `useSignificantChanges` option when calling `watchPosition`. Results were as expected. **When `TRUE`, the _Blue Bar of Shame_ was not present.**
Changes do not affect Android and location services still work as expected on Android.
* Change is for iOS only
* Using a different API will have different accuracy results. Adding `useSignificantChanges` as an option was by design so apps that want to have most accurate and most frequent update can still use standard location services.
Closes https://github.com/facebook/react-native/pull/15062
Differential Revision: D5443331
Pulled By: javache
fbshipit-source-id: 0cf5b6cd831c5a7c8c25a5ddc2e410a9aa989bf4