Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36367
* Don't iterate over JSI Value to get args, convert each of the args individually instead
* Make LongLivedObjectCollection constructor private
* allowRelease does not need to be virtual
* Move away from const-ness as a thread-safety indicator
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43354535
fbshipit-source-id: eaf8eb931ab6ec307a3dc2690eabeb34bb6afa77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36384
## Changelog:
[Internal] - Adds more test coverage to PerformanceEntryObserver functionality related to buffering of the marks/measures, as well as making fixes for certain corner cases handled incorrectly (which are now covered by tests).
Reviewed By: rubennorte
Differential Revision: D43835928
fbshipit-source-id: fc8adbd6c2a2b6b201f1f14bdf51245268c5eabd
Summary:
There was a JSDoc mismatch in `Clipboard.setString` method, `the` was considered as a parameter name, not `content`. Added correct param name and kept the same description as before, separated with a hyphen.
## Changelog
[GENERAL] [FIXED] - Fixes JSDoc in Cliapboard setString
Pull Request resolved: https://github.com/facebook/react-native/pull/36381
Test Plan: No tests needed
Reviewed By: yungsters
Differential Revision: D43839086
Pulled By: cortinico
fbshipit-source-id: 126035d9796e66938402704eaf9bc8646ee9b78b
Summary: This will cause the library to be included multiple times in different dynamic libraries, leading to potentially different values of `CoreFeatures`.
Reviewed By: christophpurrer
Differential Revision: D43772552
fbshipit-source-id: 4590bb9aef7c2330b6e488fa1640eda2720b6e7b
Summary:
This is a change we have implemented in React Native macOS that I am now upstreaming: https://github.com/microsoft/react-native-macos/pull/1257
The library `ocMock` is currently imported as a checked in binary by RN-Tester to help run unit tests on iOS. That binary is only compiled for x86 on macOS, which meant we could not run tests on M1 / M2 Macs. Switching it so that we import from source as a pod should make maintenance easier for both iOS and macOS! :)
Original change notes:
>Previously, we've been unable to test RNTester for macOS on an M1 machine. This is because we were using a framework that was prebuilt for Intel architecture, so the test components would fail to build.
>
> The fix is to build OCMock from source directly instead of using a prebuilt version.
>
> This is only necessary on macOS. The iOS version is already built for ARM architecture, as iOS devices have been running exclusively on ARM for a while now.
## Changelog
[INTERNAL] [CHANGED] - Import OCMock as a pod
Pull Request resolved: https://github.com/facebook/react-native/pull/36239
Test Plan: CI should pass as it did before.
Reviewed By: dmytrorykun
Differential Revision: D43732219
Pulled By: cipolleschi
fbshipit-source-id: 028b5a7f384042145bf1966c8c2730d7437940ec
Summary:
## Changelog:
[Internal] - Add unit tests for the WebPerformance library (PerformanceEntryReporter)
This sets up a C++ unit test suite for `PerformanceEntryReporter` (the core part of the native side of WebPerformance) and adds test coverage for its core functionality.
Reviewed By: sammy-SC
Differential Revision: D43771370
fbshipit-source-id: ad3e0f3f206701c2ea6a5c9386458a76699e7c80
Summary:
Currently the hermes tarball will be re-downloaded every time we run pod update even if the file already exists. This adds a check to avoid downloading it if it already exists. To avoid partial downloads causing issues (if the script is interrupted) we download first to a different file and rename it when done.
## Changelog
[IOS] [FIXED] - Don't download hermes nightly tarball if it exists
Pull Request resolved: https://github.com/facebook/react-native/pull/36368
Test Plan: Tested in an app using nightly builds that the download is only done once when running multiple pod update.
Reviewed By: sshic
Differential Revision: D43815772
Pulled By: cipolleschi
fbshipit-source-id: 9dedb79cab1f1cb37cd82b425d93515c6e1728c1
Summary:
This change add more tests for iOS, using different versions of Ruby
## Changelog
[iOS][Added] - Added smoke tests for iOS with Ruby 2.7.7 and 3.2.0
Pull Request resolved: https://github.com/facebook/react-native/pull/36376
Test Plan: CircleCI must be green.
Reviewed By: blakef
Differential Revision: D43825344
Pulled By: cipolleschi
fbshipit-source-id: 8d3f5a2d9688f4d58f0ad5573d7b21e059cab523
Summary:
Starting from RN 0.72, we would like to be more permissive in which version of Ruby our users can use. This means that we have to make sure that our pipeline works with various
versions of Ruby, especially the lowest one, which is 2.6.10.
This change make sure that we run all the CI jobs with version 2.6.10
## Changelog
[IOS] [CHANGED] - Use Ruby 2.6.10 in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/36361
Test Plan: CircleCI must be green
Reviewed By: blakef
Differential Revision: D43824143
Pulled By: cipolleschi
fbshipit-source-id: ecbeb66667a29d9ed07b86c099ad424380a934a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36360
This change is the iOS equivalent of D43731219 (https://github.com/facebook/react-native/commit/ab55e123da8749d982964f2aee6ce6b0bffdc7fc), but only for what concerns the RNTester example as the interop layer was already present in the codebase and exposed to the OSS.
## Changelog
[internal] - Add example on how to consume a Legacy component in Fabric with the interop layer
Reviewed By: cortinico
Differential Revision: D43735699
fbshipit-source-id: 6cb5a3591e7e4a606c274566226025af91849c16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36335
This change depends on [this PR](https://github.com/react-native-community/cli/pull/1849) of the CLI that introduces the `unstable_reactLegacyComponent` field in the `react-native.config.js` file.
This change introduce a JS script that reads that fields and generated a method in an object to return a list of components to be registered. The `RCTAppDelegate` has been updated to read those components and to automatically register them into the interop layer.
Notice that a user can just update the `react-native.config.js` and rebuild the app to integrate these changes, there is no need to reinstall the pods.
The idea behind this logic is to let the user know which components they are using with the interop layer, rather than rely on some black magic that could leave them blind to the need of actually migrate their apps.
## Changelog:
[iOS][Changed] - Implement mechanism to register legacy components in the iOS Fabric interop layer
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43665973
fbshipit-source-id: b4e8d71fa1bbed7a6130ee4f83a6221394d5306e
Summary:
Tweaking stale bot to have labels that bypass the stale bot.
## Changelog
[INTERNAL] - Add labels to bypass stale bot
Pull Request resolved: https://github.com/facebook/react-native/pull/36365
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D43771191
Pulled By: cortinico
fbshipit-source-id: 55962a9fe4480e962f94cb0456501e09d88f00da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36364
## Changelog
[Internal] -
Fixes dependencies, so we don't pull in unneeded iOS ones when we don't care about them (in this case, when running C++ tests for the RN core).
The iOS dependencies came from the `ReactCommon/react/utils` library, that was including ObjectiveC files unconditionally.
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43769718
fbshipit-source-id: e6414e9ee8c5464754a12901f39668331817396e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36366
## Changelog:
[General][Fixed] -
https://github.com/facebook/react-native/pull/36346 added some typing improvements, however there was a typo in `AnimatableStringValue` type definition, that broke tests on CI.
Reviewed By: cortinico, cipolleschi, hoxyq
Differential Revision: D43770412
fbshipit-source-id: 7b4f234b5cf04df9271e0c98cf51655c87e3bebb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36346
1. Remove Paper native assertions for converting DimensionValue string to Yoga unit, and fix a case where Fabric could throw on invalid value.
2. Move DimensionValue types in TypeScript to use template literal types, to show malformed strings in-editor, during typechecking. Update min TS version to allow this (in conformance with the min TS version used by DefinitelyTyped).
Changelog:
[General][Added] - Improve handling of invalid DimensionValue usage
Reviewed By: javache
Differential Revision: D43153075
fbshipit-source-id: db4e813df6e81cbd3158edad7c07c7a90c009803
Summary:
This diff adds the `performance.reactNativeStartupTiming` API to the performance global object for RN. This property does not exist in web, and we are free to make up our own list of properties in the startup metrics to track RN app startup process. In our case, we have the following six properties to begin with (we may extend and add more to this list in the future):
```
- `(start|end)Time`: The time ‘zero’ for the startup timing and the end of app startup. RN has no knowledge of app start time, which will be provided by the platform. The `endTime` will be the time when the first JS bundle finishes executing (Note that RN supports multiple JS bundles, which can be loaded async)
- `executeJavaScriptBundleEntryPoint(Start|End)`: The time for RN to execute the JS entry point (and finish all sync job)
```
Changelog:
[General][Added] - Add new JS performance API to support getting RN app startup timings
Reviewed By: rshest
Differential Revision: D43326564
fbshipit-source-id: 7b4c7cae70ff64ba1714a1630cd5e183df6c06b0
Summary:
Adds unit tests to test multiple animated values that connect to either transform, style, or props, to verify that the create operations are queued before connect operations. See D43717819 (https://github.com/facebook/react-native/commit/c72c592ecd9d31ec1661958d4e5f77f8dfb37cac) for context.
Changelog:
[Internal] - Add unit tests for proper order of create and connect operations for native animated
Reviewed By: mdvacca
Differential Revision: D43741191
fbshipit-source-id: 9143ba1fce86b546bc5a5a781c08ef0ca2d946d6
Summary:
This bumps all the usages of the packages in the monorepo to the latest published.
## Changelog
[INTERNAL] - Bump all the usages of published packages
Pull Request resolved: https://github.com/facebook/react-native/pull/36356
Test Plan: n/a
Reviewed By: jacdebug
Differential Revision: D43735714
Pulled By: cortinico
fbshipit-source-id: 746af2a2f34e65e1093d0670cd79dae5484f21c2
Summary:
Changelog[Internal]:
[iOS][Fixed] - Fix crash from calling setProperty in RCTTurboModule
The crash is caused by passing a utf8 encoded string to a Object::setProperty overload which only allows ascii inputs.
Reviewed By: RSNara
Differential Revision: D43705999
fbshipit-source-id: b3f1b3fd27d43d40fe0a170d4c2e60faecc26dad
Summary:
## Issue
You will run into an exception like:
Animated node with tag (child) [8] does not exist
when attempting to convert an Animated node (or starting a native animation) to native when there are multiple non-style props that have AnimatedValues (this should be a very rare case, unless you have a custom native component, as most animated props are in style).
## Root cause
Due to how __makeNative is recursively called up and down the node graph, in a specific case where multiple AnimatedValues have an AnimatedProps as their child, the "connect" operation will occur before the "create" operation for the AnimatedProps node. For example:
- When a native animation is fired via Animated.timing().start(), __makeNative is called on the AnimatedValue (call this node AnimatedValueA) that is being animated. This results in the following sequence of events:
- AnimatedValueA iterates through its children (in this case, AnimatedProps) and calls child.__makeNative
- AnimatedProps iterates through all props with AnimatedValue values and calls __makeNative on them (call these nodes AnimatedValueB and AnimatedValueC).
- AnimatedValueA.__makeNative is called again, but this time, the call early exits and does not do anything.
- AnimatedValueB.__makeNative is called. This in turn calls AnimatedProps.__makeNative, which early exits (ROOT CAUSE OF BUG).
- connectAnimatedNodes is queued (undesired)
## Fix
Short of completely refactoring of how we handle converting the DAG to native (which we should do at some point - the current implementation is error prone and suboptimal. Tracking in T146991336), for now we can make AnimatedProps.__makeNative behavior consistent with AnimatedTransform and AnimatedStyle by just avoiding the early exit, so that the connectAnimatedNodes calls all occur after all native nodes have been created
Changelog:
[General][Fixed] - Fixed error during native DAG creation when there are multiple AnimatedValue props
Reviewed By: rshest
Differential Revision: D43717819
fbshipit-source-id: 258682300a2be65935646b499591acf41eabc56e
Summary:
Part of Umbrella https://github.com/facebook/react-native/issues/34872
> [**Codegen 84** - assigned to Pranav-yadav] It depends on [Codegen 83] export the parseModuleName anonymous function (Flow, TypeScript) in a common parseModuleName function in the parsers-commons.js file.
- merged Parse Module-Name _**anon**_ fn of `Flow` & `TS` parsers; into a common `parseModuleName` fn in the `parsers-commons.js`
- added **tests** for `parseModuleName` fn from `parsers-commons.js`
- added `callExpressionTypeParameters` method to **_parsers_**
- added **tests** for `callExpressionTypeParameters` method of _parsers_
- used `parser.callExpressionTypeParameters` method in `parseModuleName` fn
PS: fixed merge conflicts several times :(
Overall :)
## Changelog
[INTERNAL] [CHANGED] - Merge Parse-Module-Name anon fn of `Flow` & `TS` and add `callExpressionTypeParameters` method to **_parsers_**
Pull Request resolved: https://github.com/facebook/react-native/pull/36297
Test Plan: - `yarn lint && yarn run flow && yarn test react-native-codegen` ==> ✅
Reviewed By: rshest
Differential Revision: D43694563
Pulled By: cipolleschi
fbshipit-source-id: 99cf40ada0a567cd9ff91078f66fd4ac3684f7cc
Summary:
This will publish several changes we have pending on main, specifically changes to React Native Gradle Plugin which are needed to unblock nightlies.
#publish-packages-to-npm
## Changelog
[INTERNAL] - Bumping all the changes we have on main
Pull Request resolved: https://github.com/facebook/react-native/pull/36355
Test Plan: n/a
Reviewed By: hoxyq
Differential Revision: D43733634
Pulled By: cortinico
fbshipit-source-id: 9c041f7557cd8e494dfc942ae89e13e55353bb48
Summary:
This adds the `UnstableReactLegacyComponentDescriptor`, part of the Fabric Interop Layer for Android.
Summary of the changes are:
* Expose a new `rrc_legacyviewmanagerinterop` native module via prefab
* Extend default App Cmake setup so `rrc_legacyviewmanagerinterop` is exposed by default
* Add a sample legacy component inside RN Tester
Changelog:
[Internal] [Changed] - Expose UnstableReactLegacyComponentDescriptor inside react/renderer/core
Reviewed By: cipolleschi
Differential Revision: D43731219
fbshipit-source-id: ee26d7e9d7eff5ef6a3e22853f8ea363b9198567
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36348
Changelog: [Internal]
Turns out that Phabricator strips `@` symbol from `@...` tags when exports commits to GitHub. Proposing to use `#` instead.
#publish-packages-to-npm
Reviewed By: cortinico
Differential Revision: D43712415
fbshipit-source-id: 86fc728eb0cb63afb6a9fe592a9ae998da2ce2e4
Summary:
Currently, `EventEmitter#addListener` defines the type (via TypeScript and Flow) of its second argument as a non-nullable function, and the implementation of `EventEmitter#emit` depends on this.
However, not everyone may be using a static type system. We're seeing some people encounter a poor developer experience when they supply non-function values to `EventEmitter#addListener`, because the type mismatch is not surfaced as an error until `EventEmitter#emit` throws later on.
This changes `EventEmitter#addListener` so that it throws when the second argument is not a function. This will make it easier for developers to identify the problematic call site because the stack trace will include the source of the non-function `listener` parameter.
Changelog:
[General][Changed] - `EventEmitter#addListener` now throws if the 2nd argument is not a function.
Reviewed By: rshest
Differential Revision: D43705465
fbshipit-source-id: 34ca91ac92862b31435bd12b7c9cb6da870a2a32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36344
This adds the `UnstableReactLegacyComponentDescriptor`, part of the Fabric Interop Layer,
inside the `react/renderer/components/legacyviewmanagerinterop` module so that it can be included by the user externally.
If we wish to place it somewhere else, I'm more than happy to move it around.
Changelog:
[Internal] [Changed] - Expose UnstableReactLegacyComponentDescriptor inside react/renderer/components/legacyviewmanagerinterop
Reviewed By: mdvacca, cipolleschi
Differential Revision: D43500868
fbshipit-source-id: acfcd89efc42ff7a4ee6cb0a1cbd71d69f79721f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36325
A lot of the code in YogaLayoutableShadowNode expects a 1:1 mapping from ShadowNode children to Yoga Node children, which is not always the case, e.g. for `RawTextShadowNode` (if text, or a number coerced to text, is rendered outside a Text component).
In S323291 we saw this cause memory corruption due to later invalid static_cast. I changed the casting mechanism to terminte instead of corrupting memory, but there is logic here that we need to make permissive (I think D29894182 (https://github.com/facebook/react-native/commit/d3e836245b5fab2e0299dd06901de74dff767b63) also tried to previously do this?).
Normally Text will be rendered inside of a ParagraphShadowNode, where "Text" from React is mapped to ParagraphShadowNode (which is layoutable), "VirtualText" is mapped to TextShadowNode (which is also not layoutable), then finally the text fragment is mapped to "RawTextShadowNode". Arguably React renderer behavior should be not to send anything to native, but we can provide a generalized solution in YogaLayoutableShadowNode to handle any other cases of this issue.
This solution works by filtering ShadowNode children to those which are YogaLayoutable, then only ever operating on that list of children. This means a guaranteed invariant of the nodes we operate on being layoutable (vs the adhoc error handling right now for when they are not), and means we maintain the index based mapping of ShadowNode children to Yoga Node children.
Note, there is another similar API, `getLayoutableChildNodes()` which is protected and returns a filtered list of LayoutableShadowNode. This is public, to allow querying/setting layout results, whearas the similar operations in YogaLayoutableShadowNode are instead an implementation detail.
Changelog:
[General][Fixed] - Fix YogaLayoutableShadowNode handling of non-layoutable children
Reviewed By: sammy-SC
Differential Revision: D43657405
fbshipit-source-id: 8ed136b03b4da15a5e7dfbdd5539b04a2952420d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36341
See https://github.com/react-native-community/discussions-and-proposals/issues/602 for more context.
TL;DR: this flag is used for an edge case. We should not expose it to every users but move it to a guide.
I'll publish a guide on the website on how to achieve the same feature.
Changelog:
[Android] [Changed] - Remove the enableSeparateBuildPerCPUArchitecture from the template entirely
Reviewed By: cipolleschi
Differential Revision: D43695574
fbshipit-source-id: a4f2df755f1d7bd0319a8e418c4ce96b541009ed
Summary:
VirtualizedList refactoring moved [a call of `_updateViewableItems`](https://www.internalfb.com/code/fbsource/[a9d4ad3cf149][history][blame]/xplat/js/react-native-github/Libraries/Lists/VirtualizedList.js?lines=1431-1447) to the inside of a state update.
This call may trigger an `onViewableItemsChanged`, which is normally not an issue (minus changing timing), but creates problems if the users callback then calls imperative methods on the VirtualizedList, since the batched state update may be in the process of changing the props/state the imperative method is reading. See https://github.com/facebook/react-native/issues/36329 for what I suspect is an example of this.
This moves the `_updateViewableItems` call to before the state update, like the previous version of VirtualizedList.
Changelog:
[General][Fixed] - Avoid VirtualizedList viewability updates during state updates
Reviewed By: javache
Differential Revision: D43665606
fbshipit-source-id: 9398273c5209e371e69aafb02bac173c69874273
Summary:
The version using `jest.spyOn()` stopped working at some point. Couldn't find any relevant setup changes, but this form seems to work.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D43669469
fbshipit-source-id: 89d207117e9a56ae3374aed47a8a75fdf2e644fd
Summary:
This PR is task 74 from https://github.com/facebook/react-native/issues/34872:
> Move getTypes functions from utils.js to specific Parsers. Right now we have two Parser classes that takes care of the language specific details and two utils files that contains similar logic. We would like to move everything under the Parsers classes for better OOP architecture and to encourage code-reuse.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Replace getTypes functions with parser specific methods
Pull Request resolved: https://github.com/facebook/react-native/pull/36225
Test Plan: I tested using Jest and Flow commands.
Reviewed By: rshest
Differential Revision: D43453454
Pulled By: cipolleschi
fbshipit-source-id: 0eebcb55e1af3319e2c35bb462980046329a2c09
Summary:
Found that we may do multiple allocations of the same ViewManager instance since ViewManagers are both accessed from the UI thread (mounting views) and from the Fabric background thread (for measuring Text), which could lead to multiple instances of the same ViewManager to be created.
As far as I can tell, this issue was harmless since our ViewManager constructors don't have side-effects, but not ideal.
Changelog: [Internall]
Reviewed By: rshest
Differential Revision: D43661306
fbshipit-source-id: 37ef82d41d43c334fdc6cfbeffb225bba87c668e
Summary:
Looked at the top soft exceptions firing from this codepath. Most of these should use `getReactApplicationContext` instead of `getReactApplicationContextIfActiveOrWarn` to do their cleanup on invalidation.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D43661307
fbshipit-source-id: 27094a6e8dfcf4748eb916531c4998f1c9ee8713
Summary:
Pre-initializing ViewManagers is not as valuable now that we've rolled out StaticViewConfigs on the new architecture. This was primarily used to pre-allocate constants and the `preInitializeViewManagers` was already deprecated.
Changelog: [Android][Removed] UIManager.preInitializeViewManagers
Reviewed By: rshest
Differential Revision: D43661304
fbshipit-source-id: 391c5207ec876a70ddd4bda30a58267090da3ff1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36314
## Changelog:
[Internal] - Added support for W3C Performance API extension (Performance,getEntries*)
See [here for the details](https://www.w3.org/TR/performance-timeline/#extensions-to-the-performance-interface).
This only supports `mark` and `measure` performance entry types (not `events`, as those are not supported by browsers either, they recommend using the `PerformanceObserver` API instead).
From the implementation perspective, we already maintained persistent buffer for `mark` entry types, which was required in order to look up measures.
The buffer is circular, limited to 1K entries by default.
I basically mimic the same behavior for `measure` entry types as well, since it's the simplest way of doing it at this point,
If we happen to want adding some other entry types that would be available via `Performance.getEntries*` API in the future, we may want to iterate on the internal data structures representation inside `PerformanceEntryReporter`, but for now I believe this approach should work just fine, and whatever changes we may want to do will be purely internal implementation detail.
Reviewed By: rubennorte
Differential Revision: D43625488
fbshipit-source-id: dd315b3f8488e910749a8e2a4158246e94d76f99
Pieter De Baets
Ruslan Shestopalyuk
Gijs Weterings
Mikhail Mikhaylov
Saad Najmi
Lulu Wu
Janic Duplessis
Riccardo Cipolleschi
Marshall Roch
Riccardo Cipolleschi
Nicola Corti
Xin Chen
Nick Gerleman
Genki Kondo
Wei Han
Pranav Yadav
Nicola Corti
christopher.hines@hybridheroes.de
Ruslan Lesiutin
Tim Yung
Simeng Pang
Yuan Du
Kyℓe Hensel
Lorenzo Sciandra
Antoine Doubovetzky