Summary:
This PR fixes the opacity bug where it fails to properly react to state change. This PR resolves the issue detailed in https://github.com/facebook/react-native/issues/32476
## 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] [Fixed] - Fixed opacity value in TouchableOpacity
Pull Request resolved: https://github.com/facebook/react-native/pull/32956
Test Plan: The code I added in componentDidUpdate does solve the issue and passes all the test cases
Reviewed By: ryancat
Differential Revision: D33766718
Pulled By: cortinico
fbshipit-source-id: 951bedf22619fc12e66156d0a6074cd8adf1d3eb
Summary:
Invoke registerForRemoteNotifications on main UI thread to avoid error messages in Xcode.
Changelog:
[iOS][Fixed] - Invoke registerForRemoteNotifications on main UI thread.
Reviewed By: philIip
Differential Revision: D33780141
fbshipit-source-id: 64b825dfc15e7ac262e210b90bb334a7e415e402
Summary:
## Rationale
verifyComponentAttributeEquivalence is the legacy check for making sure that Static ViewConfigs match Native ViewConfigs. Eventually, we should just delete this module/check from the codebase.
## Changes
This diff migrates the RNHostComponentViewConfig differences screen to display the ViewConfig differences using the new StaticViewConfigValidator validation result vs the legacy validator's lefthandObjectDiff method.
## Benefits:
- Now, **all the diffing logic** on this route uses the new StaticViewConfigValidator.
- This takes us one step closer towards deleting verifyComponentAttributeEquivalence
- StaticViewConfigValidator [supports ignoring ViewConfig properties](https://fburl.com/code/2it5r7py). Now, the RNHostComponentViewConfig respects these ignores.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34017602
fbshipit-source-id: 3ad909adcbb95b932a269dd55dd5445834a9cfd4
Summary:
Changelog: [Internal]
Fixes some files to use the preferred `import type {Foo}` syntax instead of `import {type Foo}`.
Reviewed By: rh389
Differential Revision: D34001108
fbshipit-source-id: 64675fefa71b6832118eabc60c825c65b87514d9
Summary:
Changelog:
[General][Fixed] - Remove illegal private property access in VirtualizedSectionList.scrollToLocation
`VirtualizedSectionList.scrollToLocation` internally uses `VirtualizedList`'s `_getFrameMetricsApprox` method. This method is private by convention (since it's `_`-prefixed), but under certain build setups this is also enforced at runtime, so using `scrollToLocation` can throw an error.
Here, we rename this internal method to `__getFrameMetricsApprox` (adding another leading underscore) which opts it out of being treated as private, while still communicating that it's not part of the public API. We also delete the Flow error suppression that masked this issue.
For reference: This convention for private methods (including the double-underscore opt out) has its roots in Facebook's pre-Babel [JSTransform](https://github.com/facebookarchive/jstransform/blob/master/visitors/es6-class-visitors.js) compiler and is implemented in Flow as [`munge_underscores=true`](https://flow.org/en/docs/config/options/#toc-munge-underscores-boolean).
Reviewed By: yungsters
Differential Revision: D33982339
fbshipit-source-id: 498563c59d42549c94fe90d363677d6d3ea35d2d
Summary:
Changelog:
[General] [Changed] Type the argument of Animated.interpolate as read-only
Reviewed By: javache
Differential Revision: D33950698
fbshipit-source-id: b959d34eb9752358f4a8ba1d290b56c099f535e0
Summary:
The JS-side animated node values were not being updated on AnimatedValue (and thus AnimatedValueXY); however, the native event "onAnimatedValueUpdate" is being handled properly in AnimatedNode. It turns out that single underscore prefixed methods are obfuscated at FB. And thus AnimatedValue._onAnimatedValueUpdateReceived was not getting called. Changing the method name to double underscore as a way to denote "protected" fixes the issue.
Changelog:
[General][Fixed] - JS animated node value updates properly when listener is attached
Reviewed By: yungsters
Differential Revision: D33962038
fbshipit-source-id: c4f60e1f1ccc0cef3e65b89034bdb91376a26416
Summary:
Removes the `propTypes` member from the `Image`, `Text`, and `TextInput` components.
They have been deprecated since React Native v0.66.
Changelog:
[General][Removed] - Removed `Image.propTypes`, `Text.propTypes`, and `TextInput.propTypes`.
Reviewed By: kacieb
Differential Revision: D33750298
fbshipit-source-id: 085f83ad838196bdd531b097b8ce5957270c3ad1
Summary:
Adds support for platform colors in AnimatedColor.
Passes the processed native color object to the native ColorAnimatedNode via the native config; ColorAnimatedNode then uses ColorPropConverter.getColor to resolve the resource path.
Note: setting a platform color via setValue on an existing AnimatedColor is not supported yet
Changelog:
[Android][Added] - Support platform color with AnimatedColor
Reviewed By: yungsters
Differential Revision: D33922266
fbshipit-source-id: 04d39a5ce0872b31d06ffbd4639d2f2213cf3314
Summary:
## Impact
Fix the Static ViewConfig for <View/>.
This diff fixes the base ViewConfig for all HostComponents on both platforms. Consequently, it simplifies SVC reconciliation efforts, by nearly eliminating the first of these classes of SVC errors:
1. Unexpected properties in SVC
2. Missing properties in SVC
3. Not matching properites in SVC
## What is the base ViewConfig on each iOS/Android?
**On iOS:**
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, the base ViewConfig for all components should be <View/>'s static ViewConfig.
**On Android:**
The component model is a bit more complicated:
https://pxl.cl/1Vmp5
Takeaways:
- Props come from Shadow Nodes **and** ViewManagers
- Nearly all HostComponent ViewManagers extend BaseViewManager. But, that's not <View/>'s ViewManager.
- <View/>'s ViewManager is [ReactViewManager](https://fburl.com/code/0zalv8zk), which is a descendent of BaseViewManager, and declares its own ReactProps.
So, on Android, it's not safe for the base ViewConfig to be <View>'s ViewConfig:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
So, what should the base ViewConfig be on Android?
- Nearly all components extend BaseViewManager. BaseViewManager must have a shadow node [that extends LayoutShadowNode](https://www.internalfb.com/code/fbsource/[47d68ebc06e64d97da9d069f1ab662b392f0df8a]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/BaseViewManager.java?lines=40). Therefore, we'll make the base ViewConfig on Android be generated by BaseViewManager + LayoutShadowNode.
## Changes
In this diff, I removed ReactNativeViewViewConfig, and introduced a new view config called PlatformBaseViewConfig. This ViewConfig partial will capture all the props available on all HostComponents on **both** platforms. This may not necessarily be the props made available on <View/>.
The only components that don't extend the base platform props are: RCTTextInlineImage. What we do with these components is TBD.
Changelog: [Internal]
Reviewed By: p-sun, yungsters
Differential Revision: D33135055
fbshipit-source-id: 7299f60ae45ed499ce47c0d0a6309a047bff90bb
Summary:
JS changes to support D32138347 (a96bdb7154). This was previously reverted due to missing iOS Paper support.
Changelog: [Android][Fixed] Enable hitSlop to be set using a single number.
Original commit changeset: 91cfcc86582c
Original Phabricator Diff: D32559015 (589b129581)
Reviewed By: yungsters
Differential Revision: D33453327
fbshipit-source-id: d289a0a8b8208bc9c68e6ca537632b745e8196ed
Summary:
Adds support for Animated.Color with native driver for Android. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into an integer (0xaarrggbb)
Followup changes will include support for iOS and platform colors.
Changelog:
[Android][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: javache
Differential Revision: D33833600
fbshipit-source-id: 2bf05c9715b603cf014ace09e9308b2bfd67f30a
Summary:
In addition to rgba values, allow creating Animated.Color with a string color.
Followup changes will include support for platform colors and native driver.
Changelog:
[General][Added] - Support string color values in Animated.Color
Reviewed By: javache
Differential Revision: D33810717
fbshipit-source-id: 208bc2675b6153a515fbf2122da15a065c473e73
Summary:
Creates Animated.Color for animating color props.
Implement AnimatedColor, which basically consists of 4 AnimatedValues (along the same vein as ValueXY) which allows us to just use AnimatedValue's interpolation. Provides a string color value of shape 'rgba(r, g, b, a)'
AnimationNode DAG looks like:
{F696076974}
Followup changes will include support for string color values, platform colors, and native driver.
Changelog:
[General][Added] - New Animated.Color node
Reviewed By: mdvacca
Differential Revision: D33778456
fbshipit-source-id: 83ddbc955156bf589c864f229a5f83fe6875fd0e
Summary:
Adding string annotations support to markEvent API in ReactNative
Changelog:
[Internal][Change] - markEvent API now supports string annotations
Differential Revision: D33795346
fbshipit-source-id: 414cbd08ce5ff6045e2f35ae77059be5add3d834
Summary:
QPL in ReactNative were missing markEvent API - adding it in this diff. In the next diff I will add support for annotations.
Customer request: https://fb.workplace.com/groups/QPL.QandA/posts/1228789167531266/
Changelog:
[Internal][Change] - Adding markEvent API to QuickPerformanceLogger
Differential Revision: D33789590
fbshipit-source-id: 3e9dfde9d413943281d6aa7e85b9feeafc3bef7a
Summary:
In Animated, when a toValue of AnimatedValue (as opposed to a number) is passed in, the [AnimatedValue starts tracking via AnimatedTracking](https://www.internalfb.com/code/fbsource/[b688f3747a706236fce300636978ed1ca5e4081a]/xplat/js/react-native-github/Libraries/Animated/AnimatedImplementation.js?lines=142) but it doesn't actually start animating even if start() is called on the animation.
This behavior is inconsistent with a toValue of a number, which executes immediately on start(). This diff adds a call to AnimatedTracking.update within AnimatedValue.track, which starts the tracking animation.
Changelog:
[General][Fixed] - Fixes execution of animation when a toValue of AnimatedValue is used.
Reviewed By: JoshuaGross
Differential Revision: D33800373
fbshipit-source-id: 85ee6f51bc2bb2e078b586b076a8d1dfe92c1155
Summary:
Current syntax options for RN version values break Windows. Following change to nightly build format to be 0.0.0-X-X-X, prerelease value is now a string (X-X-X).
https://github.com/microsoft/react-native-windows/issues/9223
## Changelog
[General] [Fixed] - Fix RN version syntax to match new nightly build structure.
Pull Request resolved: https://github.com/facebook/react-native/pull/32892
Reviewed By: cortinico
Differential Revision: D33712950
Pulled By: lunaleaps
fbshipit-source-id: 9e47cae34930ee624a863c832430962354ebb5be
Summary:
flow 0.146 became more conservative about refinement invalidation, no longer accepting that `this.props.onViewableItemsChanged` is truthy. this was suppressed at the time.
instead, we can assign to a const to restore typechecking.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33743126
fbshipit-source-id: 0b1f0b83c2fe812e88b027c3b1d3d8aca7b09277
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:
Removes all of the `DeprecatedPropTypes` modules from React Native.
Any call sites that were deep-linking to these modules and still requires them can instead import them from the `deprecated-react-native-prop-types` package.
Since this also removes the last reference to `prop-types`, this diff also removes the `prop-types` dependency from `react-native`. 🥳
Changelog:
[General][Removed] DeprecatedPropTypes (deep-link) modules removed from React Native.
Reviewed By: kacieb
Differential Revision: D33671645
fbshipit-source-id: 91829a556b272bbd17ee94806fc548af753593db
Summary:
The iOS WebSocket implementation has a race condition that causes WebSocket frame payloads to be processed incorrectly.
This can cause errors on RFC6455 compliant WebSocket servers:
- the server sends a ping frame with no payload
- the server sends a text frame with a payload longer than 125 bytes
- the client answers the ping with a pong frame echoing back the contents of the text frame
This is caused by concurrent modification of the current frame contents, that is passed by reference to the handlers. The concurrent modification happens [here](https://github.com/facebook/react-native/blob/main/Libraries/WebSocket/RCTSRWebSocket.m#L1162).
The bug was detected and fixed in the original SocketRocket repository in [this PR](https://github.com/facebookincubator/SocketRocket/pull/371). The relevant part of the fix is applied in this PR.
Resolves https://github.com/facebook/react-native/issues/30020.
## 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] - Fix WebSocket control frames having payloads longer than 125 bytes
Pull Request resolved: https://github.com/facebook/react-native/pull/32847
Test Plan:
The bug is not easily and consistently reproduced, being a race condition.
We were able to reproduce it by connecting a react native app to a websocket server that sent ~100 pings per second and ~100 text frames per second. After a couple of seconds, the server receives an invalid pong message, with a payload equal to the payload of the text frame. The following is a node server that can replicate the problem on a react-native app running on iOS.
<details>
```
const { WebSocketServer } = require('ws');
const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', function connection(ws) {
const pingInterval = setInterval(() => {
ws.ping();
}, 10);
const sendInterval = setInterval(() => {
const arr = new Array(100);
for (let i = 0; i < arr.length; i++) {
arr[i] = Math.random();
}
ws.send('message with payload longer than 125 bytes: ' + arr.join(','));
}, 10);
ws.on('close', () => {
clearInterval(pingInterval);
clearInterval(sendInterval);
});
ws.on('error', (err) => {
console.error(err);
process.exit(1);
});
});
```
</details>
Reviewed By: hramos
Differential Revision: D33486828
Pulled By: sota000
fbshipit-source-id: ba52958a584d633813e0d623d29b19999d0c617b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32736
The ability to pass an additional property bag to further configure NativeAnimated is useful for a few reasons, e.g., experimentation with multiple implementations of the NativeAnimated module.
The specific use case this solves is on react-native-windows, where there are two underlying animation graph options, one "optimized" animation graph that uses UI.Composition, and another similar to the approach to iOS and Android that uses a frame rendering callback.
The platform configuration can be supplied to the animation node when `useNativeDriver` is set to `true`, and we pass the platform configuration object to the connected AnimatedValue and all it's children.
Changelog:
[General][Added] - Option to supply `platformConfig` to NativeAnimated
Reviewed By: yungsters
Differential Revision: D32988285
fbshipit-source-id: ab8a7bbf197573fc9e9a4737c255f124321295ac
Summary:
Flow currently allows duplicate members on classes. At runtime the "last" member wins out and all previous values for the member are discarded.
This diff manually removes duplicate members, and fixes resulting flow errors by converting methods to arrow function properties.
Reviewed By: pieterv
Differential Revision: D33664966
fbshipit-source-id: 0f712ac96af4df593c0918fcbadd70624ddde4a6
Summary:
While working on a fix for https://github.com/facebook/react-native/issues/29974 I notice that the `_updateBottomIfNecessary` function inside `KeyboardAvoidingView` was misspelled, so I decided to open a PR fixing it.
## Changelog
[General] [Fixed] - Fix typo in _updateBottomIfNecessary function on KeyboardAvoidingView component
Pull Request resolved: https://github.com/facebook/react-native/pull/32894
Test Plan: Shouldn't require much testing as this is just renaming a private function of `KeyboardAvoidingView`
Reviewed By: philIip
Differential Revision: D33620554
Pulled By: cortinico
fbshipit-source-id: 69b8969bef09cf58b9b1c8a9154dc52686187f8a
Summary:
instead of `errors: ?Array<Error>` and setting it back to `null` to clear errors, which Flow is not very happy with, we can make it always an array and truncate it with `errors.length = 0`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33584184
fbshipit-source-id: 81b424e69e60203c645bafbac12177ffcdc0c6ef
Summary:
Putting the static view config into its own file creates the uncertainty that n > 1 files import the static view config. This isn't true for AndroidTextViewConfig. So, let's just inline this static view config in the NativeComponent that uses it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33341776
fbshipit-source-id: 6fb710b8776d7b9276022c5226acefd7cf8395fb
Summary:
Allow JS to detect if a native UI component is registered to `RCTComponentViewFactory.mm` with JS `UIManager.hasViewManagerConfig(componentName)`.
Fyi, `UIManager.js` is
- `DummyUIManager.js` for Bridgeless,
- `LazyUIManager.js` for Fabric with SVC enabled,
- and `PaperUIManager.js`. for Fabric with SVC disabled.
# How it works in Bridgeless
- `DummyUIManager.hasViewManagerConfig()` checks whether a component exists in the binary. It is hooked up to `unstable_hasComponent()`,
- which is hooked up to the native function `RCTInstallNativeComponentRegistryBinding()`,
- which returns whether a component has been registered to `RCTComponentViewFactory`
- (and also registers the native component if hasn't been registered yet).
Changelog: [Bridgeless][JS] Hook up Venice's UIManager.hasViewManagerConfig with Fabric's native component registry
Reviewed By: RSNara
Differential Revision: D33511659
fbshipit-source-id: 14519378ce3e4247516fcf5a6f83a82aa87c7919
Summary:
Without moving this, we would get this warning about a require cycle on the next diff, because DummyUIManager and LazyUIManager both need unstable_hasComponent.
```
(NOBRIDGE) WARN Require cycle: react-native-github/Libraries/NativeComponent/NativeComponentRegistry.js -> react-native-github/Libraries/ReactNative/UIManager.js -> react-native-github/Libraries/ReactNative/DummyUIManager.js -> react-native-github/Libraries/NativeComponent/NativeComponentRegistry.js
Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
```
Changelog: [Internal]
Reviewed By: philIip, RSNara
Differential Revision: D33511566
fbshipit-source-id: fd8c9732408d08ab17335273f86168bf30747929
Summary: Changelog: [JS] For Fabric with StaticViewConfigs, fix UIManager to use LazyUImanager, not PaperUIManager
Reviewed By: fkgozali
Differential Revision: D33459937
fbshipit-source-id: 4298be7e1e455856cbcf3162b100099cd8c9ce09
Summary:
JS changes to support D32138347 (a96bdb7154)
Changelog: [Android][Fixed] Enable hitSlop to be set using a single number.
Reviewed By: yungsters
Differential Revision: D32559015
fbshipit-source-id: c0409e6e5dd95b35a2a4605b16cfb48104be2858
Summary:
This diff is a prototype to enable ConcurrentRoot in RN VR apps
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D33200238
fbshipit-source-id: 45f700808cdc3a970bcddef858944e764a7260bd
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
## iOS
On iOS:
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, it's safe to have all HostComponent Static View Configs extend <View/> Static View Config.
## Android
On Android, the model is a bit more complicated:
https://pxl.cl/1Vmp5
Takeaways:
- Props come from Shadow Nodes **and** ViewManagers
- Nearly all HostComponent ViewManagers extend BaseViewManager. But, that's not <View/>'s ViewManager.
- <View/>'s ViewManager is [ReactViewManager](https://fburl.com/code/0zalv8zk), which is a descendent of BaseViewManager, and declares its own ReactProps.
So, it's not safe to have all Android HostComponent Static View Configs to extend <View/>'s Static View Config:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
## Changes
In this diff, I removed ReactNativeViewViewConfig, and introduced a new view config called PlatformBaseViewConfig. This ViewConfig partial will capture all the props available on all HostComponents on **both** platforms. This may not necessarily be the props made available on <View/>.
The only components that don't extend the base platform props are: RCTTextInlineImage. What we do with these components is TBD.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32187832
fbshipit-source-id: 9a057abb3f58801615891c21e42ad4cfa5c69f21
Summary:
## Changelog:
[General] [Changed] Export Flow type for deceleration rate for use in other files to keep deceleration rate prop values consistently typed
Reviewed By: lunaleaps
Differential Revision: D32989199
fbshipit-source-id: 2e2fef0721de0d0eb60aaefdbb635788bfc8c1f1
Summary:
AnimatedValue fires a callback with the current value (raw value + offset) after calling it's `stopAnimation` method. The `_value` field on the `AnimatedValue` node is not necessarily kept in sync with the NativeAnimated value node, so the value provided to the callback may be out of sync.
This change checks if the `AnimatedValue` is a native node and passes the callback to the `NativeAnimatedAPI.getValue` callback, defaulting to the previous current JS node state if the node is not native.
Changelog:
[General][Fixed] - AnimatedValue.stopAnimation callback with correct value for NativeAnimated
Reviewed By: yungsters
Differential Revision: D32968572
fbshipit-source-id: b83f86eabe5456f762a15bc29cacb43f84513f6c
Summary:
changelog: [internal]
Introduce a way to execute `onKeyPress` synchronously. This feature is experimental and will be changed in the future. It is not decided if marking native events as "sync" is going to be path forward with synchronous access.
NOTE: This is experimental API.
Reviewed By: ShikaSD
Differential Revision: D32882092
fbshipit-source-id: 68c66a9bb7c97758219e085c88a77f3c475c1eb3
Summary:
changelog: [internal]
Exposes a new flag on RuntimeScheduler: `unstable_getIsSynchronous`. Flag indicates if the current code is run synchronously and therefore commit phase should be synchronous.
Unit tests will be added later, to keep this diff short. This code path is not executed yet.
Reviewed By: mdvacca, ShikaSD
Differential Revision: D32677814
fbshipit-source-id: e01d4fff7e716d627ff99fe104965851138c3aef
Summary:
Retrying D30015799 (6e903b07fa) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original Summary
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D32578661
Pulled By: sota000
fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
react-native-windows currently needs to maintain a fork of TextNativeComponent to wire through a native-only prop for `isPressable`.
The reason we do this on Windows is that we implement an optimization so we only attempt to hit test a virtual Text node if it is actually pressable, leading to significant perf improvement for pointer events (e.g., onMouseEnter / onMouseLeave) on Text.
Changelog:
[General][Added] - Native-only prop to optimize text hit testing on some RN platforms
Reviewed By: JoshuaGross
Differential Revision: D32564637
fbshipit-source-id: bf47c68d94a930d2c620cb3b1584355c5e412bd4
Summary:
as title
in practice, this doesn't make any difference, but this is to follow the apple recommendation and for us to have a more consistent codebase.
https://developer.apple.com/library/content/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
>The NS_ENUM macro helps define both the name and type of the enumeration, in this case named UITableViewCellStyle of type NSInteger. The type for enumerations should be NSInteger.
>Like enumerations, the NS_OPTIONS macro defines both a name and a type. However, the type for options should usually be NSUInteger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32641990
fbshipit-source-id: 56e4cd44cdefe54f61c90844665a685ee2d6ffad
Summary:
Links under `reactnative.dev` that ended with `.html` lead to Page not found.
Fixed the url so that users get sent to the appropriate url.
## 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] [Fixed] - Fixed dead links in the comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/32619
Test Plan: - Changed links are accessible
Reviewed By: lunaleaps
Differential Revision: D32528978
Pulled By: cortinico
fbshipit-source-id: e039d18188371cf5240b37049e431329e28b1b8b
Summary:
This diff updates the ViewConfigs in RN Android to add support for onEnter/onExit/onMove events.
Open questions:
- Should we just remove the override for RN VR: https://www.internalfb.com/code/ovrsource/[c82b81893393ad0c6f8c6e7f347e82bba39dc8cc]/arvr/js/libraries/reactvr/VrShellPanelLib/rn-support/setUpViewConfigOverrides.js
- Should we use w3c naming now (e.g. onPointerEnter / onPointerExit / onPointerMove) ? or should we migrate to it later? what would be the effort for VR to migrate now to onPointerEnter / onPointerExit / onPointerMove?
changelog: [Android][Changed] Add ViewConfigs to support onEnter/onExit/onMove events
Reviewed By: RSNara
Differential Revision: D32253129
fbshipit-source-id: 539d8672825c7f18f0b6a2570764a5988cd936bc
Summary:
fixing oncall issue: https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
in this diff, we add the properties to the native views that are needed for the `onScroll` event.
`UITextField` is not a `UIScrollView` unlike `UITextView`, so we need to add these dummy properties
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32523147
fbshipit-source-id: 1d4f227f498fa1c333e2d6c457484b559ca18f7e
Summary:
Changelog:
[General][Fixed] - Modal accepts a testID but didn't forward it to RCTModalHostView, therefore not making it show up for e2e tests depending on viewhierarchy.
Reviewed By: motiz88
Differential Revision: D32354377
fbshipit-source-id: 51df3a1f81c4b77240e83101b367b033ce98b0c7
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:
This diff makes the manual changes necessary to fix many of the errors in the stacked diff codemod.
See https://fb.workplace.com/groups/flowlang/posts/917522612186736 for details on this effort.
Reviewed By: bradzacher
Differential Revision: D31615035
fbshipit-source-id: 179b2df516833d59873b9003350f81eb4a6b4e9d
Summary:
When transpiling flow with a Babel config like
```
{
plugins: [['babel/plugin-transform-flow-strip-types', {requireDirective: true}]]
}
```
all files containing Flow syntax need to have `flow` at the top of the file.
```
node_modules/react-native/Libraries/Blob/URL.js: A flow directive is required when using Flow annotations with the `requireDirective` option.
55 | _searchParams = [];
56 |
> 57 | constructor(params: any) {
| ^^^^^
58 | if (typeof params === 'object') {
59 | Object.keys(params).forEach(key => this.append(key, params[key]));
60 | }
```
In URL, it was removed (mistakenly I think) by 63038500a2 (diff-552f9731d5c9bc329105a5f4224319966395e59b5bb23202b756c5d152e0f007). Only the `strict-local´ part should have been removed, not the whole line.
## 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] [Fixed] - Complete missing Flow declarations in URL
Pull Request resolved: https://github.com/facebook/react-native/pull/32566
Test Plan: See above
Reviewed By: yungsters
Differential Revision: D32295816
Pulled By: lunaleaps
fbshipit-source-id: 1ad19a032e3399434f4e6a8eebbf37071a0f97be
Summary:
Eliminates all of the console logs that appear when successfully running Jest tests for React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D32304619
fbshipit-source-id: 8bc8ef9337ae6af588238cec7cfb874ac6067340
Summary:
When I upgraded React Native to Prettier v2.x, I removed `format` from a few files to reduce the number of changes.
This is a follow-up to bring back `format` and fix any remaining issues.
Changelog:
[Internal]
Reviewed By: zertosh
Differential Revision: D32287259
fbshipit-source-id: 37ea6d2c973b1db5d37c46d73675bdf436fb9a9d
Summary:
Renames `Keyboard.removeEventListener` to `Keyboard.removeListener`.
When I implemented the compatibility layer in {D26589441 (035718ba97)}, I accidentally used the wrong name. Since `Keyboard.removeEventListener` was always deprecated, this removes it completely.
Changelog:
[General][Changed] - Rename deprecated `Keyboard.removeEventListener` to `Keyboard.removeListener`.
Reviewed By: lunaleaps
Differential Revision: D32282743
fbshipit-source-id: 309382af3269f85f781d38367d115a2ce3690efb
Summary:
Instead of using `.prettierrc` to ignore the files sync'd from React, replace `format` with `noformat`.
This is necessary because currently, the version of Prettier used in React Native (v2.4.1) differs from the version used in React (v1.19.1). We can revert this when React is upgraded.
Changelog:
[Internal]
Reviewed By: ShikaSD
Differential Revision: D32129937
fbshipit-source-id: ca3b379edd732670a9a0b1b20b3f31bdad4b74aa
Summary:
Ignores the `Libraries/Renderer/` directory of files which are synchronized from React (and should not be modified).
Also, formats some EventEmitter modules that for some reason were missed when I upgraded to Prettier v2.x.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/32524
Test Plan:
```
yarn run format-check
```
Reviewed By: javache
Differential Revision: D32129837
Pulled By: yungsters
fbshipit-source-id: 1cb42cec210508db499850e13f77beefdb35eb25
Summary:
## Changes
- StaticViewConfigValidator.validate() now outputs a ValidationOutput object, that contains a Array<Differences>, if invalid
- The Difference type now contains the nativeValue and the staticValue. This makes the validate() function more useful in reconciling ViewConfigs.
- Nothing should change in NativeComponentRegistry.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32139973
fbshipit-source-id: a9556fa370d2c14f9e5d0540b44824cd61773958