2015-01-30 01:10:49 +00:00
|
|
|
/**
|
2017-05-06 03:50:47 +00:00
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
2016-07-12 12:51:57 +00:00
|
|
|
*
|
2018-02-17 02:24:55 +00:00
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
2016-07-12 12:51:57 +00:00
|
|
|
*
|
2015-03-23 22:07:33 +00:00
|
|
|
* @flow
|
2018-01-13 03:07:17 +00:00
|
|
|
* @format
|
2015-01-30 01:10:49 +00:00
|
|
|
*/
|
|
|
|
'use strict';
|
|
|
|
|
2018-03-07 21:12:51 +00:00
|
|
|
import type {DangerouslyImpreciseStyleProp} from 'StyleSheet';
|
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,
|
2016-02-03 11:59:20 +00:00
|
|
|
Text,
|
|
|
|
TouchableOpacity,
|
2015-01-30 01:10:49 +00:00
|
|
|
View,
|
2018-01-13 03:07:17 +00:00
|
|
|
Image,
|
2016-04-09 03:36:40 +00:00
|
|
|
} = ReactNative;
|
2015-01-30 01:10:49 +00:00
|
|
|
|
2017-02-07 04:58:23 +00:00
|
|
|
exports.displayName = 'ScrollViewExample';
|
2015-01-30 01:10:49 +00:00
|
|
|
exports.title = '<ScrollView>';
|
2018-01-13 03:07:17 +00:00
|
|
|
exports.description =
|
|
|
|
'Component that enables scrolling through child components';
|
2015-01-30 01:10:49 +00:00
|
|
|
exports.examples = [
|
2018-01-13 03:07:17 +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
|
|
|
title: '<ScrollView>\n',
|
2018-01-13 03:07:17 +00:00
|
|
|
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;
|
2017-02-07 04:58:23 +00:00
|
|
|
return (
|
2018-01-13 03:07:17 +00:00
|
|
|
<View>
|
2017-02-07 04:58:23 +00:00
|
|
|
<ScrollView
|
2018-01-13 03:07:17 +00:00
|
|
|
ref={scrollView => {
|
|
|
|
_scrollView = scrollView;
|
|
|
|
}}
|
2017-02-07 04:58:23 +00:00
|
|
|
automaticallyAdjustContentInsets={false}
|
2018-01-13 03:07:17 +00:00
|
|
|
onScroll={() => {
|
|
|
|
console.log('onScroll!');
|
|
|
|
}}
|
|
|
|
scrollEventThrottle={200}
|
|
|
|
style={styles.scrollView}>
|
2017-02-07 04:58:23 +00:00
|
|
|
{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"
|
2018-01-13 03:07:17 +00:00
|
|
|
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"
|
2018-01-13 03:07:17 +00:00
|
|
|
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"
|
2018-01-13 03:07:17 +00:00
|
|
|
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
|
|
|
}}
|
|
|
|
/>
|
2017-02-07 04:58:23 +00:00
|
|
|
</View>
|
|
|
|
);
|
2018-01-13 03:07:17 +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
|
|
|
title: '<ScrollView> (horizontal = true)\n',
|
2018-01-13 03:07:17 +00:00
|
|
|
description:
|
|
|
|
"You can display <ScrollView>'s child components horizontally rather than vertically",
|
|
|
|
render: function() {
|
|
|
|
function renderScrollView(
|
|
|
|
title: string,
|
2018-01-30 03:10:33 +00:00
|
|
|
additionalStyles: typeof StyleSheet,
|
2018-01-13 03:07:17 +00:00
|
|
|
) {
|
2018-05-12 17:25:05 +00:00
|
|
|
let _scrollView: ?ScrollView;
|
2018-01-13 03:07:17 +00:00
|
|
|
return (
|
2018-01-30 03:10:33 +00:00
|
|
|
<View style={additionalStyles}>
|
2018-01-13 03:07:17 +00:00
|
|
|
<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"
|
2018-01-13 03:07:17 +00:00
|
|
|
onPress={() => {
|
|
|
|
_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"
|
2018-01-13 03:07:17 +00:00
|
|
|
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"
|
2018-01-13 03:07:17 +00:00
|
|
|
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
|
|
|
}}
|
|
|
|
/>
|
2018-01-13 03:07:17 +00:00
|
|
|
</View>
|
|
|
|
);
|
|
|
|
}
|
2017-02-07 04:58:23 +00:00
|
|
|
|
2018-01-13 03:07:17 +00:00
|
|
|
return (
|
|
|
|
<View>
|
2018-04-17 12:37:02 +00:00
|
|
|
{/* $FlowFixMe(>=0.70.0 site=react_native_fb) This comment
|
|
|
|
* suppresses an error found when Flow v0.70 was deployed. To see
|
|
|
|
* the error delete this comment and run Flow. */
|
|
|
|
renderScrollView('LTR layout', {direction: 'ltr'})}
|
|
|
|
{/* $FlowFixMe(>=0.70.0 site=react_native_fb) This comment
|
|
|
|
* suppresses an error found when Flow v0.70 was deployed. To see
|
|
|
|
* the error delete this comment and run Flow. */
|
|
|
|
renderScrollView('RTL layout', {direction: 'rtl'})}
|
2018-01-13 03:07:17 +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
|
|
|
if (Platform.OS === 'ios') {
|
|
|
|
exports.examples.push({
|
|
|
|
title: '<ScrollView> smooth bi-directional content loading\n',
|
|
|
|
description:
|
2018-01-18 21:51:43 +00:00
|
|
|
'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}
|
2018-01-18 21:51:43 +00:00
|
|
|
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}
|
2018-01-18 21:51:43 +00:00
|
|
|
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]}>
|
2018-01-18 21:51:43 +00:00
|
|
|
<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,
|
2018-03-07 21:12:51 +00:00
|
|
|
style?: DangerouslyImpreciseStyleProp,
|
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
|
|
|
|}> {
|
2016-07-26 08:00:02 +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>
|
|
|
|
);
|
|
|
|
}
|
2016-07-26 08:00:02 +00:00
|
|
|
}
|
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 = [
|
2017-02-07 04:58:23 +00:00
|
|
|
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: {
|
2017-02-07 04:58:23 +00:00
|
|
|
backgroundColor: '#eeeeee',
|
2015-01-30 01:10:49 +00:00
|
|
|
height: 300,
|
|
|
|
},
|
|
|
|
horizontalScrollView: {
|
2017-02-07 04:58:23 +00:00
|
|
|
height: 106,
|
2015-01-30 01:10:49 +00:00
|
|
|
},
|
|
|
|
text: {
|
2017-02-07 04:58:23 +00:00
|
|
|
fontSize: 16,
|
|
|
|
fontWeight: 'bold',
|
|
|
|
margin: 5,
|
2015-01-30 01:10:49 +00:00
|
|
|
},
|
|
|
|
button: {
|
2017-02-07 04:58:23 +00:00
|
|
|
margin: 5,
|
2015-01-30 01:10:49 +00:00
|
|
|
padding: 5,
|
|
|
|
alignItems: 'center',
|
2017-02-07 04:58:23 +00:00
|
|
|
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',
|
|
|
|
},
|
2017-02-07 04:58:23 +00:00
|
|
|
thumb: {
|
|
|
|
margin: 5,
|
|
|
|
padding: 5,
|
|
|
|
backgroundColor: '#cccccc',
|
|
|
|
borderRadius: 3,
|
|
|
|
minWidth: 96,
|
2015-01-30 01:10:49 +00:00
|
|
|
},
|
|
|
|
img: {
|
|
|
|
width: 64,
|
|
|
|
height: 64,
|
2018-01-13 03:07:17 +00:00
|
|
|
},
|
2015-01-30 01:10:49 +00:00
|
|
|
});
|