Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47468
Across our scroll view implementations on iOS, we fire `onMomentumScrollEnd` whenever the scroll view finishes decelerating, whether it comes from a user's touch or call to `setContentOffset` with animations. But we omit dispatching the `onMomentumScrollBegin` event in the latter cases.
This change updates both old and new architecture to dispatch `onMomentumScrollBegin` when a view-command-driven scroll occurs with animation, like `scrollTo` or `scrollToEnd`.
Changelog:
[iOS][Fixed] - Fixed `onMomentumScrollBegin` event not firing on command-driven scroll events
Reviewed By: javache
Differential Revision: D65556000
fbshipit-source-id: bc4b778c63d8a032e1d8e00b9d4d5f83a5d651d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47280
Noticed in the screenshots of https://github.com/facebook/react-native/pull/47230 that Android's logic of setting scroll content origin to zero, then right aligning scroll offset, won't correctly handle case where content is smaller than scrolling container. We can fix that by only resetting the origin when content overflows container, since we otherwise are not scrollable, and scroll adjustment will not translate.
Changelog:
[Android][Fixed] - Fix RTL ScrollView position when content smaller than container
Reviewed By: rshest
Differential Revision: D65136654
fbshipit-source-id: 2818ff6360cbfac64d7e57bdcbbe8c0a9b4bbb97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46898
Replaces *many* `Text` component usages with `RNTesterText`: a thin wrapper around `Text` that applies color based on the color scheme chosen by the user. It makes text legible for dark mode across 41 different example files. This changes intentionally do not touch a few larger component sites that expand beyond RNTester, like `Animated` and `NewAppScreen`
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D64053464
fbshipit-source-id: 9516fef2afe1b364eb38e85e3a2dbb5c434e44db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45998
The exact `React.Element` type is deprecated and will be removed in a future version of Flow.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D61205640
fbshipit-source-id: a029a3a46c7d8d9f94b0b931b991b2ce461151b2
Summary:
For the ones where `React.MixedElement` would suffice, I change them to `React.MixedElement`. For everything else, I changed it to be `React.Element`
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60798229
fbshipit-source-id: 40176b44769aade2c6b63a680d03c10056b2ddfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42127
The current scrollViewExamples does not trigger the OnScrollToTop event.
This change for Paper adds that and refactors the codebase to isolate that example.
## Changelog:
[Internal] - Improve RNTester ScrollView example adding OnScrollView event.
Reviewed By: sammy-SC
Differential Revision: D52509669
fbshipit-source-id: 8fd0fcca7153ba41bf054832928e661ef7dff3fe
Summary:
This is a reopened version of https://github.com/facebook/react-native/issues/35224 by isidoro98 which was closed without explanation, updated to resolve new merge conflicts and now includes an example in the RN-Tester app. Aside from that it is unchanged. Here is isidoro98's description from their original PR:
This PR builds on top of https://github.com/facebook/react-native/issues/31402, which introduced the `automaticallyAdjustsScrollIndicatorInsets` functionality. It aims to fix one of RN's longstanding pain point regarding the keyboard.
The changes provide a better way of handling the `ScrollView` offset when a keyboard opens. Currently, when a keyboard opens we apply an **offset** to the `Scrollview` that matches the size of the keyboard. This approach is great if we are using an `InputAccessoryView` but if we have multiple `TextInputs` in a `ScrollView`; offsetting the content by the size of the keyboard doesn't yield the best user experience.
## Changelog:
[iOS] [Changed] - Scroll `ScrollView` text fields into view with `automaticallyAdjustsScrollIndicatorInsets`
Pull Request resolved: https://github.com/facebook/react-native/pull/37766
Test Plan:
The videos below compare the current and proposed behaviors for the following code:
```js
<ScrollView
automaticallyAdjustKeyboardInsets
keyboardDismissMode="interactive">
{[...Array(10).keys()].map(item => (
<CustomTextInput placeholder={item.toString()} key={item} />
))}
</ScrollView>
```
| Current behaviour | Proposal |
|-|-|
|  |  |
As can be seen in the video, the **current behavior** applies an offset to the `ScrollView` content regardless of where the `TextInput` sits on the screen.
The proposal checks if the `TextInput` will be covered by the keyboard, and only then applies an offset. The offset applied is not the full size of the keyboard but instead only the required amount so that the `TextInput` is a **specific** distance above the top of the keyboard (customizable using the new `bottomKeyboardOffset` prop). This achieves a less "jumpy" experience for the user.
The proposal doesn't change the behavior of the `ScrollView` offset when an `InputAccessory` view is used, since it checks if the `TextField` that triggered the keyboard is a **descendant** of the `ScrollView` or not.
## Why not use other existing solutions?
RN ecosystem offers other alternatives for dealing with a keyboard inside a ScrollView, such as a `KeyboardAvoidingView` or using third party libraries like `react-native-keyboard-aware-scroll-view`. But as shown in the recordings below, these solutions don't provide the smoothness or behavior that can be achieved with `automaticallyAdjustsScrollIndicatorInsets`.
| KeyboardAvoidingView | rn-keyboard-aware-scroll-view |
|-|-|
|  |  |
As shown in the videos, the `TextInput` is hidden by the keyboard for a split second before becoming visible.
Code for the videos above:
```js
// KeyboardAvoidingView
<KeyboardAvoidingView
style={{flex: 1, flexDirection: 'column', justifyContent: 'center'}}
behavior="padding"
enabled>
<ScrollView>
{[...Array(10).keys()].map(item => (
<CustomTextInput placeholder={item.toString()} key={item} />
))}
</ScrollView>
</KeyboardAvoidingView>
```
```js
// rn-keyboard-aware-scroll-view
<KeyboardAwareScrollView>
{[...Array(10).keys()].map(item => (
<CustomTextInput placeholder={item.toString()} key={item} />
))}
</KeyboardAwareScrollView>
```
Reviewed By: sammy-SC
Differential Revision: D49269426
Pulled By: javache
fbshipit-source-id: 6ec2e7b45f6854dd34b9dbb06ab77053b6419733
Summary:
Reland of https://github.com/facebook/react-native/issues/35319 with a fix for custom pull to refresh components.
Custom pull to refresh component in fabric will need to conform to the `RCTCustomPullToRefreshViewProtocol` protocol, this way we know that the view is a pull to refresh and not the content view.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [ADDED] - Add fabric support for maintainVisibleContentPosition on iOS
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36095
Test Plan:
This will need to be tested internally in the product the crash happened.
Take a local build of Wilde open Marketplace.
Reviewed By: jacdebug
Differential Revision: D43128163
Pulled By: cipolleschi
fbshipit-source-id: 6cf8ddff92aeb446072a3d847434e21b9e38af61
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary:
Add explicit annotations to React hook callbacks as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
This diff adds `any` or `$FlowFixMe` in cases where more precise types could not be determined.
Details:
- Codemod script: `.facebook/flowd codemod annotate-react-hooks ../../xplat/js --default-any --write`
- Local Type Inference announcement: [post](https://fb.workplace.com/groups/flowlang/posts/788206301785035)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
bypass-lint
Reviewed By: SamChou19815
Differential Revision: D41231214
fbshipit-source-id: d5f5ce8d61020baa1138292c9e9f1c69dffd324c
Summary:
The `typeof X` type annotation now respects the initialization state of `X`: if `X` hasn't been declared it will be an error to get its type.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D40638870
fbshipit-source-id: 57459dec30ec5b87397365a709f2d846c87e378a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
ScrollView's contentOffset prop was assumed to be iOS only, but in reality it is supported on Android as well: https://fburl.com/code/nuxpjpth
Changelog:
[General] - Move ScrollView's contentOffset to common props
Reviewed By: yungsters
Differential Revision: D36219604
fbshipit-source-id: f41679fd2ce7971a30129e0d91ae9f32b9cf756e
Summary:
Changelog:
[Internal]
Cleans up unnecessary type casts / suppressions throughout the codebase following D35869725.
Reviewed By: javache
Differential Revision: D35870027
fbshipit-source-id: eefcb544b19ba93587011cdfd4046d18dddb246e
Summary:
`Easing` only has static properties and is never constructed or subclassed, so there doesn't seem to be any reason for it to be a class instead of an object.
as a class, Flow errors about `method-unbinding` on every single use of it.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33774944
fbshipit-source-id: c0bd2e3d7a78e538f95b88b2b1b12d301c8f590c
Summary:
This diff runs the codemod to add type annotations to function parameters in preparation for Flow's local type inference (LTI) project. I ran the codemod over xplat/js and reverted any files that had flow errors in them. See the list of commands run to see the regeneration of various files.
Changelog:
[Internal][Changed] - Added type annotations
Reviewed By: yungsters
Differential Revision: D32075270
fbshipit-source-id: 6a9cd85aab120b4d9e690bac142a415525dbf298
Summary:
Change usages of `exports.foo` and `module.exports.foo` to just `foo`.
This will fix future errors when Flow no longer allows reads from `exports`/`module.exports`.
Changelog: [Internal]
Reviewed By: bradzacher
Differential Revision: D32009490
fbshipit-source-id: bb609b37ba948b44c3877f8dbbfa9137b963586b
Summary:
This diff implements the SnapToAlignment functionality in ReactHorizontalScrollView for RN Android.
In order to use SnapToAlignment, the pagingEnabled prop should be set
Based on the documentation the behavior implemented in this diff is more "advanced" than the one implemendted in RNiOS, because it let you snap without specifying any interval nor offset (it calculates the intervals in real time based on the size of its content)
I still need to verify how different RNiOS and RN Android behaviors are
changelog: [Android][Added] Implement SnapToAlignment in ReactHorizontalScrollView
Reviewed By: JoshuaGross
Differential Revision: D31174544
fbshipit-source-id: 204a82f55e3b7598124ce2528d8ad7d854c0ac77
Summary:
There was an unused example in ScrollView example, so I've added the example to RNTester App
## 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
-->
[Internal] [Added] - Added persistentScrollbar option example for ScrollView in RNTester App
Pull Request resolved: https://github.com/facebook/react-native/pull/31895
Test Plan: - RNTester App builds and shows example properly on Android
Reviewed By: sshic
Differential Revision: D29881126
Pulled By: mdvacca
fbshipit-source-id: 9e7e61c9d3f712cb767a78e729469fc95cb9953e
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## 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] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary:
Changelog:
[Internal] - Rename some types and components in RNTester to support work for tertiary levels of navigation.
module = component | api
moduleExample = an example of a certain feature a module
Reviewed By: kacieb
Differential Revision: D29381875
fbshipit-source-id: c348bcbb73aaf95e85928bb14080a097e685cc78
Summary:
Add a test case showing off a pressable sticky header to RNTester.
Note that this test case does not follow the styling of the other ScrollView Examples. I chose not to make it follow the styling because the existing examples need to be refactored later to not use custom buttons.
Changelog:
[General][Added] Add Pressable Sticky Header example to ScrollViewExamples in RNTester
Reviewed By: lunaleaps
Differential Revision: D29437827
fbshipit-source-id: 3ccee5df99bc6f00a04e1ecbd47fbe86b1eda4dc
Summary:
Adding a minHeight property messed up some screenshot tests. T93437971
I'm honestly not sure why this happened since that ScrollView container has a fixed height set of 300, so it shouldn't have changed heights... It didn't change heights in RNTester.
We should probably take the full example (including title etc.) from RNTester for our E2E tests to avoid these types of weird layout breakages in the future.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29201224
fbshipit-source-id: 30b98fa43d06eec1da345becc473690a3b075fb7
Summary:
Quick fix to fix a few test cases that had very small height buttons. (buttons became like this after flex: 1 was added to them in D29082450 (https://github.com/facebook/react-native/commit/f12f0e679dd6f1cdbd3c993d940a736ea1e952a3))
Added a minHeight to the buttons and added Views around groups of buttons.
Eventually we should update these examples to not use a custom button.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29145288
fbshipit-source-id: 238c298a25b33da662b4897399f82ad0aa29b9cd
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
A few places in RNTester where using hard coded color values, which meant the UI looks broken in dark themes.
The area behind the bookmark button was using a solid color png file, which I've replaced with a color from the theme object.
## Changelog
[Internal] [Fixed] - Fix a couple of places RNTester is using non-theme values
Pull Request resolved: https://github.com/facebook/react-native/pull/31479
Test Plan: Verified in RNTester in react-native-windows in light+dark theme.
Reviewed By: TheSavior
Differential Revision: D28290192
Pulled By: rozele
fbshipit-source-id: 78192200ac2dc8629759c10f8e8b3ec2f6699acd
