Summary:
D5016368 to suppress the warning had a typo which meant `_isMounted` would never get set
`false` and thus some functions could be called on unmounted refs.
Reviewed By: yungsters
Differential Revision: D5034076
fbshipit-source-id: 6334db6ee2f9e19c1bb4da2572987dc10773e28d
Summary:
The list items' selected state is inside the `selected` Map, not inside the `state`.
This PR corrects a small mistake in the minimal example in the Documentatioin of the FlatList component.
1. Create a vanilla React Native project.
2. Create the components involved in the minimal example of FlatList.
3. Run to see if the `selected` property of the `MyListItem` changes as intended.
Currently the example has this mistake so an error will show up when running:
Closes https://github.com/facebook/react-native/pull/13795
Differential Revision: D5010105
Pulled By: javache
fbshipit-source-id: 09585cea2f2e3e6746419ef54ef8da9dbdb8dbb1
Summary: Exporting an object instead of an array so it can be used as an enum by other files.
Reviewed By: sahrens
Differential Revision: D5007488
fbshipit-source-id: 8253a424f0dbb51511b889b1da637f366c0f290a
Summary:
Hey there :)
Please let me know if the name `ListEmptyComponent` should be changed. I also thought about `ListNoItemsComponent`. Or maybe `ListPlaceholderComponent`?
- [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.
In a FlatList, I wanted to show some placeholder when my data is empty (while keeping eventual Header/Footer/RefreshControl).
A way around this issue would be to do something like adding a `ListHeaderComponent` that checks if the list is empty, like so:
```js
ListHeaderComponent={() => (!data.length ? <Text style={styles.noDataText}>No data found</Text> : null)}
```
But I felt it was not easily readable as soon as you have an actual header.
This PR adds a `ListEmptyComponent` that is rendered when the list is empty.
I added tests for VirtualizedList, FlatList and SectionList and ran `yarn test -- -u`. I then checked that the snapshots changed like I wanted.
I also tested this against one of my project, though I had to manually add my changes because the project is on RN 0.43.
Here are the docs screenshots:
- [VirtualizedList](https://cloud.githubusercontent.com/assets/82368/25566000/0ebf2b82-2dd2-11e7-8b80-d8c505f1f2d6.png)
- [FlatList](https://cloud.githubusercontent.com/assets/82368/25566005/2842ab42-2dd2-11e7-81b4-32c74c2b4fc3.png)
- [SectionList](https://cloud.githubusercontent.com/assets/82368/25566010/368aec1e-2dd2-11e7-9425-3bb5e5803513.png)
Thanks for your work!
Closes https://github.com/facebook/react-native/pull/13718
Differential Revision: D4993711
Pulled By: sahrens
fbshipit-source-id: 055b40f709067071e40308bdf5a37cedaa223dc5
Summary:
The main reason to use **VirtualizedList** is to set the `getItem` and `getItemCount` props, so having default values for these props makes things error prone.
* In **VirtualizedList**, changed the `getItem` and `getItemCount` props from optional to required, and removed default values.
* Ensured that implementing classes **FlatList** and **SectionVirtualizedList** are always passing these props.
* Updated VirtualizedList-test.js accordingly.
Reviewed By: sahrens
Differential Revision: D4980236
fbshipit-source-id: ad1838931253bc61ff9068c40929f6e9c755b92c
Summary:
- If the initial render doesn't extend past `onEndReachedThreshold` it is likely that onEndReached won't get called until scroll, which can be a bad experience if the `initialNumToRender` is very close to the viewport height. This happens because when `onContentSizeChange`, `onLayout` may not have fired yet so we don't know what the `visibleLength` is. Fix is to also call `maybeCallOnEndReached` in `_onLayout` as well.
- We have an optimization that does hi-pri render window updates when scrolling quickly and the content reaches the edge of the viewport, but there is also an important case where the user has scrolled to the end of the content and is waiting for a network response. Once the new data comes in, we want to render it ASAP because the user is waiting for it. To solve this we refactor our scheduling code into a shared function that always checks if it should be a hi-pri update instead of just in `_onScroll`.
Reviewed By: bvaughn
Differential Revision: D4975314
fbshipit-source-id: 8d64832ecbcbdbac430a08a4018d7a32b2216a85
Summary:
- [x] Explain the **motivation** for making this change.
- [ ] ~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.
The key name required to access the CameraRoll in iOS is incorrect.
Closes https://github.com/facebook/react-native/pull/13755
Differential Revision: D4994048
Pulled By: javache
fbshipit-source-id: 9ec2f793f03f529e9cf0f89106f88445fde50f2a
Summary: People rarely re-order sections so this is an annoying requirement and we can just use the index by default.
Reviewed By: thechefchen
Differential Revision: D4972154
fbshipit-source-id: 256c445b36c9ba101277614d30a6dc1dbd477ee0
Summary: The xcode project for these bundled libraries should not depend on UIExplorer
Reviewed By: yungsters
Differential Revision: D4979629
fbshipit-source-id: 440b225805e9ebaf0a02b39a35c3ab9c2a83ad05
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4680300
fbshipit-source-id: 337836deef0767e5f26350f5a8ce73adb4146a02
Summary:
I don't think editing the search path is necessary anymore for notifications since [0.40](https://github.com/facebook/react-native/releases/tag/v0.40.0).
I removed the part that says to edit the search paths, and changed `#import "RCTPushNotificationManager.h"` to `#import <React/RCTPushNotificationManager.h>` in the documentation
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
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.
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/13700
Differential Revision: D4969728
Pulled By: javache
fbshipit-source-id: d72aee1c5b8578cea27d6b7d45ee7a7f269433fc
Summary:
In the current docs, it's not quite clear, at the first sight, what the `lang` parameter passed to `onValueChange` is. This makes it obvious.
Closes https://github.com/facebook/react-native/pull/13617
Differential Revision: D4969592
Pulled By: javache
fbshipit-source-id: e94bedefebbe19d838d010f0c79d9a76743a4341
Summary:
What existing problem does the pull request solve?
I was seeing errors in the crash monitoring software for my app in production. Many took the form of, `Unable to open URL: telprompt:5551231234`
After some research, I found that when the user attempts to call a phone number, a dialog pops up in iOS asking the user to confirm or cancel the call. If the call is canceled, the promise returned by `openURL` is rejected.
This PR improves the documentation around what happens to the promise returned by `openURL`.
No test plan, text changes only.
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/13624
Differential Revision: D4962161
Pulled By: javache
fbshipit-source-id: c8d5ffbc24ba4c14c85db6ea799a6f95339b94c8
Summary:
Looking to address a few new `FlowFixMe`s I had to do some minor refactoring of `MessageQueue`. Has the advantage of (IMO) making things clearer by removing a redundant counter and some gratuitous bitwise operations.
Previously `_callbacks` was an array of `?Function`s where even elements were failure callbacks and odd elements were successes. Each new call incremented `_callID` by one and `_callbackID` by two. I've changed this to use two arrays `_successCallbacks` and `_failureCallbacks` indexed by `callID`. That made the `_callbackID` counter unnecessary and reduced the need for computed indices.
Tested with flow and a quick play with UIExplorer.
Closes https://github.com/facebook/react-native/pull/11986
Differential Revision: D4962162
Pulled By: javache
fbshipit-source-id: 17dddfedc0cb5950dbdd9bd06fae6eb6de4c4a7d
Summary:
This PR solves issue #13618.
Selectable text still behaves the same way:
```jsx
<Text selectable={true}>yo yo yo</Text>
```
Text that is not selectable and has a custom tooltip now do not include the copy item:
```jsx
import * as React from 'react';
import { Text } from 'react-native';
import ToolTip from 'react-native-tooltip';
const MyComponent = () => (
<Text>
<Text>This is my text.</Text>
<ToolTip
actions={[
{text: 'My', onPress: (): any => null },
{text: 'Context', onPress: (): any => null },
{text: 'Menu', onPress: (): any => null },
]}
underlayColor='transparent'
longPress={true}
arrowDirection='down'
>
<Text>You can long press me for a tooltip.</Text>
</ToolTip>
<Text>This is the rest of my text</Text>
</Text>
);
export default MyComponent;
```
Closes https://github.com/facebook/react-native/pull/13619
Reviewed By: shergin
Differential Revision: D4936900
Pulled By: ericvicenti
fbshipit-source-id: 82028b0958c37d63b8a80882196295be4aebecb4
Summary:
Importing `react` modules from `react-native` has been deprecated since 0.25 so I think it's safe to remove it now since everyone has migrated their code and it is now well know and documented that you import from different packages. This finishes the spring cleanup of `react-native-implementation.js` :)
**Test plan**
Tested that UIExplorer still works.
Closes https://github.com/facebook/react-native/pull/13354
Reviewed By: bvaughn
Differential Revision: D4928785
Pulled By: javache
fbshipit-source-id: 38c623c309b06b2cb5e73074833342d2745ab198
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve? Minor omission in doc.
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.
If you have added code that should be tested, add tests.
No code changes.
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/13666
Differential Revision: D4953796
Pulled By: javache
fbshipit-source-id: 131c2326d6631fe193f6ccae124e1f09af3f5c73
Summary:
These got smashed together with some weird rebase snafu. They are pretty intertwined anyway so the value of
separate commits is minimal (e.g. separate commits would not revert cleanly anyway).
== [lists] better fill rate logging (previously D4907958)
After looking through some production data, I think this will address all the issues we're seeing. Now:
- Header/Footer getting no longer counted as blank.
- Avoid floating point for Scuba.
- Compare actual time of blankness, not just samples.
- Include both "any" vs. "mostly" blank (similar to 1 and 4 frame drops).
- Include events where there is no blankness so we have a baseline.
- Remove events with too few samples
**Test Plan: **
A bunch of scrolling in FlatListExample
T17384966
== [Lists] Update SectionSeparatorItem docs (previously D4909526)
Forgot to update the language here when we modified the behavior with the introduction of separator
highlighting support.
** Test Plan: **
nope.
== [Lists] Add renderSectionFooter prop to SectionList (previously D4923353)
Handy for things like "see more" links and such.
The logic here is to render the footer last, *after* the bottom section separator. This is to preserve
the highlighting behavior of the section separator by keeping it adjacent to the items.
**Test Plan: **
Added to snapshot test and example:
{F66635525}
{F66635526}
== [SectionList] Add a bunch more info for rendering items and separators (previously D4923663)
This extra info can be helpful for rending more complex patterns.
**Test Plan: **
Made snapshot test more comprehensive and inspected the output.
== [Lists] reduce render churn (previously D4924639)
I don't think the velocity based leadFactor is helping and might actually be hurting because
it causes a lot of churn in the items we render.
Instead, this diff introduces fillPreference which biases the window expansion in the direction of scroll,
but doesn't actually affect the final bounds of the window at all, so items that are already rendered are
more likely to stay rendered.
**Test Plan: **
Played around in debug mode and watched the overlay - seems better. Also tests all pass.
T16621861
== [Lists] Add initialScrollIndex prop
Makes it easy to load a VirtualizedList at a location in the middle of the content without
wasting time rendering initial rows that aren't relevant, for example when opening an infinite calendar
view to "today".
**Test Plan: **
With debug overlay, set `initialScrollIndex={52}` prop in `FlatListExample` and
and see it immediately render a full screen of items with item 52 aligned at the top of the screen. Note
no initial items are mounted per debug overlay. Scroll around a bunch and everything else seems to work
as normal.
No SectionList impl since `getItemLayout` isn't easy to use there.
T17091314
Reviewed By: bvaughn
Differential Revision: D4907958
fbshipit-source-id: 8b9f1f542f9b240f1e317f3fd7e31c9376e8670e
Summary:
This is one of the last feature that is missing from native animated, it was already supported on Android and this implementation is based on it.
**Test plan**
Test that the existing decay animation example now works on iOS
Run unit tests
Closes https://github.com/facebook/react-native/pull/13368
Differential Revision: D4938061
Pulled By: javache
fbshipit-source-id: 36b57b1029a542e9daf21e048a06d3b3347e9659
Summary:
Small edit to comment, shouldn't require a test plan.
Closes https://github.com/facebook/react-native/pull/13604
Differential Revision: D4928784
Pulled By: javache
fbshipit-source-id: b8f4aff1580a7c5e8c80bbec3f52252b5e62c852
Summary:
The ART library backend did not get build support for tvOS when other libraries did. We are writing an application that will run on tvOS, and wanted to use ART, so it was important to have this. This PR adds that build support.
Verified that this builds and works on tvOS simulator for development of this project.
Closes https://github.com/facebook/react-native/pull/12547
Differential Revision: D4925864
Pulled By: lacker
fbshipit-source-id: f72c650d7620e9c7f59d9ae68cfc39f0e7bab12b
cailenmusselman
Pieter De Baets
Spencer Ahrens
Alexey Lang
Dan Abramov
Valentin Shergin
Jiajie Zhu
Eric Vicenti
liushigit
Pieter De Baets
Fred Liu
Emily Janzer
Brian Vaughn
Louis Lagrange
Andres Suarez
周中原
Jeff Case
janus_wel
Sokovikov
Blair Vanderhoof
Jan Kassens
Karin Wefald
Brendan Rius
Vojtech Novak
Garrett McCullough
rh389
Gabriel Bull
Eli White
Janic Duplessis
Adam Perry
Rich R
Jean Lauliac
Andrew Y. Chen
Tom Haynes
Daniel Farrell
Marc Horowitz
