react-native/Libraries/Lists/VirtualizedList.js

906 lines
33 KiB
JavaScript
Raw Normal View History

Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
/**
* Copyright (c) 2015-present, Facebook, Inc.
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
* All rights reserved.
*
* This source code is licensed under the BSD-style license found in the
* LICENSE file in the root directory of this source tree. An additional grant
* of patent rights can be found in the PATENTS file in the same directory.
*
* @providesModule VirtualizedList
* @flow
*/
'use strict';
const Batchinator = require('Batchinator');
const FillRateHelper = require('FillRateHelper');
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const React = require('React');
const ReactNative = require('ReactNative');
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const RefreshControl = require('RefreshControl');
const ScrollView = require('ScrollView');
const View = require('View');
const ViewabilityHelper = require('ViewabilityHelper');
const infoLog = require('infoLog');
const invariant = require('fbjs/lib/invariant');
const {computeWindowedRenderLimits} = require('VirtualizeUtils');
import type {ViewabilityConfig, ViewToken} from 'ViewabilityHelper';
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
type Item = any;
Many improvements 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
2017-04-25 21:44:00 +00:00
type renderItemType = (info: any) => ?React.Element<any>;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
type RequiredProps = {
renderItem: renderItemType,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
/**
* The default accessor functions assume this is an Array<{key: string}> but you can override
* getItem, getItemCount, and keyExtractor to handle any type of index-based data.
*/
data?: any,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
};
type OptionalProps = {
/**
* `debug` will turn on extra logging and visual overlays to aid with debugging both usage and
* implementation, but with a significant perf hit.
*/
debug?: ?boolean,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
/**
* DEPRECATED: Virtualization provides significant performance and memory optimizations, but fully
* unmounts react instances that are outside of the render window. You should only need to disable
* this for debugging purposes.
*/
disableVirtualization: boolean,
/**
* A marker property for telling the list to re-render (since it implements `PureComponent`). If
* any of your `renderItem`, Header, Footer, etc. functions depend on anything outside of the
* `data` prop, stick it here and treat it immutably.
*/
extraData?: any,
/**
* A generic accessor for extracting an item from any sort of data blob.
*/
getItem: (data: any, index: number) => ?Item,
/**
* Determines how many items are in the data blob.
*/
getItemCount: (data: any) => number,
getItemLayout?: (data: any, index: number) =>
{length: number, offset: number, index: number}, // e.g. height, y
horizontal?: ?boolean,
/**
* How many items to render in the initial batch. This should be enough to fill the screen but not
* much more. Note these items will never be unmounted as part of the windowed rendering in order
* to improve perceived performance of scroll-to-top actions.
*/
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
initialNumToRender: number,
Many improvements 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
2017-04-25 21:44:00 +00:00
/**
* Instead of starting at the top with the first item, start at `initialScrollIndex`. This
* disables the "scroll to top" optimization that keeps the first `initialNumToRender` items
* always rendered and immediately renders the items starting at this initial index. Requires
* `getItemLayout` to be implemented.
*/
initialScrollIndex?: ?number,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
keyExtractor: (item: Item, index: number) => string,
/**
* The maximum number of items to render in each incremental render batch. The more rendered at
* once, the better the fill rate, but responsiveness my suffer because rendering content may
* interfere with responding to button taps or other interactions.
*/
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
maxToRenderPerBatch: number,
onEndReached?: ?(info: {distanceFromEnd: number}) => void,
onEndReachedThreshold?: ?number, // units of visible length
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
onLayout?: ?Function,
/**
* If provided, a standard RefreshControl will be added for "Pull to Refresh" functionality. Make
* sure to also set the `refreshing` prop correctly.
*/
onRefresh?: ?Function,
/**
* Called when the viewability of rows changes, as defined by the
* `viewabilityConfig` prop.
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
*/
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
onViewableItemsChanged?: ?(info: {
viewableItems: Array<ViewToken>,
changed: Array<ViewToken>,
}) => void,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
/**
* Set this true while waiting for new data from a refresh.
*/
refreshing?: ?boolean,
/**
* Note: may have bugs (missing content) in some circumstances - use at your own risk.
*
* This may improve scroll performance for large lists.
*/
removeClippedSubviews?: boolean,
/**
* Render a custom scroll component, e.g. with a differently styled `RefreshControl`.
*/
renderScrollComponent: (props: Object) => React.Element<any>,
/**
* Amount of time between low-pri item render batches, e.g. for rendering items quite a ways off
* screen. Similar fill rate/responsiveness tradeoff as `maxToRenderPerBatch`.
*/
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
updateCellsBatchingPeriod: number,
viewabilityConfig?: ViewabilityConfig,
/**
* Determines the maximum number of items rendered outside of the visible area, in units of
* visible lengths. So if your list fills the screen, then `windowSize={21}` (the default) will
* render the visible screen area plus up to 10 screens above and 10 below the viewport. Reducing
* this number will reduce memory consumption and may improve performance, but will increase the
* chance that fast scrolling may reveal momentary blank areas of unrendered content.
*/
windowSize: number,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
};
/* $FlowFixMe - this Props seems to be missing a bunch of stuff. Remove this
* comment to see the errors */
export type Props = RequiredProps & OptionalProps;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
let _usedIndexForKey = false;
type State = {first: number, last: number};
/**
* Base implementation for the more convenient [`<FlatList>`](/react-native/docs/flatlist.html)
* and [`<SectionList>`](/react-native/docs/sectionlist.html) components, which are also better
* documented. In general, this should only really be used if you need more flexibility than
* `FlatList` provides, e.g. for use with immutable data instead of plain arrays.
*
* Virtualization massively improves memory consumption and performance of large lists by
* maintaining a finite render window of active items and replacing all items outside of the render
* window with appropriately sized blank space. The window adapts to scrolling behavior, and items
* are rendered incrementally with low-pri (after any running interactions) if they are far from the
* visible area, or with hi-pri otherwise to minimize the potential of seeing blank space.
*
* Some caveats:
*
* - Internal state is not preserved when content scrolls out of the render window. Make sure all
* your data is captured in the item data or external stores like Flux, Redux, or Relay.
* - This is a `PureComponent` which means that it will not re-render if `props` remain shallow-
* equal. Make sure that everything your `renderItem` function depends on is passed as a prop
* (e.g. `extraData`) that is not `===` after updates, otherwise your UI may not update on
* changes. This includes the `data` prop and parent component state.
* - In order to constrain memory and enable smooth scrolling, content is rendered asynchronously
* offscreen. This means it's possible to scroll faster than the fill rate ands momentarily see
* blank content. This is a tradeoff that can be adjusted to suit the needs of each application,
* and we are working on improving it behind the scenes.
* - By default, the list looks for a `key` prop on each item and uses that for the React key.
* Alternatively, you can provide a custom `keyExtractor` prop.
*
*/
class VirtualizedList extends React.PureComponent<OptionalProps, Props, State> {
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
props: Props;
// scrollToEnd may be janky without getItemLayout prop
scrollToEnd(params?: ?{animated?: ?boolean}) {
const animated = params ? params.animated : true;
const veryLast = this.props.getItemCount(this.props.data) - 1;
const frame = this._getFrameMetricsApprox(veryLast);
const offset = frame.offset + frame.length + this._footerLength -
this._scrollMetrics.visibleLength;
this._scrollRef.scrollTo(
this.props.horizontal ? {x: offset, animated} : {y: offset, animated}
);
}
// scrollToIndex may be janky without getItemLayout prop
scrollToIndex(params: {
animated?: ?boolean, index: number, viewOffset?: number, viewPosition?: number
}) {
const {data, horizontal, getItemCount, getItemLayout} = this.props;
const {animated, index, viewOffset, viewPosition} = params;
invariant(
index >= 0 && index < getItemCount(data),
`scrollToIndex out of range: ${index} vs ${getItemCount(data) - 1}`,
);
invariant(
getItemLayout || index < this._highestMeasuredFrameIndex,
'scrollToIndex should be used in conjunction with getItemLayout, ' +
'otherwise there is no way to know the location of an arbitrary index.',
);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const frame = this._getFrameMetricsApprox(index);
const offset = Math.max(
0,
frame.offset - (viewPosition || 0) * (this._scrollMetrics.visibleLength - frame.length),
) - (viewOffset || 0);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
this._scrollRef.scrollTo(horizontal ? {x: offset, animated} : {y: offset, animated});
}
// scrollToItem may be janky without getItemLayout prop. Required linear scan through items -
// use scrollToIndex instead if possible.
scrollToItem(params: {animated?: ?boolean, item: Item, viewPosition?: number}) {
const {item} = params;
const {data, getItem, getItemCount} = this.props;
const itemCount = getItemCount(data);
for (let index = 0; index < itemCount; index++) {
if (getItem(data, index) === item) {
this.scrollToIndex({...params, index});
break;
}
}
}
scrollToOffset(params: {animated?: ?boolean, offset: number}) {
const {animated, offset} = params;
this._scrollRef.scrollTo(
this.props.horizontal ? {x: offset, animated} : {y: offset, animated}
);
}
recordInteraction() {
this._viewabilityHelper.recordInteraction();
this._updateViewableItems(this.props.data);
}
/**
* Provides a handle to the underlying scroll responder.
* Note that `this._scrollRef` might not be a `ScrollView`, so we
* need to check that it responds to `getScrollResponder` before calling it.
*/
getScrollResponder() {
if (this._scrollRef && this._scrollRef.getScrollResponder) {
return this._scrollRef.getScrollResponder();
}
}
getScrollableNode() {
if (this._scrollRef && this._scrollRef.getScrollableNode) {
return this._scrollRef.getScrollableNode();
} else {
return ReactNative.findNodeHandle(this._scrollRef);
}
}
static defaultProps = {
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
disableVirtualization: false,
getItem: (data: any, index: number) => data[index],
getItemCount: (data: any) => data ? data.length : 0,
horizontal: false,
initialNumToRender: 10,
keyExtractor: (item: Item, index: number) => {
if (item.key != null) {
return item.key;
}
_usedIndexForKey = true;
return String(index);
},
maxToRenderPerBatch: 10,
onEndReachedThreshold: 2, // multiples of length
renderScrollComponent: (props: Props) => {
if (props.onRefresh) {
invariant(
typeof props.refreshing === 'boolean',
'`refreshing` prop must be set as a boolean in order to use `onRefresh`, but got `' +
JSON.stringify(props.refreshing) + '`',
);
return (
<ScrollView
{...props}
refreshControl={
<RefreshControl
refreshing={props.refreshing}
onRefresh={props.onRefresh}
/>
}
/>
);
} else {
return <ScrollView {...props} />;
}
},
scrollEventThrottle: 50,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
updateCellsBatchingPeriod: 50,
windowSize: 21, // multiples of length
};
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
state: State;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
constructor(props: Props, context: Object) {
super(props, context);
invariant(
!props.onScroll || !props.onScroll.__isNative,
'Components based on VirtualizedList must be wrapped with Animated.createAnimatedComponent ' +
'to support native onScroll events with useNativeDriver',
);
this._fillRateHelper = new FillRateHelper(this._getFrameMetrics);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
this._updateCellsToRenderBatcher = new Batchinator(
this._updateCellsToRender,
this.props.updateCellsBatchingPeriod,
);
this._viewabilityHelper = new ViewabilityHelper(this.props.viewabilityConfig);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
this.state = {
Many improvements 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
2017-04-25 21:44:00 +00:00
first: this.props.initialScrollIndex || 0,
last: Math.min(
this.props.getItemCount(this.props.data),
(this.props.initialScrollIndex || 0) + this.props.initialNumToRender,
) - 1,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
};
}
Many improvements 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
2017-04-25 21:44:00 +00:00
componentDidMount() {
if (this.props.initialScrollIndex) {
this._initialScrollIndexTimeout = setTimeout(
() => this.scrollToIndex({animated: false, index: this.props.initialScrollIndex}),
0,
);
}
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
componentWillUnmount() {
this._updateViewableItems(null);
this._updateCellsToRenderBatcher.dispose();
this._viewabilityHelper.dispose();
Many improvements 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
2017-04-25 21:44:00 +00:00
this._fillRateHelper.deactivateAndFlush();
clearTimeout(this._initialScrollIndexTimeout);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
}
componentWillReceiveProps(newProps: Props) {
const {data, extraData, getItemCount, maxToRenderPerBatch} = newProps;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
// first and last could be stale (e.g. if a new, shorter items props is passed in), so we make
// sure we're rendering a reasonable range here.
this.setState({
first: Math.max(0, Math.min(this.state.first, getItemCount(data) - 1 - maxToRenderPerBatch)),
last: Math.max(0, Math.min(this.state.last, getItemCount(data) - 1)),
});
if (data !== this.props.data || extraData !== this.props.extraData) {
this._hasDataChangedSinceEndReached = true;
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
this._updateCellsToRenderBatcher.schedule();
}
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
_pushCells(
cells: Array<Object>,
stickyHeaderIndices: Array<number>,
stickyIndicesFromProps: Set<number>,
first: number,
last: number,
) {
const {ItemSeparatorComponent, data, getItem, getItemCount, keyExtractor} = this.props;
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
const stickyOffset = this.props.ListHeaderComponent ? 1 : 0;
const end = getItemCount(data) - 1;
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
let prevCellKey;
last = Math.min(end, last);
for (let ii = first; ii <= last; ii++) {
const item = getItem(data, ii);
invariant(item, 'No item for index ' + ii);
const key = keyExtractor(item, ii);
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
if (stickyIndicesFromProps.has(ii + stickyOffset)) {
stickyHeaderIndices.push(cells.length);
}
cells.push(
<CellRenderer
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
ItemSeparatorComponent={ii < end ? ItemSeparatorComponent : undefined}
Many improvements 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
2017-04-25 21:44:00 +00:00
cellKey={key}
fillRateHelper={this._fillRateHelper}
index={ii}
item={item}
key={key}
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
prevCellKey={prevCellKey}
onUpdateSeparators={this._onUpdateSeparators}
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
onLayout={(e) => this._onCellLayout(e, key, ii)}
onUnmount={this._onCellUnmount}
parentProps={this.props}
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
ref={(ref) => {this._cellRefs[key] = ref;}}
/>
);
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
prevCellKey = key;
}
}
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
_onUpdateSeparators = (keys: Array<?string>, newProps: Object) => {
keys.forEach((key) => {
const ref = key != null && this._cellRefs[key];
ref && ref.updateSeparatorProps(newProps);
});
};
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
render() {
const {ListFooterComponent, ListHeaderComponent} = this.props;
const {data, disableVirtualization, horizontal} = this.props;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const cells = [];
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
const stickyIndicesFromProps = new Set(this.props.stickyHeaderIndices);
const stickyHeaderIndices = [];
if (ListHeaderComponent) {
const element = React.isValidElement(ListHeaderComponent)
? ListHeaderComponent
: <ListHeaderComponent />;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
cells.push(
<View key="$header" onLayout={this._onLayoutHeader}>
{element}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
</View>
);
}
const itemCount = this.props.getItemCount(data);
if (itemCount > 0) {
_usedIndexForKey = false;
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
const spacerKey = !horizontal ? 'height' : 'width';
Many improvements 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
2017-04-25 21:44:00 +00:00
const lastInitialIndex = this.props.initialScrollIndex
? -1
: this.props.initialNumToRender - 1;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const {first, last} = this.state;
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
this._pushCells(cells, stickyHeaderIndices, stickyIndicesFromProps, 0, lastInitialIndex);
const firstAfterInitial = Math.max(lastInitialIndex + 1, first);
if (!disableVirtualization && first > lastInitialIndex + 1) {
let insertedStickySpacer = false;
if (stickyIndicesFromProps.size > 0) {
const stickyOffset = ListHeaderComponent ? 1 : 0;
// See if there are any sticky headers in the virtualized space that we need to render.
for (let ii = firstAfterInitial - 1; ii > lastInitialIndex; ii--) {
if (stickyIndicesFromProps.has(ii + stickyOffset)) {
const initBlock = this._getFrameMetricsApprox(lastInitialIndex);
const stickyBlock = this._getFrameMetricsApprox(ii);
const leadSpace = stickyBlock.offset - (initBlock.offset + initBlock.length);
cells.push(
<View key="$sticky_lead" style={{[spacerKey]: leadSpace}} />
);
this._pushCells(cells, stickyHeaderIndices, stickyIndicesFromProps, ii, ii);
const trailSpace = this._getFrameMetricsApprox(first).offset -
(stickyBlock.offset + stickyBlock.length);
cells.push(
<View key="$sticky_trail" style={{[spacerKey]: trailSpace}} />
);
insertedStickySpacer = true;
break;
}
}
}
if (!insertedStickySpacer) {
const initBlock = this._getFrameMetricsApprox(lastInitialIndex);
const firstSpace = this._getFrameMetricsApprox(first).offset -
(initBlock.offset + initBlock.length);
cells.push(
<View key="$lead_spacer" style={{[spacerKey]: firstSpace}} />
);
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
}
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
this._pushCells(cells, stickyHeaderIndices, stickyIndicesFromProps, firstAfterInitial, last);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
if (!this._hasWarned.keys && _usedIndexForKey) {
console.warn(
'VirtualizedList: missing keys for items, make sure to specify a key property on each ' +
'item or provide a custom keyExtractor.'
);
this._hasWarned.keys = true;
}
if (!disableVirtualization && last < itemCount - 1) {
const lastFrame = this._getFrameMetricsApprox(last);
// Without getItemLayout, we limit our tail spacer to the _highestMeasuredFrameIndex to
// prevent the user for hyperscrolling into un-measured area because otherwise content will
// likely jump around as it renders in above the viewport.
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const end = this.props.getItemLayout ?
itemCount - 1 :
Math.min(itemCount - 1, this._highestMeasuredFrameIndex);
const endFrame = this._getFrameMetricsApprox(end);
const tailSpacerLength =
(endFrame.offset + endFrame.length) -
(lastFrame.offset + lastFrame.length);
cells.push(
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
<View key="$tail_spacer" style={{[spacerKey]: tailSpacerLength}} />
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
);
}
}
if (ListFooterComponent) {
const element = React.isValidElement(ListFooterComponent)
? ListFooterComponent
: <ListFooterComponent />;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
cells.push(
<View key="$footer" onLayout={this._onLayoutFooter}>
{element}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
</View>
);
}
const ret = React.cloneElement(
this.props.renderScrollComponent(this.props),
{
onContentSizeChange: this._onContentSizeChange,
onLayout: this._onLayout,
onScroll: this._onScroll,
onScrollBeginDrag: this._onScrollBeginDrag,
Many improvements 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
2017-04-25 21:44:00 +00:00
onScrollEndDrag: this._onScrollEndDrag,
onMomentumScrollEnd: this._onMomentumScrollEnd,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
ref: this._captureScrollRef,
scrollEventThrottle: this.props.scrollEventThrottle, // TODO: Android support
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
stickyHeaderIndices,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
},
cells,
);
if (this.props.debug) {
return <View style={{flex: 1}}>{ret}{this._renderDebugOverlay()}</View>;
} else {
return ret;
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
}
componentDidUpdate() {
this._updateCellsToRenderBatcher.schedule();
}
_averageCellLength = 0;
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
_cellRefs = {};
_hasDataChangedSinceEndReached = true;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_hasWarned = {};
_highestMeasuredFrameIndex = 0;
_headerLength = 0;
Many improvements 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
2017-04-25 21:44:00 +00:00
_initialScrollIndexTimeout = 0;
_fillRateHelper: FillRateHelper;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_frames = {};
_footerLength = 0;
_scrollMetrics = {
Many improvements 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
2017-04-25 21:44:00 +00:00
contentLength: 0, dOffset: 0, dt: 10, offset: 0, timestamp: 0, velocity: 0, visibleLength: 0,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
};
_scrollRef = (null: any);
_sentEndForContentLength = 0;
_totalCellLength = 0;
_totalCellsMeasured = 0;
_updateCellsToRenderBatcher: Batchinator;
_viewabilityHelper: ViewabilityHelper;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_captureScrollRef = (ref) => {
this._scrollRef = ref;
};
Many improvements 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
2017-04-25 21:44:00 +00:00
_computeBlankness() {
this._fillRateHelper.computeBlankness(
this.props,
this.state,
this._scrollMetrics,
);
}
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
_onCellLayout(e, cellKey, index) {
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const layout = e.nativeEvent.layout;
const next = {
offset: this._selectOffset(layout),
length: this._selectLength(layout),
index,
inLayout: true,
};
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const curr = this._frames[cellKey];
if (!curr ||
next.offset !== curr.offset ||
next.length !== curr.length ||
index !== curr.index
) {
this._totalCellLength += next.length - (curr ? curr.length : 0);
this._totalCellsMeasured += (curr ? 0 : 1);
this._averageCellLength = this._totalCellLength / this._totalCellsMeasured;
this._frames[cellKey] = next;
this._highestMeasuredFrameIndex = Math.max(this._highestMeasuredFrameIndex, index);
this._updateCellsToRenderBatcher.schedule();
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
} else {
this._frames[cellKey].inLayout = true;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
}
Many improvements 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
2017-04-25 21:44:00 +00:00
this._computeBlankness();
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_onCellUnmount = (cellKey: string) => {
const curr = this._frames[cellKey];
if (curr) {
this._frames[cellKey] = {...curr, inLayout: false};
}
};
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_onLayout = (e: Object) => {
this._scrollMetrics.visibleLength = this._selectLength(e.nativeEvent.layout);
this.props.onLayout && this.props.onLayout(e);
this._updateCellsToRenderBatcher.schedule();
};
_onLayoutFooter = (e) => {
this._footerLength = this._selectLength(e.nativeEvent.layout);
};
_onLayoutHeader = (e) => {
this._headerLength = this._selectLength(e.nativeEvent.layout);
};
_renderDebugOverlay() {
const normalize = this._scrollMetrics.visibleLength / this._scrollMetrics.contentLength;
const framesInLayout = [];
const itemCount = this.props.getItemCount(this.props.data);
for (let ii = 0; ii < itemCount; ii++) {
const frame = this._getFrameMetricsApprox(ii);
if (frame.inLayout) {
framesInLayout.push(frame);
}
}
const windowTop = this._getFrameMetricsApprox(this.state.first).offset;
const frameLast = this._getFrameMetricsApprox(this.state.last);
const windowLen = frameLast.offset + frameLast.length - windowTop;
const visTop = this._scrollMetrics.offset;
const visLen = this._scrollMetrics.visibleLength;
const baseStyle = {position: 'absolute', top: 0, right: 0};
return (
<View style={{...baseStyle, bottom: 0, width: 20, borderColor: 'blue', borderWidth: 1}}>
{framesInLayout.map((f, ii) =>
<View key={'f' + ii} style={{
...baseStyle,
left: 0,
top: f.offset * normalize,
height: f.length * normalize,
backgroundColor: 'orange',
}} />
)}
<View style={{
...baseStyle,
left: 0,
top: windowTop * normalize,
height: windowLen * normalize,
borderColor: 'green',
borderWidth: 2,
}} />
<View style={{
...baseStyle,
left: 0,
top: visTop * normalize,
height: visLen * normalize,
borderColor: 'red',
borderWidth: 2,
}} />
</View>
);
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_selectLength(metrics: {height: number, width: number}): number {
return !this.props.horizontal ? metrics.height : metrics.width;
}
_selectOffset(metrics: {x: number, y: number}): number {
return !this.props.horizontal ? metrics.y : metrics.x;
}
Fix bug - FlatList component did not render more items when content was filtered 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
2017-04-18 01:10:39 +00:00
_maybeCallOnEndReached() {
const {data, getItemCount, onEndReached, onEndReachedThreshold} = this.props;
const {contentLength, visibleLength, offset} = this._scrollMetrics;
const distanceFromEnd = contentLength - visibleLength - offset;
if (onEndReached &&
this.state.last === getItemCount(data) - 1 &&
distanceFromEnd < onEndReachedThreshold * visibleLength &&
(this._hasDataChangedSinceEndReached ||
this._scrollMetrics.contentLength !== this._sentEndForContentLength)) {
// Only call onEndReached once for a given dataset + content length.
this._hasDataChangedSinceEndReached = false;
this._sentEndForContentLength = this._scrollMetrics.contentLength;
onEndReached({distanceFromEnd});
}
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_onContentSizeChange = (width: number, height: number) => {
if (this.props.onContentSizeChange) {
this.props.onContentSizeChange(width, height);
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
this._scrollMetrics.contentLength = this._selectLength({height, width});
this._updateCellsToRenderBatcher.schedule();
Fix bug - FlatList component did not render more items when content was filtered 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
2017-04-18 01:10:39 +00:00
this._maybeCallOnEndReached();
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
};
_onScroll = (e: Object) => {
if (this.props.onScroll) {
this.props.onScroll(e);
}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const timestamp = e.timeStamp;
const visibleLength = this._selectLength(e.nativeEvent.layoutMeasurement);
const contentLength = this._selectLength(e.nativeEvent.contentSize);
const offset = this._selectOffset(e.nativeEvent.contentOffset);
const dt = Math.max(1, timestamp - this._scrollMetrics.timestamp);
if (dt > 500 && this._scrollMetrics.dt > 500 && (contentLength > (5 * visibleLength)) &&
!this._hasWarned.perf) {
infoLog(
'VirtualizedList: You have a large list that is slow to update - make sure your ' +
'renderItem function renders components that follow React performance best practices ' +
'like PureComponent, shouldComponentUpdate, etc.',
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
{dt, prevDt: this._scrollMetrics.dt, contentLength},
);
this._hasWarned.perf = true;
}
const dOffset = offset - this._scrollMetrics.offset;
const velocity = dOffset / dt;
Many improvements 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
2017-04-25 21:44:00 +00:00
this._scrollMetrics = {contentLength, dt, dOffset, offset, timestamp, velocity, visibleLength};
Fix bug - FlatList component did not render more items when content was filtered 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
2017-04-18 01:10:39 +00:00
const {data, getItemCount, windowSize} = this.props;
this._updateViewableItems(data);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
if (!data) {
return;
}
Fix bug - FlatList component did not render more items when content was filtered 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
2017-04-18 01:10:39 +00:00
this._maybeCallOnEndReached();
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const {first, last} = this.state;
Many improvements 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
2017-04-25 21:44:00 +00:00
if (velocity !== 0) {
this._fillRateHelper.activate();
}
this._computeBlankness();
Fix bug - FlatList component did not render more items when content was filtered 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
2017-04-18 01:10:39 +00:00
const itemCount = getItemCount(data);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
if ((first > 0 && velocity < 0) || (last < itemCount - 1 && velocity > 0)) {
const distanceToContentEdge = Math.min(
Math.abs(this._getFrameMetricsApprox(first).offset - offset),
Math.abs(this._getFrameMetricsApprox(last).offset - (offset + visibleLength)),
);
const hiPri = distanceToContentEdge < (windowSize * visibleLength / 4);
if (hiPri) {
// Don't worry about interactions when scrolling quickly; focus on filling content as fast
// as possible.
this._updateCellsToRenderBatcher.dispose({abort: true});
this._updateCellsToRender();
return;
}
}
this._updateCellsToRenderBatcher.schedule();
};
_onScrollBeginDrag = (e): void => {
this._viewabilityHelper.recordInteraction();
this.props.onScrollBeginDrag && this.props.onScrollBeginDrag(e);
};
Many improvements 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
2017-04-25 21:44:00 +00:00
_onScrollEndDrag = (e): void => {
const {velocity} = e.nativeEvent;
if (velocity) {
this._scrollMetrics.velocity = this._selectOffset(velocity);
}
this._computeBlankness();
this.props.onScrollEndDrag && this.props.onScrollEndDrag(e);
};
_onMomentumScrollEnd = (e): void => {
this._scrollMetrics.velocity = 0;
this._computeBlankness();
this.props.onMomentumScrollEnd && this.props.onMomentumScrollEnd(e);
};
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_updateCellsToRender = () => {
const {data, disableVirtualization, getItemCount, onEndReachedThreshold} = this.props;
this._updateViewableItems(data);
if (!data) {
return;
}
this.setState((state) => {
let newState;
if (!disableVirtualization) {
newState = computeWindowedRenderLimits(
this.props, state, this._getFrameMetricsApprox, this._scrollMetrics,
);
} else {
const {contentLength, offset, visibleLength} = this._scrollMetrics;
const distanceFromEnd = contentLength - visibleLength - offset;
const renderAhead = distanceFromEnd < onEndReachedThreshold * visibleLength ?
this.props.maxToRenderPerBatch : 0;
newState = {
first: 0,
last: Math.min(state.last + renderAhead, getItemCount(data) - 1),
};
}
return newState;
});
};
_createViewToken = (index: number, isViewable: boolean) => {
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const {data, getItem, keyExtractor} = this.props;
const item = getItem(data, index);
invariant(item, 'Missing item for index ' + index);
return {index, item, key: keyExtractor(item, index), isViewable};
};
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
_getFrameMetricsApprox = (index: number): {length: number, offset: number} => {
const frame = this._getFrameMetrics(index);
if (frame && frame.index === index) { // check for invalid frames due to row re-ordering
return frame;
} else {
const {getItemLayout} = this.props;
invariant(
!getItemLayout,
'Should not have to estimate frames when a measurement metrics function is provided'
);
return {
length: this._averageCellLength,
offset: this._averageCellLength * index,
};
}
};
_getFrameMetrics = (index: number): ?{
length: number, offset: number, index: number, inLayout?: boolean,
} => {
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
const {data, getItem, getItemCount, getItemLayout, keyExtractor} = this.props;
invariant(getItemCount(data) > index, 'Tried to get frame for out of range index ' + index);
const item = getItem(data, index);
let frame = item && this._frames[keyExtractor(item, index)];
if (!frame || frame.index !== index) {
if (getItemLayout) {
frame = getItemLayout(data, index);
}
}
return frame;
};
_updateViewableItems(data: any) {
const {getItemCount, onViewableItemsChanged} = this.props;
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
if (!onViewableItemsChanged) {
return;
}
this._viewabilityHelper.onUpdate(
getItemCount(data),
this._scrollMetrics.offset,
this._scrollMetrics.visibleLength,
this._getFrameMetrics,
this._createViewToken,
onViewableItemsChanged,
this.state,
);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
}
}
class CellRenderer extends React.Component {
props: {
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
ItemSeparatorComponent: ?ReactClass<*>,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
cellKey: string,
Many improvements 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
2017-04-25 21:44:00 +00:00
fillRateHelper: FillRateHelper,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
index: number,
item: Item,
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
onLayout: (event: Object) => void, // This is extracted by ScrollViewStickyHeader
onUnmount: (cellKey: string) => void,
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
onUpdateSeparators: (cellKeys: Array<?string>, props: Object) => void,
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
parentProps: {
getItemLayout?: ?Function,
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
renderItem: renderItemType,
},
prevCellKey: ?string,
};
state = {
separatorProps: {
highlighted: false,
leadingItem: this.props.item,
},
};
// TODO: consider factoring separator stuff out of VirtualizedList into FlatList since it's not
// reused by SectionList and we can keep VirtualizedList simpler.
_separators = {
highlight: () => {
const {cellKey, prevCellKey} = this.props;
this.props.onUpdateSeparators([cellKey, prevCellKey], {highlighted: true});
},
unhighlight: () => {
const {cellKey, prevCellKey} = this.props;
this.props.onUpdateSeparators([cellKey, prevCellKey], {highlighted: false});
},
updateProps: (select: 'leading' | 'trailing', newProps: Object) => {
const {cellKey, prevCellKey} = this.props;
this.props.onUpdateSeparators([select === 'leading' ? prevCellKey : cellKey], newProps);
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
},
};
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
updateSeparatorProps(newProps: Object) {
this.setState(state => ({separatorProps: {...state.separatorProps, ...newProps}}));
}
componentWillUnmount() {
this.props.onUnmount(this.props.cellKey);
}
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
render() {
Many improvements 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
2017-04-25 21:44:00 +00:00
const {ItemSeparatorComponent, fillRateHelper, item, index, parentProps} = this.props;
const {renderItem, getItemLayout} = parentProps;
invariant(renderItem, 'no renderItem!');
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
const element = renderItem({
item,
index,
separators: this._separators,
});
Many improvements 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
2017-04-25 21:44:00 +00:00
const onLayout = (getItemLayout && !parentProps.debug && !fillRateHelper.enabled())
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
? undefined
: this.props.onLayout;
support sticky headers Summary: This adds support for both automagical sticky section headers in `SectionList` as well as the more free-form `stickyHeaderIndices` on `FlatList` or `VirtualizedList`. The basic concept is to take the initial `stickySectionHeaders` and remap them to the indices corresponding to the mounted subset in the render window. The main trick here is that the currently stuck header might itself be outside of the render window, so we need to search the gap to see if that's the case and render it (with spacers above and below it instead of one big spacer). In the `SectionList` we simply pre-compute the sticky headers at the same time as when we scan the sections to determine the flattened length and pass those to `VirtualizedList`. This also requires some updates to `ScrollView` to work in the churny environment of `VirtualizedList`. We propogate the keys on the children to the animated wrappers so that as items are removed and the indices of the remaining items change, react can keep proper track of them. We also fix the scroll back case where new headers are rendered from the top down and aren't updated with the `setNextLayoutY` callback because the `onLayout` call for the next header happened before it was mounted. This is done by just tracking all the layout values in a map and providing them to the sticky components at render time. This might also improve perf a little by property configuring the animations syncronously instead of waiting for the `onLayout` callback. We also need to protect against stale onLayout callbacks and other fun stuff. == Test Plan == https://www.facebook.com/groups/react.native.community/permalink/940332509435661/ Scroll a lot with and without debug mode on. Make sure spinner still spins and there are no crashes (lots of crashes during development due to the animated configuration being non-monotonic if anything stale values get through). Also made sure that tapping a row to change it's height would properly update the animation configurations so the collision point would still be correct. Reviewed By: yungsters Differential Revision: D4695065 fbshipit-source-id: 855c4e31c8f8b450d32150dbdb2e07f1a9f9f98e
2017-03-22 05:19:03 +00:00
// NOTE: that when this is a sticky header, `onLayout` will get automatically extracted and
// called explicitly by `ScrollViewStickyHeader`.
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
return (
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
<View onLayout={onLayout}>
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
{element}
Add support for updating adjacent separators on row highlight to FlatList 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
2017-04-12 23:57:04 +00:00
{ItemSeparatorComponent && <ItemSeparatorComponent {...this.state.separatorProps} />}
Better ListView - FlatList Summary: We really need a better list view - so here it is! Main changes from existing `ListView`: * Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window. * No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible. * Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`. * Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props. * Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive. * Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>` * Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior. * Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable. Demo: https://www.facebook.com/groups/576288835853049/permalink/753923058089625/ Reviewed By: yungsters Differential Revision: D4412469 fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
2017-02-04 18:25:32 +00:00
</View>
);
}
}
module.exports = VirtualizedList;