Summary:
motivation: I was just checking out https://github.com/facebook/react-native/commit/30cc158a875a0414cf53d4d5155410eea5d5aeea
and noticed that the commit, I believe, is missing logic for when `contentOffset` is actually `null`.
That is, consider you render `ScrollView` with `contentOffset` { x: 0, y: 100 } and then change that to null / undefined. I'd expect the content offset to invalidate (set to 0 - hope that's the default).
## 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
-->
[Android] [Fixed] - ScrollView, HorizontalScrollView: do not ignore `null` `contentOffset` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/28760
Test Plan:
Tested locally within RNTester
<details><summary>code</summary>
<p>
```js
const Ex = () => {
let _scrollView: ?React.ElementRef<typeof ScrollView> = React.useRef(null);
const [offset, setOffset] = React.useState({x: 0, y: 20});
setTimeout(() => {
setOffset(undefined);
}, 2000);
return (
<View>
<ScrollView
ref={_scrollView}
automaticallyAdjustContentInsets={false}
onScroll={() => {
console.log('onScroll!');
}}
contentOffset={offset}
scrollEventThrottle={200}
style={styles.scrollView}>
{ITEMS.map(createItemRow)}
</ScrollView>
<Button
label="Scroll to top"
onPress={() => {
nullthrows(_scrollView.current).scrollTo({y: 0});
}}
/>
<Button
label="Scroll to bottom"
onPress={() => {
nullthrows(_scrollView.current).scrollToEnd({animated: true});
}}
/>
<Button
label="Flash scroll indicators"
onPress={() => {
nullthrows(_scrollView.current).flashScrollIndicators();
}}
/>
</View>
);
};
```
</p>
</details>
Reviewed By: shergin
Differential Revision: D22298676
Pulled By: JoshuaGross
fbshipit-source-id: e411ba4c8a276908e354d59085d164a38ae253c0
Summary:
This early return is a very minor perf optimization, and it complicates things on Fabric: if scroll perf logging is disabled, the scroll position in C++ (State) doesn't get updated for the scrollview.
Just remove it. Always run the Runnable, no matter what.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D21503695
fbshipit-source-id: 13dfe232d692ff544bff725a2344a66b572f5444
Summary:
Problem: ScrollView offset was not being reported to the C++ ScrollView side of Fabric.
This results in taps not working correctly, for example if you tap a button inside scroll view after you scrolled, the tap might not trigger anything.
The root cause of this is our implementation of detecting whether scroll view has stopped scrolling.
To make this more robust, I now require that multiple "frames" have not scrolled because it's easy to trigger race conditions by scrolling very fast.
We also explicitly call `updateStateOnScroll` in a couple more places.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21496396
fbshipit-source-id: 2e565dd2fc4fc1ce582daa8a449c520e7cb19be0
Summary:
Android ScrollView/HorizontalScrollView `smoothScrollTo` contains some logic that, if called multiple times in a short amount of
time, will treat all calls as part of the same animation and will not lengthen the duration
of the animation. This means that, for example, if the user is scrolling rapidly, multiple
pages could be considered part of one animation, causing some page animations to be animated
very rapidly - looking like they're not animated at all.
We use a custom animation to perform `smoothScrollTo` to improve the UX.
This resolves a longstanding issue in non-Fabric RN, as well as Fabric, since this code is shared between the platforms.
Changelog: [Update] Android ScrollView/HorizontalScrollView scrolls using custom animations instead of default Android `smoothScrollTo` implementation, leading to smoother scrolls for paginated ScrollViews
Reviewed By: mdvacca
Differential Revision: D21416520
fbshipit-source-id: 6ebe63cb054a98336b6e81253d35623fe5522f89
Summary:
Since support for contentOffset was added to horizontal ScrollView on android (30cc158a87) I'm seeing a crash in my app because of a library. What happens is that it passes a partial object for contentOffset so something like `{x: 1}` which causes a crash on Android.
According to the flow types the object should always contain both x and y but I think we should preserve the runtime behaviour and just use 0 like iOS does.
## Changelog
[Android] [Fixed] - Allow passing partial contentOffset to ScrollView on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/28817
Test Plan: Tested that passing partial object for contentOffset does not crash.
Reviewed By: JoshuaGross
Differential Revision: D21396319
Pulled By: shergin
fbshipit-source-id: 4b52c868e3bfe183ff7f68a76ac34d1abd5e1069
Summary:
According to the Flow types, `contentOffset` is nullable. Support that.
Changelog: [Internal] Fix to (1) support null contentOffset in ScrollView and HorizontalScrollView, added on Android after the last release. (2) Correctly add support for contentOffset in ScrollView (I missed that when adding it to HorizontalScrollView in the previous diff).
Reviewed By: alsun2001
Differential Revision: D21243028
fbshipit-source-id: ebef9a9054a3e4dd88556739e836b7ece48fda12
Summary:
For a very long time, iOS has supported the `contentOffset` property but Android has not:
https://github.com/facebook/react-native/issues/6849
This property can be used, primarily, to autoscroll the ScrollView to a starting position when it is first rendered, to avoid "jumps" that occur by asynchronously scrolling to a start position.
Changelog: [Android][Changed] ScrollView now supports `contentOffset`
Reviewed By: mdvacca
Differential Revision: D21198236
fbshipit-source-id: 2b0773569ba42120cb1fcf0f3847ca98af2285e7
Summary:
Instead of just blindly retrying all ViewCommands if they fail - which could be dangerous, since it's arbitrary imperative commands we'd be executing twice, potentially with bad app state - we only retry if the ViewCommand throws a "RetryableMountingLayerException".
Changelog: [Internal] Optimization to ViewCommands
Reviewed By: mdvacca
Differential Revision: D20529985
fbshipit-source-id: 0217b43f4bf92442bcc7ca48c8ae2b9a9e543dc9
Summary:
Changelog: [Internal]
# Problem
Fabric didn't know about content offset, even though `reactSmoothScrollTo` calls `updateStateOnScroll`, the value of content offset is {0, 0}.
# Fix
Call `updateStateOnScroll` from `reactSmoothScrollTo` with where the scroll view is going to be rather than where it is.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D20248959
fbshipit-source-id: b1da645576dd5e8dce29e7e1d90ab232e0df9fd5
Summary:
# Problem
HorizontalScrollView was not reporting its `contentOffset` to Fabric, therefore `measure` was returning wrong value.
# Solution
Copy over implementation of `updateState` from scrollView. I noticed that there is a lot of duplication between the two classes, that's why I decided to duplicate `updateState` as well.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D20247552
fbshipit-source-id: 48b1eb0c11198a32531effe55301f8d554e92130
Summary:
We must use FLog instead of android.util.log, this diff moves the current callsites of android.util.log to FLog
changeLog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19884741
fbshipit-source-id: 300f7d691961aa51f0b525c37da7ae3d64fe5131
Summary:
# Problem
`UIManager::getRelativeLayoutMetrics` returns incorrect `frame.origin.y` value.
Just quick reiteration how calculation of `frame.origin` works. We take frame of the target shadow node, travers hierarchy to the root and keep adding `frame.origin` of each ancestor to target shadow node's origin.
One more important piece of information, to calculate scroll view's `frame.origin`, we need to have its contentOffset which gets passed to Fabric core through state.
# So where does it go wrong?
Problem is that on Android, calling view command `scrollTo` doesn't set its internal state correctly. So when we calculate the layoutmetrics, scroll view's `frame.origin` is off by whatever value was used in `scrollTo`.
# The fix
In `ReactScrollView`, correctly set state after `scrollTo` is called on it.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19835549
fbshipit-source-id: d56e7b0b05023c0497e52c8b46fdcf58ca78b4a5
Summary:
This diff back out the migration of events on ScrollView to be bridgeless (D18862857)
This is causing the bug: T59882485 and the migration is not necessary in production yet.
Heads-up ejanzer this diff will affect events for scroll in Venice, I will create another diff to figure it out the root cause. But we need the land and pick this diff in v252
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19269906
fbshipit-source-id: d61e67975d508cddafc3af34b0f7dfe83bda6bd7
Summary:
This implements propagation of ScrollView's contentOffset value on Android. That allows `LayoutableShadowNode::getRelativeLayoutMetrics` (and some measure functions) return values that take that info into account.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19027433
fbshipit-source-id: 023ff9642d023971b3d24d5cc5f7c2f4b443031e
Summary:
This diff migrates a couple of events callsites of ReactRootView and ScrollView to be compatible with Bridgeless React mode
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D18862857
fbshipit-source-id: f8e0d2d684bfaf84e9c138746507bb7728481b18
Summary:
This diff introduces a new ReactFeatureFlag that will be used to enable / disable a custom implementation of getChildVisibleRect in the classes ReactViewGroup, ReactHorizontalScrollView and ReactScrollView.
The new ReactFeatureFlag is disabled by default bevause of T57363204
This is disabling the code landed as part of D17782658 / https://github.com/facebook/react-native/pull/26334
Changelog: Introduce ReactFeatureFlag to disable custom implementation of getChildVisibleRect (disabled by default)
This will disable the custom algorithm created on https://github.com/facebook/react-native/pull/26334
Reviewed By: yungsters
Differential Revision: D18621042
fbshipit-source-id: 35ca3417b596117b47edab29515a824c1726c2ce
Summary:
This PR addresses issue https://github.com/facebook/react-native/issues/23870 (`View.getGlobalVisibleRect()` is broken in some use cases)
The issue affects the following Android APIs:
- ViewGroup.getChildVisibleRect()
- View.getGlobalVisibleRect() (Which calls into ViewGroup.getChildVisibleRect)
- View.getLocalVisibleRect() (Which calls into View.getGlobalVisibleRect())
According to Android documentation, View.getGlobalVisibleRect() should provide a rect for a given view that has been clipped by the bounds of all of its parent views up the view hierarchy. It does so through the use of the recursive function ViewGroup.getChildVisibleRect().
Since React Native has a separate clipping mechanism that does not rely on Android UI's clipping implementation, ViewGroup.getChildVisibleRect() is unable to determine that a rect should be clipped if the clipping view is a ReactClippingViewGroup. This resultantly breaks some important use cases for things like testing with Detox, which relies on this functionality to tell when a component is on-screen, as explained in the above referenced issue.
The rationale of the fix is essentially to implement logic analogous to [ViewGroup.getChildVisibleRect()](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#6176), discarding irrelevant Android clipping modes, and instead testing against the 'overflow' property, restoring the originally intended functionality. This is implemented as an override to ViewGroup.getChildVisibleRect() in the following classes:
- ReactViewGroup
- ReactScrollView
- ReactHorizontalScrollView
Unfortunately, since the public ViewGroup.getChildVisibleRect() API recurses into a `hide` annotated API which cannot be overridden, it was necessary to provide this override in each of the above React Native classes to ensure the superclass implementation would not be called, which would break the recursion.
## Changelog
[Android] [Fixed] - View.getGlobalVisibleRect() clips result rect properly when overflow is 'hidden'
Pull Request resolved: https://github.com/facebook/react-native/pull/26334
Test Plan:
The functionality in question is neither used internally nor exposed by React Native, and thus only affects Android native modules that use the above referenced APIs.
As such, I have primarily performed testing with a forked example project that had been submitted with issue https://github.com/facebook/react-native/issues/23870, originally by d4vidi.
The example project can be found here:
- [Configured to build against RN Master](https://github.com/davidbiedenbach/RNClipVisibilityBugDemo/tree/rn-master)
- [Configured to build against PR branch](https://github.com/davidbiedenbach/RNClipVisibilityBugDemo/tree/fix-23870)
(Original project here: https://github.com/d4vidi/RNClipVisibilityBugDemo)
### Bug in effect:
When built against RN master, it can be observed that fully clipped views are reported as visible, as in the below screenshots.
#### Views inside a ReactViewGroup do not report as clipped
#### Views inside a ReactScrollView do not report as clipped
#### Views inside a ReactHorizontalScrollView do not report clipping properly
### Bug fixed
When built against the PR branch, fully-clipped views no longer report visible.
#### Views inside a ReactViewGroup report clipping properly
#### Views inside a ReactScrollView report clipping properly
#### Views inside a ReactHorizontalScrollView report clipping properly
Reviewed By: mdvacca
Differential Revision: D17782658
Pulled By: yungsters
fbshipit-source-id: 0cd0d385898579a7a8a3e453f6ba681679ebe496
Summary:
Currently, horizontal `ScrollViews` don't properly support `removeClippedSubviews`.
This is because the container view, `ReactHorizontalScrollContainerView` extends from regular `ViewGroup` instead of `ReactViewGroup` so doesn't have all the logic around clipping children.
Moreover, the `ReactHorizontalScrollContainerViewManager` doesn't actually support the `removeClippedSubviews` prop
This change:
- Makes `ReactHorizontalScrollContainerView` extend from `ReactViewGroup` while maintaining the special logic around RTL scrolling
- Factors out a common `ReactClippingViewManager` which will be used to bridge all components which extend `ReactViewGroup` and support clipping. It has the logic for adding/removing children and getting child counts while considering clipped subviews
- `ReactViewManager` now extends this new `ReactClippingViewManager`
- `ReactHorizontalScrollContainerViewManager` also extends `ReactClippingViewManager`
Reviewed By: JoshuaGross
Differential Revision: D17708630
fbshipit-source-id: d257566ee54ad46f6d62f176a657c596bba96aa4
Summary:
After some thought, we decided we don't need the flexibility of
separate horizontal and vertical props - it would be much nicer
to just have a single prop for the edge length and then the native
code can enable the booleans as appropriate.
Original PR: https://github.com/facebook/react-native/pull/26163
Original commit changeset: f72a9a890d90
Reviewed By: TheSavior
Differential Revision: D16997468
fbshipit-source-id: 7973262287a7ec2cee5957f8dc1806a0f28c1432
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
ScrollView doesn't handle the scrollEnabled property using dpad. When set to false, the directionnal pad still allows to scroll in the view.
## Changelog
[ANDROID] [ADDED] - Prevent scrollView to scroll with dpad when scrollEnabled property is set to false.
Pull Request resolved: https://github.com/facebook/react-native/pull/25309
Test Plan:
Add P67680731 to Playground.js and start the Catalyst Android app:
```buck install -r catalyst```
Send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_LEFT```
```adb shell input keyevent DPAD_RIGHT_RIGHT```
Make sure the ScrollView doesn't scroll to the left and right.
Add ```horizontal={true}``` to ScrollView and send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_TOP```
```adb shell input keyevent DPAD_RIGHT_BOTTOM```
Make sure the ScrollView doesn't scroll to the top and bottom.
Reviewed By: mdvacca
Differential Revision: D15983785
Pulled By: makovkastar
fbshipit-source-id: 678cc801a168531d71c8651b986c99ecd9da400e
Summary: This diff fixes a typo in the JavaDoc for ReactScrollViewManager.
Reviewed By: cpojer
Differential Revision: D15965028
fbshipit-source-id: 3506cdde21c8d00ab916455a2d9fa29772f35359
Summary:
Scrolling improvements in ReactAndroid:
1.
Issue: With current ReactHorizontalScrollView behavior, it treats all views as focusable, regardless of if they are in view or not. This is fine for non-paged horizontal scroll view, but when paged this allows focus on elements that are not within the current page. Combined with logic to scroll to the focused view, this breaks the paging for ReactHorizontalScrollView.
Fix: limit the focusable elements to only elements that are currently in view when ReactHorizontalScrollView has paging enabled
2.
Issue: When keyboard is attached and user tries to navigate through Tab key, Scroll views do not scroll to the focused child.
Since ReactScrollView handles layout changes on JS side, it does not call super.onlayout due to which mIsLayoutDirty flag in android ScrollView remains true and prevents scrolling to child when requestChildFocus is called.
Fix: To fix the focus navigation, we are overriding requestChildFocus method in ReactScrollView. We are not checking any dirty layout flag and scrolling to child directly. This will fix focus navigation issue for KeyEvents which are not handled by android's ScrollView, for example: KEYCODE_TAB. Same applies to ReactHorizontalScrollView.
3.
Set Android ScrollView to be non-focusable when scroll is disabled. Prior to this change, non-scrollable Scrollview would still be focusable, causing a poor keyboarding experience
## Changelog
[Android] [Fixed] Scrolling improvements in ReactAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/25105
Differential Revision: D15737563
Pulled By: mdvacca
fbshipit-source-id: 0d57563415c68668dc1acb05fb3399e6645c9595
Summary:
React Native Environment Info:
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 1.12 GB / 15.55 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 3.5.2 - /usr/bin/npm
SDKs:
Android SDK:
API Levels: 16, 19, 22, 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
npmPackages:
react: 16.8.6 => 16.8.6
react-native: git+https://github.com/facebook/react-native.git#v0.59.5 => 0.59.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
The workaround implemented in https://github.com/facebook/react-native/pull/21117 tries to fix
https://issuetracker.google.com/issues/112385925 scroll direction (according to the latest comments, the scroll direction problem has been reverted in security patches so not sure if the workaround is still valid).
But... proposed solution in fling method is using signum which leads to zero computedVelocityY in case of zero mOnScrollDispatchHelper.getYFlingVelocity() on old devices(Samsung s4 mini) even when real velocityY is non zero
```
final int correctedVelocityY = (int)(Math.abs(velocityY) * Math.signum(mOnScrollDispatchHelper.getYFlingVelocity()));
```
Proposed solution is to take signum from original velocityY in case of zero
```
float signum = Math.signum(mOnScrollDispatchHelper.getYFlingVelocity());
if (signum == 0) {
signum = Math.signum(velocityY);
}
final int correctedVelocityY = (int)(Math.abs(velocityY) * signum);
```
The symptoms are the same as described in issue https://github.com/facebook/react-native/issues/22925, but proposed workaround doesn't work.
[Android][fixed] - Fix smooth scrolling on old devices (SDK >=16)
Pull Request resolved: https://github.com/facebook/react-native/pull/24545
Differential Revision: D15044834
Pulled By: cpojer
fbshipit-source-id: 3f523eb1a438df774e22387aecded433b9031ab9
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
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
Summary:
It seems that the content view can sometimes be null when onOverScrolled is called (presumably when the scrollview gets unmounted while it's in the middle of scrolling?).
Changelog: [Android][fixed] - Guard against content view being null in onOverScrolled.
Reviewed By: mdvacca
Differential Revision: D14737534
fbshipit-source-id: e88ec6f585e50517b734a8809fc3843c0b22df10
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary:
Fix lint errors and warning, which might be a cause of various crashes on older Android OS, using Android Support Library.
```bash
./gradlew :ReactAndroid:lint
```
[Android] [Changed] - fix lint error/warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23333
Differential Revision: D14019322
Pulled By: mdvacca
fbshipit-source-id: 74c98da269c318cf3b114c8d9c876186369f2b8c
Summary:
RN supports API 16 and above, but we have redundant historical artifacts where we check and target APIs 16 and below. This PR removes redundant artifacts.
[Android] [Changed] - remove redundant targetApi and version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23302
Differential Revision: D13970434
Pulled By: mdvacca
fbshipit-source-id: 096b5ee6c8f076b0365e7dda0e77940290077ea2
Summary:
ScrollView (as well as FlatList) used with horizontal={true} and inverted={true} do not scroll as expected due to a known Android P bug.
Fixes#22710. This is pretty much a clone of PR #21117, applied to a horizontal ScrollView.
[Android] [Fixed] - Fix Inverted Horizontal ScrollView on Android
1. Create a test application with a FlatList with horizontal={true} inverted={true}.
2. Fill it with data
3. Scroll and release your finger
Pull Request resolved: https://github.com/facebook/react-native/pull/23233
Differential Revision: D13915911
Pulled By: cpojer
fbshipit-source-id: d32c82e6d9076f5ffdf342fcd71bd921e9c8a97b
Summary:
Motivation:
----------
This is one of the more sought after feature requests for RN:
react-native.canny.io/feature-requests/p/add-speed-attribute-to-scrollto
This PR adds the support to add a "duration" whenever using "scrollTo" or "scrollToEnd" with
a scrollView. Currently this only exists for Android as the iOS implementation will be somewhat more involved.
This PR is also backwards compatible and does not yet deprecate the "animated" boolean. It may not make sense to ever deprecate "animated", as it could be the flag that is used when devs want the system default duration (which is 250ms for Android). I'm not sure what it is for iOS. It would simplify things to remove "animated", though.
Pull Request resolved: https://github.com/facebook/react-native/pull/22884
Differential Revision: D13860038
Pulled By: cpojer
fbshipit-source-id: f06751d063a33d7046241c95348b6abbb327d36f
Summary:
This is a safe workaround to an issue in Android P: https://issuetracker.google.com/issues/112385925
It is based on a fact that even though `fling` receive a wrong sign in `velocityY`, `mOnScrollDispatchHelper.getYFlingVelocity()` still returns a fling direction.
Fixes#19434
Pull Request resolved: https://github.com/facebook/react-native/pull/21117
Differential Revision: D13082740
Pulled By: hramos
fbshipit-source-id: 1b28586d2c7bdcae4a111d3cead4a0455cebb99a
Summary: Using strings to refer to Native Modules and View Managers in ReactPackages are prone to error. The compiler replaces the constants with the actual strings anyway, so using constants gives us better type safety
Reviewed By: achen1
Differential Revision: D12843649
fbshipit-source-id: 7a7c6c854c8689193f40df92dc8426a3b37f82c8
