Summary:
It looks like `ScrollView` still contains the remnant props for VR platform, which afaik has be discontinued a while ago (please correct me, if I'm wrong).
This PR removes `scrollBarThumbImage` prop marked as VR platform only prop from `ScrollView`.
## 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
-->
[VR] [Removed] - remove VR platform specific `scrollBarThumbImage` prop from `ScrollView`
Pull Request resolved: https://github.com/facebook/react-native/pull/31230
Test Plan: CI
Reviewed By: javache
Differential Revision: D27367267
Pulled By: PeteTheHeat
fbshipit-source-id: b76fdb0e03c443aaf87308162bf75f8683220918
Summary:
When there are multiple sticky headers, ScrollViewStickyHeader should push up the header above it when it gets to the top.
This behavior was accidentally changed in D21948830 (fa5d3fb6b8) when this component was fixed to work in Fabric.
This diff added a new variable `_shouldRecreateTranslateY`, which determines whether the `translateY` value should be recreated on render. `_shouldRecreateTranslateY` was not being set to true during `setNextHeaderY`, so the next header's Y value was never accounted for at render.
Changelog:
[General][Fixed] Fix ScrollViewStickyHeader to push up header above it
Reviewed By: lunaleaps
Differential Revision: D27277829
fbshipit-source-id: 83c9aacd454be178649bf8d060d1a5c750f4060f
Summary:
Flow is changing the behavior of object types to no longer be valid supertypes of classes. This replaces object types when they appear as supertypes of classes to be interfaces to avoid errors when this change rolls out.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D27193522
fbshipit-source-id: c3e3fca8a4cacd90770a95b773ff2c659774b9a6
Summary:
https://github.com/facebook/react-native/issues/30950
automatically set `disabled` to accessibilityState when TouchableHighlight is disabled
## 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
-->
[General] [Changed] - Set disabled accessibilityState when TouchableHighlight is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/31135
Test Plan: Tested on physical android device that pressing disabled TouchableHighlight announces "dim" when talkback is on
Reviewed By: yungsters, nadiia
Differential Revision: D27157207
Pulled By: kacieb
fbshipit-source-id: b8e24aad699c43cf02401b3ba39726a06b751995
Summary:
Issue # https://github.com/facebook/react-native/issues/30934 .When using a screen reader disabled buttons do not announce that they are disabled.
## Changelog
[Android] [Changed] - Passing accessibility state in button so it can announce disabled in talkback
Pull Request resolved: https://github.com/facebook/react-native/pull/31001
Test Plan:
I have added Button in Button Example with accessibiltyState prop that will announce button is disabled when testing with talkback.
## Ios test
I am unable to run ios project on my machine. RNTesterPods.xcworkspace gives workspace integrity error :/
Reviewed By: kacieb
Differential Revision: D26492483
Pulled By: lunaleaps
fbshipit-source-id: c4bbe8ca896b0d303976591c300ccac67a96ac73
Summary:
Restore deprecated event listener removal methods in order to minimize breaking changes for the next release. The methods will work, but they will not report a warning via `console.error`.
Changelog:
[General][Added] - `EventEmitter.removeListener` now emits a deprecation notice.
[General][Added] - Restored `AppState.removeEventListener` with a deprecation notice.
[General][Added] - Restored `Keyboard.removeEventListener` with a deprecation notice.
[General][Added] - Restored `Linking.removeEventListener` with a deprecation notice.
Reviewed By: nadiia, kacieb
Differential Revision: D26589441
fbshipit-source-id: 7d89982a182cf2163136e157d4c1beee91c30393
Summary:
Add a stickyHeaderHiddenOnScroll option to keep the sticky header hidden during scrolling down, and only slide in when scrolling up
Changelog:
[General][Added] - Add a stickyHeaderHiddenOnScroll option to keep the sticky header hidden during scrolling down, and only slide in when scrolling up
Reviewed By: JoshuaGross
Differential Revision: D26900810
fbshipit-source-id: 6bfb1a4da07fff0763223d60836df187f9d95dd6
Summary:
This diff migrates AndroidDropdownPicker to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26810196
fbshipit-source-id: 7be0396d49d9e1413d424ab1be035cbb6a211706
Summary:
This diff migrates AndroidDialogPicker to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26799476
fbshipit-source-id: d6605f60cc083d1d22b4f0fc0a2f79881502b1b4
Summary:
This diff migrates RCTPicker to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26799477
fbshipit-source-id: 2f5935e0a4796c7a76921762a087cf7823ebd62e
Summary:
# The bug
Sticky headers would not "stick" to the top of the ScrollView on initial render. On subsequent redners, all sticking would work correctly.
# Why the bug existed
This code to initialize the animated values used for sticky headers was in `UNSAFE_componentWillMount` prior to D26375818 (1641d46529). `UNSAFE_componentWillMount` is called before `render`.
In D26375818 (1641d46529), I moved the code into `componentDidMount`, which is called after `render`.
This caused a problem because code in `render` was relying on these initializations being done already.
# How I resolved the bug
To resolve this, I initialize these values in the constructor.
# Reference
Docs for React mount ordering: https://reactjs.org/docs/react-component.html#mounting
Changelog:
[General][Fixed] Fix sticky header not sticking on first render in ScrollView
Reviewed By: nadiia
Differential Revision: D26792003
fbshipit-source-id: c575e8cdd1d986ce3c38941d95d763e329e74874
Summary:
Changelog:
[General][Changed] Hide caret in the TextInput during test runs.
Reviewed By: lunaleaps
Differential Revision: D26728766
fbshipit-source-id: b75827f00b4d5c6243d93106093f97b40dc4b366
Summary:
We recently fixed RTL scrolling in Fabric on iOS: D26608231 (e5921f7f38)
Turns out, the mechanism for RTL scrolling on Android is completely different. It requires that content be wrapped in a "directional content view", which is `View` in LTR and `AndroidHorizontalScrollContentView` in RTL, backed by `ReactHorizontalScrollContainerView.java`.
iOS doesn't require that and just uses View and some custom logic in ScrollView itself.
In the future it would be great to align the platforms, but for now, for backwards-compat with non-Fabric and so we don't have to tear apart ScrollView.js, we codegen the AndroidHorizontalScrollContentView so it exists in C++, register the component, and stop mapping it to View explicitly in C++.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26659686
fbshipit-source-id: 3b9c646dbdb7fe9527d24d42bdc6acb1aca00945
Summary:
This diff removes `UNSAFE_componentWillReceiveProps` and adds the changes to `componentDidUpdate` instead.
Why use `componentDidUpdate`? When reading through the [React docs on removing UNSAFE_componentWillReceiveProps](https://reactjs.org/docs/react-component.html#unsafe_componentwillreceiveprops), it says:
> If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
The original usage of `UNSAFE_componentWillReceiveProps` updates the content inset when `props.contentInset` changes. However, we don't always want it to update if the content inset hasn't changed, as calling `setValue` will reset the animated value unnecessarily, and kill any current animations (which we don't want to do). [React Native doc on setValue for reference](https://reactnative.dev/docs/animatedvalue#setvalue).
Changelog:
[General] Use componentDidUpdate instead of UNSAFE_componentwillReceiveProps in ScrollView
Reviewed By: lunaleaps
Differential Revision: D26487276
fbshipit-source-id: 77419deacf5db676cd721b58f34932bd6ca2399f
Summary:
The purpose of this diff is to move all of the ScrollResponder methods into ScrollView to delete ScrollResponder.Mixin.
NOTE: ScrollResponder.Mixin uses a variable named "state" but it does not use React state correctly. Instead of calling `setState()`, state is set using `this.state.item = 123` ([example](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Components/ScrollResponder.js?lines=315)). This means these are not actually React state - these are functionally just variables. In this stack, these "state" items from ScrollResponder are turned into regular internal variables.
Changelog:
[General][Removed] Moved ScrollResponder.Mixin methods into ScrollView to Remove ScrollResponder.js
Reviewed By: lunaleaps, nadiia
Differential Revision: D20715880
fbshipit-source-id: 99441434a6dc1c8ff3f435e7d6ec2840821e4e05
Summary:
Simplifies `Keyboard` by removing redundant methods and changing `addEventListener` to return an `EventSubscription`.
Changelog:
[General][Changed] - `Keyboard.addListener` now returns an `EventSubscription` object.
[General][Removed] - Removed `Keyboard.removeListener`. Instead, use the `remove()` method on the object returned by `Keyboard.addListener`.
[General][Removed] - `Keyboard` no longer inherits from `NativeEventEmitter`, so it no longer implements `removeAllListeners`, and `removeSubscription`.
Reviewed By: milroc
Differential Revision: D26163536
fbshipit-source-id: b4bd91627cd027a13fcba269a253823913eb7589
Summary:
It is currently possible to activate a disabled Pressable with VoiceOver/TalkBack. This fixes this.
Changelog:
[General][Fixed] Fix disabled prop not disabling onPress for voice assistant
Reviewed By: blavalla
Differential Revision: D26225448
fbshipit-source-id: 67fa10f9e5c50143d986dc709a2fb639fdc3e718
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
This is just cleanup. When I migrated components to `Pressability` instead of `Touchable`, I left `TOUCH_TARGET_DEBUG` alone to minimize moving pieces. But I had created `PressabilityDebug` as the eventual destination for this logic.
Now that `Text` is migrated away from `Touchable` (see D26106824 (f275514f27)), this cleans up the final internal reference to `Touchable`.
Changelog:
[General][Changed] - `Touchable.renderDebugView` now accepts `ColorValue` instead of `string | number`.
[General][Removed] - Removed `Touchable.TOUCH_TARGET_DEBUG` property.
Reviewed By: kacieb
Differential Revision: D26108570
fbshipit-source-id: 2694c9a9c29182ae04a77ba6c2e4406fcd5a277e
Summary:
`sendAccessibilityEvent_unstable` is a cross-platform, Fabric/non-Fabric replacement for previous APIs (which went through UIManager directly on Android, and a native module on iOS).
Changelog: [Added] sendAccessibilityEvent_unstable API in AccessibilityInfo and sendAccessibilityEvent in React renderer
Reviewed By: kacieb
Differential Revision: D25821052
fbshipit-source-id: 03f7a9878c95e8395f9102b3e596bfc9f03730e0
Summary:
This diff adds TextInput in the list of components that support static view configs
changelog: [internal]
Reviewed By: yungsters
Differential Revision: D26040854
fbshipit-source-id: d6b5d3a78ef4657acf3f2c4ebe527ad4ca40bcb5
Summary:
This diff changes the flow types of RefreshControl.size prop from 'int' to string'. For more context see previous diff of the stack.
This diff will be landed as soon as the native release containing D25933458 (65975dd28d) goes to production.
It's important to clarify that there are currently no usages of this prop in production
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933457
fbshipit-source-id: 2f34566f2f8a097e6d40f63c09ecb3ada2fd8409
Summary:
This diff changes the type of the SwipeRefreshLayoutManager.size prop from Int to String in Fabric.
The current implementation of this prop allows JS developers to use "int" type when fabric is enables and "int or string" types when using Fabric is disabled.
Since long term we want to only support "string" type for this prop, I'm changing the type of the prop to be String.
After my diff Fabric will start supporting only "string" types, non fabric screens will keep supporting "int or string" values.
**Will this break production?**
No, because there are no usages of RefreshControl.Size prop in fbsource
**What about if someone start using this prop next week?**
IMO It's very unlikely because of the nature of this prop, I will be monitoring next week and if there's an usage it will be detected by flow when trying to land D25933457.
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933458
fbshipit-source-id: 55067d7405b063f1e8d9bb7a5fd7731f5f168960
Summary:
Changelog: [internal]
Revert a change introduced in https://github.com/facebook/react-native/pull/30333 where rickhanlonii asked it to be reverted as well.
The change breaks sticky header in Fabric.
Reviewed By: rubennorte
Differential Revision: D25883861
fbshipit-source-id: b01305c6def390d0664c7be939ab3fc72186a07a
Summary:
Adds types to Event Emitters and migrates the most relevant modules using them in `react-native`.
The most relevant file of this diff is `react-native/Libraries/vendor/emitter/__flowtests__/EventEmitter-flowtest.js` with the Flow tests showing and testing the behavior of the new types
Changelog: [Internal] Add types for Event Emitters and subclasses
Reviewed By: motiz88
Differential Revision: D25587936
fbshipit-source-id: feeb09f9ad15d383cdd82deaaaba0d12b94e868b
Summary:
This prevents having to modify too many files when we add the proper typing for that module
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25586848
fbshipit-source-id: 16001ada4a37a58f83b6e5a4400daebf9257be72
Summary:
Migrates all usages of `NativeEventEmitter` to `NativeEventEmitter<$FlowFixMe>`.
This prevents having to modify a very large number of files in the same change that adds support for typed events. It adds an unused typed parameter to `NativeEventEmitter` so we can change all usages to add `$FlowFixMe`.
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25575774
fbshipit-source-id: c7979e1502e980401d9c03456282eba333c1606d
Summary:
Even though replacing an error with a warning does not look like a future-proof solution here are the reasons for this:
* The measuring operation might just fail because of the async nature of React Native. And here, from my understanding, we don't even have a good reason for measuring. Auto-scrolling to selected textinput (which is the reason for this code, AFAIK) is a standard feature that OS does for all text input. I suspect that this (very old) feature was built in a timeframe where this system feature was originally broken (sometime before 2016).
* This product-facing API does not have an error-callback, so just loggin an error here is as (not) actionable as logging a warning.
* The error callback was never implemented in the pre-Fabric world, so it *never* got called for years, and now when Fabric is starting calling in some cases, it is being "punished" for this. In the next diff, I will try to retrofit this feature back to Paper to reach parity with Paper.
Changelog: [Internal]
Differential Revision: D25700156
fbshipit-source-id: 319a146b17cc2130848148ad11adbde16e86c5d5
Summary:
According to https://github.com/facebook/react-native/issues/20011, the first onPress will not work after pull to refresh.
Dive into the code, found out that is because the state `isTouching` in `Libraries/Components/ScrollResponder.js` is not updated after the pull to refresh.
Update the `isTouching` state in `scrollResponderHandleResponderRelease` to fix this.
## 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] - First press not working after pull to refresh
Pull Request resolved: https://github.com/facebook/react-native/pull/30291
Test Plan:
### Before
- The first onPress fail
### After
- The first onPress success
Eli:
I tested this myself internally using this code sample:
```
'use strict';
import PlaygroundRoute from 'PlaygroundRoute';
import type {SurfaceProps} from 'Surface';
import TetraText from 'TetraText';
import TetraView from 'TetraView';
import {TouchableOpacity, Text, View, ScrollView, RefreshControl, StyleSheet} from 'react-native';
import * as React from 'react';
type Props = SurfaceProps<PlaygroundRoute>;
class App extends React.Component<{}> {
constructor() {
super();
this.state = {refreshing: true, items: []};
}
componentDidMount() {
this.refresh();
}
refresh = () => {
this.setState({
refreshing: true,
items: [],
});
setTimeout(
() =>
this.setState({
refreshing: false,
items: [0, 1, 2, 3, 4, 5],
}),
1500,
);
};
renderItem = ({item}) => {
return (
<TouchableOpacity onPress={() => alert('pressed!')} key={`${item}`}>
<Text style={{width: '100%', height: 48, backgroundColor: 'white'}}>
{item}
</Text>
<View style={{width: '100%', height: 1, backgroundColor: 'gray'}} />
</TouchableOpacity>
);
};
render() {
return (
<View style={{flex: 1, padding: 48}}>
<ScrollView
style={{
flex: 1,
backgroundColor: '#aaa',
borderColor: 'gray',
borderWidth: 1,
}}
keyExtractor={item => `${item}`}
refreshControl={
<RefreshControl
refreshing={this.state.refreshing}
onRefresh={this.refresh}
/>
}>
{this.state.items.map(item => this.renderItem({item}))}
</ScrollView>
</View>
);
}
}
export default function Playground(props: Props): React.Node {
return (
<App />
);
}
const styles = StyleSheet.create({
container: {
padding: 10,
paddingTop: 30,
},
});
```
{F351458967}
Reviewed By: appden
Differential Revision: D25574927
Pulled By: TheSavior
fbshipit-source-id: 7abf8a2f947d94150419e51d46a19e792441c981
Summary:
Changelog: [General][Fixed] Fix stalling UI due to a bug in KeyboardAvoidingView
I introduced this bug in D22764192 (b08fff6f86).
The stalling was caused by onLayout in JavaScript triggering native layout which called onLayout in JavaScript without terminating condition.
The fix is to only cause native layout once from JavaScript's onLayout function. This makes sure both Fabric and Paper works correctly and UI stall isn't caused.
Resolves:
https://github.com/facebook/react-native/issues/30495https://github.com/facebook/react-native/issues/30532
Reviewed By: TheSavior
Differential Revision: D25522362
fbshipit-source-id: 602e540bb1c40ae4f421b3e6ebc5a047cd920c17
Summary:
Migrates `View` to use `NativeComponentRegistry`, which enables configuring it to avoid reflection by using a static `ViewConfig`.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25136054
fbshipit-source-id: f2abda1105bd2a8b396db6f1a640430b62bbcdaf
Summary:
There may be assumptions that `Native*.js` contains TurboModule. In order to avoid introducing unplanned breaking changes (especially right before the holidays), roll this back for now.
In doing so, I also realized that I forgot to migrate over `ScrollContentViewNativeComponent`. This does that, too.
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D25129324
fbshipit-source-id: 343c4b800969dab91f7cd9f2bf253788c94d38e6
Summary:
Migrates `ScrollView` (and its related native components) to use `NativeComponentRegistry`. This will enable it to be configured using experiments to conditionally use the native `ViewConfig` or verify the static `ViewConfig`.
This also cleans up a bunch of the modules and types related to defining the native `ScrollView` component.
This also proposes adopting the same module naming protocol was has been adopted for TurboModules (i.e. `NativeScrollView` instead of `ScrollViewNativeComponent`).
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25098530
fbshipit-source-id: ff1394bfac023daf58e85d5f9068e4f8da3538be
Summary:
Fixes some of the type errors in `ScrollView` that were previously being suppressed by comments. This also slightly simplifies the implementation of `ScrollView`.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D25097225
fbshipit-source-id: a444db8179c91e264671d8f32431b93c4da8dfc4
Luna Wei
Kacie Bawiec
simek
Daniel Sainati
Jesse Katsumata
David Vacca
Huzaifa Khan
David Biedenbach
Tim Yung
Yan Zhang
Nadiia D
Joshua Gross
Paige Sun
Micha Reiser
Vladislav Shabanov
Samuel Susla
Valentin Shergin
Igor Klemenski
Kshitij Kotasthane
Rubén Norte
Mike
