react-native/RNTester/js/ScrollViewExample.js

335 lines
9.5 KiB
JavaScript
Raw Normal View History

2015-01-30 01:10:49 +00:00
/**
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @flow
* @format
2015-01-30 01:10:49 +00:00
*/
'use strict';
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
const ActivityIndicator = require('ActivityIndicator');
const Platform = require('Platform');
const React = require('react');
const ReactNative = require('react-native');
const {
2015-01-30 01:10:49 +00:00
ScrollView,
StyleSheet,
Text,
TouchableOpacity,
2015-01-30 01:10:49 +00:00
View,
Image,
} = ReactNative;
2015-01-30 01:10:49 +00:00
import type {ViewStyleProp} from 'StyleSheet';
exports.displayName = 'ScrollViewExample';
2015-01-30 01:10:49 +00:00
exports.title = '<ScrollView>';
exports.description =
'Component that enables scrolling through child components';
2015-01-30 01:10:49 +00:00
exports.examples = [
{
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
title: '<ScrollView>\n',
description:
'To make content scrollable, wrap it within a <ScrollView> component',
render: function() {
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
let _scrollView: ScrollView;
return (
<View>
<ScrollView
ref={scrollView => {
// $FlowFixMe Invalid prop usage
_scrollView = scrollView;
}}
automaticallyAdjustContentInsets={false}
onScroll={() => {
console.log('onScroll!');
}}
scrollEventThrottle={200}
style={styles.scrollView}>
{THUMB_URLS.map(createThumbRow)}
</ScrollView>
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
<Button
label="Scroll to top"
onPress={() => {
_scrollView.scrollTo({y: 0});
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
}}
/>
<Button
label="Scroll to bottom"
onPress={() => {
_scrollView.scrollToEnd({animated: true});
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
}}
/>
<Button
label="Flash scroll indicators"
onPress={() => {
_scrollView.flashScrollIndicators();
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
}}
/>
</View>
);
},
},
{
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
title: '<ScrollView> (horizontal = true)\n',
description:
"You can display <ScrollView>'s child components horizontally rather than vertically",
render: function() {
function renderScrollView(
title: string,
additionalStyles: ViewStyleProp,
) {
let _scrollView: ?ScrollView;
return (
<View style={additionalStyles}>
<Text style={styles.text}>{title}</Text>
<ScrollView
ref={scrollView => {
_scrollView = scrollView;
}}
automaticallyAdjustContentInsets={false}
horizontal={true}
style={[styles.scrollView, styles.horizontalScrollView]}>
{THUMB_URLS.map(createThumbRow)}
</ScrollView>
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
<Button
label="Scroll to start"
onPress={() => {
// $FlowFixMe Invalid prop usage
_scrollView.scrollTo({x: 0});
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
}}
/>
<Button
label="Scroll to end"
onPress={() => {
// $FlowFixMe Invalid prop usage
_scrollView.scrollToEnd({animated: true});
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
}}
/>
<Button
label="Flash scroll indicators"
onPress={() => {
// $FlowFixMe Invalid prop usage
_scrollView.flashScrollIndicators();
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
}}
/>
</View>
);
}
return (
<View>
{renderScrollView('LTR layout', {direction: 'ltr'})}
{renderScrollView('RTL layout', {direction: 'rtl'})}
</View>
);
},
},
];
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
if (Platform.OS === 'ios') {
exports.examples.push({
title: '<ScrollView> smooth bi-directional content loading\n',
description:
'The `maintainVisibleContentPosition` prop allows insertions to either end of the content ' +
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
'without causing the visible content to jump. Re-ordering is not supported.',
render: function() {
let itemCount = 6;
class AppendingList extends React.Component<{}, *> {
state = {
items: [...Array(itemCount)].map((_, ii) => (
<Thumb msg={`Item ${ii}`} />
)),
};
render() {
return (
<View>
<ScrollView
automaticallyAdjustContentInsets={false}
maintainVisibleContentPosition={{
minIndexForVisible: 1,
autoscrollToTopThreshold: 10,
}}
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
style={styles.scrollView}>
<ActivityIndicator style={{height: 40}} />
{this.state.items.map(item =>
React.cloneElement(item, {key: item.props.msg}),
)}
</ScrollView>
<ScrollView
horizontal={true}
automaticallyAdjustContentInsets={false}
maintainVisibleContentPosition={{
minIndexForVisible: 1,
autoscrollToTopThreshold: 10,
}}
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
style={[styles.scrollView, styles.horizontalScrollView]}>
<ActivityIndicator style={{width: 40}} />
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
{this.state.items.map(item =>
React.cloneElement(item, {key: item.props.msg, style: null}),
)}
</ScrollView>
<View style={styles.row}>
<Button
label="Add to top"
onPress={() => {
this.setState(state => {
const idx = itemCount++;
return {
items: [
<Thumb
style={{paddingTop: idx * 5}}
msg={`Item ${idx}`}
/>,
].concat(state.items),
};
});
}}
/>
<Button
label="Remove top"
onPress={() => {
this.setState(state => ({
items: state.items.slice(1),
}));
}}
/>
<Button
label="Change height top"
onPress={() => {
this.setState(state => ({
items: [
React.cloneElement(state.items[0], {
style: {paddingBottom: Math.random() * 40},
}),
].concat(state.items.slice(1)),
}));
}}
/>
</View>
<View style={styles.row}>
<Button
label="Add to end"
onPress={() => {
this.setState(state => ({
items: state.items.concat(
<Thumb msg={`Item ${itemCount++}`} />,
),
}));
}}
/>
<Button
label="Remove end"
onPress={() => {
this.setState(state => ({
items: state.items.slice(0, -1),
}));
}}
/>
<Button
label="Change height end"
onPress={() => {
this.setState(state => ({
items: state.items.slice(0, -1).concat(
React.cloneElement(
state.items[state.items.length - 1],
{
style: {paddingBottom: Math.random() * 40},
},
),
),
}));
}}
/>
</View>
</View>
);
}
}
return <AppendingList />;
},
});
}
2015-01-30 01:10:49 +00:00
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
class Thumb extends React.PureComponent<{|
source?: string | number,
msg?: string,
style?: ViewStyleProp,
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|}> {
render() {
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
const {source} = this.props;
2015-01-30 01:10:49 +00:00
return (
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
<View style={[styles.thumb, this.props.style]}>
<Image
style={styles.img}
source={source == null ? THUMB_URLS[6] : source}
/>
<Text>{this.props.msg}</Text>
2015-01-30 01:10:49 +00:00
</View>
);
}
}
2015-01-30 01:10:49 +00:00
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
let THUMB_URLS = [
require('./Thumbnails/like.png'),
require('./Thumbnails/dislike.png'),
require('./Thumbnails/call.png'),
require('./Thumbnails/fist.png'),
require('./Thumbnails/bandaged.png'),
require('./Thumbnails/flowers.png'),
require('./Thumbnails/heart.png'),
require('./Thumbnails/liking.png'),
require('./Thumbnails/party.png'),
require('./Thumbnails/poke.png'),
require('./Thumbnails/superlike.png'),
require('./Thumbnails/victory.png'),
];
THUMB_URLS = THUMB_URLS.concat(THUMB_URLS); // double length of THUMB_URLS
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
const createThumbRow = (uri, i) => <Thumb key={i} source={uri} />;
2015-01-30 01:10:49 +00:00
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
const Button = ({label, onPress}) => (
<TouchableOpacity style={styles.button} onPress={onPress}>
<Text>{label}</Text>
</TouchableOpacity>
);
const styles = StyleSheet.create({
2015-01-30 01:10:49 +00:00
scrollView: {
backgroundColor: '#eeeeee',
2015-01-30 01:10:49 +00:00
height: 300,
},
horizontalScrollView: {
height: 106,
2015-01-30 01:10:49 +00:00
},
text: {
fontSize: 16,
fontWeight: 'bold',
margin: 5,
2015-01-30 01:10:49 +00:00
},
button: {
margin: 5,
2015-01-30 01:10:49 +00:00
padding: 5,
alignItems: 'center',
backgroundColor: '#cccccc',
2015-01-30 01:10:49 +00:00
borderRadius: 3,
},
new feature to support smooth bi-directional content loading Summary: == Problem / Background == Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example. Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications). == Approach == The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate. This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker. There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport. == Notes == Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom. This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that. == Test Plan == https://youtu.be/4GcqDGz9eOE Reviewed By: shergin Differential Revision: D6696921 fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
row: {
flexDirection: 'row',
justifyContent: 'space-around',
},
thumb: {
margin: 5,
padding: 5,
backgroundColor: '#cccccc',
borderRadius: 3,
minWidth: 96,
2015-01-30 01:10:49 +00:00
},
img: {
width: 64,
height: 64,
},
2015-01-30 01:10:49 +00:00
});