react-native/Libraries/Lists/SectionList.js

313 lines
11 KiB
JavaScript
Raw Normal View History

/**
* Copyright (c) 2015-present, Facebook, Inc.
* 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 SectionList
* @flow
*/
'use strict';
const MetroListView = require('MetroListView');
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 Platform = require('Platform');
const React = require('React');
const VirtualizedSectionList = require('VirtualizedSectionList');
import type {ViewToken} from 'ViewabilityHelper';
import type {Props as VirtualizedSectionListProps} from 'VirtualizedSectionList';
type Item = any;
type SectionBase<SectionItemT> = {
/**
* The data for rendering items in this section.
*/
data: $ReadOnlyArray<SectionItemT>,
/**
* Optional key to keep track of section re-ordering. If you don't plan on re-ordering sections,
* the array index will be used by default.
*/
key?: string,
// Optional props will override list-wide props just for this section.
renderItem?: ?(info: {
item: SectionItemT,
index: 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
section: SectionBase<SectionItemT>,
separators: {
highlight: () => void,
unhighlight: () => void,
updateProps: (select: 'leading' | 'trailing', newProps: Object) => void,
},
}) => ?React.Element<any>,
ItemSeparatorComponent?: ?ReactClass<any>,
keyExtractor?: (item: SectionItemT) => string,
// TODO: support more optional/override 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
// onViewableItemsChanged?: ...
};
type RequiredProps<SectionT: SectionBase<any>> = {
/**
* The actual data to render, akin to the `data` prop in [`<FlatList>`](/react-native/docs/flatlist.html).
*
* General shape:
*
* sections: $ReadOnlyArray<{
* data: $ReadOnlyArray<SectionItem>,
* renderItem?: ({item: SectionItem, ...}) => ?React.Element<*>,
* ItemSeparatorComponent?: ?ReactClass<{highlighted: boolean, ...}>,
* }>
*/
sections: $ReadOnlyArray<SectionT>,
};
type OptionalProps<SectionT: SectionBase<any>> = {
/**
* Default renderer for every item in every section. Can be over-ridden on a per-section basis.
*/
renderItem: (info: {
item: Item,
index: 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
section: SectionT,
separators: {
highlight: () => void,
unhighlight: () => void,
updateProps: (select: 'leading' | 'trailing', newProps: Object) => void,
},
}) => ?React.Element<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
* Rendered in between each item, but not at the top or bottom. By default, `highlighted`,
* `section`, and `[leading/trailing][Item/Separator]` props are provided. `renderItem` provides
* `separators.highlight`/`unhighlight` which will update the `highlighted` prop, but you can also
* add custom props with `separators.updateProps`.
*/
ItemSeparatorComponent?: ?ReactClass<any>,
/**
Add ListEmptyComponent prop Summary: Hey there :) Please let me know if the name `ListEmptyComponent` should be changed. I also thought about `ListNoItemsComponent`. Or maybe `ListPlaceholderComponent`? - [x] Explain the **motivation** for making this change. - [x] Provide a **test plan** demonstrating that the code is solid. - [x] Match the **code formatting** of the rest of the codebase. - [x] Target the `master` branch, NOT a "stable" branch. In a FlatList, I wanted to show some placeholder when my data is empty (while keeping eventual Header/Footer/RefreshControl). A way around this issue would be to do something like adding a `ListHeaderComponent` that checks if the list is empty, like so: ```js ListHeaderComponent={() => (!data.length ? <Text style={styles.noDataText}>No data found</Text> : null)} ``` But I felt it was not easily readable as soon as you have an actual header. This PR adds a `ListEmptyComponent` that is rendered when the list is empty. I added tests for VirtualizedList, FlatList and SectionList and ran `yarn test -- -u`. I then checked that the snapshots changed like I wanted. I also tested this against one of my project, though I had to manually add my changes because the project is on RN 0.43. Here are the docs screenshots: - [VirtualizedList](https://cloud.githubusercontent.com/assets/82368/25566000/0ebf2b82-2dd2-11e7-8b80-d8c505f1f2d6.png) - [FlatList](https://cloud.githubusercontent.com/assets/82368/25566005/2842ab42-2dd2-11e7-81b4-32c74c2b4fc3.png) - [SectionList](https://cloud.githubusercontent.com/assets/82368/25566010/368aec1e-2dd2-11e7-9425-3bb5e5803513.png) Thanks for your work! Closes https://github.com/facebook/react-native/pull/13718 Differential Revision: D4993711 Pulled By: sahrens fbshipit-source-id: 055b40f709067071e40308bdf5a37cedaa223dc5
2017-05-04 07:08:14 +00:00
* Rendered at the very beginning of the list. Can be a React Component Class, a render function, or
* a rendered element.
*/
ListHeaderComponent?: ?(ReactClass<any> | React.Element<any>),
/**
Add ListEmptyComponent prop Summary: Hey there :) Please let me know if the name `ListEmptyComponent` should be changed. I also thought about `ListNoItemsComponent`. Or maybe `ListPlaceholderComponent`? - [x] Explain the **motivation** for making this change. - [x] Provide a **test plan** demonstrating that the code is solid. - [x] Match the **code formatting** of the rest of the codebase. - [x] Target the `master` branch, NOT a "stable" branch. In a FlatList, I wanted to show some placeholder when my data is empty (while keeping eventual Header/Footer/RefreshControl). A way around this issue would be to do something like adding a `ListHeaderComponent` that checks if the list is empty, like so: ```js ListHeaderComponent={() => (!data.length ? <Text style={styles.noDataText}>No data found</Text> : null)} ``` But I felt it was not easily readable as soon as you have an actual header. This PR adds a `ListEmptyComponent` that is rendered when the list is empty. I added tests for VirtualizedList, FlatList and SectionList and ran `yarn test -- -u`. I then checked that the snapshots changed like I wanted. I also tested this against one of my project, though I had to manually add my changes because the project is on RN 0.43. Here are the docs screenshots: - [VirtualizedList](https://cloud.githubusercontent.com/assets/82368/25566000/0ebf2b82-2dd2-11e7-8b80-d8c505f1f2d6.png) - [FlatList](https://cloud.githubusercontent.com/assets/82368/25566005/2842ab42-2dd2-11e7-81b4-32c74c2b4fc3.png) - [SectionList](https://cloud.githubusercontent.com/assets/82368/25566010/368aec1e-2dd2-11e7-9425-3bb5e5803513.png) Thanks for your work! Closes https://github.com/facebook/react-native/pull/13718 Differential Revision: D4993711 Pulled By: sahrens fbshipit-source-id: 055b40f709067071e40308bdf5a37cedaa223dc5
2017-05-04 07:08:14 +00:00
* Rendered when the list is empty. Can be a React Component Class, a render function, or
* a rendered element.
*/
ListEmptyComponent?: ?(ReactClass<any> | React.Element<any>),
/**
* Rendered at the very end of the list. Can be a React Component Class, a render function, or
* a rendered element.
*/
ListFooterComponent?: ?(ReactClass<any> | React.Element<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
* Rendered at the top and bottom of each section (note this is different from
* `ItemSeparatorComponent` which is only rendered between items). These are intended to separate
* sections from the headers above and below and typically have the same highlight response as
* `ItemSeparatorComponent`. Also receives `highlighted`, `[leading/trailing][Item/Separator]`,
* and any custom props from `separators.updateProps`.
*/
SectionSeparatorComponent?: ?ReactClass<any>,
/**
* 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,
/**
* 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.
*/
initialNumToRender: number,
/**
* Used to extract a unique key for a given item at the specified index. Key is used for caching
* and as the react key to track item re-ordering. The default extractor checks item.key, then
* falls back to using the index, like react does.
*/
keyExtractor: (item: Item, index: number) => string,
/**
* Called once when the scroll position gets within `onEndReachedThreshold` of the rendered
* content.
*/
onEndReached?: ?(info: {distanceFromEnd: number}) => void,
/**
* How far from the end (in units of visible length of the list) the bottom edge of the
* list must be from the end of the content to trigger the `onEndReached` callback.
* Thus a value of 0.5 will trigger `onEndReached` when the end of the content is
* within half the visible length of the list.
*/
onEndReachedThreshold?: ?number,
/**
* If provided, a standard RefreshControl will be added for "Pull to Refresh" functionality. Make
* sure to also set the `refreshing` prop correctly.
*/
onRefresh?: ?() => void,
/**
* Called when the viewability of rows changes, as defined by the
* `viewabilityConfig` prop.
*/
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,
/**
* 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,
/**
* Rendered at the top of each section. These stick to the top of the `ScrollView` by default on
* iOS. See `stickySectionHeadersEnabled`.
*/
renderSectionHeader?: ?(info: {section: SectionT}) => ?React.Element<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
/**
* Rendered at the bottom of each section.
*/
renderSectionFooter?: ?(info: {section: SectionT}) => ?React.Element<any>,
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
/**
* Makes section headers stick to the top of the screen until the next one pushes it off. Only
* enabled by default on iOS because that is the platform standard there.
*/
stickySectionHeadersEnabled?: boolean,
legacyImplementation?: ?boolean,
};
type Props<SectionT> = RequiredProps<SectionT>
& OptionalProps<SectionT>
& VirtualizedSectionListProps<SectionT>;
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 defaultProps = {
...VirtualizedSectionList.defaultProps,
stickySectionHeadersEnabled: Platform.OS === 'ios',
};
type DefaultProps = typeof defaultProps;
/**
* A performant interface for rendering sectioned lists, supporting the most handy features:
*
* - Fully cross-platform.
* - Configurable viewability callbacks.
* - List header support.
* - List footer support.
* - Item separator support.
* - Section header support.
* - Section separator support.
* - Heterogeneous data and item rendering support.
* - Pull to Refresh.
* - Scroll loading.
*
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 you don't need section support and want a simpler interface, use
* [`<FlatList>`](/react-native/docs/flatlist.html).
*
* Simple Examples:
*
* <SectionList
* renderItem={({item}) => <ListItem title={item.title} />}
* renderSectionHeader={({section}) => <H1 title={section.title} />}
* sections={[ // homogenous rendering between sections
* {data: [...], title: ...},
* {data: [...], title: ...},
* {data: [...], title: ...},
* ]}
* />
*
* <SectionList
* sections={[ // heterogeneous rendering between sections
* {data: [...], title: ..., renderItem: ...},
* {data: [...], title: ..., renderItem: ...},
* {data: [...], title: ..., renderItem: ...},
* ]}
* />
*
* This is a convenience wrapper around [`<VirtualizedList>`](docs/virtualizedlist.html),
* and thus inherits it's props (as well as those of `ScrollView`) that aren't explicitly listed
* here, along with the following 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 SectionList<SectionT: SectionBase<any>>
extends React.PureComponent<DefaultProps, Props<SectionT>, void>
{
props: Props<SectionT>;
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
static defaultProps: DefaultProps = defaultProps;
/**
* Scrolls to the item at the specified `sectionIndex` and `itemIndex` (within the section)
* positioned in the viewable area such that `viewPosition` 0 places it at the top (and may be
* covered by a sticky header), 1 at the bottom, and 0.5 centered in the middle. `viewOffset` is a
* fixed number of pixels to offset the final target position, e.g. to compensate for sticky
* headers.
*
* Note: cannot scroll to locations outside the render window without specifying the
* `getItemLayout` prop.
*/
scrollToLocation(params: {
animated?: ?boolean,
itemIndex: number,
sectionIndex: number,
viewOffset?: number,
viewPosition?: number,
}) {
this._wrapperListRef.scrollToLocation(params);
}
/**
* Tells the list an interaction has occured, which should trigger viewability calculations, e.g.
* if `waitForInteractions` is true and the user has not scrolled. This is typically called by
* taps on items or by navigation actions.
*/
recordInteraction() {
const listRef = this._wrapperListRef && this._wrapperListRef.getListRef();
listRef && listRef.recordInteraction();
}
/**
* Provides a handle to the underlying scroll responder.
*/
getScrollResponder() {
const listRef = this._wrapperListRef && this._wrapperListRef.getListRef();
if (listRef) {
return listRef.getScrollResponder();
}
}
getScrollableNode() {
const listRef = this._wrapperListRef && this._wrapperListRef.getListRef();
if (listRef) {
return listRef.getScrollableNode();
}
}
render() {
const List = this.props.legacyImplementation ? MetroListView : VirtualizedSectionList;
return <List {...this.props} ref={this._captureRef} />;
}
_wrapperListRef: MetroListView | VirtualizedSectionList<any>;
_captureRef = (ref) => { this._wrapperListRef = ref; };
}
module.exports = SectionList;