Repository navigation
Description
Is this a bug report?
Yes
Have you read the Contributing Guidelines?
Yes
Environment
Environment:
OS: macOS Sierra 10.12.6
Node: 6.9.4
Yarn: 0.19.1
npm: 3.10.10
Watchman: 4.7.0
Xcode: Xcode 9.0 Build version 9A235
Android Studio: 2.3 AI-162.4069837
Packages: (wanted => installed)
react: 16.0.0-beta.5 => 16.0.0-beta.5
react-native: 0.49.5 => 0.49.5
Target Platform: iOS (10.3) (any though)
Steps to Reproduce
- Add a Flatlist component
- Add a
ListHeaderComponentof any length - use
onViewableItemsChangedto track viewable rows in local state - That's it, the calculations will be off by the header height.
Expected Behavior
onViewableItemsChanged fires at the correct time
(Write what you thought would happen.)
Actual Behavior
calculations for onViewableItemsChanged are always off by the length of the header.
(Write what happened. Add screenshots!)
Reproducible Demo
- Example repo: https://github.com/shakyShane/flatlist-bug (from react-native init, it's a single file)
- Snack https://snack.expo.io/HJz_uaS0b
- gif
Flatlist Bug with ListHeaderComponent
Flatlist exposes onViewableItemsChanged - which can be used to determine which elements are currently
visible within a list. This works correctly.
If a ListHeaderComponent is also given, the calculations used for determining which items are in view
will be incorrect - by exactly the height of the header.
in Libraries/Lists/VirtualizedList.js, this._headerLength is initialised as 0 and then updated on render
to store the length of the header dynamically, but then this value is not used anywhere else.
Calculations need to account for the 'length' of the Header component
We found the easiest way was to subtract the this._headerLength from the offset calculation, such as
_selectOffset(metrics: {x: number, y: number}): number {
- return !this.props.horizontal ? metrics.y : metrics.x;
+ return (!this.props.horizontal ? metrics.y : metrics.x) - this._headerLength;
}
Activity
shakyShane commentedon Oct 31, 2017
Sorry I forgot to mention it affects android too
stale commentedon Dec 30, 2017
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.
fix: account for length when calculating offset in VirtualizedList - f…
fix: account for `ListHeaderComponent` length when calculating offset…
esprehn commentedon Apr 17, 2018
Is it possible to land this? That bug is still there.
fix: account for `ListHeaderComponent` length when calculating offset… (