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.
When copy pasting the SectionList, got an error with a non closing JSX tag
What existing problem does the pull request solve?
Closing the JSX tag in 2 files
no test required
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.
Closes https://github.com/facebook/react-native/pull/13525
Differential Revision: D4908495
Pulled By: javache
fbshipit-source-id: f2dc49c9238d1da8906f7daf144429a57ad725a3
Summary:
**Bug Description**
The FlatList component receives content items via the data prop, and renders an initial number of items on the app's view. When a user scrolls to the end of the list, the component will append and render more available items at the end of the list. There was a bug where when the content was filtered, there were more available items but the component did not append/render them. This is due to the current appending/rendering logic in VirtualizedList, which does not account for data changes as a condition for updating/rendering. VirtualizedList is a dependency of FlatList, so this issue affects FlatList as well.
**Approach to Fixing Bug**
(i) Reproduce bug on iOS view of FlatList.
(ii) For VirtualizedList component:
# Isolate onEndReached function that appends more data to component UI.
# Isolate _onContentSizeChange function that is called when list content changes.
# Write snapshot tests using jest, based off existing test for FlatList.
# Refactor logic to append more data to list into _maybeCallOnEndReached function.
# Call _maybeCallOnEndReached in both _onContentSizeChange and _onScroll.
(iii) Run snapshot tests and observe jest output.
(iv) Bring up iOS view of FlatList and check that component now renders more items when content is filtered.
Many thanks to sahrens for guidance in developing this code!
Reviewed By: sahrens
Differential Revision: D4877388
fbshipit-source-id: c10c9eef1912f491450a62b81a9bc41f7f784203
Summary:
It's just causing problems (e.g. when combined with transform animations like those used
in some navigators) and hopefully it's not necessary with JS-side windowing. If people need the
perf, they can turn it on themselves.
Should fix https://github.com/facebook/react-native/issues/13316 and related issues.
Reviewed By: achen1
Differential Revision: D4884147
fbshipit-source-id: 95c82448581076c0d0b2c80b1cd80cc294898174
Summary:
A nice bit of polish for apps is to update the separators between list items
when press actives the highlight (things get especially noticeable/ugly when
the separators are not full width and don't adjust). This can be difficult to
coordinate and update efficiently, so we bake the functionality into
`VirtualizedList`.
The approach taken here is a little different from `ListView`. We pass a new
`separators` object with `renderItem` that has easy-to-use callbacks for toggling
the 'highlighted' prop on both adjacent separators - they can be wired up
directly to the `onShow/HideUnderlay` props of `TouchableHighlight` (pit of
success and all that - we want those RN apps to be polished!), but we also
provide a more generic `separators.updateProps` method to set any custom
props. This also passes in `leadingItem` so more custom wiring can be done on
initial render (e.g. linking the highlight state with `Animated`).
This also moves the separator rendering into the `CellRenderer`. I think this might
also fix some subtle measurement bugs with the `onLayout` not capturing the
height of the separator, so that's nice too, but the main reason is to have
an easy place to store the state so we don't have to re-render the entire list
like `ListView` does. Instead we track references to the cells and call update
only on the two we care about so the feedback is instantaneous even with big,
heavy lists.
This diff also messes with a bunch of flow and updates the example to be more
like a standard list.
`SectionList` support is coming in a stacked diff.
**TestPlan**
Video demo:
https://youtu.be/uFE7qGA0mg4
Pretty sure this is backwards compatible....
Reviewed By: thechefchen
Differential Revision: D4833557
fbshipit-source-id: 685af46243ba13246bf280dae8a4223381ce8cea
Summary: It can be much more convenient instead of binding and setting `extraData` or what-not.
Reviewed By: blairvanderhoof
Differential Revision: D4829165
fbshipit-source-id: bb781fedc831059e7b5065ea4357955aed79beda
Summary:
If tracking is enabled and the sampling check passes on a scroll or layout event,
we compare the scroll offset to the layout of the rendered items. If the items don't cover
the visible area of the list, we fire an `onFillRateExceeded` call with relevant stats for
logging the event through an analytics pipeline.
The measurement methodology is a little jank because everything is async, but it seems directionally
useful for getting ballpark numbers, catching regressions, and tracking improvements.
Benchmark testing shows a ~2014 MotoX starts hitting the fill rate limit at about 2500 px / sec,
which is pretty fast scrolling.
This also reworks our frame rate stuff so we can use a shared `SceneTracking` thing and track blankness
globally.
Reviewed By: bvaughn
Differential Revision: D4806867
fbshipit-source-id: 119bf177463c8c3aa51fa13d1a9d03b1a96042aa
Summary:
This fixes the website build because docgen was unable to parse this `*`
Closes https://github.com/facebook/react-native/pull/13300
Differential Revision: D4828837
Pulled By: ericvicenti
fbshipit-source-id: 7ebc04241742f7bb5a871e7e438fb23af90a70bd
Summary:
Basic functionality that takes `itemIndex` and `sectionIndex`
**TestPlan**
Added this to onChangeText:
this._listRef.getNode().scrollToLocation({itemIndex: 6, sectionIndex: 3, viewOffset: 25});
and saw it scroll to the correct position right under the sticky header.
Reviewed By: bvaughn
Differential Revision: D4821714
fbshipit-source-id: 261e373f9c4af384db5a363df5b0fd9274b1bdfe
Summary:
so users can call `setNativeProps` and do more compositing.
**Test Plan:**
Added this to `onPress` of `SectionListExample` and `FlatListExample`:
this._listRef.getNode().getScrollResponder().setNativeProps({scrollEnabled: false});
and saw scroll get disabled. Note the call to `getNode` because we are using the `Animated.createComponent` wrapper.
Reviewed By: achen1, bvaughn
Differential Revision: D4821711
fbshipit-source-id: 8d1f3dd7ccc646524f154721c5c7036620d57132
Summary:
Should key separators with their cells.
**Test Plan**
before/after in this video: https://youtu.be/vid1w5x8-58
Reviewed By: achen1
Differential Revision: D4821708
fbshipit-source-id: 261f1bac34dfa9001297a24a44f11128f338e62b
Summary: it's possible to update data and not have the content length change, which could prevent onEndReached from ever firing again, so fix that.
Reviewed By: bvaughn, yungsters
Differential Revision: D4783818
fbshipit-source-id: ec4640f4b8cf820165b045eaafee6fb41c0b0499
Van der Auwermeulen Grégoire
Tony Tan
Gabe Levi
Spencer Ahrens
Brian Vaughn
Naman Goel
Tim Yung
Eric Vicenti