Summary:
Builds off of cae7179c94
- Make the prop a dictionary for more configuration options
- Rename `maintainPositionAtOrBeyondIndex` -> `maintainVisibleContentPosition` + `minIndexForVisible`
- Add autoscroll threshold feature
Given the async native of RN JS and background layout, there is no way to trigger the scrollTo from JS without risking a delay, so we add the feature in native code.
== Test Plan ==
ScrollViewExample:
https://youtu.be/pmY8pxC9PRs
Reviewed By: shergin
Differential Revision: D6729160
fbshipit-source-id: 70f9bae460ce84567857a4f696da78ce9b3b834c
Summary:
The code to display HMR errors on the client was reading the `description` field from Metro payloads. Metro does not include `description` in the body of its error payloads -- only in its `body.errors[]` items. This commit changes RN's HMR code to show `body.message` (set consistently with https://github.com/facebook/metro/pull/124) instead of the non-existent `body.description`.
Open a test RN app, enable HMR, and then introduce a syntax error in an app source file. See that the redbox provides information about the syntax error instead of just saying "TransformError undefined".
- https://github.com/facebook/metro/pull/124
[GENERAL][ENHANCEMENT][HMR] - Fix display of syntax error messages when HMR is enabled
Closes https://github.com/facebook/react-native/pull/17619
Differential Revision: D6726516
Pulled By: mjesun
fbshipit-source-id: b1d1008d6f1aa8f88ff8a2aa1374724a305c773b
Summary:
Currently `isInAParentText` context works as imaginary `isInAAncestorText` context (not like a real `isInAParentText`).
Let's imagine we have hierarchy like:
`View -> Text -> Text* -> View* -> Text* -> Text* -> View*`
With current implementation all nodes marked with asterisk have `isInAParentText` context, which is incorrect (because some of them actually in View context).
With the new implemetations it will work like this:
`View -> Text -> Text* -> View* -> Text -> Text* -> View*`
So, only nodes which have <Text> (or <TextInput>) as a parent will have `isInAParentText` context.
This change allows to select proper `Text` vs. `VirtualText` component in cases where <Text> and <View> components can interleave each other.
Reviewed By: sahrens
Differential Revision: D6690495
fbshipit-source-id: f7c59b23d0eaf68a1d08036b858d99c9547f7878
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
Summary:
This fixes#17486
make sure locationManager is being set before continuing.
Used if !locationManager vs else on previous statement as we should NEVER enter this code without _locationManager set. Also the else version might experience issues if someone touches the auth code and doesn't check this case, so seems more "long term stable".
<!--
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!
-->
This fixes#17486
1) Have a working geolocation demo
2) Add navigator.geolocation.setRNConfiguration({'skipPermissionRequests':true}); to your code. I added it to the constructor or componentWillMount for the app.
3) Observe that geolocation no longer works (times out)
4) Apply patch
5) Observe that geolocation works again
re #15096
<!--
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] [BUGFIX] [GeoLocation] - Fix skipPermissionRequests by setting _locationManager
Closes https://github.com/facebook/react-native/pull/17487
Differential Revision: D6718389
Pulled By: hramos
fbshipit-source-id: 08c1c9306b4d87cc40acdaa1550bb6df8345db02
Summary:
iOS TV CI is currently broken.
CI for both iOS and iOS TV successfully pass.
[INTERNAL] Continous integration for iOS fixed.
Closes https://github.com/facebook/react-native/pull/17564
Differential Revision: D6711693
Pulled By: hramos
fbshipit-source-id: c36ffc2581dac69cb6e4f8670f21c2816496e9df
Summary:
RCTCameraRollManager.m crashes when there is no filename provided for the asset (usually from iCloud). #13671
Tested on real device with iCloud library using the library without and after my fix. It worked after my changes.
[IOS] [BUGFIX] [CameraRoll] - Changed the filename if nil to be empty when the asset is coming from iCloud.
Closes https://github.com/facebook/react-native/pull/17549
Differential Revision: D6710665
Pulled By: hramos
fbshipit-source-id: 319865b0a71728798c62ee380e7bee4af584b3e3
Summary:
We currently support inherited view props but not event handlers,
this diff fixes it.
This change will allow to unify set of supported events for single- and multli-line <TextInput>s and avoid code duplication.
Reviewed By: sahrens
Differential Revision: D6690281
fbshipit-source-id: f142828bd7deae92fb306914b7cefd10da8b43f7
Summary:
`thread-id` is an Apple-defined key. `PushNotificationIOS.getDeliveredNotifications()` includes it, but the notification object currently ignores it. Since it's in the `aps` key, it's impossible to access without this change, as `getData()` does not include it.
Closes https://github.com/facebook/react-native/pull/17499
Differential Revision: D6696577
Pulled By: shergin
fbshipit-source-id: e0f48efd640bf5addb24a8d4352f9bb23f42612a
Summary: See RCTYogaFloatFromCoreGraphicsFloat for more details.
Differential Revision: D6677092
fbshipit-source-id: ca1b2634c903277f529c57557055760a9bf48f28
Summary: Bunch or identical code was moved to superclass.
Reviewed By: mmmulani
Differential Revision: D6663772
fbshipit-source-id: 82321f56bbab0e9d17c0227c97dd86904cf5ab30
Summary:
The pull request adds the `--port` option to `run-ios` allowing a developer to build and launch a react-native app using a single command line like this:
```
react-native run-ios --port 8088
```
It defaults to the current port 8081.
This pull request fixes issue #9145 and issue #14113.
This patch also extends `run-android` to properly test and launch the packager with the specified port, extending the work done in PR: ##15316
1. Create a new react-native app, or simply clone this branch and then update your version of react-native using `yarn add file:./path/to/this/fork/of/react-native`
2. run `react-native run-ios --port 8088`
3. watch the packager start on the desired port (8088 in this case) and watch your app in your simulator connect to the packager and launch the app.
Closes https://github.com/facebook/react-native/pull/16172
Differential Revision: D6612534
Pulled By: shergin
fbshipit-source-id: 50af449f5e4c32fb76ba95f4cb7bf179e35526d5
Summary:
This implements onKeyPress for Android on TextInputs and addresses https://github.com/facebook/react-native/issues/1882.
**N.B. that this PR has not yet addressed hardware keyboard inputs**, but doing will be fairly trivial. The main challenge was doing this for soft keyboard inputs.
I've tried to match the style as much as I could. Will happily make any suggested edits be they architectural or stylistic design (edit: and of course implementation), but hopefully this is a good first pass :).
I think important to test this on the most popular keyboard types; maybe different languages too.
I have not yet added tests to test implementation, but will be happy to do that also.
- Build & run RNTester project for Android and open TextInput.
- Enter keys into 'event handling' TextInput.
- Verify that keys you enter appear in onKeyPress below the text input
- Test with autocorrect off, on same input and validate that results are the same.
Below is a gif of PR in action.
Closes https://github.com/facebook/react-native/pull/14720
Differential Revision: D6661592
Pulled By: hramos
fbshipit-source-id: 5d53772dc2d127b002ea5fb84fa992934eb65a42
Summary:
`renderItem` on `SectionList` is within the `OptionalProps` group of props but it is not actually marked as optional. Which means that doing things such as in the example where each section has its own `renderItem` and no `renderItem` prop is passed into `SectionList` will fail flow.
Create a `SectionList` where each section has it's own `renderItem` and do not pass in a `renderItem` into `SectionList`. Run flow, it should error.
[GENERAL] [MINOR] [SectionList] -Makes `renderItem` prop on `SectionList` optional for flow.
Closes https://github.com/facebook/react-native/pull/17262
Differential Revision: D6645672
Pulled By: hramos
fbshipit-source-id: 1096e8c4998c14003cf42f29ea559505082047c1
Summary:
Related to #15126, and this would be useful for use React DevTools on real device without modify `setupDevtools.js`.
In Android emulator, the host of `SourceCode.scriptURL` is same with `PlatformConstants.ServerHost` so we can just replace it.
* Tested on iOS device with [react-devtools](https://github.com/facebook/react-devtools/tree/master/packages/react-devtools) package.
* Tested on Android emulator, the `getDevServer` module got the correctly hostname so that don't need `adb reverse`.
[ENHANCEMENT] [setupDevtools] Set host of development server for setupDevtools
Closes https://github.com/facebook/react-native/pull/15547
Differential Revision: D6544980
Pulled By: javache
fbshipit-source-id: a286874bcef0501c5d2e0be2251d58c236a5534a
Summary:
`ScrollView` has a bunch of `onFoo` handlers for scrolling-related events, most of which have a proptype defined and are documented. However, `onScrollBeginDrag` and `onScrollEndDrag` do not currently have a proptype and are not currently documented (as noted at https://stackoverflow.com/a/41793747/1709587). It seems reasonable to bring consistency and to provide documentation of these otherwise hard-to-discover props.
I haven't added or run any tests, and don't plan to do so (beyond waiting and seeing that no existing checks fail in CircleCI).
I have also created a PR to update the documentation at https://github.com/facebook/react-native-website/pull/99
*(None needed; this isn't a functionality change.)*
Closes https://github.com/facebook/react-native/pull/17368
Differential Revision: D6642695
Pulled By: TheSavior
fbshipit-source-id: fa40ed2ae6d5947a161b816a47441d8f5d4d9c4d
Summary:
Setting `windowSize = 0` doesn't make sense. Let's make sure we catch this problem in the constructor so that it doesn't cause inexplicable list behavior.
Also fixed an invariant in `VirtualizeUtils` that is meant to prohibit non-monotonically-increasing offset arrays. As written, the invariant condition can never actually be violated.
Reviewed By: sahrens
Differential Revision: D6625302
fbshipit-source-id: b2a983cbe7bb5fbe0aed7c5d59e69a8a00672993
Summary:
The previous file/class name convention seemed cool... but now it drives me BANANAS! It makes all this code really hard to maintain.
So, evething were renamed following common modern RN convention.
Reviewed By: mmmulani
Differential Revision: D6605090
fbshipit-source-id: 88ca13d793a5d2adaac2b7922ec6bd4654aacec5
Summary:
The change enabling virtualization in nested lists contained a hidden assumption that nested lists would only appear within the *cells* of a parent list.
If a list header or footer component contains a `VirtualizedList`, that child list won't be wrapped in a `CellRenderer` component and therefore won't have access to `virtualizedCellRenderer` through its context. This causes an error when the child list tries to access the `cellKey` property on an undefined object.
This change wraps the header/footer views in a `VirtualizedCellWrapper` component which supplies that context properly.
Reviewed By: sahrens
Differential Revision: D6603342
fbshipit-source-id: 4d2d82f04947048a16ec9968121d8ecc8c95655a
Summary: As it was mentioned in previous diffs, we are removing this because it overcomplicates rendering layer and provides (almost) no benefits (and cannot be implemented 100% accurate way).
Reviewed By: mmmulani
Differential Revision: D6582560
fbshipit-source-id: 0778db96a45dd8e2520268d5d00792677cb01a20
Summary:
`autoGrow` feature was/is totally awesome but... nowadays <TextInput> component is always autoexpandable (on both iOS and Android),
so we don't need JavaScript implementation of this anymore. Sometimes it is even harmfull (see T23403231).
I am sorry, sumkit. You are still awesome. :)
Reviewed By: sahrens
Differential Revision: D6553514
fbshipit-source-id: 1d24a2f2c046f514bd6b6318797a607b6e1841d0
Summary:
We are removing `reactSetInheritedBackgroundColor` feature because it overcomplicates RN rendering layer and provides very small benefits.
This is the last place where we are using `reactSetInheritedBackgroundColor`.
Reviewed By: mmmulani
Differential Revision: D6581599
fbshipit-source-id: 129997332a03daf927acdd174e5853bfd388332f
Summary:
This is a long story. Awhile ago awesome Nick Lockwood (Hey Nick!) introduced a special optimization for ReactNative rendering layer called "inherited background color".
He described this idea in D2811031:
>>>
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just <Image/> and <Text/> components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except <Text/> nodes. It might still be useful for <Image/> nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
However. I think it is time to remove it. Why? There are several reasons:
* It drastically complicates rendering layer. DRASTICALLY. In many many unrelated places (try search for "backgroundColor"!);
* This mechanism is totally non-conceptual to RN and it prevents us to implement some new possible render optimization that we plan to do;
* This adopted only by two components now: Text and ART;
* This is not a significant performance drain anymore; from iOS 6 even UILabel has clear background color by default.
* I doubt that it even works now because `drawRect:` in Text component does not call super method.
So, this diff just turns this feature off for Text. If all performance metrics are neutral, I will delete this mechanism.
Peace.
Reviewed By: sahrens
Differential Revision: D6564199
fbshipit-source-id: 70524fdd955ca32bbf86d2d1ff5e73316b791219
Summary: JSON.stringify will convert a function to null, but folly::dynamic in the native code can't represent a JS function. Props do sometimes have functions, but don't permit them everywhere.
Reviewed By: johnislarry
Differential Revision: D6541878
fbshipit-source-id: b2a9d3ba7899dfb98a6a2ada3aa91a26549fdd94
Summary:
Because it is not simply flushing, it (in the future) is more complex process. And the names should represent logical meaning of the process, not particular implementation details.
It also nice to have unified terminology across our reactive UI frameworks.
See the next diffs.
Reviewed By: rsnara
Differential Revision: D6436770
fbshipit-source-id: 0a0b686e8ace89e30f6787a37c0a7965c5af757b
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!
-->
There are some errors I noticed after upgrading my flow version. I had them in my project, and they were also reported in #11655. These errors were ignored on master, but I went through and fixed them so the static analysis will work still.
After these changes, I receive no errors using flow `0.60.1` on latest master, or using `0.59` in my local project (which does not have the requisite ignores included).
- init a new project
`react-native init --version <path-to-repo> helloworld`
- add the flow binary
`yarn add -D flow-bin`
- run flow
`yarn flow`
- make sure there are no errors in the project.
```
No errors!
✨ Done in 23.60s.
```
<!--
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
-->
[GENERAL][BUGFIX][./Libraries] - Fix up some flow definitions
Closes https://github.com/facebook/react-native/pull/17086
Differential Revision: D6509112
Pulled By: hramos
fbshipit-source-id: a61145b5306c666ab6510ccb9eea02d96f3decb3
Summary:
This feature has been requested by customers. Our previous (pre-react) application had support for custom accessibility actions.
This feature allows UI elements to provide a list of custom actions that can be read when VoiceOver is enabled. UI elements expose one accessibility action by default. Some UI elements may support multiple actions though other mechanisms like tap and hold. To expose these actions in an accessible way iOS provides custom accessibility actions.
Feature was tested in the iOS simulator using the Accessibility Inspector. Custom actions were added to a button and observed in the tool. Custom actions were also invoked using the tool and then stepped through in the debugger.
The feature was also tested on an iPhone. VoiceOver was enabled on the device and custom actions were observed for controls that exposed them.
We have been using this feature in our app for some time as well.
[IOS] [ENHANCEMENT] [Accessibility] - Added support for custom accessibility actions
Eric Davison
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/17020
Differential Revision: D6472283
Pulled By: shergin
fbshipit-source-id: 4ac4697dca07028e87ffe71b70c00280e7f2043c
Summary: Though this module is dev-only, if not connected to the packager it will collect websockets forever. Some estimate it'll take up 200MB after like 20 minutes.
Reviewed By: shergin
Differential Revision: D6464304
fbshipit-source-id: bef1ce967e4c13dd29e3c7ab4228e9c88d02c157
Summary:
when a hardware keyboard is connected, the virtual keyboard can be hidden (this can easily be demonstrated in the simulator), which means the height of the keyboard is 0. When in this case a `LayoutAnimation` is scheduled, the `KeyboardAvoidingView` won't be affected, but the next layout change will be animated, which can have unintended side-effects. This can also trigger the `Overriding previous layout animation with new one before the first began` warning.
<details>
<summary>Screenshot</summary>
</details>
Open the `KeyboardAvoidingView` example in the `RNTester` project, import `LayoutAnimation` and add something rendered conditionally to the content of the `Modal`, e.g.;
```jsx
{this.state.behavior === 'position' &&
<Text>We're using position now</Text>
}
```
Then update the `onSegmentChange` handler with a `LayoutAnimation`;
```js
onSegmentChange = (segment: String) => {
LayoutAnimation.easeInEaseOut();
this.setState({behavior: segment.toLowerCase()});
};
```
Now open the example in the simulator and play with the "Toggle Software Keyboard" option;
Now when you focus the input, no keyboard should appear, and when you then press an option of the segmented control, you should get the beforementioned warning.
After this change this warning will no longer appear, but the component still behaves the same as before.
[IOS] [BUGFIX] [KeyboardAvoidingView] - prevent scheduling unnecessary `LayoutAnimation`
Closes https://github.com/facebook/react-native/pull/16984
Differential Revision: D6472300
Pulled By: shergin
fbshipit-source-id: c4041dfdd846cdc88b2e9d281517ed79da99dfe7
Summary: We need this trivial funcs to unify spinner appearance logic.
Reviewed By: rsnara
Differential Revision: D6367072
fbshipit-source-id: 70e288bc1fed5911828a5f6deaa829597bf8ebff
Summary:
Currently goes to the same page
<!--
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!
-->
Online doc was not helpful because the link kept going to the wrong page. Someone told me to make a pull request
Documentation change
Go to original link https://facebook.github.io/react-native/docs/animated.html#animatedvaluexy
See that it does not have any info on valuexy
Go to https://facebook.github.io/react-native/releases/next/docs/animatedvaluexy.html
See that the page loads and has information about valuexy
<!--
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/16999
Differential Revision: D6467512
Pulled By: shergin
fbshipit-source-id: 69887e34446c3ea57ad831ed870be4e1a8a7a514
Summary:
WIP: Starting point insofar as I'm not sure if there should be an Android equivalent.
My application needs me to delete photos from the photos in iOS.
I have tested this in my application and it works, have a screenshot from iOS asking as well and it does successfully delete the photos from the global Photos app.
Related to https://github.com/facebook/react-native/issues/15253, it kind of continues using the deprecated assets-library framework, but that does need (and will be an bigger and bigger issue coming up) of assets-library URLs being used.
I also assume RN prefers error handling at the JS level? Are the URLs starting with `asset-library`, etc.
Closes https://github.com/facebook/react-native/pull/15481
Differential Revision: D6438016
Pulled By: hramos
fbshipit-source-id: 47512140f62f458c14ad2ade2b358846e168c964
Summary:
Not ready but want to start conversation. (i.e. not sure if to change key name to `urls` from `url`)
I want to be able to share more than 1 image at a time, the current code only lets one use one url, but the API allows for much more.
Some places already make this an issue:
https://github.com/EstebanFuentealba/react-native-share/issues/85
And I also need to be able to email/send on iMessage, etc with multiple URL resources.
Closes https://github.com/facebook/react-native/pull/15475
Differential Revision: D6437807
Pulled By: hramos
fbshipit-source-id: 336c696c5633c0080904ca9306a38120e27f9173
Summary:
$FlowFixMe suppressed type validation on _listRef. Add appropriate typing to let Flow succeed when $FlowFixMe is removed.
Not sure what this project's philosophy around ref types is. In some places I've seen them annotated as any rather than trying to get a more granular type to match. I'm open to suggestions.
`yarn flow`
[INTERNAL] [ENHANCEMENT] [FlatList.js] - Remove $FlowFixMe from FlatList
Closes https://github.com/facebook/react-native/pull/16882
Differential Revision: D6386479
Pulled By: hramos
fbshipit-source-id: bed14f2c7071525cb46425ab14214771de0277f3
Summary:
Solves https://github.com/facebook/react-native/issues/13034
Now the `ScrollView` mock has all the methods available.
React Native tests pass.
To test this specific part of the code,
```sh
$ react-native init Test
$ cd Test/
$ yarn add react-navigation
```
Then, add a simple project that uses `react-navigation`:
```js
import React from 'react';
import { Text } from 'react-native';
import { StackNavigator } from 'react-navigation';
class HomeScreen extends React.Component {
static navigationOptions = {
title: 'Welcome',
};
render() {
return <Text>Hello, Navigation!</Text>;
}
}
const SimpleApp = StackNavigator({
Home: { screen: HomeScreen },
});
export default SimpleApp
```
Run the default render tests:
```js
$ npm run test
```
Closes https://github.com/facebook/react-native/pull/13048
Differential Revision: D4746028
Pulled By: shergin
fbshipit-source-id: cb1791978d15be7f5d14b7b22979388066ad6caa
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
Jean Lauliac
Spencer Ahrens
Mathias Bynens
Eli White
David Vacca
Liubov Zvereva
Jiajie Zhu
James Ide
Valentin Shergin
Tim Yung
Semen Zhydenko
ngandhy
Sergei Dryganets
Hristo Hristov
André Costa
Alexey Lang
ashoat
Wenjing Wang
Antonio Corrado
glevi@fb.com
Michael S. Kazmier
Josh Hargreaves
Jimmy Zhuang
Matt Sessions
Jhen-Jie Hong
Mark Amery
Logan Daniels
Yujie Liu
Pritesh Nandgaonkar
Sam Goldman
Marc Horowitz
Ayush Sood
Andrew Imm
Rafael Oleza
Oleg Lokhvitsky
Paco Estevez Garcia
Brian Shin
Gustavo Gard
David Buchan-Swanson
Adam Ernst
Brian Vaughn
Eric Davison
Marshall Roch
Mehdi Mulani
Koen Punt
garlic-rice-with-butter
Edgar Aroutiounian
Chris Lewis
Christoph Nakazawa
Álvaro Medina Ballester
David Detlefs
Leland Richardson
Brian Vaughn
