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:
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:
What existing problem does the pull request solve?
My motivation was to improve the documentation for ListView and ListViewDataSource because I always have trouble remembering how they work and the documentation was lacking an example for `cloneWithRowsAndSections`
My PR does the following:
* add a note about how headers and footers are rendered on a horizontal ListView
* fix a typo in an example
* clarify that the sectionIdentities should match the keys or array indexes of the data source
* add an example of cloneWithRowsAndSections
* add notes on the return values of `getRowCount` and `getRowAndSectionCount`
n/a; documentation only
Closes https://github.com/facebook/react-native/pull/13811
Differential Revision: D5473192
Pulled By: hramos
fbshipit-source-id: f31fc6edfdeb8dff75d39bbcceda06fd839df934
Summary:
<!--
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/15089
Differential Revision: D5448987
Pulled By: shergin
fbshipit-source-id: eb240517dc94475744f1bda2652f8aff994c0bcd
Summary:
ListView does specify this: https://facebook.github.io/react-native/docs/listview.html#props
The link in ListView is generated by the documentation generator, but because the format of FlatList's props is different, it fails to catch it. Consider finding a way to specify this explicitly to the documentation generator (although this would be a bigger change).
<!--
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/14891
Differential Revision: D5386036
Pulled By: sahrens
fbshipit-source-id: 0b8a685411507cc4d0b781fd39b792d59614ce52
Summary:
Added language to explain that you still need to add keys for each section even if you use a keyExtractor method.
No code changed; just clarified documentation.
Closes https://github.com/facebook/react-native/pull/15007
Differential Revision: D5425897
Pulled By: hramos
fbshipit-source-id: db44064a28a673feeda5a6765ea45217d3ae51e2
Summary:
The invariant condition doesn't allow scrolling to the last index
Here is a simple reproduction of the problem: https://snack.expo.io/BJ59gzWrZ
Surely, if the last item is rendered, we should be able to scroll to it without an invariant failing?
Tested locally that this change fixes the issue.
Closes https://github.com/facebook/react-native/pull/14934
Differential Revision: D5414535
Pulled By: shergin
fbshipit-source-id: 38dac4c0e2ae5e1e199a67ca0e98e8f7325e77f4
Summary:
This replaces all uses of `React.createClass` with `createReactClass` from the `create-react-class` package, attempting to match use of `var` and `const` according to local style.
Fixes#14620
Refs #14712
Closes https://github.com/facebook/react-native/pull/14729
Differential Revision: D5321810
Pulled By: hramos
fbshipit-source-id: ae7b40640b2773fd89c3fb727ec87f688bebf585
Summary:
<!--
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/14764
Differential Revision: D5375730
Pulled By: javache
fbshipit-source-id: 776db77c4dc681edef5832552b220197225e9d3f
Summary:
Could have sworn we put this in a while ago...
Closes https://github.com/facebook/react-native/pull/14870
Differential Revision: D5376747
Pulled By: sahrens
fbshipit-source-id: d2bf3efea205defa48d6cd7f853739f17eb39ece
Summary:
(prior to the scroll metrics being set up, or prior to the view being scrolled to the right location).
I'm using a StackNavigator to push a FlatList secondary screen, and it was causing extraneous rendering (item X ->item 0 -> item X)
I've logged inside the render functions of my `renderItem` function, and verified that it no longer attempts to render item 0 anymore. And I've verified from the `VirtualizedList.state` no longer renders a `{first: 0, last: 0}`, but persistently stays at `{first: X, last: X}` from start until things stabilize.
Closes https://github.com/facebook/react-native/pull/14562
Reviewed By: bvaughn
Differential Revision: D5283771
Pulled By: sahrens
fbshipit-source-id: 0f70ac0b89922449bd20bfa69edbc8939eafdf1f
Summary:
Returning an object that doesn't have all the required properties from `getItemLayout` doesn't cause a flow error (maybe because we are using `createAnimatedComponent`) and caused ALL items to be rendered which caused perf issues that were hard to debug (typo lenght -> length -_-). This adds a simple warning in DEV mode using checkPropTypes.
**Test plan**
Tested in RNTester by passing a bad `getItemLayout` function.
Closes https://github.com/facebook/react-native/pull/14111
Differential Revision: D5283942
Pulled By: sahrens
fbshipit-source-id: 8909532dfddd8628b7fb3380c198f0dfa88f240a
Summary:
Curently FlatList does not implement setting native props directly like the old ListView did. This pr introduce the `setNativeProps` function which delegates to MetroListView or VirtualizedList. Thos don't have `setNativeProps` handling either, so, I delegated further to the respective ListView and Scroll components, which do have handling for it, thus, allowing to set the native props through FlatList.
Create a project with a FlatList and change a native property using `setNativeProps`:
```javascript
componentDidMount() {
setInterval(() => {
this.list.setNativeProps({ style: {backgroundColor:"white"} })
}, 1000)
}
render() {
return (
<View style={styles.container}>
<FlatList ref={component => this.list = component}
style={{backgroundColor:"black"}}
data={[{key: 'a'}, {key: 'b'}]}
renderItem={({item}) => <Text>{item.key}</Text>} />
</View>
)
}
```
Fixes#13501
Closes https://github.com/facebook/react-native/pull/13529
Differential Revision: D5283593
Pulled By: sahrens
fbshipit-source-id: 8f96f88e286042d82452fef924689b5a8a783987
Summary:
When rendering a large list without a getItemLayout (ie SectionList, where it's hard to compute), it freaks out and attempt to render them all, starving the rendering/layout engine from computing the size (and more accurately figurnge out how few it actually should render.)
Before this change, with <FlatList maxToRenderPerBatch={5} data={objectOfLengthN} />, I essentially saw it doing:
```
{first: 0, last: 0}
{first: 0, last: 5}
{first: 0, last: 10}
....
{first: 0, last: N}
```
(no more hiPri renders since all elements have been rendered)
(actually renders and lays out all N objects, and computes their sizes)
(realizes that it doesn't need to show all N for my current screen size and row size)
```{first: 0, last: 55}```
After this change, that whole first part where it keeps incrementing `last` to try to "keep up with the scrolling" disappears.
Closes https://github.com/facebook/react-native/pull/14563
Differential Revision: D5278796
Pulled By: sahrens
fbshipit-source-id: 5db117b40909ec4bc92fba9b5556c6a2add046ac
Summary:
This uses `context` to render inner lists of the same orientation to a plain `View` without
virtualization instead of rendering nested `ScrollView`s trying to scroll in the same direction,
which can cause problems.
Reviewed By: bvaughn
Differential Revision: D5174942
fbshipit-source-id: 989150294098de837b0ffb401c7f5679a3928a03
Summary:
This is necessary to fix an extraneous warning when a VirtualizedList is constructed on the first frame.
On the first frame, the dt is huge (ie, time since epoch).
On the second frame (which may legitimately be slow as a result of a lot to render), it will then assume there were two consecutive slow frames, and print a warning:
"VirtualizedList: You have a large list that is slow to update..."
Closes https://github.com/facebook/react-native/pull/14393
Differential Revision: D5210467
Pulled By: sahrens
fbshipit-source-id: 2e79218c3d66a4a9df4884f328a125047ef264ed
Summary: Optimize ScrollView by adding flag "DEPRECATED_sendUpdatedChildFrames" to gate whether updatedChildFrames data is computed and propagated on scroll events. The frame data is used in ListView by the onChangeVisibleRows prop. When this prop is not defined, unnecessary computation in ScrollView should not be performed.
Reviewed By: sahrens
Differential Revision: D5174898
fbshipit-source-id: e3eaed8760b76becf14dfeb00122bdebdaeae4ef
Summary:
Flashing scroll indicators is a standard behavior on iOS to show the user there's more content.
Launch RNTester on iOS, go to the ScrollView section, tap the "Flash scroll indicators" button.
You'll see this:
I've exposed the method `flashScrollIndicators` on all scrolling components that were already exposing a `scrollToXXX` method so it's usable from those components using a ref.
Let me know what you think.
Closes https://github.com/facebook/react-native/pull/14058
Differential Revision: D5103239
Pulled By: shergin
fbshipit-source-id: caad8474fbe475065418d771b17e4ea9766ffcdc
Summary:
I expanded the documentation of the scrollToOffset method a bit in FlatList
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.
The documentation of the scrollToOffset method in FlatList was a bit confusing. Also, there was no documentation for this method on VirtualizedList. I added the doc block there and linked to it from the FlatList doc block.
Please check if the link on the FlatList scrollToOffset method links to the scrollToOffset method of the VirtualizedList docs page.
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/14317
Differential Revision: D5192378
Pulled By: hramos
fbshipit-source-id: 6131a8e5adb2a2f7cb84344541f4f8b999a232d2
Summary:
When ListViews has multiple sections, then rowIDs are required to be unique per section.
However the ListViewMock required rowIDs to be unique per whole list.
This change fixes the limitation of ListViewMock.
Closes https://github.com/facebook/react-native/pull/13642
Differential Revision: D5189675
Pulled By: shergin
fbshipit-source-id: 8a4fb68feb74af3307407d6d70f3f6642f50452a
Summary:
minor spelling error fix
Thanks for submitting a PR! Please read these instructions carefully:
- [ Found this small spelling error while reading thought of reporting it ] Explain the **motivation** for making this change.
- [ Test not required ] 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/14273
Differential Revision: D5160964
Pulled By: hramos
fbshipit-source-id: 3142cc511476e8b494576b8e31faf43eb97b40c5
Summary:
Fixes https://github.com/facebook/react-native/issues/13784
The section footer was only rendered with the last item of the section. However, that meant in sections where no items were rendered, no section footer would be rendered. This patch makes sure that when there are no items the section footer is rendered with the section header in addition to adding tests asserting the existance of section footers in empty lists.
One potential point of contention is whether or not a section separator (as defined by the `SectionSeparatorComponent` prop to `<SectionList>`) should be rendered in an empty list. I did not include a section separator for empty lists, but let me know if you think one should be included. See the test plan below for an image of an empty section rendered without a section separator.
I was also running into a lint error, `no-alert`, in `SectionListExample.js` around line 135 that blocked me from publishing. This error looks to be triggered when the `alert()` global function is called, so to fix the error I added an import for the `Alert` module and called the `alert()` function on that module.
To help debug the `scrollToLocation()` behavior that was modified as a part of this PR I added three buttons (can be seen in the test plan image) which scroll to arbitrary points in the list.
Reviewed By: sahrens
Differential Revision: D5084095
fbshipit-source-id: 4c98bebc1c3f1ceaa5a634fa144685d83d1072df
Summary:
This is a simple bugfix. `_updateViewableItems` expects the `data` prop, as it calls `getItemCount` on it. Without this, `onViewableItemsChanged` updates twice for each scroll position, once from `_onScroll` with the incorrect results, and once from `_updateCellsToRender` with the correct results. This means the callback nigh-on unusable.
I simply logged the results of `onViewableItemsChanged` and made sure they were correct.
Closes https://github.com/facebook/react-native/pull/14162
Differential Revision: D5128363
Pulled By: sahrens
fbshipit-source-id: 3faef812068921a26ed871339da79870fd0d911c
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:
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: 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
Vince Oppedisano
Spencer Ahrens
Caleb Meredith
Eli White
Oleg Lokhvitsky
Gant Laborde
glevi@fb.com
Luy Tran
Tim Wang
Garrett McCullough
JSON Deppen
Tomas Reimers
Dean G
Maarten Schumacher
Seth Fitzsimmons
superyarik
Spencer Ahrens
Christopher Chedeau
Mike Lambert
Jan Söndermann
zongwan
Janic Duplessis
Rene Weber
Taylor Kline
James Burnett
Kexi Long
John O'Leary
Jean Regisser
Jakob Kerkhove
Tomasz Szajna
Cherag Verma
ashoat
Xinbo Wang
Gabe Levi
liushigit
Louis Lagrange
Jeff Case
