Commit Graph

14 Commits

Author SHA1 Message Date
Mike a4526bcc3f fix: incorrect ScrollView offset on update (#30647)
Summary:
This pull request is to fix https://github.com/facebook/react-native/issues/30258.

After an investigation, I found out the scroll offset of the list seems to be calculated incorrectly due to a workaround in the source code.

Instead of fixing the `calculateOffsetForContentSize`, I chose to remove it, the reason why I do so is because this workaround is for fixing the offset when `contentSize` is set manually, but according to the source code, there is no interface for a react-native user to set the `contentSize` of ScrollView, it is just set to `GCSizeZero` and will never be changed ([ref](https://github.com/facebook/react-native/pull/30647/files#diff-cf6f991f585ebf4cfdd555fe474e1f9ce40c2e4f823fc3f42b549414639c8c30L304)).

Also I changed the function name from `updateContentOffsetIfNeeded` to  `updateContentSizeIfNeeded` according what the function is actually doing.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[iOS] [Fixed] - Incorrect ScrollView offset on update

Pull Request resolved: https://github.com/facebook/react-native/pull/30647

Test Plan:
1. Create a fresh new project named `testapp` using npx create-react-native-app
2. Apply example code to `testapp` from https://snack.expo.io/lokomass/flatlist
3. Run `testapp` on iOS emulator and reproduce the bug
4. Make changes to files in `testapp/node_modules/react-native/`
5. Rebuild `testapp` and run on iOS emulator again, the bug is no more exist
6. Apply changes from step 4 to react-native, make a pull request.

#### Screenshots

Before: The scroll offset is incorrect after children of FlatList has changed

https://user-images.githubusercontent.com/48589760/103155130-b54a0580-47d7-11eb-97af-bdfd3e728714.mov

After: No more incorrect scroll offset if children of FlatList has changed

https://user-images.githubusercontent.com/48589760/103155091-6ef4a680-47d7-11eb-89fa-6f708bfef1c9.mov

Reviewed By: sammy-SC

Differential Revision: D25732958

Pulled By: shergin

fbshipit-source-id: dac6eff15ac3bbfec502452ac14b3d49fee76c29
2021-01-05 11:06:30 -08:00
Lulu Wu ea93151f21 Make RCTEventDispatcher TurboModule-compatible
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.

Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible

Reviewed By: fkgozali

Differential Revision: D18439488

fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
2020-10-14 02:40:10 -07:00
Emilio 7a4753d76a tapping on iOS status bar should scroll inverted ScrollViews to their top (#27574)
Summary:
React Native ScrollViews are flipped upside down when the prop inverted is set to true. This is the root of a bug: tapping on the status bar in iOS should scroll the Flatlist up to the top but currently it does to the bottom.

The solution proposed is to detect natively if the ScrollView is inverted, on such case, prevent it from scrolling it to the beginning of the ScrollView (as a non-inverted ScrollView would do) and force a scroll to the end of it.

I've been careful enough not to force the scroll if the user explicitly selected not to do it or if it's happening in a nested ScrollView, as it is the default behaviour in iOS.

Fixes https://github.com/facebook/react-native/issues/21126

## Changelog

[iOS] [Fixed] - Inverted ScrollViews scroll to their bottom when the status bar is pressed
Pull Request resolved: https://github.com/facebook/react-native/pull/27574

Test Plan:
- on iOS, add a ScrollView and put enough content to overflow the screen size so it can be scrolled
- add the prop `inverted={true}` to the ScrollView
- go to the screen the Scrollview is in and press the status bar
- it should scroll to top (previously it scrolled to the bottom)

![v](https://user-images.githubusercontent.com/807710/71188640-a0ac6680-2281-11ea-91a7-d1e46aba8b14.gif)

Differential Revision: D19185270

Pulled By: hramos

fbshipit-source-id: 5445093ff38f4ba4082f1d883d8ed087e9565eaf
2019-12-19 15:29:54 -08:00
Andres Suarez 3b31e69e28 Tidy up license headers [2/n]
Summary: Changelog: [General] [Fixed] - License header cleanup

Reviewed By: yungsters

Differential Revision: D17952694

fbshipit-source-id: 17c87de7ebb271fa2ac8d00af72a4d1addef8bd0
2019-10-16 10:06:34 -07:00
Taylor123 faaa92bb04 disable momentum scrolling for horizontal ScrollView (#24045)
Summary:
Would like feedback from the community as this may not be the best solution for all

I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.

This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.

To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature  #21302 .

[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045

Differential Revision: D14939754

Pulled By: sahrens

fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
2019-04-15 14:40:44 -07:00
Craig_Martin 6f4239b37c Add scrollToOverflowEnabled prop to ScrollView (#24296)
Summary:
ScrollView's scrollTo behavior on iOS was recently changed to limit the offset to the content size plus any content inset (see #23427). This departure from the old behavior created UI issues for anyone that is using the over-scroll ability for the purpose of positioning elements at specific coordinates on the screen. Examples include using this behavior to position TextInputs above the virtual keyboard programmatically when focused or moving drop down elements positioned near the bottom of the content toward the top of the screen when selected to show a larger absolutely positioned item list. Default behavior does not change and this is an "opt-in" type of prop to re-enable the old behavior.

[iOS] [Added] - Added scrollToOverflowEnabled prop to ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/24296

Differential Revision: D14762619

Pulled By: cpojer

fbshipit-source-id: d2a552b5cb321d52e8ea4116327bf9ec647a3aae
2019-04-03 16:21:08 -07:00
James Reggio 9733b92f3d Add onScrollToTop to ScrollView for iOS (#21204)
Summary:
This PR exposes the `onScrollToTop` event on iOS using the same event-forwarding infrastructure as other ScrollView events. (As such, its `nativeEvent` object reflects the same fields as other ScrollView events.)

Motivation:
----------

If your app is only interested in knowing the position of a ScrollView after a scroll has completed, it can use `onScrollEndDrag` and `onMomentumScrollEnd` to inspect the `contentOffset` after a drag-initiated scroll has finished. (This is much less expensive than observing the `onScroll` event if you only want to know the end position.) However, neither of these `End` events fire if the ScrollView is scrolled to the top by tapping the status bar.

By exposing `onScrollToTop`, it is now possible for an app to cheaply know when such a scroll has completed.
Pull Request resolved: https://github.com/facebook/react-native/pull/21204

Differential Revision: D9943618

Pulled By: hramos

fbshipit-source-id: ac5ee42b7f12d94655ffda617f8f811138da7f6f
2018-09-19 11:17:30 -07:00
Héctor Ramos 1151c096da Update copyright headers to yearless format
Summary: This change drops the year from the copyright headers and the LICENSE file.

Reviewed By: yungsters

Differential Revision: D9727774

fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
2018-09-11 15:33:07 -07:00
Oleg Lokhvitsky 5f48d28119 ScrollView snapToStart/snapToEnd
Summary: Added `snapToStart` and `snapToEnd` props to ScrollView which work together with `snapToOffsets` and determine whether the beginning and end of the list automatically count as snap offsets or not. If not, the list is allowed to free-scroll between its start/end and the first/last snap offset.

Reviewed By: sahrens

Differential Revision: D9442386

fbshipit-source-id: 47a5fdb20f884542434b01b1f0a486ed2b478c6e
2018-08-30 13:04:50 -07:00
Oleg Lokhvitsky fd744dd56c ScrollView snapToOffsets
Summary:
* Added snapToOffsets prop to ScrollView. Allows snapping at arbitrary points.

* Fixed pagingEnabled not being overridden by snapToInterval on iOS.

* Fixed Android *requiring* pagingEnabled to be defined alongside snapToInterval.
* Added support for decelerationRate on Android.

* Fixed snapping implementation. It was not calculating end position correctly at all (velocity is not a linear offset).
  * Resolves https://github.com/facebook/react-native/issues/20155
* Added support for new content being added during scroll (mirrors existing functionality in vertical ScrollView).

* Added support for snapToInterval.
  * Resolves https://github.com/facebook/react-native/issues/19552

Reviewed By: yungsters

Differential Revision: D9405703

fbshipit-source-id: b3c367b8079e6810794b0165dfdbcff4abff2eda
2018-08-30 13:04:50 -07:00
Sophie Alpert 1490ab12ef Update license headers for MIT license
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.

find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.

Reviewed By: TheSavior, yungsters

Differential Revision: D7007050

fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
2018-02-16 18:31:53 -08:00
Spencer Ahrens 65184ec6b0 rename and extend new maintain visible content position feature
Summary:
Builds off of https://github.com/facebook/react-native/commit/cae7179c9459f12b1cb5e1a1d998a9dc45f927dc

- Make the prop a dictionary for more configuration options
- Rename `maintainPositionAtOrBeyondIndex` -> `maintainVisibleContentPosition` + `minIndexForVisible`
- Add autoscroll threshold feature

Given the async native of RN JS and background layout, there is no way to trigger the scrollTo from JS without risking a delay, so we add the feature in native code.

== Test Plan ==
ScrollViewExample:
https://youtu.be/pmY8pxC9PRs

Reviewed By: shergin

Differential Revision: D6729160

fbshipit-source-id: 70f9bae460ce84567857a4f696da78ce9b3b834c
2018-01-18 14:01:50 -08:00
Spencer Ahrens cae7179c94 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-12 19:16:00 -08:00
Valentin Shergin 098a63a1ce ScrollView related files were moved to dedicated folder
Summary: Trivial.

Reviewed By: rsnara

Differential Revision: D6539747

fbshipit-source-id: 716a02be185bde79e60011fcc226131972e74951
2017-12-11 19:08:00 -08:00