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:
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