Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51693
This moves React Native to use the Central Portal URLs rather than the legacy OSSRH ones.
See https://github.com/gradle-nexus/publish-plugin for more context.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D75673984
fbshipit-source-id: 1de6746809eed72f232eac0c3fb4d809c2046620
* add privacy manifest to pod install
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
* add privacy manifest to hello world template
Summary:
Changelog: [iOS][Added]
this change will be included in the RN CLI. so all new apps running the RN CLI to get created will get this manifest. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53682756
fbshipit-source-id: 0426fe0002a3bc8b45ef24053ac4228c9f61eb85
---------
Co-authored-by: Phillip Pan <phillippan@meta.com>
Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
[iOS][Fixed] don't allow cocoapods 1.15.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/42702
Test Plan:
```
bundle exec pod install
```
Reviewed By: cipolleschi
Differential Revision: D53180111
Pulled By: blakef
fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd
* Fix android platform border color (#39893)
Summary:
If you try to apply PlatformColor to borders on Android app will crash with the next error:
"Error while updating property 'borderColor' of a view managed by: RCTView"
## Changelog:
[ANDROID] [FIXED] - Fix android crash when apply PlatformColor to borders
Pull Request resolved: https://github.com/facebook/react-native/pull/39893
Test Plan:
In RNTester example, go to APIs -> PlatformColor
| Before | After |
| ----------- | ----------- |
| <img src="https://github.com/facebook/react-native/assets/70860930/66ac2880-53da-4438-bd9a-332f8ea40645" alt="drawing" width="200"/> | <img src="https://github.com/facebook/react-native/assets/70860930/151f58a1-d857-4b3d-9ec6-de74eb065127" alt="drawing" width="200"/> |
Reviewed By: NickGerleman
Differential Revision: D50011758
Pulled By: javache
fbshipit-source-id: ea06c18c6aef4b6731e9b9b87422a1e0d13de208
* Android: fix ClassCastException in ReactRootView.java when software keyboard is shown (#40755)
Summary:
Fixes https://github.com/facebook/react-native/issues/40754
Hi all!
We noticed that our app started to crash after bumping to RN v0.71.13, anyways after a deeper investigation we also found that the crash occurs in the latest version as well.
Crash log:
```
E FATAL EXCEPTION: main
Process: com.nfl.fantasy.core.android.debug, PID: 6034
java.lang.ClassCastException: android.app.ContextImpl cannot be cast to android.app.Activity
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.getActivity(ReactRootView.java:926)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:946)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:912)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
```
The code which causes ClassCastException is following [here](https://github.com/facebook/react-native/blob/ea88fbe229e1d276753ee8e118184274fc872138/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java#L864).
In this code explicit type conversion to Activity is not safe because it's not guaranteed by the compiler that context will be compatible with Activity type.
The appropriate issue [has been filed](https://github.com/facebook/react-native/issues/40754).
<!-- 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
-->
[ANDROID] [FIXED] - Fixed crash occurring in certain native views when keyboard events are fired.
Pull Request resolved: https://github.com/facebook/react-native/pull/40755
Test Plan:
Tested it manually with the [reference application](https://github.com/kot331107/rnCrashReproducer). Repro steps are as follows:
- Build and run the app on Android
- Tap the button "Open Modal"
- You should see the red popup fragment to the bottom of the screen
- Tap on the text input to open software keyboard
- Expected: it should show the keyboard and no crash happens.
Reviewed By: arushikesarwani94
Differential Revision: D50198424
Pulled By: NickGerleman
fbshipit-source-id: a5a6d86334856f4ffbe818150da5793380da4702
* chore: bump podfile.lock
---------
Co-authored-by: Ivan Alexandrov <axinvd@gmail.com>
Co-authored-by: Filipp Mikheev <kot331107@gmail.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828
Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.
This fix ensures that we install compatible versions of the Gem.
[iOS][Fixed] - Set the max version of Active support to 7.0.8
Reviewed By: hoxyq
Differential Revision: D49949782
fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503
Summary:
An earlier [change](https://github.com/facebook/react-native/commit/8b1bf058c4bcbf4e5ca45b0056217266a1ed870c) I made (that huntie resubmitted) only works on Xcode 14.3+ (See more info [here](https://github.com/react-native-community/discussions-and-proposals/discussions/687)). This change adds the appropriate compiler checks so that the change is compatible with Xcode 14.2 and earlier, and therefore cherry-pickable to 0.71 and 0.72.
The check works by checking if iOS 16.4+ is defined, which is the closest proxy I could find for "Is this Xcode 14.3".
## Changelog:
[IOS] [CHANGED] - Guard `JSGlobalContextSetInspectable` behind a compile time check for Xcode 14.3+
Pull Request resolved: https://github.com/facebook/react-native/pull/39037
Test Plan: I can't actually test on Xcode 14.2 (it won't launch on my MacBook 😢), but I made a similar [PR](https://github.com/microsoft/react-native-macos/pull/1848) in React Native macOS, whose CI checks run against Xcode 14.2 and I'm getting passing checks there.
Reviewed By: huntie
Differential Revision: D48414196
Pulled By: NickGerleman
fbshipit-source-id: ba10a6505dd11d982cc56c02bf9f7dcdc104bbec
Summary:
Jscodeshift has become maintained again in the past year, and has gotten rid of quite a good chunk of old dependencies that are no longer needed!
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - update jscodeshift
Pull Request resolved: https://github.com/facebook/react-native/pull/35356
Reviewed By: cipolleschi
Differential Revision: D41325527
Pulled By: rshest
fbshipit-source-id: 666b25c9bb3b1720479e9e098968b3b983adc2b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39516
With Xcode15, Apple rewrote the C++ linker.
This is a breaking change that does not work with weak symbols.
As a workaround, apple is suggesting to add `-ld_classic` to the linker in order to readd support for weak symbols. The flag does not exists for Xcode 14.3 or lower, so we need to add it conditionally.
With this change, we introduce a couple of checks in the Hermes build logic:
1. Detect the version of Xcode that is used
2. Add the new flag to `HERMES_EXTRA_LINKER_FLAGS` if Xcode version is 15.
[Internal] - Make hermes build properly with Xcode 15
Reviewed By: cortinico, dmytrorykun
Differential Revision: D49368675
fbshipit-source-id: 62d8ed81855c426f56ed94b6a2d6da2eb882b355
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39474
When it comes to Xcode 15 RC, we are aware of two issues:
1. `unary_function` and `binary_function` not available in Cxx17
2. [Weak linking](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking) is not supported anymore.
This change should fix both of the issues, adding the flags to allow for `unary_function`and `binary_function` to be called and adding the `-Wl -ld_classic` flag to `OTHER_LDFLAGS` in case Xcode 15 is detected.
[Internal] - add the `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` and the `-Wl -ld_classic` flags to projects when needed
Reviewed By: dmytrorykun
Differential Revision: D49319256
fbshipit-source-id: bb895f1e60db915db79684f71fa436ce80b42111
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39478
When testing Xcode 15, we realized that a few pods we do not control directly have the IPHONEOS_DEPLOYMENT_TARGET set to old versions of iOS.
We can update that setting to silence the warning with Cocoapods and this is what this script does.
Notice that bumping that setting generated other warning as some APIs have been deprecated.
[Internal] - Bump min IPHONEOS_DEPLOYMENT_TARGET for 3rd party pods
Reviewed By: dmytrorykun
Differential Revision: D49274837
fbshipit-source-id: 584d105c76d654daa2ecf5eb2f1b9381e70f567a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38256
Add RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support to DevSupportManagerBase for Android 14 change. See
https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details.
Without this fix, app crashes during launch because of :
```SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts```
Changelog:
[Targeting SDK 34] Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase
Reviewed By: javache
Differential Revision: D47313501
fbshipit-source-id: 12e8299559d08b4ff87b4bdabb0a29d27763c698
Summary:
One of the limitations of the existing flow for the release crew is that they need to manually remember to publish all the other packages in the monorepo ahead of a new patch release - this PR modifies the logic for the bump-oss-version script (and makes it available via yarn) so that it will not run if:
* there are git changes lying around
* if some of the packages need a new release
it required a bit of refactoring to extract some portions of the logic from the bump-all-package-versions script, but I think the end result is pretty decent.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - improve bump oss script to allow less human errors
Pull Request resolved: https://github.com/facebook/react-native/pull/38666
Test Plan:
* checkout this branch
* comment L54 of bump-oss-version.js (to remove the check on the branch name)
* run `yarn bump-all-updated-packages`, verify that it works and that it detects that some packages have unreleased code
* run `yarn bump-oss-version -t asd -v asd` (the "fake" parameters are needed to pass the yargs check), verify that it will throw an error because it finds a package that has unreleased code
Reviewed By: mdvacca
Differential Revision: D48156963
Pulled By: cortinico
fbshipit-source-id: 2473ad5a84578c5236c905fd9aa9a88113fe8d22
# Conflicts:
# scripts/publish-npm.js
re-add the file
nit
# Conflicts:
# package.json
Summary:
See: http://blog.nparashuram.com/2019/10/debugging-react-native-ios-apps-with.html
When using direct debugging with JavaScriptCore, Safari Web Inspector doesn't pick up the source map over the network. Instead, as far as I can tell, it expects you to pass the source URL at the time you load your bundle: https://developer.apple.com/documentation/javascriptcore/jscontext/1451384-evaluatescript?language=objc . This leads to a very sub-par developer experience debugging the JSbundle directly. It will however, pick up an inline source map. Therefore, let's add a way to have React Native tell metro to request an inline source map.
I did this by modifying `RCTBundleURLProvider` to have a new query parameter for `inlineSourceMap`, and set to true by default for JSC.
[IOS] [ADDED] - Added support to inline the source map via RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/37878
Test Plan:
I can put a breakpoint in RNTester, via Safari Web Inspector, in human readable code :D
<img width="1728" alt="Screenshot 2023-06-14 at 4 09 03 AM" src="https://github.com/facebook/react-native/assets/6722175/055277fa-d887-4566-9dc6-3ea07a1a60b0">
Reviewed By: motiz88
Differential Revision: D46855418
Pulled By: huntie
fbshipit-source-id: 2134cdbcd0a3e81052d26ed75f83601ae4ddecfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38005
Fixes https://github.com/facebook/react-native/issues/32093 by guarding the expensive `BABEL_CODE_FRAME_ERROR_FORMAT` regex with a cheaper initial scan. (Longer term, we should reduce our reliance on string parsing and propagate more structured errors.)
Changelog: [General][Fixed] Prevent LogBox from crashing on very long messages
Reviewed By: GijsWeterings
Differential Revision: D46892454
fbshipit-source-id: 3afadcdd75969c2589bbb06f47d1c4c1c2690abd
# Conflicts:
# Libraries/LogBox/Data/parseLogBoxLog.js
# packages/react-native/package.json
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37501
This is the iOS side of the fix for https://github.com/facebook/react-native/issues/36794.
That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction).
Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](https://github.com/react-native-community/discussions-and-proposals/pull/646) to pass to the JS engine, even where the request URL isn't JSC-safe.
We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too).
For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment.
For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first.
Changelog:
[iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL
Reviewed By: huntie
Differential Revision: D45950661
fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d
Summary:
We've been encountering a crash in `runAnimationStep` with "Calculated frame index should never be lower than 0" https://github.com/facebook/react-native/issues/35766 with OnePlus/Oppo devices as well, but don't have one on hand to test.
This just works around the issue: if the time is before the start time of an animation, we shouldn't do anything anyways, so we just log a message instead of throwing while in production. We still throw in debug mode though for easier debugging.
### Hypothesis of the root cause
Based on stacktrace in https://github.com/facebook/react-native/issues/35766 (which is the same one we see)
Normally, this should happen
1. Choreographer.java constructs a FrameDisplayEventReceiver
2. FrameDisplayEventReceiver.onVSync gets called, which sets the `mTimestampNanos`
3. FrameDisplayEventReceiver.run gets called, which then eventually calls our `doFrame` callback with `mTimestampNanos`. This then causes `FrameBasedAnimationDriver.runAnimationStep` to be called with the same timestamp
I suspect what's happening on OnePlus devices is that the `onVSync` call either doesn't happen or happens rarely enough that the `mTimestampNanos` when `run` is called is sometime in the past
### Fix
1. Add logging so we get the parameters to debug more if we end up getting this error
2. In production, just ignore past times instead of throwing an Error
## Changelog:
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Prevent crash on OnePlus/Oppo devices in runAnimationStep
Pull Request resolved: https://github.com/facebook/react-native/pull/37487
Test Plan: Ran our app using patched version and verified no issues showed up when using it
Reviewed By: cipolleschi
Differential Revision: D46102968
Pulled By: cortinico
fbshipit-source-id: bcb36a0c2aed0afdb8e7e68b141a3db4eb02695a
Summary:
Hi 👋
I'm one of the Expo contributors. When upgrading the Stripe dependency in Expo for SDK48 release on Android, we noticed the following error:
```java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity```
With Kudo we narrowed it down to an underlying issue in the following cast in `ReactRootView` done during checking for keyboard events:
```((Activity) getContext())```
The `getContext()` is actually a `ContextThemeWrapper` for `ExperienceActivity`, so we should not cast it to an `Activity` directly - instead, we unwrap it using `getBaseContext()`.
Implementing the following fix into the Expo fork fixed the crash for us:
https://github.com/expo/react-native/commit/0e2c9cada120a3709e8285ab4bcdaa1c5c446732
## Changelog
[ANDROID] [FIXED] - Fixed crash occurring in certain native views when handling keyboard events.
<!-- 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
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36121
Test Plan:
Tested manually by comparing two builds before and after this change. The main branch build crashes when the [Stripe 0.23.1](https://github.com/stripe/stripe-react-native) Card Element from the example app is mounted on screen. Applying the change fixed the issue.
Happy to make a more isolated reproduction if necessary.
---
Full stack trace:
```
AndroidRuntime D Shutting down VM
E FATAL EXCEPTION: main
E Process: host.exp.exponent, PID: 8849
E java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity
E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:937)
E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:913)
E at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
E at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3352)
E at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2286)
E at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8948)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239)
E at android.view.Choreographer.doCallbacks(Choreographer.java:899)
E at android.view.Choreographer.doFrame(Choreographer.java:832)
E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214)
E at android.os.Handler.handleCallback(Handler.java:942)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loopOnce(Looper.java:201)
E at android.os.Looper.loop(Looper.java:288)
E at android.app.ActivityThread.main(ActivityThread.java:7898)
E at java.lang.reflect.Method.invoke(Native Method)
E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
```
Reviewed By: cortinico
Differential Revision: D43186530
Pulled By: javache
fbshipit-source-id: 2143495f6b0c71f342eba6d5abb2bfa4a529fbdd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37452Fixes#37428
We do have cache poisoning for hermesc on Windows and Linux due to reusing the same cache key among different
React Native version. This fixes it by specifying a cache key which is version dependent + it invalidates the
caches by defining a new key.
Changelog:
[Internal] [Fixed] - Make CircleCI caches for hermesc be version dependent
Reviewed By: cortinico
Differential Revision: D45909178
fbshipit-source-id: 830c87ae45739c7053342a68dac2ee7581945c1d
Summary:
For 3rd party libraries to work with a React Native fork (such as the TV repo) that uses a different Maven group for `react-android` and `hermes-android` artifacts, an additional dependency substitution is required.
## Changelog:
[Android][fixed] RNGP dependency substitutions for fork with different Maven group
Pull Request resolved: https://github.com/facebook/react-native/pull/37445
Test Plan:
- Manual tested with an existing project
- Unit tests pass
Reviewed By: rshest, dmytrorykun
Differential Revision: D45948901
Pulled By: cortinico
fbshipit-source-id: 4151a1d3616172a92c68812c3a0034c98b330d67
Summary:
Since v0.71 the autoComplete prop on TextInput is available on iOS ([release notes](https://reactnative.dev/blog/2023/01/12/version-071#component-specific-behavior)). However, this change is not reflected in the types.
Original types PR here - https://github.com/DefinitelyTyped/DefinitelyTyped/pull/65144 by chwallen
## Changelog:
[GENERAL] [FIXED] - Fix autoComplete type for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/36931
Test Plan: Setting the autoComplete prop on TextInput to `nickname`, `organization`, `organization-title`, or `url` should not result in typescript errors.
Reviewed By: NickGerleman
Differential Revision: D45052350
Pulled By: javache
fbshipit-source-id: 40993833b4ed14f91e3bf3521a264ea93517a0c9
Summary:
The [React Native TV repo](https://github.com/react-native-tvos/react-native-tvos) shares most of the same Android code as the core repo. Beginning in 0.71, it needs to also publish Android Maven artifacts for the `react-android` and `hermes-android` libraries.
In order to avoid conflicts, it needs to publish the artifacts to a different group name. However, `react-native-gradle-plugin` uses a hardcoded group name (`com.facebook.react`).
Solution: read the group name from the existing `GROUP` property in `ReactAndroid/gradle.properties`.
## Changelog:
[Android] [Fixed] - read GROUP name in gradle-plugin dependency code
Pull Request resolved: https://github.com/facebook/react-native/pull/37204
Test Plan:
- Android unit tests have been added for the new code and new method in `DependencyUtils.kt`.
- Existing tests should pass
- The new code defaults to the correct group (`com.facebook.react`) so no functional change is expected in the core repo.
Reviewed By: luluwu2032
Differential Revision: D45576700
Pulled By: cortinico
fbshipit-source-id: 6297ab515b4bdbb17024989c7d3035b0a2ded0ae
# Conflicts:
# packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactPlugin.kt
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36575
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all.
We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding.
Changelog:
[Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()`
Reviewed By: javache
Differential Revision: D44298159
fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002
# Conflicts:
# ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36577
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change allows us to strip CustomStyleSpan. We already set all but `fontVariant` on the underlying EditText, so we just need to route that through as well.
Note that because this span is non-parcelable, it is seemingly not subject to the buggy behavior on Samsung devices of infinitely cloning the spans, but non-parcelable spans have different issues on the devices (they disappear), so moving `fontVariant` to the top-level makes sense here.
Changelog:
[Android][Fixed] - Minimize EditText Spans 8/N: CustomStyleSpan
Reviewed By: javache
Differential Revision: D44297384
fbshipit-source-id: ed4c000e961dd456a2a8f4397e27c23a87defb6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36576
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change addresses some minor CR feedback and removes the temporary list of spans in favor of applying them directly.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D44295190
fbshipit-source-id: bd784e2c514301d45d0bacd8ee6de5c512fc565c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36548
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change lets us set `letterSpacing` on the EditText instead of using our custom span.
Changelog:
[Android][Fixed] - Minimize EditText Spans 6/N: letterSpacing
Reviewed By: rshest
Differential Revision: D44240777
fbshipit-source-id: 9bd10c3261257037d8cacf37971011aaa94d1a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36544
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change makes us apply strikethrough and underline as paint flags to the underlying EditText, instead of just the spans. We then opt ReactUnderlineSpan and ReactStrikethroughSpan into being strippable.
This does actually create visual behavior changes, where child text will inherit any underline or strikethrough of the root EditText (including if the child specifies `textDecorationLine: "none"`. The new behavior is consistent with both iOS and web though, so it seems like more of a bugfix than a regression.
Changelog:
[Android][Fixed] - Minimize Spans 5/N: Strikethrough and Underline
Reviewed By: rshest
Differential Revision: D44240778
fbshipit-source-id: d564dfc0121057a5e3b09bb71b8f5662e28be17e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36545
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds ReactForegroundColorSpan to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 4/N: ReactForegroundColorSpan
Reviewed By: javache
Differential Revision: D44240780
fbshipit-source-id: d86939cc2d7ed9116a4167026c7d48928fc51757
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36547
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds `ReactBackgroundColorSpan` to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 3/N: ReactBackgroundColorSpan
Reviewed By: javache
Differential Revision: D44240782
fbshipit-source-id: 2ded1a1687a41cf6d5f83e89ffadd2d932089969
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36546
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change generalizes `stripAttributeEquivalentSpans()` to allow plugging in different spans.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D44240781
fbshipit-source-id: 89005266020f216368e9ad9ce382699bd8db85a8
# Conflicts:
# ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36543
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
We cache the backing EditText span on text change to later measure. To measure outside of a TextInput we need to restore any spans we removed. Spans may overlap, so base attributes should be behind everything else.
The logic here for dealing with precedence is incorrect, and we should instead accomplish this by twiddling with the `SPAN_PRIORITY` bits.
Changelog:
[Android][Fixed] - Minimize Spans 1/N: Fix precedence
Reviewed By: javache
Differential Revision: D44240779
fbshipit-source-id: f731b353587888faad946b8cf1e868095cdeced3
Summary:
D42721684 (https://github.com/facebook/react-native/commit/be69c8b5a77ae60cced1b2af64e48b90d9955be5) left a pretty bad bug when using Fabric for Android. I missed that in Fabric specifically, on edit we will cache the Spannable backing the EditText for use in future measurement.
Because we've stripped the sizing spans, Spannable measurement has incorrect font size, and the TextInput size will change (collapsing) after the first edit. This effectively breaks any uncontrolled TextInput which does not have explicit dimensions set.
Changelog:
[Android][Fixed] - Fix measurement of uncontrolled TextInput after edit
Reviewed By: sammy-SC
Differential Revision: D43158407
fbshipit-source-id: 51602eab06c9a50e2b60ef0ed87bdb4df025e51e
Summary:
The current `test-e2e-local` script had two bugs:
- On [this](https://github.com/facebook/react-native/blob/c1c22ebacc4097ce56f19385161ebb23ee1624b3/scripts/test-e2e-local.js#L219) line we were initializing a new RN project with the packed `react-native` created [here](https://github.com/facebook/react-native/blob/c1c22ebacc4097ce56f19385161ebb23ee1624b3/scripts/test-e2e-local.js#L211)
- We were updating the local RN version after running `npm pack` [here](https://github.com/facebook/react-native/blob/c1c22ebacc4097ce56f19385161ebb23ee1624b3/scripts/test-e2e-local.js#L214). This meant that the version inside the packaged `react-native-xyz.tgz` was not updated since we ran `pack` before updating it. This was fine since the `init` command was using the local `react-native` repository instead of the packed version.
## Changelog:
[INTERNAL] [FIXED] - Use packaged react-native in test-e2e-local script
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[INTERNAL] [FIXED] - Use packaged react-native in test-e2e-local script
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36703
Test Plan:
- Run `yarn test-e2e-local -t RNTestProject -p Android`. The command should succeed.
I am not completely sure how to double check that we are using the packed version. Locally, I have a `fsmonitor--daemon.ipc` in my `react-native/.git` that can't be copied. The `.git` folder would be copied only when `cli.js init` was called with the whole repository – which is how I found out about the issue in the first place.
Reviewed By: hoxyq
Differential Revision: D44504599
Pulled By: cipolleschi
fbshipit-source-id: e57e2858bab46d4f978eed3cbaf3e504138594b8
# Conflicts:
# scripts/test-e2e-local.js
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36201
[Changelog][Internal]
Guard call to the C++ ReadableNAtiveMap.importValues with a lock.
Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136.
My corresponding comment from the task, for justification:
> If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues().
It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions.
> Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't.
NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well.
Reviewed By: javache
Differential Revision: D43398416
fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340
Summary: Changelog: [iOS][Changed] - Give precedence to `textContentType` property for backwards compat as mentioned in https://github.com/facebook/react-native/issues/36229#issuecomment-1470468374
Reviewed By: necolas
Differential Revision: D44106291
fbshipit-source-id: 5702d7f171735d1abe6cfbc9ca1ad8f21751d51e
Summary:
This PR prevents blob data from being prematurely de-allocated in native code when using slice to create views into an existing blob. Currently, whenever a new blob is created via createFromOptions, BlobManager.js creates a new blobCollector object since options.__collector is never provided.
https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Blob/BlobManager.js#L115-L123
When the reference to a blobCollector is garbage collected, the corresponding native memory for the blob data is de-allocated.
https://github.com/facebook/react-native/blob/27651720b40cab564a0cbd41be56a02584e0c73a/Libraries/Blob/RCTBlobCollector.mm#L19-L25
Since, `blob.slice()` is supposed to create a new view onto the same binary data as the original blob, we need to re-use the same collector object when slicing so that it is not GC'd until the last reference to the binary data is no longer reachable. Currently, since each blob slice gets a new blobCollector object, the memory is de-allocated when the first blob is GC'd.
Fixes https://github.com/facebook/react-native/issues/29970
Fixes https://github.com/facebook/react-native/issues/27857
## 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] - Blob data is no longer prematurely deallocated when using blob.slice
Pull Request resolved: https://github.com/facebook/react-native/pull/31392
Test Plan: I could use help coming up with a test plan here. I could add a referential equality check for the blob.data.__collector in `Blob-test` but it doesn't seem quite right to be testing the implementation detail there.
Reviewed By: javache
Differential Revision: D41730782
Pulled By: cortinico
fbshipit-source-id: 5671ae2c69908f4c9acb5d203ba198b41b421294
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36421
Changelog: [Internal]
Adding an extra choice for commit question, user can now choose between three options:
1. Commit with generic message, no further actions needed
2. Commit with custom message, intercative VIM input will open
3. Not committing anything
Reviewed By: cortinico
Differential Revision: D43943526
fbshipit-source-id: 014215105d192961486b7d1c697f491697492812
Summary:
Relative path in conditional IF in settings.gradle.kts doesn't work when it try to build (`yarn install-android-jsc`) a package that isn't in root dir and needs of react-native-gradle-plugin or when it try to run rn-tester.
When trying to compile rn-tester (`yarn install-android-jsc` command) the error below:
```Shell
arthur@assuncao � ~/projects/react-native-test/react-native/packages/rn-tester � � main � yarn install-android-jsc
yarn run v1.22.19
$ ../../gradlew :packages:rn-tester:android:app:installJscDebug
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
Project directory '/home/arthur/projects/react-native-test/react-native/packages/rn-tester' is not part of the build defined by settings file '/home/arthur/projects/react-native-test/react-native/settings.gradle.kts'. If this is an unrelated build, it must have its own settings file.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 8s
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
## Changelog
[INTERNAL] [FIXED] - Fix conditional to include rn-tester and react-native-gradle-plugin in settings.gradle.kts.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36188
Test Plan:
Execute rn-tester like [(RN-Tester Readme)](https://github.com/facebook/react-native/blob/main/packages/rn-tester/README.md).
After my changes, the output of `yarn install-android-jsc` is:
```Shell
[... many of the other tasks completed above]
> Task :packages:rn-tester:android:app:compileJscDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :packages:rn-tester:android:app:stripJscDebugDebugSymbols
Unable to strip the following libraries, packaging them as they are: libicu_common.so.
> Task :packages:rn-tester:android:app:installJscDebug
Installing APK 'app-jsc-arm64-v8a-debug.apk' on 'ASUS_Z01KD - 8.0.0' for :packages:rn-tester:android:app:jsc-debug
Installed on 1 device.
BUILD SUCCESSFUL in 31m 53s
121 actionable tasks: 121 executed
Done in 1913.92s.
```
This PR Resolves https://github.com/facebook/react-native/issues/36187
Reviewed By: rshest
Differential Revision: D43393440
Pulled By: cortinico
fbshipit-source-id: 824644aa77147b3747007908db11fe9c120ad92f
Summary:
In our build logic we're mixing `plugins{}` and `buildscript{}`
which have unpredictable side-effect on the build classpath.
I'm moving over everything to use `plugins{}`. This is possible now
that we don't use build from source for New Architecture anymore.
Changelog:
[Internal] [Changed] - Do not use a mixture of plugins{} and buildscript{}
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D43186768
fbshipit-source-id: dcd115bd9d7aadf5cb837b3a28598e274a092873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36236
D38198351 (https://github.com/facebook/react-native/commit/d574ea3526e713eae2c6e20c7a68fa66ff4ad7d2) addedd a guard to FlatList, to no-op if passed `data` that was not an array. This broke functionality where Realm had documented using `Realm.Results` with FlatList. `Real.Results` is an array-like JSI object, but not actually an array, and fails any `Array.isArray()` checks.
This change loosens the FlatList contract, to explicitly allow array-like non-array entities. The requirement align to Flow `ArrayLike`, which allows both arrays, and objects which provide a length and indexer. Flow `$ArrayLike` currently also requires an iterator, but this is seemingly a mistake in the type definition, and not enforced.
Though `Realm.Results` has all the methods of TS `ReadonlyArray`, RN has generally assumes its array inputs will pass `Array.isArray()`. This includes any array props still being checked [via prop-types](https://github.com/facebook/prop-types/blob/044efd7a108556c7660f6b62092756666e39d74b/factoryWithTypeCheckers.js#L548).
This change intentionally does not yet change the parameter type of `getItemLayout()`, which is already too loose (allowing mutable arrays). Changing this is a breaking change, that would be disruptive to backport, so we separate it into a different commit that will be landed as part of 0.72 (see next diff in the stack).
Changelog:
[General][Changed] - Make FlatList permissive of ArrayLike data
Reviewed By: yungsters
Differential Revision: D43465654
fbshipit-source-id: 3ed8c76c15da680560d7639b7cc43272f3e46ac3
Summary:
This page is not up to date anymore:
https://reactnative.dev/contributing/how-to-build-from-source
I'm pushing those changes to make it easier to consume our build when building from source.
I'll update the page those change lands.
## Changelog
[Internal] [Changed] - Make it easier for users to build from source if needed
Pull Request resolved: https://github.com/facebook/react-native/pull/36165
Test Plan: If the CI is green, we should be good to merge this
Reviewed By: cipolleschi
Differential Revision: D43303867
Pulled By: cortinico
fbshipit-source-id: c0080b06cbcbf872ee92fcfa82a9f823d5b247f4
Summary:
When building from source, the PrivateReactExtension is getting no defaults (or missing defaults).
Specifically root should point to ../../ (as the build from source will originate
from `./node_modules/react-native`).
Without that root specified, all the subsequent paths are broken,
specifically, the default being `../` causes the codegen to be searched inside:
```
project/node_modules/node_modules/react-native/codegen
```
which is broken
Changelog:
[Internal] [Changed] - RNGP - Fix defaults for PrivateReactExtension
Reviewed By: cipolleschi
Differential Revision: D43435590
fbshipit-source-id: 2ed5e26c1d63fd808fc2d559ea83d6d39d106ff6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36128
This commit fixes a problem which is making harder to use the New Architecture in monorepos.
Specifically if a user specifies a `codegenDir` in their app, libraries should honor it.
This is not the case today.
The fix is to register an extension on the root project which will "pass" values from app
to libraries.
I've also cleaned up some of the logic in `readPackageJsonFile` function restricting
the access to those functions only to `.root` which is the only field they're accessing.
Fixes#35495
Changelog:
[Android] [Fixed] - Better Monorepo support for New Architecture
Reviewed By: cipolleschi
Differential Revision: D43186767
fbshipit-source-id: 5c5ca39397306120b6b6622cb728633bd331e021
Summary:
The `rrc_root` was not exposed via prefab. I'm adding it to make possible for Reanimated to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/35643.
## Changelog
[ANDROID] [CHANGED] - Expose `rrc_root` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/36166
Reviewed By: cipolleschi
Differential Revision: D43304302
Pulled By: cortinico
fbshipit-source-id: 1c4a7013a33b48a8a7a445a78430630542420f4d
Summary:
Incorrect TS type disallows use of `hitSlop={number}`. Fixed by using Pressable's hitSlop type.
NOTE: I did not bother to change Flow types in the `.js` file, please add a commit doing that if required.
## Changelog
[GENERAL] [FIXED] - Fix touchable hitSlop type
Pull Request resolved: https://github.com/facebook/react-native/pull/36065
Test Plan: None needed
Reviewed By: christophpurrer
Differential Revision: D43117689
Pulled By: javache
fbshipit-source-id: 96e5ae650f47382c8d7fa1ddf63c76461c65dcc7
Summary:
The commit https://github.com/facebook/react-native/commit/3eddc9abb70eb54209c68aab7dbd69e363cc7b29 included on v0.69 introduced a wrong `if` statement inside the `componentDidUpdate` function of the `TouchableOpacity` component. As this `if` statement always evaluates to `true` (`(true || false) !== undefined`) we end up making unnecessary calls to the `_opacityInactive` method every time the component props changes, e.g. every time a `<Text>` inside the TouchableOpacity changes we call this function over and over, and this has been causing some performance issues on big lists.
This PR fixes this problem by adjusting the `componentDidUpdate` function to only call `_opacityInactive` when necessary.
Closes https://github.com/facebook/react-native/issues/34442
Closes https://github.com/facebook/react-native/issues/32476
## Changelog
[General] [Fixed] - Fix TouchableOpacity componentDidUpdate causing an excessive number of pending callbacks
Pull Request resolved: https://github.com/facebook/react-native/pull/35387
Test Plan:
1. Open the RNTester app and navigate to the `Touchable* and onPress` page
2. Test the `TouchableOpacity` component through the many sections
Reviewed By: cipolleschi
Differential Revision: D41397396
Pulled By: ryancat
fbshipit-source-id: 24863b5cbbdd2f3dd1f654b43d7031560937b888
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:
Changelog: [Internal]
- While working on 0.71.3, it was discovered that `react-native-codegen` package is being published almost empty (without `lib` folder)
- The reason for it is that `prepare` script is not being executed
- The main reason for it is npm v6, which requires adding `unsafe-perm` flag for it: https://www.vinayraghu.com/blog/npm-unsafe-perm
- Instead of using this flag, changing executor to `nodelts`, which has node v18 and npm v8
- Also adding `run_yarn` before running the script, because `react-native/codegen` uses external dependencies (such as rimraf) for its build scripts
Differential Revision: D43248175
fbshipit-source-id: ea696aae5b75cb284db380d2040e678bb24a0eb4
Summary:
the current jsc-android is still built based on ndk r21, and react-native is now built based on ndk r23. the unwinder between r21 and r23 is incompatible (libgcc vs libunwind). if there's exceptions throwing from jsc, other react native libraries cannot catch these exceptions and cause runtime crash.
this pr updates jsc-android to 235231.0.0 which is the same webkitgtk version as 235230.2.1 but only built by ndk r23. the jsc-android pr is from https://github.com/react-native-community/jsc-android-buildscripts/pull/179. note that the jsc is based on ndk r23c and react-native is based on ndk r23b. the reason is that i cannot get jsc building successfully on r23b. hopefully r23b and r23c are abi safe.
there is another crash from libjscexecutor when testing the new jsc-android. to fix the issue, i have to explicitly link libunwind.a from libjscexecutor.so. supposedly ndk r23 should help to link libunwind under the hood, i still not figure out why it doesn't. but after linking libunwind.a, i can get new jsc-android work successfully.
```
E/art ( 2669): dlopen("/data/app/com.test-1/lib/x86_64/libjscexecutor.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): at java.lang.Runtime.load(Runtime.java:331)
W/System.err( 2669): at java.lang.System.load(System.java:982)
W/System.err( 2669): at com.facebook.soloader.SoLoader$1.load(SoLoader.java:558)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibraryFrom(DirectorySoSource.java:110)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
W/System.err( 2669): at com.facebook.soloader.ApplicationSoSource.loadLibrary(ApplicationSoSource.java:91)
W/System.err( 2669): at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1067)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:20)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:363)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
W/System.err( 2669): at com.test.MainApplication.onCreate(MainApplication.java:60)
W/System.err( 2669): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
W/System.err( 2669): at androidx.test.runner.MonitoringInstrumentation.callApplicationOnCreate(MonitoringInstrumentation.java:483)
W/System.err( 2669): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4518)
W/System.err( 2669): at android.app.ActivityThread.access$1500(ActivityThread.java:144)
W/System.err( 2669): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
W/System.err( 2669): at android.os.Handler.dispatchMessage(Handler.java:102)
W/System.err( 2669): at android.os.Looper.loop(Looper.java:135)
W/System.err( 2669): at android.app.ActivityThread.main(ActivityThread.java:5221)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Native Method)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Method.java:372)
W/System.err( 2669): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
W/System.err( 2669): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
```
fixes https://github.com/facebook/react-native/issues/36052
## Changelog
[ANDROID][FIXED] - Fixed jscexecutor crash on Android which is caused from NDK incompatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/36062
Test Plan: tested on [jsc-android instrumented test](https://github.com/react-native-community/jsc-android-buildscripts/tree/2.26.1/test) (based on react-native 0.71.2)
Reviewed By: cipolleschi
Differential Revision: D43040295
Pulled By: cortinico
fbshipit-source-id: e0e5b8fb7faa8ee5654d4cde5f274bef4b517376
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36080
For Android release builds on Windows, gradle release build fails if there are spaces in path (https://github.com/facebook/react-native/issues/34878). This is due to gradle improperly handling arguments with spaces (this is also [an open issue](https://github.com/gradle/gradle/issues/6072) on Gradle). Since the Hermes compilation and other Gradle exec invocations involve arguments which will contain spaces (if there are spaces in your path), this also means it is hard to get around this by simply escaping the spaces (eg: by using double quotes), since these arguments are not properly handled by Gradle itself.
As a workaround, this PR uses relative paths for all Gradle commands invoked for Android. As long as there aren't any spaces in the react-native directory structure (i.e this repo), this fix should work.
## Changelog
[Android][Fixed] - Used relative paths for gradle commands
Pull Request resolved: https://github.com/facebook/react-native/pull/36076
Test Plan: `npx react-native run-android` builds and runs the app successfully on Android device, when run inside an RN0711 project with a path containing spaces (and with the changes in this PR applied) on Windows. This includes release builds (i.e with the `--variant=release` flag).
Reviewed By: cipolleschi
Differential Revision: D43080177
Pulled By: cortinico
fbshipit-source-id: 7625f3502af47e9b28c6fc7dfe1459d7c7f1362d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36004
Changelog: [Internal]
This fixes CircleCI job, which is responsible for publishing bumped packages. We should not check for `stderr`, apparently `npm` uses it to store debug information:
- https://github.com/npm/npm/issues/118#issuecomment-325440
So we've tried to use this on 0.71-stable before and it succesfully published one package, but have exited right after it because `stderr` was not empty
Reviewed By: cortinico, cipolleschi
Differential Revision: D42836212
fbshipit-source-id: 6f2a9a512121683268fe6aae6a187fccb8d9dfbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35992
Fixes https://github.com/software-mansion/react-native-gesture-handler/issues/2382
I've just realized that the default value fo `jsRootDir` is not entirely correct.
That's the root of the folder where the codegen should run.
For apps, it should be defaulted to `root` (i.e. ../../)
For libraries, it should be defaulted to `../` (currently is root).
This causes a problem where libraries without either a `codegenConfig` or a `react{ jsRootDir = ... }`
specified in the build.gradle will be invoking the codegen and generating duplicated symbols.
Changelog:
[Android] [Fixed] - RNGP - Properly set the `jsRootDir` default value
Reviewed By: cipolleschi
Differential Revision: D42806411
fbshipit-source-id: ffe45f9684a22494cc2e4d0a19de9077cb341365
Summary:
I discovered that 0.69 could run React Native as Dynamic framework with Hermes and starting from 0.70 that's not possible anymore.
This diff restore that possibility.
Notice that now Hermes provisdes JSI and Dynamic Frameworks requires that all the dependencies are explicitly defined, therefore, whenever we have a pod that depended on `React-jsi`, now it also has to explicitly depends on `hermes-engine`
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the Old Architecture with Hermes
Reviewed By: cortinico
Differential Revision: D42829728
fbshipit-source-id: a660e3b1e346ec6cf3ceb8771dd8bceb0dbcb13a
Summary:
I discovered that 0.69 and 0.70 could run React Native as Dynamic framework with JSC and starting from 0.71 that's not possible anymore.
This diff restore that possibility.
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the old architecture
Reviewed By: cortinico
Differential Revision: D42829137
fbshipit-source-id: 848672f714d8bab133e42f5e3b80202b350d5261
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36003
This diff adds 4 tests in CircleCI to make sure we don't regress in the support of Dynamic Frameworks for the old architecture.
## Changelog
[iOS][Fixed] - Add CircleCI tests for dynamic frameworks with the Old Architecture.
Reviewed By: cortinico
Differential Revision: D42829895
fbshipit-source-id: 5669be45d4f55161a11a6ece161b2a2aa384a644
Summary:
Update the CircleCI configuration to use the proper `exclude` parameter of matrix rather then bootstrap a machine and then kill it.
## 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
-->
## Changelog
[Internal] - Use the `exclude` parameter of matrices to avoid spinning up unnecessary machines
Pull Request resolved: https://github.com/facebook/react-native/pull/35794
Test Plan: The number of jobs on CircleCI should decrease.
Reviewed By: dmytrorykun
Differential Revision: D42475445
Pulled By: cipolleschi
fbshipit-source-id: 3d733ac459a3bc9747440a62cb2caecb7a235fec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35967
In https://github.com/facebook/react-native/issues/35936 we observed that the presence of AbsoluteSizeSpan may lead to hangs when using the Grammarly keyboard on Samsung.
This mitigation makes it so that we do not emit this span in any case where it is sufficient to rely on already set EditText textSize. In simple cases, tested on two devices, it causes typing into the TextInput to no longer hang.
This does not fully resolve the issue for TextInputs which meaningfully use layout-effecting spans (or at least font size), such as non-uniform text size within the input. We instead just try to reduce to minimum AbsoluteSizeSpan possible.
Testing the first commit was able to resolve hangs in some simpler inputs tested, by me and cortinico.
Changelog:
[Android][Fixed] - Mitigation for Samsung TextInput Hangs
Reviewed By: cortinico
Differential Revision: D42721684
fbshipit-source-id: e0388dfb4617f0217bc1d0b71752c733e10261dd
Summary:
Bringing the typescript function signature in-line with the js code.
## Changelog
[GENERAL] [FIXED] - Added AlertOptions argument to the type definition for Alert.prompt to bring it into parity with the js code.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35957
Test Plan: Before the change, VS Code would show a typescript error when I pass AlertOptions to Alert.prompt (even though the js would execute successfully and respect the options I passed. After the change, when I use an Alert.prompt in VS code the function signature was recognized without errors.
Reviewed By: christophpurrer
Differential Revision: D42737818
Pulled By: jacdebug
fbshipit-source-id: 4d4318f38f5c7b7302aae62de5ce224db67e088a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35897
Fixes https://github.com/facebook/react-native/issues/35894
Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (https://github.com/facebook/react-native/commit/1e48274223ee647ac4fc2c21822b5240f3c47e4c) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.
An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.
From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.
Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events
Reviewed By: christophpurrer
Differential Revision: D42604176
fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Summary:
`accessibilityLabelledBy` is missing from `AccessibilityPropsAndroid` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLabelledBy` TypeScript type
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35883
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604287
Pulled By: NickGerleman
fbshipit-source-id: 476d24d1c0257be787b7e84c2c11bcadc3527979
Summary:
TurboModuleRegistry export functions and not a TurboModuleRegistry object. See https://github.com/facebook/react-native/blob/main/Libraries/TurboModule/TurboModuleRegistry.js#L37
## Changelog
[GENERAL] [FIXED] - Fix TurboModuleRegistry TS type
Pull Request resolved: https://github.com/facebook/react-native/pull/35885
Test Plan:
Tested that the import doesn't generate a type error when used correctly.
```ts
import * as TurboModuleRegistry from 'react-native/Libraries/TurboModule/TurboModuleRegistry';
export default TurboModuleRegistry.get<Spec>('RNCSafeAreaContext');
```
Reviewed By: christophpurrer
Differential Revision: D42604208
Pulled By: NickGerleman
fbshipit-source-id: e6259df24aaf6e37b32cc4b51947294fd655837e
Summary:
`accessibilityLanguage` is missing from `AccessibilityPropsIOS` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLanguage` TypeScript type
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35882
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604363
Pulled By: NickGerleman
fbshipit-source-id: fb8dd4b5bba78a080473a9dc7b49a07587530229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35875
Fixes https://github.com/facebook/react-native/issues/35871
Nested VirtualizedLists register to their parents for updates, associated to a specfific cellKey set by VirtualizedListCellContextProvider. This cellKey is usually set when rendering a cell for a data item, but we can also render a nested VirtualizedList by putting one in a ListHeaderComponent/ListFooterComponent/ListEmptyComponent.
D6603342 (https://github.com/facebook/react-native/commit/a010a0cebd4afc0d88336c2c265a5d9dbb19918f) added cellKeys when we render from a header/footer, but not ListEmptyComponent, so that association would silently fail earlier.
D39466677 (https://github.com/facebook/react-native/commit/010da67bef0c22418d0d41b7c2eae664672a4a27) added extra invariants to child list handling, that are now triggered by this case, complaining because we are trying to unregister a child list we never successfully registered, due to a missing cellKey.
This fixes the issue by providing a cellKey for ListEmptyComponent as well.
Changelog:
[General][Fixed] - Fix invariant violation when nesting VirtualizedList inside ListEmptyComponent
Reviewed By: christophpurrer
Differential Revision: D42574462
fbshipit-source-id: f76fa795bf471cb8a929c2efdbd814ea51927663
# Conflicts:
# Libraries/Lists/VirtualizedList.js
Summary:
Removing a stale configuration that was configuring username/password before publishing to NPM. This is effectively unused + the Github Token there is invalid therefore can be removed.
## Changelog
[INTERNAL] - Remove unused .netrc file from CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/35785
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D42385163
Pulled By: cortinico
fbshipit-source-id: 0dbbf44459d59f792da4221d6100800a2f4efda2
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35857
It seems like there is an incompatibility between NDK 23 (shipped in 0.71)
and the usage of custom `CMAKE_BUILD_TYPE` we do for Hermes.
Specifically the `-DCMAKE_BUILD_TYPE=Release` we specify for the debug
variant of Hermes is partially ignored by the new Android native build toolchain.
See https://github.com/android/ndk/issues/463 for mentions on how the
toolchains requires CMake 3.20+
As AGP 7.3 defaults to use CMake 3.18 unless specified, and NDK 23 unless specified.
AGP 7.4 defaults to use CMake 3.22 unless specified, and NDK 23 unless specified.
See: https://developer.android.com/studio/releases/gradle-plugin#7-4-0
Here I'm:
1. Bumping the docker image to an image that contains the CMake 3.22
2. Updating the logic for building `react-native` & `hermes-engine` to use 3.22
3. Provide fallbacks if the user specified `CMAKE_VERSION`
Template tests will run on AGP 7.3 and will still use CMake 3.18, but I forecast
no problem there as the user is not supposed to specify custom `CMAKE_BUILD_TYPE`.
This is only a problem as we build `hermes-engine` with custom build types.
Changelog:
[Android] [Fixed] - Bump CMake to 3.22.1 to properly honor CMAKE_BUILD_TYPE
Reviewed By: cipolleschi
Differential Revision: D42544864
fbshipit-source-id: efd0f51120370fb808337c201df31d71f4ddfdbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35872
When downgrading from AGP 7.4 to 7.3 we were forced to resort to older APIs
to bundle resources. It seems like we haven't properly wired the task to make sure
resources generated by Metro are correctly accounted before the generation of
release app bundles/apks.
This fixes it. This fix can also be removed once we are on AGP 7.4
Fixes#35865
Changelog:
[Android] [Fixed] - Fix for resources not correctly bundlded on release appbundles
Reviewed By: cipolleschi
Differential Revision: D42573450
fbshipit-source-id: a810924315f72e02e4c988ae86112bf0a06a9ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35860
I've just realized that the `--active-arch-only` is not correctly passed down
to RNGP to set up an abiFilter so users on 0.71 on New Architecture end up
building all the architectures even if `--active-arch-only` is set.
This fix makes sure the `abiFilters` is applied if the user specified
either the `--active-arch-only`, the `reactNativeArchitectures` property
and is not using the Split ABI feature.
Changelog:
[Android] [Fixed] - RNGP - Honor the --active-arch-only when configuring the NDK
Reviewed By: cipolleschi
Differential Revision: D42547987
fbshipit-source-id: 5a34e7087bb4f89de74cc52f9c505e36896fbf03
Summary:
Hi there,
While upgrading to 0.71 we realised the RCTAppDelegate doesn't offer a way to set custom `initProps` that would depend on `launchOptions`.
This PR adds an `initialProps` property to the RCTAppDelegate. This would let us set this property based on `launchOptions` in our implementation of `didFinishLaunchingWithOptions` before calling `[super didFinishLaunchingWithOptions]`
Thanks !
## Changelog
[IOS] [ADDED] - Add `initialProps` property to `RCTAppDelegate`
Pull Request resolved: https://github.com/facebook/react-native/pull/35848
Reviewed By: rshest
Differential Revision: D42543027
Pulled By: cipolleschi
fbshipit-source-id: 55374914890445f8193c12a06a943b7796edb457
Summary:
On iOS 13.0+, app may use SceneDelegate for multiple windows support or CarPlay support. RCTAlertController can't find the correct root vc in such scene based apps.
## 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
-->
[iOS] [Fixed] - Fix RCTAlertController not showing when using SceneDelegate on iOS 13.0+.
Pull Request resolved: https://github.com/facebook/react-native/pull/35716
Reviewed By: cipolleschi
Differential Revision: D42253653
Pulled By: makovkastar
fbshipit-source-id: ae4e833abca2af7af8028f3af9bd8d3f60ebd392
Summary:
Enhancing native iOS modules and preventing crashes inside the RCTAlertController
## Changelog
[iOS][Fixed] - Handle properly a `nil` `keyWindows` in the AlertController
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35689
Reviewed By: cipolleschi
Differential Revision: D42179169
Pulled By: ryancat
fbshipit-source-id: 05a6788f610db1d222e3c10b3c774c75edaf55f5
Summary:
When inheriting `RCTAppDelegate` in a module with swift code, the compiler will have a build error when it goes through module headers. because swift does not support cxx headers. we found this issue when we try to inherit the class at Expo's [`EXAppDelegateWrapper`](https://github.com/expo/expo/blob/main/packages/expo-modules-core/ios/AppDelegates/EXAppDelegateWrapper.h) with RCTAppDelegate in new architecture mode.
## Changelog
[IOS][FIXED] - Fix build errors when inheriting RCTAppDelegate in Swift modules
Pull Request resolved: https://github.com/facebook/react-native/pull/35661
Test Plan:
- ci passed
- tested with expo's setup: https://github.com/expo/expo/pull/20470
Reviewed By: rshest
Differential Revision: D42293851
Pulled By: cipolleschi
fbshipit-source-id: 8a173279db070cc0008c6f8214093951f504dcc1
Summary:
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - fixed typo in template build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/35209
Reviewed By: cipolleschi
Differential Revision: D41080347
Pulled By: cortinico
fbshipit-source-id: d2e36f232f798a636f98843edbc5651730125fc4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35679
The Codegen cleanup step was not always working due to an issue with the codegen folder path. It was working for RNTester, but not for apps created from the Template.
## Changelog:
[iOS][Fixed] - Fix path issue to properly run the codegen cleanup step
Reviewed By: jacdebug
Differential Revision: D42137600
fbshipit-source-id: ba4cb03d4c6eb17fda70a4aff383908d2e468429
Summary:
This PR introduce an automatic way to detect whether the user sets its podfile to use frameworks.
In this way, users don't have to install pods with a specific environment flag but they can rely on the standard Cocoapods usage
## Changelog
[IOS][ADDED] - Automatically detect whether use_frameworks! is used
Pull Request resolved: https://github.com/facebook/react-native/pull/35636
Test Plan:
- CircleCI is Green
- Added unit tests
- Tested locally with an app
Reviewed By: dmytrorykun
Differential Revision: D42029355
Pulled By: cipolleschi
fbshipit-source-id: 76c92133deabbda59603b043a4d542737f10f044
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35672
While working on some example, I discovered that the helper function `install_module_dependencies` was not adding the proper `-DRCT_NEW_ARCH_ENABLED=1` flag to the compiler flags.
## Changelog:
[iOS][Fixed] - Make sure to add the New Arch flag to libraries
Reviewed By: jacdebug
Differential Revision: D42131287
fbshipit-source-id: 68c492150ba4e4a2ec726b3e8b8a9c7842b543bc
Summary:
This PR adds a safety check in case the Cocoapod build script is not able to clean the build folder.
We had evidences where this process failed, and in this way the user has a clear and actionable message to fix its situation.
## Changelog
[iOS][Added] - Add message with instructions about what to do if the cleanup of the build folder fails.
Pull Request resolved: https://github.com/facebook/react-native/pull/35642
Test Plan:
I was not able to reproduce the issue locally.
The fix is not destructive, let's see if the amount of issues decreases.
Reviewed By: dmytrorykun
Differential Revision: D42067939
Pulled By: cipolleschi
fbshipit-source-id: 433dbfaec42a1bf460dc9a48051aa51ec6e12d16
Summary:
This fixes some style errors found by dtslint, along with some test cases for StyleSheet.compose() where the recent change made it slightly too permissive when explicit return types are given. I also added runs of the TS tests to a script which runs in sandcastle so we can catch this at diff-submission time in the future.
Changelog:
[General][Fixed] - Fix Errors with TypeScript Tests
Reviewed By: lunaleaps
Differential Revision: D42085257
fbshipit-source-id: 7e6ca49d3c3aef822c61c97ecc07b55b0a949d51
Summary:
Adds some imperative VirtualizedList methods to the TS types which are documented on the website and are public enough. Also explicitly add `viewOffset` to `scrollToItem` since `scrollToItem` params are indefinite in flow and are passed to `scrollToIndex` (which supports the prop).
Changelog:
[General][Fixed] - Add missing VirtualizedList Imperative Types
Reviewed By: GijsWeterings
Differential Revision: D42047674
fbshipit-source-id: 60f7b35b049853d9fcb724918b3a0008a75ea573
Summary:
These are all documented on the website and seem to likely work in OSS to at least some extent. Add the missing types corresponding to functions exported from AppRegistry.
Changelog:
[General][Fixed] - Add missing types for AppRegistry
Reviewed By: GijsWeterings
Differential Revision: D42036018
fbshipit-source-id: 0728d6c5602a50e50f1eaf7f76c54ab47dcb0124
Summary:
This is exported from the RN entrypoint and documented on the RN website, so we should give types for it.
Changelog:
[General][Fixed] - Add type for RootTagContext
Reviewed By: christophpurrer
Differential Revision: D42040806
fbshipit-source-id: cb8cdf557098ddbe33c143b7ab5d80bda7f80a6e
Summary:
Adds some types referenced on the React Native webpage that aren't part of the typings.
Changelog:
[General][Fixed] - Add missing types to PushNotificationIOS
Reviewed By: christophpurrer
Differential Revision: D42040583
fbshipit-source-id: be7b86a02e30b99231f3ab35afc3222954f41cf0
Summary:
Accidentally added a reference to a flow type that doesn't exist in TS. This should fix the issue.
Changelog:
[General][Fixed] - Fix missing animation type
Reviewed By: christophpurrer
Differential Revision: D42043293
fbshipit-source-id: 03470aa25f503337e9e2b79cf74cff96c15a4ad8
Summary:
This was renamed in Flow but not in TS.
Changelog:
[General][Fixed] - Fix types for deprecated scrollTo fields
Reviewed By: christophpurrer
Differential Revision: D42040913
fbshipit-source-id: 5d9746be7b785bea8613f199d39940c4d5d7d138
Summary:
The flow type allows these parameters to be optional but not null. Make TS the same.
Changelog:
[General][Fixed] - Fix Vibration.vibrate() allowing null params
Reviewed By: christophpurrer
Differential Revision: D42046301
fbshipit-source-id: a030d4f141a526dfe2f0fb3a90e36e641fa6d789
Summary:
The flow type and inheriting TS types mark animated as optional, mark it here as well.
Changelog:
[General][Fixed] - Mark scrollToEnd animated as optional
Reviewed By: christophpurrer
Differential Revision: D42036647
fbshipit-source-id: 59d408adc639ee1e0ca040301511c64d7ba55bfe
Summary:
This was flagged when typechecking the existing examples. The current type enforces that both stylesheets overlap, meaning composed stylesheets with distinct props cause a typechecking error. This changes the signature so that each style can be different, and the intersection type of the two is returned.
Changelog:
[General][Fixed] - Fix type for `StyleSheet.compose()`
Reviewed By: christophpurrer
Differential Revision: D42008355
fbshipit-source-id: 238971a61b387c09be001d5df50fe3db70df566f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35644
The `repositories{}` block in the top level build.gradle is not needed anymore
The React Native Gradle Plugin is taking care of it.
Users can still specify if they need to provide custom repositories.
Changelog:
[Android] [Changed] - Remove unnecessary repositories{} block from top level build.gradle
Reviewed By: cipolleschi
Differential Revision: D42033953
fbshipit-source-id: 8ec1c12147fae68302ab47c60045869c72d1812c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35631Fixes#35592
I'm de-bumping AGP from 7.4 to 7.3 as per #35592. There is no stable release
of AGP that is working fine with the `addGeneratedSourceDirectory` API for resources.
Here I'm reverting to use the older APIs.
Changelog:
[Internal] [Changed] - De-bump AGP to 7.3.1 and do not use `addGeneratedSourceDirectory`
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D42004813
fbshipit-source-id: f1a2b0f7c2233402749a3e4f3828be80111ad3a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35619
Reference https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4353534
I'm exposing `ReactAndroid/src/main/jni/react/cxxcomponents` to be consumed via prefab.
It will be available to both: `react_nativemodule_core` and `reactnativejni`
Changelog:
[Internal] [Changed] - Expose ReactAndroid/src/main/jni/react/cxxcomponents via prefab
Reviewed By: cipolleschi
Differential Revision: D41965512
fbshipit-source-id: 3a5a7473267e2e161d9d7fb0e8dfa74593b47b6e
Summary:
After adding `<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>` on my `AndroidManifest.xml`, I expected to use `PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS` but `POST_NOTIFICATIONS` is `undefined` and is named `POST_NOTIFICATION` instead.
Every other Android permission is 1:1 in spelling except this one where it lacks `S`.
Not sure if this is a welcome change since this can be breaking. Or maybe we can include both with and without `S` to not be a breaking change. Or just keep it as is and close this PR.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Rename `POST_NOTIFICATION` to `POST_NOTIFICATIONS`
Pull Request resolved: https://github.com/facebook/react-native/pull/35533
Test Plan: `PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS` should not be `undefined`.
Reviewed By: cortinico
Differential Revision: D41705866
Pulled By: philIip
fbshipit-source-id: a0328b174f0196421565f0cd2b2f1eb509428553
# Conflicts:
# packages/rn-tester/js/examples/PermissionsAndroid/PermissionsExample.js
Summary:
Encountered this, causing typechecking to fail on an example in the current RN documentation.
`onFail` is an optional parameter (see https://github.com/facebook/react/blob/8e2bde6f2751aa6335f3cef488c05c3ea08e074a/packages/react-native-renderer/src/ReactNativeTypes.js#L106), which is not optional in current TS types. Update the TS typings to match.
Note that "?" here is positioned to be a Flow optional parameter, instead of a maybe type. Which means it accepts undefined, but not null, matching the TS usage of "?" which always means possibly undefined (but never null, like a flow maybe type allows).
Changelog:
[General][Fixed] - Fix TS Type for measureLayout optional parameter
Reviewed By: lunaleaps
Differential Revision: D41775900
fbshipit-source-id: 8f53428b8077ec9139c7c1bbc60ed20f5fa9f7ea
Summary:
Small PR with bump to the new versions of CLI and Metro in preparation of the stable release for 0.71.
## Changelog
[General] [Changed] - Bump CLI to 10.0.0 and Metro to 0.73.5
Pull Request resolved: https://github.com/facebook/react-native/pull/35580
Test Plan: CI green
Reviewed By: cortinico
Differential Revision: D41800580
Pulled By: jacdebug
fbshipit-source-id: 7bf81308eb41490b004e685b1763574bfd3b27fb
# Conflicts:
# package.json
# yarn.lock
Summary:
`findPackageJsonFile` always returns a path even though `package.json` does not exist. This causes issues in libraries whose repo setups look like:
```
react-native-webview
├── android
│ └── build.gradle
├── example <-- Note the lack of `package.json` here
│ └── App.tsx
├── ios
│ └── RNCWebView.xcodeproj
├── macos
│ └── RNCWebView.xcodeproj
├── package.json
└── src
```
When `newArchEnabled=true`, running `yarn android` will fail with the following:
```
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':app:generateCodegenArtifactsFromSchema'.
> Could not create task ':app:generateCodegenSchemaFromJavaScript'.
> /~/react-native-webview/example/package.json (No such file or directory)
```
## Changelog
[Android] [Fixed] - `findPackageJsonFile` should return `null` if `package.json` does not exist
Pull Request resolved: https://github.com/facebook/react-native/pull/35566
Test Plan:
```
git clone https://github.com/react-native-webview/react-native-webview.git
cd react-native-webview
git checkout new-arch-ios
yarn
cd example/android
./gradlew clean assembleDebug
```
Reviewed By: NickGerleman
Differential Revision: D41739176
Pulled By: cortinico
fbshipit-source-id: cab0f1f717db160df244c9bb2769e345d6e19917
Summary:
Revert the template `Podfile` to using `react-native-community/cli-platform-ios/native_modules`. The new internal script currently has a hard-coded path to `react-native-community/cli-platform-ios` which may not work in monorepos. The path in the `Podfile` is also hard-coded, but this is a file that the user has access to and can fix themselves if necessary.
## Changelog
[iOS] [Fixed] - Don't use the internal `native_modules.rb` script yet, as it hides a hard-coded path
Pull Request resolved: https://github.com/facebook/react-native/pull/35531
Test Plan: n/a
Reviewed By: rshest
Differential Revision: D41682119
Pulled By: cortinico
fbshipit-source-id: 1822fcd20a794dc9df6e8d6f36615e90b42c1a94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35529
ESLint configuration is derived from `react-native/eslint-config`, which has supported Flow, vanilla JS, and TypeScript.
https://github.com/react-native-community/react-native-template-typescript/pull/238 and a related PR ended up adding new rules to the TypeScript config, to fix bugs with TS linting. It required a followup change, to specify the parser/plugin, and explicity reference them as devDependencies. https://github.com/react-native-community/react-native-template-typescript/pull/240
`react-native/eslint-config` already includes setting the plugin/parser. But overriding rules requires declaring that again, and directly referencing a plugin means a need for the app to declare dependencies, since ESLint resolves modules from the current config.
The rules overridedn were later fixed in `react-native/eslint-config`, which is really the right place for the fix (e.g. https://github.com/facebook/react-native/pull/32644). I noticed this when deriving from the TS template in https://github.com/facebook/react-native/pull/32644 and removed the rule overrides, but didn't have the historical context to realize this means we can then:
1. Remove the explicit parser/plugins since `react-native/eslint-config` already sets them, and we are no longer overriding any rules.
2. Remove the devDependencies, to let the versions be managed entirely by `react-native/eslint-config`.
Changelog:
[General][Changed] - Simplify Template ESLint Configuration
Reviewed By: cortinico
Differential Revision: D41652699
fbshipit-source-id: 8e3313dbf27407c5866f3c2432cffc2ecec1b01d
# Conflicts:
# template/_eslintrc.js
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35521
Inside RC3 the jscexecutor target was prepared for prefab consumption
but not properly exposed.
This was not caught by the CI as we're not effectively using this target,
but some of our popular libraries do (i.e. Reanimated). I'm exposing it here.
Changelog:
[Internal] [Changed] - Properly expose `jscexecutor` as a prefab target
Reviewed By: javache
Differential Revision: D41648349
fbshipit-source-id: 1a04bc21aa50eece304828ce1d99ae795a51af48
* [LOCAL] fix: use META_CI instead of CI envvar
* META_CI -> REACT_NATIVE_CI
* Rename more occurences of CI to REACT_NATIVE_CI
* Use REACT_NATIVE_CI in rn-tester/Podfile
* Add REACT_NATIVE_CI to prepare_hermes_workspace
* revert: Use REACT_NATIVE_CI in rn-tester/Podfile
* Consume hermes-engine.podspec from sdks/hermes-engine
* Consume hermes-engine.podspec from sdks/hermes-engine. Update tests
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35497
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This adds some CircleCI jobs to make sure we do not regress on those. It also updates the template to support these tests.
## Changelog
[iOS][Added] - CircleCI jobs to keep the use_framework! setup in check for the Old Arch
Reviewed By: cortinico
Differential Revision: D41551288
fbshipit-source-id: 531fabb1a7b6aceab2926bb83cf2887129df1776
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
# Conflicts:
# ReactCommon/jsi/React-jsidynamic.podspec
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
The `use_frameworks! :linkage => :static` use to work fine with the Old Architecture.
We modified how the `React-bridging` pod is configured and, now those are broken.
This change make sure to use the right imports for React-bridging.
## Changelog
[iOS][Changed] - Fix imports in React Bridging for Old Arch and frameworks
Reviewed By: christophpurrer, cortinico
Differential Revision: D41551103
fbshipit-source-id: 4416fde92fef11eb801daf2302a57fe52732e4ef
Summary:
This change excludes the `LongLivedObject.h` file from the pod in the ReactCommon library.
The file creates a problem when the `use_frameworks!` option is used in an app because there can't be two files with the same name, despite being in different paths,
within the same framework. Specifically, this `LongLivedObject` is just a redirect to the other one, so it should be safe to exclude this.
## Changelog
[iOS][Fixed] - Exclude redirector to `LongLivedObject.h` from ReactCommon podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/35491
Test Plan: 1. Manually tested in an app from RC2
Reviewed By: cortinico
Differential Revision: D41548985
Pulled By: cipolleschi
fbshipit-source-id: acc57fccdedb344a3aa105f2968645a049392e07
Summary:
See the issue at https://github.com/facebook/react-native/issues/32432#issuecomment-1242234121
This fixes a bizarre issue when using the GNU coreutils tools. There are very minor differences in the standard command-line tools on macOS and the GNU coreutils. The `cp` command has slightly different semantics across these operating systems, so this commit normalizes those differences and allows GNU coreutils to be used or the system native version of `cp`.
Fixes#32432
## Changelog
[General] [Fixed] - Allow GNU coreutils to be used to build projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35382
Test Plan: This change allows the use of the system or GNU coreutils verson of `cp`.
Reviewed By: cipolleschi
Differential Revision: D41532472
Pulled By: cortinico
fbshipit-source-id: f0fe5274d3828bf6099deceee797a82a6adfdcab
Summary:
This PR updates the Cache strategy for the tarballs to include the React Native version we are building. In this way, when we publish a new Release/RC we are sure that we are going to rebuild a nmew
tarball. This should fix caching problems like:
- we have misconfigured the build script for the Hermes tarball, we then fix it, but we distribute the wrong cached artifacts
- the cached artifact has the wrong version
## Changelog
[Internal] - Fixed Hermes Tarball Cache Logic
Pull Request resolved: https://github.com/facebook/react-native/pull/35471
Test Plan:
1. CircleCI
The real way to check this is in the next RC cycle or in the next nightly.
Reviewed By: cortinico
Differential Revision: D41530651
Pulled By: cipolleschi
fbshipit-source-id: 45e8fd3b62c8e108d393d9463ff6762dfc6d3ec8
Summary:
Fixes https://github.com/facebook/react-native/issues/35429
This fix is fairly straightforward. Instead of hardcoding two separate paths for this repo or a simple user's project, we ask Node to resolve `react-native-codegen`.
Because `react-native-codegen` is moved [into the `/packages/*` folder](https://github.com/facebook/react-native/blob/main/package.json#L104), it's part of a workspace in this repository. That means that this fix works not only for monorepos in general but also resolves the right path within the react native repository.
You can test this out yourself when running this command in either the root, or any other workspace in this repository:
```bash
node --print "require('path').dirname(require.resolve('react-native-codegen/package.json'))"
```
I've tested this on Node 16 and 18, and seems to work nicely. Note that you _**have to specify `react-native-codegen/package.json`**_. That's because the `react-native-codegen` package itself is technically invalid; it's missing an entry point within the package (no `main`). When running `node --print "require.resolve('react-native-codegen')"` Node can't resolve the main entry point, and will fail during this process.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix incorrect codegen CLI paths in monorepo projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35430
Test Plan: See PR https://github.com/facebook/react-native/issues/35429
Reviewed By: cortinico
Differential Revision: D41475878
Pulled By: cipolleschi
fbshipit-source-id: f0c362b64cf9c3543a3a031d7eaf302c1314e3f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35508
It turns out that my previous diff hasn't really solved the Windows support.
The problem is that we're not escaping the URI of the Maven Local repository
properly on Windows.
To overcome this, I'll instead use the `toURI()` Api of File to properly
create a valid URI for a given folder.
Changelog:
[Internal] [Changed] - RNGP - Fix DependencyUtils for Windows support
Reviewed By: cipolleschi
Differential Revision: D41581849
fbshipit-source-id: 7905073c6daaf7c6a97405b3e6fb94b8f382234a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35506
In our build we had a mixture of `_` and `-` to separate targets.
Dashes don't play well with Gradle + as we expose them now via Prefab,
let's stick to use only underscores
Changelog:
[Internal] [Changed] - Rename target to don't use dashes
Reviewed By: cipolleschi
Differential Revision: D41578938
fbshipit-source-id: 8aa44aa2dc7bf4822b45e5044532837b989817d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35496
This commit includes a series of fixes needed for better integration with libraries for 0.71:
- I've added an `android/README.md` file as some libraries were failing the build if the folder was missing
- RNGP now applies dep substitution on app and all the libraries project
- RNGP now adds repositories on app and all the libraries project
- I've removed the maven local repo to the `/android` folder as now is empty
- I've fixed the path for the JSC repo for Windows users
- I've added a bit of backward compat by re-adding an empty `project.react.ext` block that libraries might read from.
- I've removed `codegenDir` from the `GenerateCodegenArtifactsTask` which was unused.
Changelog:
[Internal] [Changed] - RNGP - Various improvements needed for 3rd party libs
Reviewed By: cipolleschi
Differential Revision: D41549489
fbshipit-source-id: 2252da0180ac24fd3fe5a55300527da6781f0f8c
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35456Fixes#35439
There is a bug in AGP 7.3.x which is causing assets to don't be copied properly inside the
final artifact: issuetracker.google.com/issues/237421684
As AGP 7.4.x is really close to release (is in Beta5, should be released stable in the next weeks)
we should be fine by bumping to beta5.
This also requires a bump of RNGP
Changelog:
[Android] [Changed] - Bump AGP to 7.4.x
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D41519549
fbshipit-source-id: 60d568a3e49798a23f1d7bf4839ab58bd5549aba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35461
This is another library which is adding prefab support as it's needed by
Expo libraries and Reanimated.
Changelog:
[Internal] [Changed] - Allow `reactnativejni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520801
fbshipit-source-id: 91142a5b5051cfba478d93a2475a178eed6fbb29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35460
Reanimated reported that `react_nativemodule_core` was missing some headers.
Specifically the one from ReactAndroid::react_debug, ReactAndroid::react_render_core, ReactAndroid::glog,
and ReactAndroid::react_render_debug.
I'm adding them here so they get included in the shipped headers for `react_nativemodule_core`
Changelog:
[Internal] [Changed] - Add missing headers to `react_nativemodule_core` prefab module
Reviewed By: cipolleschi
Differential Revision: D41520751
fbshipit-source-id: 4627a2d0f880d4bb3ff2f0e43cd735cf9a3f2f9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35458
We're adding prefab support for those modules as they're needed by Reanimated
and we're exposing headers for them as well.
Changelog:
[Internal] [Changed] - Add prefab for _uimanager _scheduler and _mounting
Reviewed By: cipolleschi
Differential Revision: D41520606
fbshipit-source-id: 76f3c81705e99057b92cd9b86d0601a2b1410f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35457
This exposes `hermes-executor` to be consumed via prefab so that
libraries can depend on it and use its symbols if needed (Expo and Reanimated need it).
Changelog:
[Internal] [Changed] - Expose `hermes-executor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520019
fbshipit-source-id: d590a043ea89fdd8ff41b0ed20900c9cf381a1e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35454
Historically, we used to have hermes-executor debug and release as separate dynamic libraries.
This makes it impossible to prefab this library, so I have to reconcile it into a single library.
This will also help keep the setup consistent with the internal (BUCK) where we have a single target.
Changelog:
[Internal] [Changed] - Consolidate hermes-executor-debug and -release inside a single target
Reviewed By: cipolleschi
Differential Revision: D41519119
fbshipit-source-id: d9ddc30b72164daa29c735836ea433fd4d917fc8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35455
This little change allows to support Gradle Configuration cache in user projects:
https://docs.gradle.org/current/userguide/configuration_cache.html
It allows to save several seconds on the build time.
We'll keep it disabled for now, but Gradle plans to enable it by default for everyone
in the future, so this changes makes us ready for it.
Changelog:
[Internal] [Changed] - RNGP - Correctly Support Gradle Configuration Cache
Reviewed By: cipolleschi
Differential Revision: D41519506
fbshipit-source-id: 6252546e811deb0777c0aab5332291368be7fa8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35397
This Diff removes the `HERMES_BUILD_FROM_SOURCE` that was not always propagated to the original script. This lead to some cases where hermesC was built during `pod install` and then removed by the `react_native_post_install`'s `else` branch.
Basically, when the Pods are installed the first time, everything run smoothly. Subsequent invocations of `pod install`, to install other dependencies, for example, will incur in this problem because:
1. Cocoapods will see that hermes-engine is already installed
2. the podspec is not executed, given that the pod has been fetched from the cache
3. The env var is not set (given that the podspec is not executed)
4. the main script sees the env var as not set, `ENV['HERMES_BUILD_FROM_SOURCE'] == "1"` return false
5. The `else` branch is executed, and it removes the `hermesc_build_dir` and the `copy Hermes framework` script phase.
[iOS][Changed] - Remove `HERMES_BUILD_FROM_SOURCE` flag
Reviewed By: cortinico, dmytrorykun
Differential Revision: D41373439
fbshipit-source-id: ea4aafd187c0ca3ff5c0d79f8aeaaa46ad50f499
Summary:
This is a backport of [this](https://github.com/facebook/react-native/commit/becb47ccb6a6ed77e81b5488561ef6d683933ffe) local fix we made on
0.71-stable.
All our podspecs delegates to the main React Native pods script to set up the dependencies properly. The React-Codegen.podspec, which is generated by
the script itself, was generated with hardcoded dependencies. This PR aligns the versioning with the other podspec.
On a side note, this could create issues in CI and when releaseing, because we are changing the versions to prepare the new release and it breaks some
steps.
## Changelog
[iOS] [Fixed] - Make sure that the React-Codegen.podspec does not enforce specific versions of its dependencies.
Pull Request resolved: https://github.com/facebook/react-native/pull/35274
Test Plan:
1. Ruby tests are passing
2. Manually tested that pods are correctly installed in the following configurations
- RNTester - Hermes - Old Architecture
- RNTester - Hermes - New Architecture
- RNTester - JSC - Old Architecture
- RNTester - JSC - New Architecture
Reviewed By: christophpurrer
Differential Revision: D41153859
Pulled By: cipolleschi
fbshipit-source-id: 043513866a66ecca3e326f8671bea3ec576422de
# Conflicts:
# scripts/cocoapods/codegen_utils.rb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35296
This change adds some version checks and enforces that every version matches some specific format based on the build type we are trying to run.
## Changelog
[General][Changed] - Improve version checks
Reviewed By: cortinico
Differential Revision: D41161756
fbshipit-source-id: 4172195c5e031c1eaf7b33bb74f381c04e9adaf5
Summary:
This PR makes sure that the `preapre_package_for_release` script fail fast if there is already a tag for the desired version
on github.
## Changelog
[General] [Added] - Make the `prepare_package_for_release` fail if there is already a git tag with that version
Pull Request resolved: https://github.com/facebook/react-native/pull/35305
Test Plan:
Tested manually. The script is currently only invoked during the release process.
<img width="1238" alt="Screenshot 2022-11-10 at 12 24 03" src="https://user-images.githubusercontent.com/11162307/201090947-274c1b1c-0b6a-4619-bc85-fa60e5eaeee1.png">
Reviewed By: cortinico
Differential Revision: D41403159
Pulled By: cipolleschi
fbshipit-source-id: fb87df345b14568c750482e5c68be53551a9acbb
# Conflicts:
# scripts/release-utils.js
Summary:
Original title: **[RN] Do not encode path to cmake in hermes-engine Pod, build hermesc in prepare_pods**
The result of `#{%x(command -v cmake | tr -d '\n')}` was being encoded into the `hermes-engine` Pod. This can lead to conflicts in the CocoaPods cache when `pod install` is run on different machines.
Instead of running the command during `pod install`, we defer to the actual build scripts so they can find `cmake` when `$CMAKE_BINARY` is not set.
More importantly, this fixes an issue that crept into the Sandcastle CocoaPods offline mirrors, but which would only manifest itself when people run `js1 oss prepare-pods`.
RNTester would not build due to RNTesterPods.xcworkspace being configured to use cmake from an arbitrary path instead of using the cmake from $PATH.
This does not affect Sandcastle due to `CMAKE_BINARY` getting overriden in Sandcastle.
---
**Update** by dmytrorykun:
It is impossible to address the problem described in the original title by simply adding `CMAKE_BINARY=${CMAKE_BINARY:-cmake}` to `build-hermes-xcode.sh`. This script is supposed to run from Xcode. Since Xcode doesn't have access to system `PATH` variable, it is unable to locate `cmake`, and build fails.
However this diff contains other useful changes:
1. Remove trailing newline in `cmake` path in `build-hermes-xcode.sh`.
2. Fix inverted logic in `copy-hermes-xcode.sh`.
3. Fix typo in `remove xcuserdata` step in Sandcastle.
4. Remove unused `HERMES_DISABLE_HERMESC_BUILD`.
Changelog:
[iOS] [Fixed] - Various fixes for Hermes build-from-source behaviour.
Reviewed By: cipolleschi
Differential Revision: D41139384
fbshipit-source-id: 4a4a44a7ac201d279718d84cd02d60b4eaf3956b
Summary:
Investigating [this comment](https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4170008), I made some tests.
It seems like we can simply use `#import <RCTAppDelegate.h>` instead of the `#import <React-RCTAppDelegate/RCTAppDelegate.h>` in both setups:
- default setup
- `use_frameworks! :linkage => :static`
## Changelog
[iOS] [Fixed] - Support `use_framework! :linkage => :static` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/35394
Test Plan:
1. Manually tested with a new app
2. CircleCI
3. Sandcastle
Reviewed By: cortinico
Differential Revision: D41402060
Pulled By: cipolleschi
fbshipit-source-id: e1ed8196ed860b3663a88f5283f2745e39b0e944
Summary:
Changelog:
[iOS][Changed] - Abort pod install if bad HERMES_ENGINE_TARBALL_PATH is set.
Reviewed By: cipolleschi
Differential Revision: D41341471
fbshipit-source-id: 34a3ac154b0a3f795d07dcd10f92361cb9bb4ad6
Summary:
The template has moved to typescript now, the self-reference needed an update
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - reference App.tsx vs App.js in text of new typescript template
Pull Request resolved: https://github.com/facebook/react-native/pull/35377
Test Plan: It is just a text change - it either makes sense or it doesn't. I think it makes sense?
Reviewed By: cipolleschi
Differential Revision: D41386912
Pulled By: NickGerleman
fbshipit-source-id: 6e62c11567e8fbff70b123446a827b18af43e864
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35379
This diff moves the publishing coordinates from:
```
com.facebook.react:react-native
com.facebook.react:hermes-engine
```
to
```
com.facebook.react:react-android
com.facebook.react:hermes-android
```
I've picked those they are the most layout friendly when building from source, but we can discuss if we want others.
I've updated the Gradle plugin to have a dependencySubstitution rule + update the template with those changes.
It should now be possible to still use `implementation("com.facebook.react:react-native:+")` inside libraries
on 0.71+ and RNGP will resolve dependencies correctly.
Changelog:
[Android] [Changed] - Void the Maven coordinates for react-native and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D41380525
fbshipit-source-id: 91e059fa261acb89bee7ca0c79c30c3d856a2c80
Summary:
From exception logging, found crashes due to `Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference`. Tracing through the stack, it appears the constructor for `ViewGroup` conditionally calls `initializeScrollbarsInternal()`, which in turn calls `getChildCount()`. However `ReactModalHostView` overrides `getChildCount()`, so `getChildCount()` is called before `ReactModalHostView` constructor completes, resulting in null reference when accessing `mHostView` from `getChildCount()`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fix crash on initialize modal
Pull Request resolved: https://github.com/facebook/react-native/pull/35380
Test Plan: In the rn-tester project, display a modal.
Reviewed By: javache, cipolleschi
Differential Revision: D41392235
Pulled By: ryancat
fbshipit-source-id: ce78e4d458ad41769e78139ea0a8a038384e830d
Summary:
Fixes missing/incorrect devDependencies in a newly built app. The previous set did not pull in prettier, causing linting to fail. There was a peerDependency warning on yarn install. We also saw a separate lint warning at runtime specific to TS 4.9 being pulled in now, so we constrain in that version a bit.
Prettier and preset-env versions match the constraints and lockfiles of other RN packages.
## Changelog
[General] [Fixed] - Fixup template devDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/35372
Test Plan:
Created a new app targeting 0.71 via `react-native init`.
1. `yarn install --force` no longer shows warnings
2. `prettier` is installed, `yarn lint` no longer fails, and shows no warnings or errors
3. ~Tentatively a test step to add tests against linting in new app, but last time doing that in CircleCI led to timeouts with no output that I didn't have time to debug, so maybe that's fixed now? �♀️.~ (edit: still hangs)
Reviewed By: NickGerleman
Differential Revision: D41363021
Pulled By: lunaleaps
fbshipit-source-id: d6163b01e8934d75a231fa0fd849d7bde7b3500c
Summary:
This change puts back D40716048 (https://github.com/facebook/react-native/commit/279cfec55fdf404fdb9198edbb37d3adfdfb3bf1) but in the right way, i.e. modifying the script that should generate those changes.
## Changelog
[iOS][Added] - Make the blobs proper TM
Reviewed By: dmytrorykun
Differential Revision: D41312160
fbshipit-source-id: 38850a63eb8d66ffd179743b4948a23340c8782e
Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35285
While doing the release 0f 0.71.0-RC0, we noticed that having the RN version in the hermes tarball was causing more harm than good.
With the version in the name, we ended up with multiple tarballs for debug and release and we were not able to explicitly pick the right tarball given a build.
This change remove the version from the tarball name.
## Changelog
[General][Changed] - Remove React Native version from Hermes tarball name
Reviewed By: lunaleaps
Differential Revision: D41156353
fbshipit-source-id: 8899d5e1e1555bc728d923f3b78d1261e6ff09c7
Summary:
Hi, while adjusting [react-native-screens](https://github.com/software-mansion/react-native-screens) to `0.71.0-rc.0` I encountered the same problems as reported [here](https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4085694) by WoLewicki.
Basically inside `CMake`'s `foreach` loop iterator variable is not being expanded to the actual value:
```cmake
foreach(autolinked_library ${AUTOLINKED_LIBRARIES})
target_link_libraries(autolinked_library common_flags) // <-- here we are literally linking to "autolinked_library".
endforeach()
```
## Changelog
[Android] [Fixed] - Fix Android autolinking failing because of not expanded variable
Pull Request resolved: https://github.com/facebook/react-native/pull/35306
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D41220408
Pulled By: rshest
fbshipit-source-id: 12ce993f0c5227ca7d3c2cc272fe3739126930b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35226
Changelog: [Internal]
This adds scaffolding for the C++ side of NativePerformanceObserver module.
Thanks to christophpurrer for helping set this up, as this is the first one of this kind inside core/OSS.
Reviewed By: rubennorte
Differential Revision: D41028555
fbshipit-source-id: 4acf0e71a254a42044cbbe5f94f40938342c6aa2
Summary:
[Changelog][Internal]
This adds module specs for the native part of PerformanceObserver, as well as the interaction logic vs the NativePerformanceObserver API.
See https://fb.quip.com/MdqgAk1Eb2dV for more detail.
Reviewed By: rubennorte
Differential Revision: D40897006
fbshipit-source-id: 77475f21dad9ee9dbe15df5a989eb08d314e6db2
Summary:
[Changelog][Internal]
This is to prevent an accidental use of PerformanceObserver while it's still a work in progress.
PerformanceObserver is also moved into a dedicated folder, `Libraries/WebPerformance`.
Reviewed By: rubennorte
Differential Revision: D40978749
fbshipit-source-id: 09645a95bed72902870ebc00c1b4a3d81ab4c829
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35138
Changelog:
[General][Added] - Add a C++ only TurboModule example (for Android/iOS/macOS/Windows)
react-native@0.69 introduced a new bridging layer to ease integration for pure C++ TurboModules using C++ std:: types directly instead of the lower level jsi:: types:
https://github.com/facebook/react-native/tree/v0.69.0/ReactCommon/react/bridging
This bridging layer can be used in JSI functions or more conveniently in C++ TurboModules.
Here is a example of an C++ only TurboModule which will work on Android and iOS and macOS/Windows (using microsoft/react-native-macos|windows) only using flow/TypeScript and standard C++ types.
C++ only TurboModules are very handy as they do not require to work with JSI APIs - instead std:: or custom C++ can by used.
Reviewed By: javache
Differential Revision: D39011736
fbshipit-source-id: 84c833d8540671fde8505f1aeb0265074b248730
Summary:
This PR updates he cache strategy for the `checkout_with_cache command`.
The previous strategy was using three keys in descending priority order to restore from the cache:
* `<< parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}-{{ .Revision }}`
* `<< parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}`
*`<< parameters.checkout_base_cache_key >>-{{ arch }}`
When it saves, it always saves using the first key.
The restore works as it follows:
1. It tries to restore the cache using the first key
2. If it fails, it checks whether there is a cache hit for a key that matches the second key as a pattern
3. If it fails, it checks whether there is a cache hit for a key that matches the third pattern
4. Otherwise, it is a cache miss.
This does not work well. Imagine that you submit some code in commit `xxxx` for branch `abc`.
The CI run the first time, it misses all the three keys and checks out the code normally.
Then, it stores the checked out code in the `checkout_key-abc-xxxx` key.
Then, you submit a commit `yyyy` in the same branch.
The CI starts, it tries with the key `checkout_key-abc-yyyy` but it misses
It tries with the key `checkout_key-abc` and it finds the cache for `checkout_key-abc-xxxx` and it restores it, forgetting about your changes.
While doing the release, we created a tag in a commit X. Then we manually had to remove it, but the CI had a cached version of .git with the tag for
the `0.71-stable` branch. And the release failed because the tag was already existing.
### Why this should work
With this solution, we are going to cache using the commit. If there is no cache for a specific commit, it will be a miss. It won't try to be smart and
retrieve the code from previous caches.
This should prevent stale caches and if we manually remove a tag, and then we do a new commit, it should work.
This is a good trade-off that allows to pay the checkout cost only for the first batch of jobs of the pipeline.
**NOTE:** This still won't work if we don't do a new commit.
## Changelog
[General] [Fixed] - Change Cache strategy to avoid cache bumps in Release
Pull Request resolved: https://github.com/facebook/react-native/pull/35259
Test Plan: 1. CircleCI must be green
Reviewed By: jacdebug
Differential Revision: D41120895
Pulled By: cipolleschi
fbshipit-source-id: 2b45da01803197dbe4a25a313a9dfc53a976d096
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
# Conflicts:
# scripts/cocoapods/__tests__/codegen_utils-test.rb
Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
Summary:
The project.android block is unnecessary and contains a wrong path. Let's use the default path which is `./android`.
## Changelog
[Internal] - Remove project.android block from rn-tester's CLI config
Pull Request resolved: https://github.com/facebook/react-native/pull/35197
Test Plan: Tested locally + will wait for a CI run
Reviewed By: robhogan
Differential Revision: D41013193
Pulled By: cortinico
fbshipit-source-id: 5c76c9b571b23ad71a23a8f3f05a9acb4d6e20b9
Summary:
We accidentally added `-DCMAKE_BUILD_TYPE=Debug` for Hermes which is causing
a really slow engine execution. This fixes it and keep the -DCMAKE_BUILD_TYPE
aligned with the one used on Android.
Changelog:
[iOS] [Fixed] - Correctly set -DCMAKE_BUILD_TYPE for Hermes on iOS
Reviewed By: hramos, cipolleschi
Differential Revision: D40980934
fbshipit-source-id: 30f0455990a911b51eb109bebca8272507302650
Summary:
Support various annotations types in QuickPerformanceLogger markEvent for Android.
Changelog:
[Internal][Changed] - Added support for various markEvent annotation types
Reviewed By: dmitry-voronkevich
Differential Revision: D40852658
fbshipit-source-id: fc4053555f65958653be30a58742c83040a19df1
Summary:
This change moves the default new application template in OSS from Flow to TypeScript. This better aligns with the communities usage, and aligns to the great work that has been happening for TS codegen and built-in types. This used [`react-native-community/react-native-template-typescript`](https://github.com/react-native-community/react-native-template-typescript) as a main reference, maintained by radko93. A few things are different:
1. Updated `types/*` devDependencies to match bumped libraries (e.g. Jest 26 to 20).
2. Removed `types/react-native`
3. Removed explicit `moduleFileExtensions` to Jest config in package.json (TS and TSX and added by default in current versions)
4. Removed overrides to eslint config to disable `no-shadow` and `no-undef`, since this was fixed in the underlying eslint config with https://github.com/facebook/react-native/pull/32644 and https://github.com/facebook/react-native/pull/32655
5. Re-translated `App.js` to be a direct translation (e.g. still a raw function instead of React.FC which is sometimes discouraged)
6. Aligns completely to `tsconfig/react-native` maintained configuration (We no longer have the opinionated override of `skipLibCheck`). The important settings are that `strict` is enabled for, but `allowJS` is also enabled to let users import JS modules without anything unexpected. `esModuleInterop` is enabled, which is needed for consistency with Babel import transformations used by Metro. Consistent with our [current documentation](https://reactnative.dev/docs/typescript) built against the community template, `tsc` will typecheck your code without emitting(building) anything.
[Documentation](https://reactnative.dev/docs/typescript) will need to be updated as a followup.
Changelog:
[General][Changed] - Use TypeScript by default for new applications
Pull Request resolved: https://github.com/facebook/react-native/pull/35165
Test Plan: Added usage of `tsc` and `jest` when validating a newly built app. Passes in CircleCI `test_js` job. This also meant removing some cases of copying packages into the users app to pull in the root Metro config (we seem to be able to use the template Metro config consistent with what real apps would get).
Reviewed By: cortinico
Differential Revision: D40911951
Pulled By: NickGerleman
fbshipit-source-id: 15994534235695e91cf994ad06ba2183dfc89a50
Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35166
The Hermes source code is not included in the RN npm package. This piece of code is a remnant from an early experimentation into integrating Hermes more tightly with React Native. We ended up using a combination of the scripts in `scripts/hermes` to fetch the source code from GitHub and relying on prebuilts for stable releases.
Added `strict()` flag to ensure the script fails immediately if an unrecognized flag is passed.
Avoid logging temp publishing folder value to console when `--help` is used.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D40918939
fbshipit-source-id: 2e62ab16467c4c67f03efdf5211a156cb70e0b11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35123
**Context**
On RN Desktop, images can be copy/pasted into text inputs.
When copy/pasting local files w/ semi-colons in the filename (`/downloads/devices:pre-call-IMG_346C38284B2B-1.jpeg`), RN would throw this error.
{F785684529}
The error was due to no having the correct asset loader due to the local file path being parsed incorrectly.
To parse the url, we convert the string URI to a `NSURL` using a custom convertor fn.
The conversion was matching any `:` and assuming it was a network url scheme:
https://www.internalfb.com/code/archon_react_native_macos/[fde4113acd89fb13ee11636c48b59eac49c21bae]/React/Base/RCTConvert.m?lines=97-111
When an image path with `:` in the name was passed to this, it was assuming it was a valid network url and not file path.
Because this is a local filepath, the image path needs to be a filesystem url. Since this was parsed as network url, it did not have the `file://` prefix and would not pass this check, causing the loader to throw.l
https://www.internalfb.com/code/fbsource/%5B60d9d5e67383%5D/xplat/js/react-native-github/Libraries/Image/RCTImageLoader.mm?lines=220-230
## Changelog
[iOS] [Added] - Add support for parsing files w/ `:` in filename
Reviewed By: christophpurrer, philIip
Differential Revision: D40729963
fbshipit-source-id: 2f3adcabc8f0f1f22cbfca69c3484e72b1d93d25
Summary:
Just bumping RNGP to make the new sources avialable to the template.
Changelog:
[Internal] [Changed] - Bump RNGP to 0.71.8
Reviewed By: robhogan
Differential Revision: D40948246
fbshipit-source-id: c6a193fcdc0675be9ef7f1320d63e884b8b65daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35181
As the title says, this unblocks `test_buck` by removign the lambdas used inside test.
Changelog:
[Internal] [Changed] - Fix test_buck by not using lambdas inside ReactImagePropertyTest
Reviewed By: cipolleschi
Differential Revision: D40958412
fbshipit-source-id: 60b8609a25985230dfd6c4dcdf983dc2a8cfaf64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169
This reorganizes typing structure a bit.
`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.
We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.
Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.
This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).
Changelog:
[General][Fixed] - Fixup TS Organization
Reviewed By: cipolleschi
Differential Revision: D40932319
fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35178
I forgot to add the logic to fetch the -SNAPSHOT version when on nightlies.
This code takes care of it.
Changelog:
[Internal] [Changed] - Make sure nightly versions are using the -SNAPSHOT artifacts
Reviewed By: cipolleschi
Differential Revision: D40939367
fbshipit-source-id: 29d60cf281d30b3dbd05d7ea1c766541a8fab90a
Summary:
Saw in the logs an ever increasing number of warnings coming from WebSocketModule about requesting an instance that has already gone away.
On module invalidation we should close all outstanding websockets, as they will no longer be able to send events to JS.
Changelog: [Android][Fixed] On instance destroy, websockets are correctly closed
Reviewed By: mdvacca
Differential Revision: D40897255
fbshipit-source-id: 1578de8baa342479d14ee1070c3314d45c7fbd8d
Summary:
This PR is a follow up of https://github.com/facebook/react-native/pull/35075 and https://github.com/facebook/react-native/commit/1546666a6d713ef756b2f11de9581e3b2bbe08dc to ensure that even in the local e2e testing scenario the new maven approach is followed - without this, RNTestProject on Android won't work, like so:
<img width="1905" alt="Screenshot 2022-10-27 at 12 15 38" src="https://user-images.githubusercontent.com/16104054/198334105-30fb2037-4e7c-4814-8c3f-2412ba0bd49f.png">
And iOS will always build everything from source every time.
This PR addresses both by generating the artifacts locally, and passing them to RNTestProject as if they were coming from a url (mimicking as closely as possible the behaviour for the final user)
In doing so, there's been some refactoring to prep the ground for follow up work.
* refactor CI to rely less on scripts directly in the CircleCI config, but invoke .js ones
* we should be able to trigger more the "manual" artifacts generation so that it will only happen once between RNTester and RNTestProject, and we can pass existing artifacts to the other flows.
* once all of this in place, a very good improvement would be to be able to download the maven artifacts kind of like nightlies and stables do. This will only be viable by checking that there's no local changes, after which there needs to be logic to pull down from CircleCI the artifacts based on git commit <-> circleCI job references.
---
While at it, I've also fixed the hermes-engine podspec logic for detecting if it's on CI: basically the local e2e script needs to align with the changes done here: https://github.com/facebook/react-native/commit/4b512077354eb4702ce144e9958d7513c1607275
but as you can see there, the condition was actually inconsistent across the various files, so realigned to `CI === 'true'`. We probably didn't catch that so far 'cause the other condition in the hermes podspect (existence of `hermestag_file`) is only true on release branches and this new logic has not been in any release branches yet.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - add logic to local e2e script to handle maven local for iOS and Android accordingly
Pull Request resolved: https://github.com/facebook/react-native/pull/35104
Test Plan:
Run ` yarn test-e2e-local -t RNTestProject -p Android` successfully.
Run ` yarn test-e2e-local -t RNTestProject -p iOS` successfully. On the pod install stage, you will see `[Hermes] Using pre-built Hermes binaries from local path.`
Reviewed By: dmytrorykun
Differential Revision: D40893239
Pulled By: cipolleschi
fbshipit-source-id: a31217ec4f177383c62292d00fabc4cbe4391cfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35176
This commit extends the ReactNative-application.cmake logic so
that if the app is using codegen at the app level, the generate library
is properly built and linked.
It helps us simplify the RN Tester setup and makes it easier for app users
to use the codegen at the app level.
Changelog:
[Internal] [Changed] - [Android] Link against the app codegen if available
Reviewed By: cipolleschi
Differential Revision: D40936941
fbshipit-source-id: 26fa4d764fb369c987e94e0c3bce61841b982b27
Summary:
The documentation for `useColorScheme()` suggested that the user's preferred color scheme will be 'Dark Mode'. Instead suggesting 'Dark Mode' as an example of what the user's preferred color scheme could be is more correct.
## Changelog
[INTERNAL] [FIXED] - Edited documentation for `useColorScheme()` hook
Edited
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (aka Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
to
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (e.g. Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
Pull Request resolved: https://github.com/facebook/react-native/pull/35141
Test Plan: Documentation only - no testing required.
Reviewed By: cipolleschi
Differential Revision: D40934781
Pulled By: rshest
fbshipit-source-id: acac8947c3f99016839be27f505066e8992a20fa
Summary:
Improving test coverage in anticipation of some changes being made to `hermes-utils.js`.
Moved test scripts to `hermes/__tests__` and grouped related tests.
We have been delegating some of the work to local binaries via `execSync`, which can be hard to mock or test. We now use a proxy `delegateSync` method that uses `spawnSync` internally to break down the invocation into `command`, `arguments`, `options`. Instead of simply mocking based on the command being executed, we can now conditionally mock based on the arguments being passed.
Added a `createTarballFromDirectory` method. This can be used later when creating different tarballs.
Added `populateMockFilesystemWithHermesBuildArtifacts()` to mock the filesystem state after Hermes has been built.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40871802
fbshipit-source-id: 4348d3c38926ec7eb13d794040a9040010879f58
Summary:
Include dSYMs when building the universal XCFramework for Hermes iOS.
CocoaPods should pick up dSYMs automatically when using `vendored_framework` if:
- `hermes.framework` has a `hermes.framework.dSYM` in the same base directory
- `hermes.xcframework` has a `dSYMs` folder with a `hermes.framework.dSYM` in it, for each slice
The dSYMs for the macOS hermes.framework are already being created.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40790250
fbshipit-source-id: 50fcb3492434637b00458c1aa443ac6ec5472fac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35162
The dSYMs for Apple will not be distributed as part of the prebuilts tarball. They can still be included in the tarball by passing a `-d` flag to the create-tarball script.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40813679
fbshipit-source-id: 26dee8251684c5ecad649ccd27ce688cfe88ec8f
Summary:
Changelog: [Internal]
Override logic for determining whether a dispatched `Event` triggers a native `EventAnimationDriver`.
Natively driven AnimatedEvents on bubbling events is not supported. `PointerEvents` requires this and this diff adds custom matching logic such that if a parent specifies an `AnimatedEvent` on `onPointerMove` and a child view dispatches it, the `AnimatedEvent` will still fire.
Reviewed By: javache
Differential Revision: D38722563
fbshipit-source-id: 7cde57eaff9584b33c6ab15f1fe85c0a9bac132e
Summary:
Changelog: [Internal] - Refactor match logic on determining whether to run an EventAnimationDriver (drivers for natively animated events) for an Event dispatched.
Previously, drivers were stored by key on the NativeAnimatedNodesManager (based on event handler and viewTag) and has been refactored to be stored in a list for easier matching.
This diff changes it so the match logic for running an EventAnimationDriver happens on the Event instance. This change is motivated by PointerEvents needing custom match logic (done on a following change).
Reviewed By: javache
Differential Revision: D40691002
fbshipit-source-id: e4f6742a2af3b751214aefa1fc069f65e8e71d77
Summary:
As part of unifying JS QPL interface, I'm bringing markerAnnotate to the parity with Web version.
At the moment it supports only string annotations, but I'm adding support for ints, arrays of ints, arrays of strings, etc.
## Changelog:
[Internal] [Changed] - Refactored markerAnnotateWithMap -> markerAnnotate
Reviewed By: eddyerburgh
Differential Revision: D40796535
fbshipit-source-id: 9831e353036835b97bb7b2f60085016034c04269
Summary:
## Changelog:
[Internal] [Added] - Adding new markerAnnotateWithMap to the QPL.
This is part of bigger effort to unify JS QPL interfaces across platforms.
Reviewed By: eddyerburgh
Differential Revision: D40796537
fbshipit-source-id: a75b97c20ca411653552228f7dc2fcbedd8ddca9
Summary:
This is a follow up action item from S295231 and T136039462 where we want to make sure null uri in image source is handled properly. This diff adds an unit test to make sure we are using transparent image when uri is null.
Changelog:
[Android][Internal] - Add unit test to ImageView for null uri in source
Reviewed By: javache
Differential Revision: D40732791
fbshipit-source-id: fd468bfe7c33a4f3f8913ead3e84a1770d7c907f
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35160
With the simplified migration to the new arch, we are offering a function in cocoapods that takes care of configuring all the dependencies for libraries.
That function was not setting the proper version of C++ for the library. This could lead to build problems.
This Diff make sure that the libraries that are created with this function call have the proper C++ version.
NOTE: we already have a post install hook that was setting the the proper C++ version, but that was only working for the project. Plus, we can't read that version from the React-Core podspec because at the podspec definition time, cocoapods has not read that yet. Therefore, I just hardcoded the C++ version on top of the file, so it will be easier to update if we decide to change it.
## Changelog
[iOS][Fixed] - Make sure that libraries created with `install_modules_dependencies` has the right C++ version.
Reviewed By: dmytrorykun
Differential Revision: D40894561
fbshipit-source-id: a5187be2d85888a335d4c033f16fdacaf2c945f9
Summary:
This pull request migrates the dimensions example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate Dimensions to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35084
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: yungsters
Differential Revision: D40779014
Pulled By: NickGerleman
fbshipit-source-id: e740684d3022a945da5abc33b2e8834c6cfabb97
Summary:
`exact_empty_objects` is on by default in 0.191, delete usage
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D40822684
fbshipit-source-id: 8e84f0542e6b66049cac34e429f0b724f85a9557
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35156
There are two tarballs: the source code for Hermes that is downloaded from GitHub, and the hermes-runtime-darwin-{}-v{}.tar.gz tarball with prebuilt artifacts that is built in CI.
Renamed some methods to make it clearer which tarball they work with.
Changelog: [internal]
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40812290
fbshipit-source-id: a2c865e1d1461829fe8d468f52deeb55f3565cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35028
**This Diff require a bump in the react-native-codegen (including this [commit](https://github.com/facebook/react-native/commit/7680bdeb4f96a8092393372a59c77a9d7b729cae)) to work**
This diff sets up iOS and Android to pass their platform to the codegen so that we can have platform-specific specs.
## Changelog
[General][Added] - Enable platform-specific Codegen Specs
Reviewed By: cortinico
Differential Revision: D40516395
fbshipit-source-id: 0624f0bfb93c90f78131a605a4847e780783bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35154
This diff bumps the codegen to v0.71.1, preparing it for the branch cut.
## Changelog
[General][Changed] - Bump codegen version
Reviewed By: dmytrorykun
Differential Revision: D40852498
fbshipit-source-id: ba1dc87f3726bc27cbd176f160c62a0bdc291433
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35146
This class is used by Fabric - but does not compile on macOS yet.
Changelog:
[iOS][Fixed] Make ManagedObjectWrapper compile on macOS
Reviewed By: javache
Differential Revision: D40839241
fbshipit-source-id: 73b93a9963db89af19529fbfd60a64f4e5aaf036
Summary:
D38121921 (https://github.com/facebook/react-native/commit/5ddb9977e662a1b41dd7203605ca8480432fc06a) added a grid accessibilityRole to Flow typings and RNTester example shared with iOS. It it forwarded on Android, but doesn't have an equivalent UIAccessibilityTrait mapping.`RNTesterSnapshotTests/testScrollViewExample` reports an error:
```
Failure: RedBox errors: (
"Error setting property 'accessibilityRole' of RCTScrollView with tag #125: Invalid UIAccessibilityTraits 'grid'. should be one of: (
adjustable,
====================== 38 lines skipped ======================
) (NSInternalInconsistencyException)
Path: <unknown>
Line: 0
```
This adds the grid mapping, which I think should fix this error.
Changelog:
[ios][Fixed] - Map `accessibilityRole: grid` to `UIAccessibilityTraitNone`
Reviewed By: christophpurrer
Differential Revision: D40848904
fbshipit-source-id: 80f72bcd4e4826cc0d535693117a6c1e5fbd1d7d
Summary:
Fix typo
## Changelog
[General][Fixed] - Fixed typo syncronization -> synchronization
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/35132
Reviewed By: christophpurrer
Differential Revision: D40832387
Pulled By: rshest
fbshipit-source-id: 834ece525e4469c942e678e2a3d4ecf30be4f550
Summary:
## Summary
This PR extracts the content of the codegen case `'Float'` into a single `emitFloat` function inside the `parsers-primitives.js` file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitFloat` function.
## Changelog
[Internal] [Changed] - Extract the content of the case 'Float' into a single emitFloat function
Pull Request resolved: https://github.com/facebook/react-native/pull/35124
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: rshest
Differential Revision: D40828746
Pulled By: cipolleschi
fbshipit-source-id: 9c7cecf7268f16aaef29065c1983ad9a4dd18dbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35094
Currently the build on console is firing this warning:
```
> Task :app:processDebugMainManifest
package="com.androidtemplateproject" found in source AndroidManifest.xml: /tmp/AndroidTemplateProject/android/app/src/main/AndroidManifest.xml.
Setting the namespace via a source AndroidManifest.xml's package attribute is deprecated.
Please instead set the namespace (or testNamespace) in the module's build.gradle file, as described here: https://developer.android.com/studio/build/configure-app-module#set-namespace
This migration can be done automatically using the AGP Upgrade Assistant, please refer to https://developer.android.com/studio/build/agp-upgrade-assistant for more information.
```
This diff fixes it so users won't see it anymore on 0.71
Changelog:
[Android] [Fixed] - Sets the namespace via Gradle and not via AndroidManifest
Reviewed By: cipolleschi
Differential Revision: D40724654
fbshipit-source-id: 9b01748a22e9993b60e17bf25acbc68ba8e4eb77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35117
This mimics some behavior we have in Android that allow uesers to turn on selectively TM and Fabric.
Notice that if fabric is enabled, TM must be enabled as well, otherwise the app won't work
## Changelog
[iOS][Added] - Added the possibility to selectively enable TM and Fabric with the new Architecture
Reviewed By: cortinico
Differential Revision: D40794328
fbshipit-source-id: b7fc7bb819d05566dcd335832cab224f80b23346
Summary:
Quick update (requested by cortinico) ahead of release 0.71. Note that there was not a new release of `react-native-communiity/cli-platform-ios` in https://github.com/react-native-community/cli/commit/f6f23cca4b4c93030bb05e1fff68bd22ce13baba.
Changelog:
[General][Changed] - Bump CLI to 10.0.0-alpha.2
Reviewed By: robhogan, cortinico
Differential Revision: D40806560
fbshipit-source-id: 5c852a204c3c2d272d0502a34221f24ce7613cb0
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872:
> Extract the UnsupportedFunctionParamTypeAnnotationParserError in its own throwing function (if it does not exists already) and reuse that function passing a proper type. Then, refactor the code using a dictionary and avoiding the three different ifs in both parsers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract the UnsupportedFunctionParamTypeAnnotationParserError in its own throwing function in error-utils
Pull Request resolved: https://github.com/facebook/react-native/pull/35057
Reviewed By: lunaleaps
Differential Revision: D40721099
Pulled By: cipolleschi
fbshipit-source-id: af5e4cd275d0049047d35660559b94a27e660e40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35116
This diff let release versions of React Native to consume the Hermes tarball from Maven.
It is already setup to download proper debug/release version
## Changelog
[iOS][Added] - Download Hermes from Maven while for -stables
Reviewed By: cortinico
Differential Revision: D40794707
fbshipit-source-id: b6fa44a272ca044e1c4057a08accecb2009ad312
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35115
When looking at the new entry point I've realized we have the dynamicLibraryName as first parameter.
As this API is not released yet, let's move it as last.
So users on Java can easily call DefaultNewArchitectureEntryPoint.load(true, true, true)
while now they will have to call DefaultNewArchitectureEntryPoint.load("...", true, true, true)
Users in Kotlin won't be affected by this.
Changelog:
[Internal] [Changed] - Sort parameters in DefaultNewArchitectureEntryPoint
Reviewed By: cipolleschi
Differential Revision: D40793370
fbshipit-source-id: 9dc1569d76a1479a738f8e0f41a4183d7c04538f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35109
This is just a safety check to make sure we don't accidentally
publish a 1.x or a 1000.x version on Maven Central by mistake.
Changelog:
[Internal] [Changed] - Gate the Maven Central publishing to 0.x version.
Reviewed By: mdvacca
Differential Revision: D40767782
fbshipit-source-id: 58f2906c3b01bfd0fd388a300ba303b289633d4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35108
I've rewritten the comment in the android/app/build.gradle.
They were really old, contained wrong links and most of the people ignored it.
I've also moved the enabling of Hermes to the `gradle.properties` file.
RNGP still supports the old method, but we must be sure that we notify
library authors if they were reading project.ext.react.enableHermes in the past
(also the website needs to be updated).
I've also cleaned up the CircleCI setup as now we can specify Hermes enabled/disabled
via the CLI (this will also make easier to do e2e testing).
Changelog:
[Android] [Changed] - Cleanup the template documentation after RNGP & hermesEnabled to gradle.properties
Reviewed By: cipolleschi
Differential Revision: D40762872
fbshipit-source-id: 2c09245e0a923faac53cc6c8a89e99788ae47f8a
Summary:
Small PR with bump to the new versions of CLI and Metro in preparation of the branch cut for 0.71.
While at it, did a cheeky `npx yarn-deduplicate` to clean up a bit the deps.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Bump CLI to 10.0.0-alpha.1 and Metro to 0.73.3
Pull Request resolved: https://github.com/facebook/react-native/pull/35107
Test Plan: CI is green
Reviewed By: motiz88
Differential Revision: D40762683
Pulled By: huntie
fbshipit-source-id: e523a49c78588ca80351f44cb02bcd4c0137475e
Summary:
Just bumping RNGP to make the new sources avialable to the template.
Changelog:
[Internal] [Changed] - Bump RNGP to 0.71.7
Reviewed By: cipolleschi
Differential Revision: D40760927
fbshipit-source-id: 909c88377a231ea6678c6af14c5594fdc4830b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35095
This change will make sure that we load the correct JS engine at runtime,
by using the BuildConfig flag that RNGP sets for us.
This will solve a lot of noise in adb logcat for users seeing
stacktraces mentioning failing to load `jscexecutor` library.
This is also a breaking change, but as the API was not widely used nor
advertised in the template, we should be fine by just mentioning this in the release notes.
Changelog:
[Android] [Changed] - Update the template to load the correct JS engine at runtime
Reviewed By: cipolleschi
Differential Revision: D40710597
fbshipit-source-id: d59a7a52b22a9bf273ea89094c6620c3ecf6eb00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35101
Those CMake variables are effectively unused now. They're raising a warning on CMake builds
of templates + let's not expose them as we haven't released RNGP yet, before libraries
or other tools start relying on them.
Changelog:
[Internal] [Changed] - RNGP - Do not set GENERATED_SRC_DIR and REACT_ANDROID_BUILD_DIR
Reviewed By: cipolleschi
Differential Revision: D40751998
fbshipit-source-id: 13f54a6247e4734c21c263f8b1e6b4b9e8ba406c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35100
That's just a minor bump of AGP before the branch cut.
Changelog:
[Android] [Changed] - Bump AGP to 7.3.1
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D40752006
fbshipit-source-id: 4856bc7ca275cf46d3afcc7c24928c5f1d5e6e33
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35099
I'm removing the ReactFlipperPlugin from the new app template.
That plugin is effectively empty and is a stub + is deprecated
so is generating a warning for all the users.
Changelog:
[Android] [Changed] - Do not import/use the deprecated ReactFlipperPlugin
Reviewed By: cipolleschi
Differential Revision: D40751984
fbshipit-source-id: 1f1fdf9c7dfccb9e7bbd4c8c2292df71e00c644f
Summary:
In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely.
The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users.
Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change.
In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it.
To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package.
Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Changed] - Add back deprecated PropTypes
Reviewed By: yungsters
Differential Revision: D40725705
fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
Summary:
## Overview
When I implemented `ignoreLogs` it was originally just to move `console.ignoreYellowBox` over to LogBox. When I did that, I also added filtering for console messages too. My thought process was: Developers probably don't want to configure hiding logs twice, so the LogBox method can handle both.
This was a mistake. We should never hide console errors and warnings, because it completely silences important feedback to the users such as deprecation warnings. These issues should be fixed, not silenced, and since adding the silencing behavior it's clear that this feature is being abused to ignore legitimate warnings that need address.
Issue #33557 is a great reason why - the correct fix for this is not to ignore the errors, it's to address the deprecation / removal of the API. Allowing an easy `ignoreLog` method to hide the problem made this migration much more painful.
Thus, we're reverting back to the pre-logbox behavior of always showing console logs, even if they're ignored by LogBox in the app UI. Hopefully, this results in more of these issue being addressed instead of ignored.
Changelog:
[General] [Changed] - Do not filter errors/warnings from console
Reviewed By: yungsters
Differential Revision: D40724661
fbshipit-source-id: de3d2db1b0c32dee96acf92c9b1ca07ba0f4e218
Summary:
We are running into a group seeing frequent disconnects from Metro in a specific office. These are surfaced (at least on iOS) as websocket closures, without a prior websocket error. WebSocket closure can be for a variety of reasons, and the spec for a CloseEvent is to include fields `wasClean`, `code`, and `reason`, with `code` having the most well-defined meaning.
This change makes it so that we emit extra context when the websocket is closed. That should help inform developers the reason behind any close that may be abnormal.
Changelog:
[General][Added] - Log Abnormal Closes to Metro Websocket
Reviewed By: motiz88
Differential Revision: D40660765
fbshipit-source-id: ef606d8d809af1c697a78eb00cc5666c29a8bca3
Summary:
Currently, RCTBlobManager (the native module for Blob support) cannot be loaded on iOS when the new architecture is enabled.
## Changelog
[General] [Added] - `BlobModule` to `RCTCoreModulesClassProvider`
Pull Request resolved: https://github.com/facebook/react-native/pull/35047
Test Plan:
The snippet below can be used to test Blob support with the new architecture enabled.
```
// App.tsx
import { useEffect } from 'react';
import { View } from 'react-native';
function uriToBlob(uri: any) {
return new Promise((resolve, reject) => {
const xhr = new XMLHttpRequest();
xhr.responseType = 'blob';
xhr.onload = () => {
const blob = xhr.response;
resolve(blob);
};
xhr.onerror = err => {
reject(err);
};
xhr.open('GET', uri);
xhr.send();
});
}
export default function App() {
useEffect(() => {
uriToBlob('https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png');
});
return <View />;
}
```
Related issue: https://github.com/facebook/react-native/issues/35042
Reviewed By: NickGerleman
Differential Revision: D40716048
Pulled By: cipolleschi
fbshipit-source-id: 17643d230fa7ea83baee363d137d51f87818baa8
Summary:
This remove a flag to effectively go publishing to Sonatype.
The idea was to protect us against accidentally publishing a nightly as a stable release.
We need to remove this before RC0
Changelog:
[Internal] [Changed] - Remove the --dry-run gate from publishing to Sonatype
Reviewed By: cipolleschi
Differential Revision: D40687038
fbshipit-source-id: e6821905f41899430813f9575f17a5068b05a9bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35092
As we're close to the cut of the 0.71 branch, I'll take the opportunity to polish
our Gradle public API.
We're exposing a mixture of Path (String) and File (java.io.File or RegularFileProperty).
Here I've moved everything to use File as it's more configurable for the users,
specifically if they're using monorepos or other setup.
This also allows us to remove the resolution logic for the cliPath.
Changelog:
[Internal] [Changed] - RNGP - Use the File Api to specify cliPath and remove ComposeSourceMap path
Reviewed By: cipolleschi
Differential Revision: D40710595
fbshipit-source-id: a17095eebae5123b70fd2b8e3d512656817006ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35091
This diff refines the DefaultNewArchitectureEntryPoint to make it easier for user to
either turn on Fabric, TurboModules or both.
Changelog:
[Internal] [Changed] - Make it easier for user to toggle only Fabric or TurboModules in New Architecture
Reviewed By: cipolleschi
Differential Revision: D40710596
fbshipit-source-id: 236060b2ebccb1bf25e7f5c0fc15f54c5ce5f608
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35093
It turns out that using the Artifacts API to manipulate the APK to remove
.so has unintended side effects and is causing the `installDebug` and `installRelease`
commands to fail.
I've resorted to register a packaging option for each variant to make sure we include only
the correct artifacts we want.
This should fix the current startup crash that is experienced on main.
Changelog:
[Android] [Fixed] - RNGP - Do the .so cleanup using pickFirst and exclude
Reviewed By: cipolleschi
Differential Revision: D40722285
fbshipit-source-id: 982e1e9c474522fc4419c969ede5ee14e5404f3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35083
We don't need to `enableCodegenInApps` keys but we can instead rely on the
existence of the `codegenConfig` key inside the `package.json` to decide if
Codegen should run in App modules or not.
Changelog:
[Internal] [Changed] - RNGP - Remove enableCodegenInApps and infer it from package.json
Reviewed By: cipolleschi
Differential Revision: D40687079
fbshipit-source-id: cd4a6c67caa19c1d199ae75388a0551339f876a0
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872.
This PR contains two changes, extracting the visitor object and then factoring out the `getConfigType()` function to the `parsers/utils.js` file. Then we can reuse the same function in both flow and typescript by passing the extracted visitor object.
## Changelog
[Internal] [Changed] - Extract visitor object in the same file and factor out `getConfigType()` to `parsers/utils.js`.
Pull Request resolved: https://github.com/facebook/react-native/pull/35035
Test Plan: Output of `yarn jest react-native-codegen` ensures all passed test cases
Reviewed By: cortinico
Differential Revision: D40548855
Pulled By: cipolleschi
fbshipit-source-id: 310b8565322a4e4800a3fffc67479a9dfa45d620
Summary:
changelog:
[general][Added] - Concurrent rendering safe implementation of ScrollViewStickyHeader
This is a re-land of ScrollViewStickyHeader from Kacie Bawiec.
Reviewed By: yungsters
Differential Revision: D40380217
fbshipit-source-id: 60dc86086a4d9d97eef71c4ed2e26536f7e72889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35089
Changelog:
[General][Fixed] - Back out "Add enum example to Android/iOS rn-tester TurboModule"
This broke the rn-tester adding due to an invalid flow-enum setup. Needs further investigation
Reviewed By: cipolleschi
Differential Revision: D40714320
fbshipit-source-id: 9831276762f90df0ffaca3304382fe5925009343
Summary:
This pull request migrates the activity indicator example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate ActivityIndicator to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35071
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: jacdebug
Differential Revision: D40698379
Pulled By: NickGerleman
fbshipit-source-id: 08b275fcc4e3a10b5872e0031fa2ecce5360a7b9
Summary:
fd91748146 added a condition not to pump an extra message when we didn't see symbolication warnings (which do not seem to show up in a stock internal build), but I missed that the test specific to RCTLogLevelError checked for string containment instead of equality, and the last assertion we process on log level is incorrect in OSS as a result.
Changelog:
[Internal][Fixed] - Fix RCTLoggingTests in OSS
Pull Request resolved: https://github.com/facebook/react-native/pull/35085
Test Plan:
`test_ios-Hermes` passes again in OSS: https://github.com/facebook/react-native/pull/35085 (JSC and Android failures look unrelated)
RCTLoggingTests still pass running `buck test //xplat/js/react-native-github/packages/rn-tester:RNTesterIntegrationTests`
Reviewed By: rshest
Differential Revision: D40699773
Pulled By: NickGerleman
fbshipit-source-id: 5acc8ec2b26a1f9acac2f070b85f1d65ee15a011
Summary:
* Add a DevToolsSettingsManager, which has android and iOS variants, which uses a new TM (Android) or takes advantage of the Settings TM (iOS) to get/set console patch settings
* This is backed by either the existing Settings module (iOS) or a new Java TM, which uses the SharedPreferences AP
## Testing
Manual testing
## Changelog
[General] [Added] - Add DevToolsSettingsManager
Pull Request resolved: https://github.com/facebook/react-native/pull/34964
Test Plan: * Extensive manual testing
Reviewed By: NickGerleman
Differential Revision: D40333083
Pulled By: rbalicki2
fbshipit-source-id: f3816e3bd7dea3086f6f2269c3a099af14aebb3b
Summary:
Without this, the CocoaPods output would display multiple "Building RNTester..." logs. With these changes, we make it clear that these are separate targets that are being configured.
Changelog: [internal]
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40656813
fbshipit-source-id: a317112e804d08b9e64e2d62e8b27e4045b317b0
Summary:
Some portions of continuous test runs RNTesterIntegrationTests will hang for an hour when running in Sandcastle without outputting anything. Locally debugging, I see a deadlock waiting on a semaphore, where the test assumed an extraneous symbolication warning would be fired.
This change makes it so that we only look for the extraneous messages if we haven't already seen the target message, since they do not seem to show up in local testing. I also added assertions per semaphore that the log statement is propagated within a still very gracious 10 seconds. This means we still can see what tests are running/failing if this test has issues, instead of a deadlocked test runner with no output.
Changelog:
[Internal][Fixed] - Fix deadlock in RCTLoggingTests
Reviewed By: cipolleschi
Differential Revision: D40667275
fbshipit-source-id: ab78f3c2ef47e2fd740b1dad2a65912e9542301d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35079
This bumps the Docker image for React Native Android to 6.0
shipping the NDK 23 with it, finalizing all the work needed
to support NDK 23.
Changelog:
[Internal] [Changed] - Bump the Android Docker image to 6.0 (for NDK 23)
Reviewed By: cipolleschi
Differential Revision: D40675449
fbshipit-source-id: 5fb53080ce796263cd592dbc489743e6295060ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35075
This diff updates the New App template for Android to use the React Native Gradle Plugin.
With this we can:
1. Get rid of all the C++ code.
2. Remove a lot of New Architecture logic in the build.gradle
3. Reuse the prebuilts of React Native/Hermes via prefab
Changelog:
[Android] [Changed] - Update the template to use RNGP
Reviewed By: cipolleschi
Differential Revision: D40673732
fbshipit-source-id: 70935248993d1e24904c982e75f12ad580faa9d8
Summary:
There are use cases in which we want to pass a set of unique elements from C++ to JS and back. We can do this simple by re-using a plain JS array for these purposes.
Changelog:
[Internal][Added] react-native bridging > Add support for std::set
Reviewed By: cipolleschi
Differential Revision: D40668244
fbshipit-source-id: d06603440569e5f760c2859a54cf6e4232c7d97a
Summary:
With RNGP we can now deprecate react.gradle
I'll create a page on the website to describe what is the migration strategy here,
but users should be fine by just replacing `apply from react.gradle` with
`apply plugin: com.facebook.react`.
Changelog:
[Android] [Removed] - Deprecate react.gradle
Reviewed By: cipolleschi
Differential Revision: D40675546
fbshipit-source-id: a50348791d669df1ed9e0470a6664e291c1a4584
Summary:
The `typeof X` type annotation now respects the initialization state of `X`: if `X` hasn't been declared it will be an error to get its type.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D40638870
fbshipit-source-id: 57459dec30ec5b87397365a709f2d846c87e378a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35036
This diff is the base to create a polimorphic behavior for TypeScript and Flow parser. This type will allow to share a lot of code between the parsers and also to keep their differences a part.
It will be the base diff/PR for further tasks in the Codegen umbrella Issue
## Changelog:
[General][Added] - Parser interface to divide parser logic.
Reviewed By: cortinico
Differential Revision: D40548707
fbshipit-source-id: e632ba52b00b43e50306e3a792a841e72e8c07f4
Summary:
Bumping RNGP to make sure all the changes are available for 0.71
I've also removed the caret from react-native's package.json as
I don't want .5 to be used by template tests yet.
The Android template needs to be updated in order to use
that version of the Gradle plugin.
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.71.5
Reviewed By: cipolleschi
Differential Revision: D40642114
fbshipit-source-id: 70359efc3d2300e9c04c1b361c45061fd1c2931b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35066
This just bumps the NDK version used inside the template to be 23.
We can't merge this as it is but we have to wait for a bump of the Docker image for Android.
Changelog:
[Android] [Changed] - Bump NDK to 23
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D40637103
fbshipit-source-id: e637140cbe6052e94a6efedf12f4b5b81b90a7eb
Summary:
Throws a JS error instead of crashing Hermes with an invariant when trying to convert a JS symbol or BigInt to a folly::dynamic value.
Changelog:
[General][Fixed] - Fixed crash when converting JS symbol to folly::dynamic
Reviewed By: javache
Differential Revision: D40444164
fbshipit-source-id: 37df8059b2eb425563f30cf1e9c0436e8d665b34
Summary:
I tried to build the source locally to test changes with `rn-tester`. However, the gradle build failed due to "./ReactAndroid/gradle.properties (No such file or directory)". I believe this error was introduced by https://github.com/facebook/react-native/commit/3d05bac5872b42a5f412ec9042ce5be0b5d5b8d3.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - Fix ReactAndroid not found in rn-tester build
Pull Request resolved: https://github.com/facebook/react-native/pull/35058
Test Plan:
- Clone the react-native repo.
- Run `cd packages/rn-tester`.
- Run `yarn install-android-jsc` and encounter the error.
- Apply the fix.
- Run `yarn install-android-jsc` and build succeeds.
Reviewed By: cipolleschi
Differential Revision: D40639856
Pulled By: cortinico
fbshipit-source-id: 58b51bcad0af7a21cac032c98484c5942a203e4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35067
I accidentally broke test_android by landing a diff without waiting for
the full CI output.
Changelog:
[Internal] [Fixed] - Unbreak test_android by passing the correct file to hermesc
Reviewed By: cipolleschi
Differential Revision: D40638239
fbshipit-source-id: 1d03106f3b144f537265910df095a6023b181d85
Summary:
As pointed out by necolas on https://github.com/facebook/react-native/issues/34424#issuecomment-1261482517 we forgot we add the `role` prop mapping to the `Text` component. This PR adds a new `role` prop to `Text`, mapping the web `role` values to the already existing `accessibilityRole` prop and moves the `roleToAccessibilityRoleMapping` to a common file that can be imported by both the `Text` and `View` components as requested on https://github.com/facebook/react-native/issues/34424. This PR also updates the RNTester AcessebilityExample to include a test using this new prop.
## Changelog
[General] [Added] - Add role prop to Text component
Pull Request resolved: https://github.com/facebook/react-native/pull/34976
Test Plan:
1. Open the RNTester app and navigate to the Accessibility Example page
2. Test the `role` prop through the `Text with role = heading` section
Reviewed By: yungsters
Differential Revision: D40596039
Pulled By: jacdebug
fbshipit-source-id: f72f02e8bd32169423ea517ad18b598b52257b17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35063
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm add Variant support to RNGP via the Variant API from AGP 7.x
A short summary of changes:
- I've pushed a number of breaking changes to ReactExtension (we should document them in the release notes). Specifically I've removed properties which I believe were unnecessary and confusing
- I've removed all the extra logic to do the .so cleanups and use the new tasks that use the Artifacts API
- I've introduced only a `debuggableVariants` to make all the decisions for the bundling and minification which should be sufficient for users
- I've removed all the funcional interfaces are replaced them with lists as they're easy to handle and understand for users.
Changelog:
[Android] [Changed] - Added Flavor Support to React Native Gradle Plugin (RNGP)
Reviewed By: cipolleschi
Differential Revision: D40335028
fbshipit-source-id: d9ac1437de8a27db2e93df15b13772b221e036b2
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
I'm extending RNGP to do autoconfiguration of dependencies for React Native and Hermes Engine using the Utils classes which were introduced before.
Changelog:
[Internal] [Changed] - RNGP - Automatically Configure Dependencies for ReactNative & Hermes
Reviewed By: cipolleschi
Differential Revision: D40633487
fbshipit-source-id: d4240987a9400fff2ec2aff2d13afc5b24778598
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Historically we used to enable the codegen only for library modules. This is not working well for apps like RN Tester which don't have library modules but are running the codegen.
Therefore I'm introducing the `enableCodegenInApps` that is allowing apps to turn off the codegen if needed.
Changelog:
[Internal] [Changed] - RNGP - Introduce enableCodegenInApps
Reviewed By: cipolleschi
Differential Revision: D40633106
fbshipit-source-id: dc2ae9bbfe5b7940f9e9fe505ab2198a42c8a3f6
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm renaming the top level property to enable hermes from `enableHermes` to `hermesEnabled`. We have a bunch of other properties which are called *Enabled. This one was following a different convention.
I'm retaining the backward compatibility for users using `project.ext.react.enableHermes` so this is not going to be a breakign change.
Changelog:
[Internal] [Changed] - RNGP - Top level property enableHermes -> hermesEnabled
Reviewed By: cipolleschi
Differential Revision: D40633109
fbshipit-source-id: 9d7efad6cb3bb382d1beb56966795a3f42bdaae6
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm creating a new task BundleAndHermesCTask that is variant-aware.
Historically we had problems with the Bundle and the Hermes task being separated and overriding their own output. Consolidating those two steps in a single one will make it easier to support seaprate variants.
I'm going to use this task in a subsequent diff.
Changelog:
[Internal] [Changed] - RNGP - Introduce the BundleAndHermesCTask
Reviewed By: cipolleschi
Differential Revision: D40633108
fbshipit-source-id: 89f6d32ef219626ed5d4c5a0b8ac804c6704b2d6
Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Move JSC and Hermes CocoaPods configuration to scripts/cocoapods/jsengine.rb.
This file provides a setup_jsc! function and a setup_hermes! function that will configure the necessary pod dependencies for each of the supported JavaScript engines.
Currently, the JSI and JSC pods are installed in both cases. This will likely change in upcoming changes to how Hermes and JSC are configured.
Changelog: [internal]
Reviewed By: dmytrorykun
Differential Revision: D40459234
fbshipit-source-id: d6c89c7f650b1efcce5622594db7fd726eafc2bc
Summary:
The React-Hermes and hermes-engine headers are only needed when Hermes is enabled.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40451162
fbshipit-source-id: d38830f8abe57a91798e216d7930bb7add483899
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
This is part of a series of diffs to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm removing two deprecated properties `useJavaGenerator` and `reactRoot`.
They were both not widely used, we had a deprecation warning and now they're just making the whole setup harder.
Changelog:
[Internal] [Changed] - RNGP - RNGP - Setup tasks to cleanup the Apk/Aab from unused .so
Reviewed By: cipolleschi
Differential Revision: D40547688
fbshipit-source-id: c4b8c1cef3a2abae1060e8ce2540e45d0313a4be
Summary:
Changelog: [Internal]
This occurs sometimes on AR, because `measure` doesn't exist on `Suspense`.
Reviewed By: lunaruan
Differential Revision: D40531850
fbshipit-source-id: 4013d660e5e47a28b27d5b6df57bcb7ce88a4ea8
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm removing the `applyAppPlugin` property which was never used. The new logic will apply the App Plugin if the `com.android.application` plugin is found.
I've also removed the corresponding tests. New one will follow afterwards
Changelog:
[Internal] [Changed] - RNGP - Remove unused applyAppPlugin
Reviewed By: cipolleschi
Differential Revision: D40547689
fbshipit-source-id: ce1089498a586a43cb5e07950767c2c4b51b4597
Summary:
Refer to `In component, props and events pick properties from the component interface by themselves independently, I would like to reverse the direction, to have a function dispatching properties to props and events, to reduce duplicated code.
` in https://github.com/facebook/react-native/issues/34872
## Changelog
[General] [Changed] - Refactor codegen: Dispatch props and events from a central place.
Pull Request resolved: https://github.com/facebook/react-native/pull/34975
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D40507917
Pulled By: cipolleschi
fbshipit-source-id: 71988877008ae11a01affd31b34bb3a3b88f96be
Summary:
Changelog: [RNTester][Internal] - Add pointer event test ensuring that pointerover events are fired when an element appears under the cursor
This diff adds a port of an existing web platform test that checks if pointerover & pointerenter events are fired for elements that are mounted underneath the cursor.
Reviewed By: lunaleaps
Differential Revision: D40449499
fbshipit-source-id: 393f4325f7a9d9025fe9d0aab38642b1e3ab2612
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35034
Currently, when creating an app using the command:
`npx react-native init MyApp --version nightly`
iOS fails to install the dependencies because it does not find a proper tarball to run Hermes.
This diff solve the problem by fetching the Hermes tarball that is created by the CI while building the nightly.
## Changelog:
[iOS][Fixed] - Make the nightly work with the proper Hermes tarball
Reviewed By: cortinico
Differential Revision: D40512418
fbshipit-source-id: f510f84be9f19807236091687df5e13961103318
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35015
React Native releases are cut every few months. Without testing, the workflow is prone to breakage.
Dry-run the release workflow on every commit in order to surface any issues as they are introduced instead of at release time.
Fixed issues that surfaced during testing of this workflow:
- Upload both Hermes tarballs
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D40483764
fbshipit-source-id: 5ca6bd4dcdfd64c24882ffb202edbfd701efd462
Summary:
I forgot to update the path of the default CMakeLists file for the template.
I'm doing it here.
Changelog:
[Internal] [Changed] - Let the user use the default CMakeList inside the template
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40517207
fbshipit-source-id: 7c02ff5893064dbf54ad573c2984884b1017dacf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35027
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm extending preparing classes to handle the Dependency versions and pre-configure the repositories as we wish.
Changelog:
[Internal] [Changed] - RNGP - Create DependencyUtil to support with dep version configuration
Reviewed By: cipolleschi
Differential Revision: D40512101
fbshipit-source-id: 05867a4c3fd341373669ea72d950ec4ee78a158d
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm creating some tasks that will take care of doing the .so cleanup of the Apk/AppBundle.
Historically we used to use a error prone mechanism which was relying on assumptions on file paths and was breaking the variant-aware assumptions.
I'm going to use those tasks in a subsequent diff.
Changelog:
[Internal] [Changed] - RNGP - RNGP - Setup tasks to cleanup the Apk/Aab from unused .so
Reviewed By: cipolleschi
Differential Revision: D40512100
fbshipit-source-id: 649999dc8d126e7c939b61a5cec608d39cd7f688
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm extending the GenerateCodegenSchemaTask to make sure we exclude the generated build/ASSETS and build/RES folders from execution avoidance.
Changelog:
[Internal] [Changed] - RNGP - Make sure GenerateCodegenSchemaTask is not considering generated assets/res for execution avoidance
Reviewed By: cipolleschi
Differential Revision: D40512103
fbshipit-source-id: 193f4fd241a0fd973863beb6ff0dd1128dcee1d7
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
Summary:
The `template/android/app/build_defs.bzl` file can be removed as it's unused in the Template.
## Changelog
[Internal] - Remove build_defs.bzl from Android Template
Pull Request resolved: https://github.com/facebook/react-native/pull/35020
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D40506250
Pulled By: cortinico
fbshipit-source-id: 14d8522a995a4b19b5b6610fcb2c5b1dda3374c8
Summary:
I've just realized we have a typo in the `OsRule`. This is actually causing those tests to fail if run locally on M1 (but not on CI as it runs on a `amd64` architecture).
## Changelog
[Internal] - Fix typo in OsRule
Pull Request resolved: https://github.com/facebook/react-native/pull/35024
Test Plan: Not much to test other than it's green locally, previously it was red. CI should be green regardless
Reviewed By: cipolleschi
Differential Revision: D40507320
Pulled By: cortinico
fbshipit-source-id: 75600014a515b2cb76debbd6e1d79ecd78ea5092
Summary:
This configuration was stale and has no effect on the Gradle Plugin, I'm removing it then 👍
## Changelog
[Internal] - Remove useJavaGenerator key from ReactAndroid/build.gradle file
Pull Request resolved: https://github.com/facebook/react-native/pull/35021
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D40506375
Pulled By: cortinico
fbshipit-source-id: 2bcdc67686b1ac9fc77091d9324f5ad585df8818
Summary:
A super small PR to bump CLI to latest available of the 9.x stream, to make available in main the asset image fix (https://github.com/react-native-community/cli/pull/1290) and to be able to cherry pick it back in 0.70 branch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to 9.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/35022
Test Plan: CI is green
Reviewed By: dmytrorykun
Differential Revision: D40507344
Pulled By: huntie
fbshipit-source-id: 7c3753e9df154eb5835f021cdfe1b476499afb9a
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872
This PR extracts `UnsupportedFunctionReturnTypeAnnotationParserError` exception to a separate function inside an `error-utils.js` file
## Changelog
[Internal] [Changed] - Extract `UnsupportedFunctionReturnTypeAnnotationParserError` to a seperate function inside `error-utils.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/34965
Test Plan:
```sh
yarn jest react-native-codegen
```
Added unit case in `error-utils-test.js` file
<img width="939" alt="Screenshot 2022-10-13 at 11 46 54 AM" src="https://user-images.githubusercontent.com/86605635/195517350-dcb7a26d-434c-4e45-a174-ce82931073e5.png">
Reviewed By: dmytrorykun
Differential Revision: D40338048
Pulled By: cipolleschi
fbshipit-source-id: baa41e0e96c9e17a35f316433c8d80c9bf88d334
Summary:
This PR extracts the content of the codegen case 'String' into a single `emitString` function inside the parsers-primitives.js file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitString` function.
ref: https://github.com/facebook/react-native/pull/34936
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract the content of the case 'StringTypeAnnotation' into a single emitString function
Pull Request resolved: https://github.com/facebook/react-native/pull/34981
Test Plan: Run `yarn jest react-native-codegen` and ensure CI is green
Reviewed By: cortinico
Differential Revision: D40376836
Pulled By: cipolleschi
fbshipit-source-id: feb1b07ec7fc2c333f5054f8cd8d18457d985257
Summary:
https://github.com/facebook/react-native/pull/34933 has been merged just after I pushed a new commit to the branch to improve tests of `assertGenericTypeAnnotationHasExactlyOneTypeParameter` function, but the last commit was not imported to the internal repository.
The `assertGenericTypeAnnotationHasExactlyOneTypeParameter` can throw different types of Error, and I believe that `.toThrow(Error)` is not specific enough. So I replaced it with `toThrowErrorMatchingInlineSnapshot()`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Improve assertGenericTypeAnnotationHasExactlyOneTypeParameter tests in parsers-commons
Pull Request resolved: https://github.com/facebook/react-native/pull/34942
Test Plan: Some test cases were ok because the assertGenericTypeAnnotationHasExactlyOneTypeParameter function threw an Error, but for the wrong reason. I've made sure that the error displayed in the inline snapshot is the one we expect.
Reviewed By: cortinico
Differential Revision: D40384993
Pulled By: cipolleschi
fbshipit-source-id: aaa943be1e808af2c5131f7d06baf24bc3bffa31
Summary:
This PR is a part of https://github.com/facebook/react-native/issues/34872.
Extracted the UnsupportedObjectPropertyValueTypeAnnotationParserError in its own throwing function and reuse that function passing a proper type.
## Changelog
[Internal] [Changed] - Extract the UnsupportedObjectPropertyValueTypeAnnotationParserError in its own throwing function and reuse that function passing a proper type.
Pull Request resolved: https://github.com/facebook/react-native/pull/34917
Test Plan:
Output of yarn jest react-native-codegen.
<img width="451" alt="Screenshot 2022-10-10 at 12 55 39 PM" src="https://user-images.githubusercontent.com/32268377/194816863-5220dbaa-3b63-42bf-8e62-9d7b915f7cbd.png">
Reviewed By: cortinico
Differential Revision: D40424885
Pulled By: cipolleschi
fbshipit-source-id: 08d4d13ee3959391261fe13c190a4bb893970757
Summary:
[`Share`](https://reactnative.dev/docs/share) currently does not support the `anchor` option in iOS, so share sheets will always be displayed in the middle of the screen on iPads and on the top left corner of the window on Mac Catalyst.
This PR utilizes the `anchor` functionality already implemented in [`ActionSheetIOS`](https://reactnative.dev/docs/actionsheetios) to bring this support to `Share` on iOS.
## Changelog
[iOS] [Changed] - type definition for the `options` parameter of `Share.share` (added optional `anchor` property)
[iOS] [Added] - `anchor` option support for `Share`
Pull Request resolved: https://github.com/facebook/react-native/pull/35008
Test Plan:
Tested with modified `rn-tester` that utilizes the `anchor` option on iPad simulator. Marked all 3 changes in code.

```js
const SharedAction = () => {
const [shared, setShared] = React.useState();
const ref = React.useRef(); /* create ref (1/3) */
const sharedAction = async () => {
try {
const result = await Share.share(
{
title: 'Create native apps',
message:
('React Native combines the best parts of native development with React, a best-in-class JavaScript library for building user interfaces.': string),
url: 'https://reactnative.dev/',
},
{
subject: 'MUST READ: Create native apps with React Native',
dialogTitle: 'Share React Native Home Page',
tintColor: 'blue',
anchor: ref.current?._nativeTag, /* add anchor in options (2/3) */
},
);
if (result.action === Share.sharedAction) {
setShared(result.action);
} else if (result.action === Share.dismissedAction) {
//iOS only, if dialog was dismissed
setShared(null);
}
} catch (e) {
console.error(e);
}
};
return (
<View style={styles.container}>
<Text>action: {shared ? shared : 'null'}</Text>
<Text style={styles.title}>Create native apps</Text>
<Text>
React Native combines the best parts of native development with React, a
best-in-class JavaScript library for building user interfaces.
</Text>
{/* supply ref to Node (3/3) */}
<Text ref={ref} style={styles.button} onPress={sharedAction}>
SHARE
</Text>
</View>
);
};
```
Reviewed By: cipolleschi
Differential Revision: D40459336
Pulled By: skinsshark
fbshipit-source-id: 72fbb3905ea0b982bb7f4b99967d121cd482181a
Summary:
circleci analyze_code errors: https://app.circleci.com/pipelines/github/facebook/react-native/16638/workflows/76804803-ceb5-4fb3-bd24-26bbb9826827/jobs/321696
- __Image.flow and Image.ios:__ requires needed to be sorted alphabetically
- __error-utils-test.js:__ duplicate describe block title is used, i believe this was a typo
Changelog:
[Internal][Fixed] - fix circleci:analyze_code errors
Reviewed By: lunaleaps
Differential Revision: D40491001
fbshipit-source-id: a1df6ded77374f92e297d0a8866a2c4096e1196a
Summary:
Add full functionality for `Symbol`s and `BigInt`s in the debugger. Note- using the [protocol monitor](https://umaar.com/dev-tips/166-protocol-monitor/) was the most reliable way of figuring out which fields exactly need to be set for these types to play nicely in DevTools. I brought up the monitor and then used the regular, standard chrome console with the functionality I wanted:
- Evaluating `Symbol` and `BigInt` literals, like `Symbol.for("a")` and `1n`
- Right-click save the resulting expressions
From there, I inspected the CDP messages being sent. Then I was able to fill in the correct fields from there, and be confident that those were correct, given that I was copying the exact behavior of Chrome itself.
Changelog:
[General][Fixed] Support properly sending BigInts and Symbols over the Chrome DevTools Protocol.
Reviewed By: neildhar, jpporto
Differential Revision: D40442228
fbshipit-source-id: 98a514edbeb35fcbd427a25475f435e22956f2db
Summary:
Changelog:
[Internal][ErrorHandling] 3/n Add a gate for parsing unhandled JS errors in C++
Gate this just in case it causes issues. Enabling this is definitely a better behavior than before, because we want the JS stack when there is a JS error, not the native stack.
Reviewed By: sammy-SC
Differential Revision: D40397393
fbshipit-source-id: 586b4d7bcf710edb048b5c643646ba2f3c4c302a
Summary:
checking for background == null to fix this error:
```java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.drawable.Drawable$ConstantState android.graphics.drawable.Drawable.getConstantState()' on a null object reference
at com.facebook.react.views.textinput.ReactTextInputManager.setUnderlineColor(:4)
```
Changelog:
[Internal][Fixed] - check for null background in Android TextInput setUnderlineColor
Reviewed By: beatthat
Differential Revision: D40451369
fbshipit-source-id: 8618d5ff73f517f714c26a0b17af078493822244
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35013
Previously, release builds were only built for stable RN releases. This creates a discrepancy between CI jobs that run on commits versus CI jobs that run on releases. We are working on reducing these differences in order to limit the number of issues we may face when cutting a React Native release.
Now, build_hermes_macos will be run as a matrix of Debug/Release builds in every workflow.
Updated build_hermes_macos to take 'flavor' as a Enum, not a string.
Store hermesc in separate directories as Circle CI does not allow two different jobs (e.g. build_hermes_macosDebug and build_hermes_macosRelease) to write to the same path when storing artifacts.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D40308952
fbshipit-source-id: b96b9a6c7cf8d0becafcf2fdcb761540816ae336
Summary:
In this diff I'm shipping and deleting mapBufferSerialization for Text measurement
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348982
fbshipit-source-id: 7336cbe055a55d7d8d4f0a723049842bae1defb5
Summary:
This diff refactors the initialization of MapBuffer so
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348981
fbshipit-source-id: 88bbf4f2370373c20f805c3b23d0ecbe8a26bb86
Summary:
Recently this PR got merged https://github.com/facebook/react-native/pull/34919 that aligned the info.plist to the current default. Problem: the variable `MARKETING_VERSION` was not set in the template, so generating a new project and testing on iOS would fail accordingly:
<img width="1400" alt="Screenshot 2022-10-18 at 15 27 27" src="https://user-images.githubusercontent.com/16104054/196461640-470079f5-0f64-471f-8221-0d17f2b0114f.png">
This PR takes care of setting the variable so that the app can build successfully.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - add MARKETING_VERSION to template project
Pull Request resolved: https://github.com/facebook/react-native/pull/35012
Test Plan: Run `yarn test-e2e-local -t RNTestProject`, apps builds correctly and runs on simulator.
Reviewed By: cipolleschi
Differential Revision: D40472420
Pulled By: cortinico
fbshipit-source-id: 18ddd57ce54186a101321583a7a8391e97ca9511
Summary:
This is the second diffs that backs out the Custom Native State from the Codegen. The reason why we are backing it out are:
1. It forces users to create new types in JS that are not ctually used there. For example, the NativeState you define, and eventually exports, in JS is not used anywhere in your JS code.
2. You need to put in the JS native state some types that does not exists in JS, only to have them generated by the Codegen. ImageRequest, for example, does not exists in JS, but you need it in your (iOS) state to load images
3. There are a lot of edge cases due to how C++ handles variables. Some variables needs to be created as pointers. Some others as `const &`. It does not scale to hard code all of them and there is the risk to have the same type that needs to be a pointer in some case and something else in others.
4. It is better to instruct the users on how to properly create a component with Custom State, Shadow Node and Descriptor.
## Changelog:
[General][Removed] - Back out parsing and generation of Custom Native State from Codegen
Reviewed By: cortinico
Differential Revision: D40426134
fbshipit-source-id: c368e122cc31ee8df056fe1bf6cecaab482140a4
Summary:
This is the first diffs that backs out the Custom Native State from the Codegen. The reason why we are backing it out are:
1. It forces users to create new types in JS that are not ctually used there. For example, the NativeState you define, and eventually exports, in JS is not used anywhere in your JS code.
2. You need to put in the JS native state some types that does not exists in JS, only to have them generated by the Codegen. ImageRequest, for example, does not exists in JS, but you need it in your (iOS) state to load images
3. There are a lot of edge cases due to how C++ handles variables. Some variables needs to be created as pointers. Some others as `const &`. It does not scale to hard code all of them and there is the risk to have the same type that needs to be a pointer in some case and something else in others.
4. It is better to instruct the users on how to properly create a component with Custom State, Shadow Node and Descriptor.
## Changelog
[General][Removed] - Back out components with native state in RNTester
Reviewed By: cortinico
Differential Revision: D40419254
fbshipit-source-id: 1895c7050f01f76a8901a97e9700f74cae707b79
Summary:
Changelog:
[General][Added] - Introduce `useAnimatedValue` hook to make it easier working with `Animated.Value`s in function components.
Reviewed By: javache
Differential Revision: D40434219
fbshipit-source-id: 3caf6ad98d11a534b8cc6816820bc1d125150380
Summary:
This change starts adding more coverage to GitHub Actions. Existing workflows are split up to be per-platform, and stale scripts, etc are removed.
We are currently limited a bit by issues with the build itself, but this still adds a good bit of coverage that readily works, and adds places to inject more.
Another option would have been to move these to CircleCI where we have more credits, or used docker images instead of manual setup steps. etc, The Yoga build and number of changes is very light though, so we don't really need the complexity yet.
Some TODOs:
1. Fix the Apple Builds (pod lint and pod install return errors seen by the community)
2. Add working Android UTs
3. Add C++ UTs
4. Add Apple Publish
5. Add version stamping
Changelog:
[Internal][Added] - Start Adding Yoga GitHub Actions
X-link: https://github.com/facebook/yoga/pull/1165
Reviewed By: cortinico
Differential Revision: D40386426
Pulled By: NickGerleman
fbshipit-source-id: c540dd25bfec6ac8c05e461c1236ef7fe6cb8598
Summary:
We found this feature crashing the app during hot reload, and as there is no user code dependent on it so far, we decided to disable it until we find the root cause.
changelog: [internal] internal
Reviewed By: mdvacca
Differential Revision: D40445312
fbshipit-source-id: fe28b58c5dca6c91389ad38675ca37669a4965a0
Summary:
Changelog: [RNTester][Internal] - Add PointerOver/PointerOut handling test
This diff adds another platform test based on WPT testcase for mouseover/mouseout events but instead applied to pointerover/pointerout events recently implemented for RN.
Reviewed By: lunaleaps
Differential Revision: D40359286
fbshipit-source-id: 672f413f56faca55b9d838150fb66de66d78d6f2
Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## 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] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary:
This PR is the follow up to the conversation started here by SimenB: https://github.com/react-native-community/discussions-and-proposals/issues/509
Basically, we want to move RN to use its own custom environment so that we can tweak it going forward - this PR in fact only sets up the groundwork for that; robhogan mentioned that with this in place, Meta engineers can
> iterate on it (with jest-environment-node as a starting point) against our internal product tests
This is also connected to Rob's work to bring Jest 29 into the codebase https://github.com/facebook/react-native/pull/34724 and my "mirror" PR to bring template in main up to the same version (https://github.com/facebook/react-native/pull/34972)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - move Jest config to use a custom react-native Jest env
Pull Request resolved: https://github.com/facebook/react-native/pull/34971
Test Plan: Tested that `yarn test` in main works fine after the changes; CI and Meta's internal CI will also serve the purpose of verifying that it works (but there's no reason not to since it's still pretty much just relying on `node`).
Reviewed By: huntie
Differential Revision: D40379760
Pulled By: robhogan
fbshipit-source-id: 2c6d0bc86d337fda9befce0799bda2f56cc4466c
Summary:
Breaks the runtime dependency cycle introduced in D40259791 (https://github.com/facebook/react-native/commit/971599317b7bdf1152157206f9503a23ac8c4162) by converting a value import to a type import. (Unlike runtime dependency cycles, type-level cycles are OK as long as they are reasonably small.)
Changelog:
[General][Fixed] - Fix require cycle warning in VirtualizedList
Reviewed By: javache
Differential Revision: D40412019
fbshipit-source-id: 33bf3af12be64a1932549a0d11f2ce8b3c483218
Summary:
changelog: [internal]
Removing listener on detached node leads to a red box, if the said node is `DiffClampAnimatedNode`. This is because calling `AnimatedNode.__getNativeTag()` makes native module call and creates node in native. This node is not completely initialised and red boxes because `[RCTAnimatedNode parentNodes]` is nil when it shouldn't be.
The fix is make sure all listeners are removed before node is destroyed. It is logically correct thing to do. The fix is global, for all components using `DiffClampAnimatedNode`.
Reviewed By: yungsters
Differential Revision: D40381895
fbshipit-source-id: 4f558faf8101b70552f30e6360998e902aacbc83
Summary:
Changelog:
[Internal][Added] - Add support for passing objects with `AnimatedNode` values and arrays of `AnimatedNode` elements in the `transform` styling prop.
Reviewed By: javache
Differential Revision: D40379943
fbshipit-source-id: 826b9cd0c0cfe02b55d86d1c735f8faf31196e64
Summary:
It seems like CircleCI is not handling well env variables with \n in it.
I'm moving it over to a base64 encoded string and I'm extending the publish
scripts to base64 decode the key.
Changelog:
[Internal] [Changed] - Unbreak Nightly job by providing a GPG key as base64 encoded.
Reviewed By: cipolleschi
Differential Revision: D40426438
fbshipit-source-id: a60a7e7ad71580e81e675c84008d2712712e42a6
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872:
> Extract the visit function in a shared function in the parsers/utils.js folder. Use the new function in the Flow and TypeScript parsers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract the visit function in a shared function in the parsers/utils.js
Pull Request resolved: https://github.com/facebook/react-native/pull/34946
Test Plan: I tested using jest, flow and eslint commands.
Reviewed By: NickGerleman
Differential Revision: D40276462
Pulled By: cipolleschi
fbshipit-source-id: 299cc2a3aa65a9757b217192a13838d037c497a1
Summary: Changelog: [Internal] Add more properties to PointerEvent, ensure all web platform tests are passing
Reviewed By: mdvacca
Differential Revision: D40314330
fbshipit-source-id: 071683f26f5a1e17d7ea49ac022c0ca23b6f9947
Summary: Changelog: [Internal] - Add an option to only see failed tests for PointerEvents web platform tests
Reviewed By: mdvacca
Differential Revision: D40281369
fbshipit-source-id: 638879b39ca66c11e722e6140c631dacfc98ee34
Summary:
Changelog: [Internal] Reorder and prefix things with wpt for convenience
Open to other suggestions
Reviewed By: mdvacca
Differential Revision: D40247488
fbshipit-source-id: 4046040d5904b324a9a84dc47f4de858456e7bbc
Summary:
Changelog:
[General][Added] - Highlight elements on hover while mouse down for React DevTools element inspection.
Since there is probably no mouse hover events for RN, this diff implements something that works similar like hover for RN: user keeps the mouse down and moves the cursor around, and the elements under the mouse is highlighted just like Web.
Reviewed By: lunaruan
Differential Revision: D40369733
fbshipit-source-id: ef223ee0f31f4e0372674fc39dd13bad8c15aa92
Summary:
This diff adds defaults to Jest.fn's type params.
An upcoming change to flow will be more restrictive about how we implicitly instantiation type arguments. Since the argument to jest.fn is often omitted, this signature is the single biggest offender of our new rules. To reduce the error diff, I'm adding reasonable defaults so that the mocked function can still behave like a function without adding extra flow errors where there were none before.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D40394215
fbshipit-source-id: 2df596b6ba8b54680694e08c432a1e7c94dc2df0
Summary:
The jsi library itself is `jsi/jsi.{h,cpp}`. JSIDynamic provides support for converting between folly::dynamic and jsi::value, independent of the jsi library.
Changelog:
[iOS][Changed] Moved JSIDynamic out of React-jsi and into React-jsidynamic
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40334023
fbshipit-source-id: d2c69e7afb7f43f93080301b88c81e1fa46279d7
Summary:
There's no need for the 3 type arguments here. Flow will infer a union already if multiple properties are provided. Worse, by not providing these properties these tvars end up with no bounds, which can cause downstream constraints to stall. All of the suppresisons added here are for legitimate errors that were uncovered by consolidating to one type argument.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D40355811
fbshipit-source-id: 088fd087017a6082c793ef00c8810a81b39fb9fb
Summary:
Changelog: [Internal] Code clarity: Use enum to clarify the values parsed by JsErrorHandler
Create a enum `JSErrorHandlerKey` to define the keys for the values that goes into each stack frame.
Next up -- using this in the Bridge!
Reviewed By: sammy-SC
Differential Revision: D40326127
fbshipit-source-id: e416814fbcaa922afa92d9baf79eaa898ff979f0
Summary: changelog: Fix vertical text alignment in new architecture when line height is not 0.
Reviewed By: javache
Differential Revision: D40346225
fbshipit-source-id: f6282cb8df80e9a543e5602fddcca1a1a82377e3
Summary:
changelog: [internal]
`parentNodes` may be nil in case `DiffClampAnimatedNode` was not setup correctly. In this case, let's just noop and warn rather than throw redbox. This is not necessary but makes the code safer in world where native animated is invoked by new and old architecture at the same time (pre-bridgeless).
Reviewed By: yungsters
Differential Revision: D40381724
fbshipit-source-id: 6252f05951079649b810902559bfec9dd4f957d9
Summary:
There's no need for the 3 type arguments here. Flow will infer a union already if multiple properties are provided. Worse, by not providing these properties these tvars end up with no bounds, which can cause downstream constraints to stall. All of the suppresisons added here are for legitimate errors that were uncovered by consolidating to one type argument.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D40355813
fbshipit-source-id: f02a101e5e32f3a2f660a34349e6416b9fde4124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34983
This sets up our CircleCI logic to publish artifacts to Maven Central.
I will check if tomorrow's nightly successfully landed on Maven Central
Snapshot repository.
I've added a --dry-run to the the close and release step of the publishing
to avoid accidentally publishing to Maven Central. We'll remove this if
we decide to go with the Maven Central publishing.
Changelog:
[Internal] [Changed] - Configure CircleCI to publish artifacts to Maven Central
Reviewed By: jacdebug, huntie
Differential Revision: D40377691
fbshipit-source-id: 36a74074ea95097bb7268352e40f4d2670f3cd65
Summary:
Changelog:
[General][Changed] - Add Metro health check files to the template's `.gitignore`
We're adding an opt-in watcher health check to Metro, which can occasionally leave files named `.metro-health-check*` in the project. To ensure this doesn't clutter people's repos accidentally if enabled, we preemptively add this as a pattern to `.gitignore` in the new project template. We also add it to the React Native repo's `.gitignore` file just in case.
Reviewed By: arushikesarwani94
Differential Revision: D40352040
fbshipit-source-id: 261803b684d79292c014205084e61d5e4f7aeb3d
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872.
As a part of this PR, `UntypedModuleRegistryCallParserError` is separated into its own throwing function in `error-utils.js` file and is used in both Flow and TypeScript parsers
## Changelog
[Internal] [Changed] - Extract `UntypedModuleRegistryCallParserError` to a separate function inside `error-utils.js` file.
Pull Request resolved: https://github.com/facebook/react-native/pull/34953
Test Plan:
Added unit case in error-utils-test.js file to test the new function.
Output of `yarn jest react-native-codegen` ensures all passed test cases.
<img width="450" alt="Screenshot 2022-10-12 at 12 44 36 PM" src="https://user-images.githubusercontent.com/32268377/195277708-97340db3-f3d8-48a3-9a59-95d2747c67b0.png">
Reviewed By: christophpurrer
Differential Revision: D40297017
Pulled By: cipolleschi
fbshipit-source-id: b02dcf0e110ab903a0d1831783194ae4a543075b
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872.
This PR extracts `IncorrectModuleRegistryCallTypeParameterParserError` exception to a separate function inside an `error-utils.js` file
## Changelog
[Internal] [Changed] - Extract `IncorrectModuleRegistryCallTypeParameterParserError` to a seperate function inside `error-utils.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/34941
Test Plan:
```sh
yarn jest react-native-codegen
```
Added unit case in `error-utils-test.js` file
<img width="940" alt="Screenshot 2022-10-11 at 4 42 03 PM" src="https://user-images.githubusercontent.com/86605635/195076564-3b023c17-661c-4330-805c-0216c4391d59.png">
Reviewed By: dmytrorykun
Differential Revision: D40296642
Pulled By: cipolleschi
fbshipit-source-id: 7c7bba6a4f68e9b8fa4729a7651f22cce6d7ca6e
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872
This PR extracts `IncorrectModuleRegistryCallArityParserError` exception to `throwIfIncorrectModuleRegistryCallArityParserError` inside an `error-utils.js` file.
## Changelog
[Internal] [Changed] - Extracted IncorrectModuleRegistryCallArityParserError exception to throwIfIncorrectModuleRegistryCallArityParserError function
Pull Request resolved: https://github.com/facebook/react-native/pull/34940
Test Plan:
Added unit case in error-utils-test.js file
yarn jest react-native-codegen
<img width="1144" alt="Screenshot 2022-10-11 at 4 04 55 PM" src="https://user-images.githubusercontent.com/22423684/195070498-627d1bb8-53b1-43d3-b410-462e4f0da23a.png">
Reviewed By: dmytrorykun
Differential Revision: D40296626
Pulled By: cipolleschi
fbshipit-source-id: 33a299b1adf6334753c2390a81a54832c9096ec5
Summary:
This PR extracts the codegen `ModuleInterfaceNotFoundParserError` exception into a separate function inside `error-utils.js` so that it can be used by both Flow and Typescript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `throwIfModuleInterfaceNotFound` function.
## Changelog
[Internal] [Changed] - Extract codegen `ModuleInterfaceNotFoundParserError` in a separate function that can de used by Flow and TypeScript parsers
Pull Request resolved: https://github.com/facebook/react-native/pull/34922
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: dmytrorykun
Differential Revision: D40296533
Pulled By: cipolleschi
fbshipit-source-id: 205469b15337f6c3847936a6ef5427b5a9e08665
Summary: Changelog: [Internal] - Add a display example for offset of many pointers
Reviewed By: mdvacca
Differential Revision: D39736111
fbshipit-source-id: 1fb3f1037d7e743ae1a383a4f4ee876e32da4a6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34962
For jobs that take a string parameter, where that string parameter is expected to be one of a set of accepted values, use an enum instead.
If an unexpected value is passed to a enum parameter, then `circleci config validate` will flag the issue.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D40310118
fbshipit-source-id: b8416c415705ff6eba80cc5f0d9bfe670569f732
Summary:
Changelog: [Internal] - Add more state to PointerEventState per pointer such that `offset` coordinates and `hitPath` accurately reflect each pointer.
This change eagerly calculates the hitPath of every pointer under a MotionEvent.
Reviewed By: mdvacca
Differential Revision: D39736109
fbshipit-source-id: ef76dc19a86eaf9b26f35c6a55781ece6e43eecc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34970
I'm setting up `gradle-nexus` on our build to simplify the closing and releasing of staging repositories.
As of now, you'll have to go to Sonatype UI and manually click the release button.
With this plugin, we can instruct CircleCI to do the publishing automatically for us as
part of the nightly/stable release process.
Changelog:
[Internal] [Changed] - Setup gradle-nexus to automate closing and releasing staging repositories
Reviewed By: cipolleschi
Differential Revision: D40342759
fbshipit-source-id: 72e80f4bcc80058d5a6ea562ae136a91b2aeedbb
Summary:
This extracts the core changes from https://github.com/facebook/yoga/pull/1116, to support gap/row-gap/column-gap, mostly identical, apart from the rename of gaps -> gutters.
The core functionality in this PR looks to be well tested from the fixtures added. I am not an expert in the internals of Yoga, but I am seeing everything that I would expect to. The space for the gap is accounted for in line-breaking, and the accumulated gaps limit the available line-length, before sizing flexible children, so items are sized correctly as to accommodate the gap. Then the gap is used for spacing during main axis and cross-axis justification.
Changelog:
[Genral][Added] - Implement gap/row-gap/column-gap (within the yoga C ABI)
Reviewed By: javache
Differential Revision: D39922410
fbshipit-source-id: 5850f22032169028bd8383b49dd240b335c11d3d
Summary:
`VirtualizedList_EXPERIMENTAL` is a fork of VirtualizedList. It was originally created for the purpose of keyboard/a11y fixes, which required the list to allow rendering discontiguous regions of cells. So, the large part of the refactor is in the data structure used to represent state (now a sparse bitmask), and building out the render function to operate off the bitmask.
This structure allows pre-rendering areas where we know focus must be able to be synchronously be moved to. This is exercised on platforms like Windows and macOS which fire view level focus events. The new implementation otherwise aims to preserve near-exact list behavior as previously.
Apart from the structure change, the refactor has made the code (subjectively) a lot easier to reason about, and there are now stronger internal invariants than before. The bitmask structure also enables new approaches for nested list stability, and implementing OffScreen.
**Why ship it now?**
Having two implementations has multiple times prevented other changes to VirtualizedList, so it is incurring a constant engineer cost.
At this point, we have a lot of reason to be confident in the maturity of the new list implementation (see the test plan below). So, reconciling the implementations not only unlocks the enhancements of the new list, but unblocks future changes to VirtualizedList.
## Test Plan
1. **Unit tests:** A few dozen unit tests were added to VirtualizedList, validating the regions it renders in response to injected input, across its API surface. Both VirtualizedList implementations must pass the same tests, around expected behavior.
2. **RNTester:** Scenarios in RNTester were manually validated, and all worked as before
3. **New invariants:** I added a lot of internal logic checks and bounds checks as invariant violations, to try to produce signal if any part of the refactor went unexpected in the wild.
4. **MSFT Rollout:** I rolled out the changes as a fork of VirtualizedList at MSFT to a couple of high-usage surfaces using Android, iOS, and Windows on Paper. Some invariant violations were surfaced and fixed, but telemetry showed solid system and scenario health with the change.
5. **Meta import:** Fixed all land-blocking test failures when using the new list. These were confined to updating snapshots, and adding additional checks for invalid input.
6. **Panel apps:** Manually validated top-level surfaces of panel apps in debug/release modes. Fixed a couple of invariant violations and novel usages. Profiled new JS structures against an expensive list with Hermes profiler.
7. **Facebook App Rollout:** After some manual validation of top-level surfaces, the change was rolled out to Facebook for Android and iOS as an experiment. New invariant violations were fixed, and the change has sat in production for several weeks at this point, while measuring impact to metrics like error rate, responsiveness, and impressions.
This is the first introduction to all of OSS, and some Meta internal apps. This means there may still be novel usages of VirtualizedList that were not picked up during testing, but I think there has been enough diligence to roll out what has been tested, and forward fix anything unexpected that might still come up.
Changelog:
[General][Changed] - Ship VirtualizedList_EXPERIMENTAL
Reviewed By: javache
Differential Revision: D40259791
fbshipit-source-id: 63eee9381d197a1e38ae663b2158436ff135c0e1
Summary:
Change version of rn apps following xcode settings.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS][Fixed] - Automatically following version on xcode.
Pull Request resolved: https://github.com/facebook/react-native/pull/34919
Reviewed By: cipolleschi
Differential Revision: D40340271
Pulled By: motiz88
fbshipit-source-id: a2263a8c7a70847fe6fcedcd82c5109100aafde6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34967
This diff is a preparatory work for publishing artifacts on Maven Central.
What it does is:
1. It sets up all the 3 modules (react-native, hermes-engine, external-artifacts) for publishg
2. Adds coordinates to publish on the Snapshot repository
3. Adds support for appendign -SNAPSHOT version if invoked with `-PisNightly=true`
4. Configures GPG signing of artifacts.
I haven't touched the CircleCI and JS code yet. I'll do it in another diff.
Changelog:
[General] [Changed] - Setup publishing for Snapshot and Stable on Maven
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40146212
fbshipit-source-id: 9321e16f6c18b35bc3ae785749d613085c56e7bc
Summary:
D31464478 enabled clang-format by default across projects, but opted out directories with a lot of formatting errors. This removes the opt-out, so clang-format is run in that directory as well.
Changelog:
[Internal][Changed] - Remove clang-format opt-out for Libraries
Reviewed By: lunaleaps
Differential Revision: D40310275
fbshipit-source-id: abe154ab466798fbfa010364a3627f40ca18b179
Summary:
Remove old `__offline_mirrors__` from `.gitignore`.
This directory is not synced to GitHub.
Changelog: [Internal]
Reviewed By: fbmal7
Differential Revision: D40245262
fbshipit-source-id: ccc93ea4cb5729432f590f78e463b14ba6e78b22
Summary:
Update RNTester Podfile.lock after running `pod install` with Hermes enabled, which is the default in open source.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40197412
fbshipit-source-id: ce57d204b704fda85cae7f2966e479e80db25e1b
Summary:
This adds the `destructuredArrayIgnorePattern` rule [recently introduced in `typescript-eslint`](https://github.com/typescript-eslint/typescript-eslint/issues/4691), making underscored identifiers in array destructurings no longer an error, e.g.
```js
const [state, _dispatch] = useContext(MyContext);
```
would be acceptable if `state` is used.
## Changelog
[General] [Added] - Add destructuredArrayIgnorePattern to eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/33552
Test Plan: Install the `react-native-community/eslint-config` package and test the example.
Reviewed By: lunaleaps, cipolleschi
Differential Revision: D40166101
Pulled By: ryancat
fbshipit-source-id: 1e30297bf40d65e09682c4f9f3b3dd432ba5310e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34886
## Reduced cache size
The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds.
This is the `build_hermes_macos` Restore Cache step, before the changes in this diff:
```
Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE=
Size: 5.2 GiB
Cached paths:
* /Users/distiller/react-native/sdks/hermes/build_host_hermesc
* /Users/distiller/react-native/sdks/hermes/build_iphoneos
* /Users/distiller/react-native/sdks/hermes/build_catalyst
* /Users/distiller/react-native/sdks/hermes/build_iphonesimulator
* /Users/distiller/react-native/sdks/hermes/build_macosx
* /Users/distiller/react-native/sdks/hermes/destroot
Downloading cache archive...
Unarchiving cache...
```
Size: 5.2 GiB
Time to restore cache: 183s
This is the `build_hermes_macos` Restore Cache step, after the changes in this diff:
```
Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk=
Size: 1.3 GiB
Cached paths:
* /Users/distiller/react-native/sdks/hermes/build_macosx
* /Users/distiller/react-native/sdks/hermes/destroot
Downloading cache archive...
Unarchiving cache...
```
Size: 1.3 GiB
Time to restore cache: 42s
**This is a size reduction of 75%, and execution time reduction of 77%.**
This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`.
## Added `export_hermesc`
As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available:
- If the cache contains hermesc, both the macOS and iOS builds will use it.
- If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously.
- The `export_hermesc` command will work regardless of the order of the Hermes build scripts
## Refactoring of magic strings into reusable yaml references
Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40153737
fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34944
In react-native-windows, the ability to detect a press event on a virtual span is dependent on setting a native only `isPressable` prop.
This modifies the Text component to include `onPressIn` and `onPressOut`. As a side-effect, this will also lazily initialize the pressability config when `onPressIn` or `onPressOut` only is set.
Changelog:
[General][Fixed] - Pressability for text with only `onPressIn` / `onPressOut` props
Reviewed By: yungsters
Differential Revision: D40264432
fbshipit-source-id: 583b210127d8f020ad98030d4a5381c302e88d2a
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34958
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D40302608
Pulled By: dmytrorykun
fbshipit-source-id: eebc98e0fccd61260fac6ff5ea9a83b0d81abfbf
Summary:
This moves configureDevPorts inside AgpConfiguratorUtils, and makes it use
finalizeDsl. This removes a deprecated API `BaseVariant` which is causing a
build warning for all the users + it's a step towards making RNGP fully variant aware.
Changelog:
[Internal] [Changed] - Move configureDevPorts inside AgpConfiguratorUtils and use finalizeDsl
Reviewed By: cipolleschi
Differential Revision: D40139558
fbshipit-source-id: 1e5b8661b8d223a603f8ab5d160edd2133304d92
Summary:
I'm suppressing this deprecation on `reactRoot` as it's unnecessary.
It creates noise and the usage is actually legit.
Changelog:
[Internal] [Changed] - Suppress deprecation on reactRoot passed as deprecatedReactRoot
Reviewed By: cipolleschi
Differential Revision: D40139555
fbshipit-source-id: f3755f020ab1dceb17d0fdd18c6c8e374c87c60c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34943
The RCTAppDelegate class is the new way we have to encapsulate logic we don't want to leak to the average user.
However, some advanced users, like Expo users, may need more options to customize their setup.
This Diff provides more methods to extend the AppDelegate.
## Changelog
[iOS][Added] - Add more extension points for RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D40262513
fbshipit-source-id: 9365a51d938a586b1508233bfa63693cf9aebf7a
Summary:
Changelog
[General][Internal] - Make react-native-codegen work on Windows within BUCK
This makes react-native code-gen work on Windows - by basically filling in some necessary windows commands for the existing bash/shell ones
Reviewed By: cortinico, cipolleschi
Differential Revision: D40268750
fbshipit-source-id: 0db7597999ec8108babf56abed436f6dc7789cce
Summary:
I'm cleaning up the Buck setup in the New App template. It hasn't been touched since 2018 and is currently not working, but will end up being propagated in user space.
This is also affecting the Gradle setup as there is a need to have an extra task just for Buck.
I doubt anyone is using this at this stage. We can get back to it or have a dedicated guide for users that are willing to use it.
## Changelog
[Android] [Remove] - Cleanup Buck usages from New App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34881
Test Plan: Testing was missing on this API so there is nothing to test here
Reviewed By: cipolleschi
Differential Revision: D40142064
Pulled By: cortinico
fbshipit-source-id: 6c65e1030bf3fe1603bfb7d486f8f3fd7d254126
Summary:
This PR extracts the content of the codegen case `'Stringish'` into a single `emitStringish` function inside the `parsers-primitives.js` file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitStringish` function.
## Changelog
[Internal] [Changed] - Extract the content of the case 'Stringish' into a single emitStringish function
Pull Request resolved: https://github.com/facebook/react-native/pull/34936
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: cipolleschi
Differential Revision: D40255921
Pulled By: rshest
fbshipit-source-id: 9c08f81f12c93995bb6ba032fabcd6451b8dc7c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34949
Changelog: [Internal]
Currently, link groups depend on supermodules to generate. To continue supporting link groups while allowing us to migrate off supermodules, we'll add a talkios_link_group label on all talkios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D40268275
fbshipit-source-id: a82e969e7cb8ec167489be73dc9bc71cf8ec37e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34884
Xcode 14 is now stable. Updating CI to use latest Xcode command line tools.
The Circle CI 14.0.1 container ships with Ruby 2.7.6 and CocoaPods 1.11.3, see full manifest here: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v8824/index.html
Changelog: [iOS][Changed] Bump to Ruby 2.7.6 and CocoaPods 1.11.3
Reviewed By: mdvacca
Differential Revision: D40148796
fbshipit-source-id: b1eab68e159ec3237ff2ef596163b73fc1e511e4
Summary: Currently, link groups depend on supermodules to generate. To continue supporting link groups while allowing us to migrate off supermodules, we'll add a talkios_link_group label on all talkios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D40268252
fbshipit-source-id: 9211add120448e95f892d36a85583c700b2ec9a0
Summary:
As identified in https://github.com/facebook/react-native/issues/34350, modals do not honor the system's status bar colors because they may not be set by the deprecated `systemUiVisibility` flags. Unless `android:windowLightStatusBar` is set to true, the default flag is a zero-integer (a.k.a. "dark mode", where the icons show as white). Since the `StatusBar` component is using the new `setSystemBarsAppearance` API, the ModalHost should also infer its status bar settings from the same API.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fixed an issue on Android API 31+ where modals would turn status bar icons white by default
Pull Request resolved: https://github.com/facebook/react-native/pull/34899
Test Plan:
- On a screen with the `StatusBar` bar style set to `dark-content`, the modal also uses white icons
- On a screen with the `StatusBar` bar style set to `light-content`, the modal also uses black icons
### Preview
Here, I change the `barStyle` from `light-content` to `dark-content` and demonstrate that the proper attributes are retained. The "Before" is a recording from `main` and the "After" is this branch. Notice how in "Before", the status bar is always turning the icons white when the modal opens.
|Before|After|
|-|-|
|||
## Other considerations
There's some argument towards removing this check entirely--the status bar appearance should be derived from the theming and/or the parent activity's settings, thereby removing the need to apply separate styling
Reviewed By: lunaleaps
Differential Revision: D40243122
Pulled By: lunaleaps
fbshipit-source-id: ffa56c7d6a1906f89658f95a12f6bf1cefd5be8e
Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
Summary: Changelog: [Internal] Adjust styling so test works on mobile screen and verified Android is passing
Reviewed By: mdvacca
Differential Revision: D40247320
fbshipit-source-id: c39bff510900393af7696e92e1f846999eb0ced3
Summary:
Add TurboModule code-gen support for macOS and Windows
Changelog
[General][Internal] - Add TurboModule code-gen support for macOS and Windows
Reviewed By: javache
Differential Revision: D40140890
fbshipit-source-id: 60d235f16af590c07abddba3d289efa7d1d973c0
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.4
Pull Request resolved: https://github.com/facebook/react-native/pull/34924
Test Plan: N/A
Reviewed By: rshest
Differential Revision: D40226689
Pulled By: rshest
fbshipit-source-id: 2c60533fb9ed40a7b40dc8385482d98cd77fd309
Summary:
This PR reduces code duplication by extracting all the errors in the module/errors into a single parsers/errors.js file. All the errors must drop the corresponding Flow or Typescript token in the name and take an extra language parameter in the constructor. Also, rename the hasteModuleName parameter to nativeModuleName.
Part of https://github.com/facebook/react-native/issues/34872
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract all the parsers errors in the module/errors into a single parsers/errors.js file
Pull Request resolved: https://github.com/facebook/react-native/pull/34896
Test Plan:
run ```yarn jest react-native-codegen``` and check all test case passes.
<img width="793" alt="image" src="https://user-images.githubusercontent.com/34857453/194545577-cf2d980b-b6b7-4f93-b13e-2e45d92dceab.png">
Reviewed By: rshest
Differential Revision: D40176486
Pulled By: rshest
fbshipit-source-id: b33ae49b2bcceeffd307370ee5e3b24a9e1bb340
Summary:
A moderate vulnerability was found in all versions of `ws` below 7.4.6 June last year. React native current uses v6.1.4 which is susceptible to it, fortunately this security fix has been backported to v6.X.X and we don't need to upgrade any major versions/worry about breaking changes. This PR bumps `ws` to 6.2.2 ([CHANGELOG](https://github.com/websockets/ws/releases/tag/6.2.2)) due to this ReDoS vulnerability
More information about this vulnerability can be found here -> https://github.com/advisories/GHSA-6fc8-4gx4-v693
Closes https://github.com/facebook/react-native/issues/31646
## Changelog
[Internal] [Security] - Bump ws to 6.2.2 due to ReDoS vulnerability
Pull Request resolved: https://github.com/facebook/react-native/pull/34759
Test Plan:
Ensure WebSocket tests are working as expected
Tested HMR working on Twilight
| iOS | Android |
| https://pxl.cl/2g70M | https://pxl.cl/2g70V |
Reviewed By: hramos, cortinico
Differential Revision: D39722905
fbshipit-source-id: 12088ab5ea26d904675de484e2014949d6696465
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34911
This diff adds the Same component with state added in the previous diff for iOS
## Changelog
[Android][Added] - ComponentWithState
Reviewed By: cortinico
Differential Revision: D40108233
fbshipit-source-id: b5bd1d1bdd7053920f737772c85034e4c5aed26a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34909
This Diff introduces a Sample component in RNTester which uses the NativeState to load some images.
It is an example on how to use CustomNativeState
In this first diff, I focused on the iOS side of things. The next diff will make this work with Android.
## Changelog
[iOS][Added] - Introduce sample component which work with the native state.
Reviewed By: cortinico
Differential Revision: D39884926
fbshipit-source-id: 9323d751fd06a1bb8ff93af836d97010c2095833
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34910
This Diff adds supports on the CustomState generation for ImageSource and ImageRequests, to enable NativeComponents to use the ImageSource loading provided by React Native.
To achieve this, I also had to fox some errors in the imports and to introduce some functions to decorate parameters.
This diff also introduces the tests for thise additional types in both generators and parsers.
## Changelog
[General][Added] - add support for ImageSource and ImageRequest in the State.
Reviewed By: cortinico
Differential Revision: D39884889
fbshipit-source-id: ae3d2d51dfe6a4fe688dc78fec83f428beb8d443
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34796
This diff introduces the generation of custom native states using basic types as we do with the Props.
To make it work, the custom types are already writte in the Props.h file, therefore the State.h file must import that other file to have access to the required types.
This diff adds and updates the tests for the State.
## Changelog
[General][Added] - Generate custom Native State
Reviewed By: cortinico
Differential Revision: D39816763
fbshipit-source-id: 42d1aa9a6df23145f4a46ae8ccfb43d81fa651fb
Summary:
ios debug archiving build will generate ip.txt that will leak metro server address for other people testing.
moreover, it will slow down launch time for metro server availability to wrong address.
this pr introduce `SKIP_BUNDLING_METRO_IP` to prevent ip.txt generation.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [iOS] [Changed] - introduce SKIP_BUNDLING_METRO_IP to skip ip.txt generation
Pull Request resolved: https://github.com/facebook/react-native/pull/31829
Test Plan:
### Classic build will generate ip.txt
```sh
xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester -configuration Debug -sdk iphoneos -destination 'generic/platform=iOS'
find $HOME/Library/Developer/Xcode/DerivedData/RNTesterPods-* -name 'ip.txt'
```
this will find the ip.txt
### Specify `SKIP_BUNDLING_METRO_IP=1` will not generate ip.txt
```sh
SKIP_BUNDLING_METRO_IP=1 xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester -configuration Debug -sdk iphoneos -destination 'generic/platform=iOS'
find $HOME/Library/Developer/Xcode/DerivedData/RNTesterPods-* -name 'ip.txt'
```
this will NOT find the ip.txt
Reviewed By: hramos
Differential Revision: D40095785
Pulled By: hramos
fbshipit-source-id: 0c913f078e683879e07e9ce3306e899d631206b2
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872
_Extract the modules/utils.js from the flow and typescript folders in a shared parsers-commons.js file. Then, have the two parsers use the same wrapModuleSchema function for modules._
(`wrapModuleSchema` is a copy-paste mistake, in this case it is `wrapNullable` and `unwrapNullable`)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extracts Codegen's modules/utils.js files from the flow and typescript folders in parsers-commons
Pull Request resolved: https://github.com/facebook/react-native/pull/34898
Test Plan:
I ran `yarn jest react-native-codegen`:
<img width="775" alt="Capture d’écran 2022-10-07 à 21 29 48" src="https://user-images.githubusercontent.com/17070498/194639515-a446c2cf-daf3-43a1-9833-cd546ca5865e.png">
Reviewed By: cipolleschi
Differential Revision: D40193740
Pulled By: cipolleschi
fbshipit-source-id: 02cbacc215fe5dd9bdd0839d8796587ab2821906
Summary:
[Changelog]: Internal
integrate the offscreen component when we render an application that is configured to do so
Reviewed By: rubennorte
Differential Revision: D39458472
fbshipit-source-id: 9bd492ca258723cb9cf0b7e4f6c9b0005554e91e
Summary:
Changelog: [RNTester][Internal] - Add "PointerMove Between" platform test
This diff adds another port of a web platform test which verifies the event order when a hoverable pointer moves between elements.
Reviewed By: lunaleaps
Differential Revision: D40164303
fbshipit-source-id: 12f39dfcf7a1a4acabfd762185bc2227451b1057
Summary:
Changelog: [iOS][Internal] - Get the "move across" pointer event test passing on iOS
After implementing the "MoveAcross" pointer event test it indicated that the implementation, at least on iOS, was firing the events in an incorrect order. Extrapolating from the test's expectations all the events related to entering/leaving/ect. should fire before the down/move/up instead of placing those down/move/up/ect. between the leave and enter events.
Reviewed By: lunaleaps
Differential Revision: D39221372
fbshipit-source-id: 31b7292e524a9ec9d998e658b7d0ef3ebc825d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34875
Create common script for generating a Hermes tarball after Hermes is built from source.
Use after building Hermes from source to create a tarball of the resulting build artifacts. The path to the tarball can be passed to CocoaPods via a `HERMES_ENGINE_TARBALL_PATH` envvar in order to use these pre-built Hermes artifacts when installing the `hermes-engine` pod with `pod install`.
Use in Circle CI when creating a Hermes tarball for caching and for use in stable React Native releases.
Usage:
```
pod install
# When Hermes is built from source via CocoaPods, the build artifacts will be located in the Pods directory for hermes-engine
node ./scripts/hermes/create-tarball.js \
--inputDir ./sdks/hermes \
--buildType Debug \
--releaseVersion 1000.0.0 \
--outputDir .
```
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40124378
fbshipit-source-id: f9712e87526ccc737afac4599b0ab0a7bb3f3956
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34885
We use workflows extensively in Circle CI, so caching a git checkout should help speed up tests when downstream jobs need to checkout the repository. In the current configuration, the Windows job is most likely to run and write to the .git cache first, which results in permission issues when the .git cache is loaded onto macOS or linux hosts.
By splitting the cache by architecture, we may lose on some reusability across jobs with distinct architectures, but it ensures we avoid cross-platform permission issues.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40150781
fbshipit-source-id: 4a4b2a4da5e20f754b72db0c9852c7c1616b610c
Summary:
A few fixings to make `yarn jest react-native-doegen` works on Windows:
- ~~Add a `.gitignore` file to tell git not to track generated/temporary files.~~
- There is no `rm` on Windows, change it to `rimraf`.
I have been using it in the last 3 months and it works perfectly on Windows, otherwise I could not even build the code in my laptop.
## Changelog
[General] [Changed] - Make `yarn` and `yarn jest react-native-codegen` works on Windows with git
Pull Request resolved: https://github.com/facebook/react-native/pull/34854
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D40059524
Pulled By: cortinico
fbshipit-source-id: e3cde2506c7d18c2b580099257637b90f4cb328c
Summary:
On some platforms, when two inputs are in a scrollview, trying to switch focus to another textinput doesn't work and requires two taps. This is because from `_handleTouchEnd` we blur the currently focused input, even if that input had only just become focused from the same touch event. Instead, only blur when the event did not target the current textinput.
Changelog: [Android][Fixed] TextInputs may not get focused when switching inputs in a ScrollView
Reviewed By: jehartzog
Differential Revision: D40159333
fbshipit-source-id: 388f85dff5ac8f24d7e2590e887635391c52d72f
Summary:
Replaced import cycle with Flow type cycle, which will remove the warnings from Metro.
Changelog: [internal]
Reviewed By: motiz88
Differential Revision: D40177136
fbshipit-source-id: e63986d8918e48e8c4cd8014d306d68fcbd2cf10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34897
This [commit](https://github.com/facebook/react-native/commit/7680bdeb4f96a8092393372a59c77a9d7b729cae) added the possibility to create Codegen specs that are platform specific.
However, it also modifies how the codegen is invoked and we need to publish a new version of the `react-native-codegen` package on NPM before we can use that feature.
## Changelog:
[General][Fixed] - Remove usage of the codegen spec filtering until we publish a new version of the codegen.
Reviewed By: robhogan
Differential Revision: D40176447
fbshipit-source-id: 20be630dec3dcd7efb9fd510c6cf9f2c161f906a
Summary:
Noticed that we were using a different tag for each pointer event observed (and that weren't clearing these properly when recyling views).
Each of these tags is a hashmap entry and a boxed boolean, so we can do much better by just using a single (boxed) integer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D40077519
fbshipit-source-id: 130e78c3641eaedfa8787644b98763fd4367bc27
Summary:
This diff helps the library maintainer to keep their spec file platform specific if some specs make no sense in one platform or in the other.
We are filtering the spec files when we need to create the Schema.
The diff modifies also the call sites in the `scripts` (for iOS) and in the `gradle-plugin` (for Android).
It also adds tests for the new functions in the CLI.
The change is completely additive and it should not change any pre-existing behaviour.
## Changelog
[General][Added] - Add support for platform-specific specs
Reviewed By: cortinico
Differential Revision: D40008581
fbshipit-source-id: b7fcf6d38f85fe10e4e00002d3c6f2910abdbe35
Summary:
`TSParenthesizedType`, `TSUnionType`, `TSNullKeyword`, `TSUndefinedKeyword`, `TSVoidKeyword` etc are repeatly processed in so many places. In this change I put them in a new file `parseTopLevelType.js`, and everyone call that file, all repeat implementation are deleted.
The `parseTopLevelType` function will look into a type consisted by the above types in any possible combination (but still very easy to do), and tell you if a type is nullable, or if there is a default value, and what is the real type with all noises removed.
Array types and union types are processed in component twice, for property of array, and property of nested arrays (`componentsUtils.js`). They are extracted into single functions.
## Changelog
[General] [Changed] - Refactor in turbo module TypeScript codegen: process `(T)`, `T|U`, `T|undefined` and related stuff in a central place
Pull Request resolved: https://github.com/facebook/react-native/pull/34814
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: yungsters, sammy-SC
Differential Revision: D40094373
fbshipit-source-id: f28e145bc4e7734be9036815ea425d820eadb8f0
Summary:
This change will expose the rrc_image module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose rrc_image to consuming build
Reviewed By: cipolleschi
Differential Revision: D40098541
fbshipit-source-id: 2e07d8b19f53ba93920009603c95a43b01f131eb
Summary:
This change will expose the `react_render_imagemanager` module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose react_render_imagemanager to consuming build
Reviewed By: cipolleschi
Differential Revision: D40022929
fbshipit-source-id: ece47503b11a641067ae6db82f1d69b244c9c5be
Summary:
react-native-windows builds treat a lot of c++ compiler warnings as errors. Including ones that cause value truncation when assigning `size_t` values to an `int`.
This fixes the compiler warning, by using `size_t` as the type for `i`, which matches `size`. I then modified the loop to avoid the value underflow that occurs when decrementing an unsigned zero value.
## Changelog
[Internal] [Changed] - Fix compiler warnings around mixing int and size_t usage in unsafe ways
Pull Request resolved: https://github.com/facebook/react-native/pull/34889
Test Plan: This code change was made in react-native-windows when integrating latest react-native changes. -- our fabric implementation was able to run through this code without any issues.
Reviewed By: mdvacca
Differential Revision: D40158306
Pulled By: rozele
fbshipit-source-id: b6858cb953635b37fd63a88ed1a372eb3dc394f7
Summary:
Create documentation to write C++ ViewManagers in React AR apps
changelog: [internal] internal
Differential Revision: D40119174
fbshipit-source-id: edce0e6b226a30007c39f924b5896fa2267e98b7
Summary:
This diff further simplifies the New App Template by removing the
buildConfigFields for both Hermes and New Architecture with the React Native Gradle Plugin.
Changelog:
[Android] [Changed] - Let RNGP set buildConfigFields for New Architecture and Hermes
Reviewed By: cipolleschi
Differential Revision: D40139559
fbshipit-source-id: 202b6ac9c4c036a026a2ff3e8279087ffd363eaa
Summary:
I fixed the TypeScript definitions for Systrace in https://github.com/facebook/react-native/commit/a0f56adb07dd21ee69ad1942e9d485586f1c3ec0, but I forgot to update the TypeScript tests that were outdated. This diff fixes those tests and CI in OSS.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40141920
fbshipit-source-id: f73501450af0be6b0b6f836b9a774abb1fa4f620
Summary:
This change encapsulates all the NDK configuration logic inside the React Native
Gradle Plugin. The changes are additive so that the user can still specify a
custom configuration if they wish.
So far I've applied the changes to RN Tester. Changes to the template require a
bump of the Gradle Plugin NPM package.
Changelog:
[Android] [Changed] - Hide the C++/Cmake configuration from user space inside the framework
Reviewed By: cipolleschi
Differential Revision: D40139557
fbshipit-source-id: 013220695791e3d0d458e118de16953e0545c3de
Summary:
We're currently using `global.__RCTProfileIsProfiling` to determine if the app is currently profiling to forward calls to Systrace to native.
We're defining `global.__RCTProfileIsProfiling` when the React Native runtime is initialized (which, in most cases, is on startup or shortly after startup), which means that enabling profiling in the middle of the session doesn't set this value to `true`.
This diff adds a new method (in the global scope for now, as the rest of bindings for Systrace) to check if we're profiling in real time. This call should be very cheap as it's implemented as a JSI function that calls into a C++ API directly.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095840
fbshipit-source-id: e7030d6370ecb43d56478b03cb63806ffa0cd0cf
Summary:
It doesn't make sense to have checks for whether we're profiling or not in `__DEV__` blocks, where we shouldn't be profiling in the first case.
We're going to remove the `global.__RCTProfileIsProfiling` flag in favor of a function that checks if we're profiling in real time (as opposed to checking if we're profiling only on startup, which is what that value does). This is just to make that migration easier without having to migrate callsites that are bad practices anyway.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095841
fbshipit-source-id: ba6cdf4bef8a4c169c50a974671c21144ccee92b
Summary:
This refactors the systrace module to:
1) Migrate it to ESM
2) Fix the typing of certain parameters (e.g.: `eventName` and `cookie` shouldn't be optional)
2) Fix TypeScript definitions
3) Add inline documentation for methods
4) Add args (metadata) to all methods where it's supported in fbsystrace (`endEvent` and `endAsyncEvent`).
5) Make `setEnabled` a no-op. The only place where this method is called is from native, when starting a profile session. The problem is that implementation for Systrace in OSS (https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/systrace/Systrace.java#L40-L42) doesn't support listeners, so this wouldn't work correctly there. It also doesn't get called with Venice, so instead of fixing it for Venice with the same Meta-internal behavior, I decided to fix it for everyone with the synchronous method.
I'm not considering this a change in the public API of systrace because this module has been broken in OSS for ages and I'm assuming no one's using it at this point.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095842
fbshipit-source-id: fee41b2b7ae23aefe059e390c55d139db75247c5
Summary:
This moves the prefab/pickFirst configuration from the user's
build.gradle to the React Native Gradle Plugin.
As this configuration is entirely under our control, is safe
to assume users won't need to tweak it (e.g. we control which
libraries are built, etc.).
Changelog:
[Android] [Changed] - Encapsulate the prefab configuration for consumers
Reviewed By: cipolleschi
Differential Revision: D40094691
fbshipit-source-id: d1510a0a382d26e94e3d01f30661af39f7bedf52
Summary:
I'm adding a series of excludes to the `GenerateCodegenSchemaTaskTest`.
The reason is that RN Tester is setting `packages/rn-tester` as the root of the
specs as they're not isolated.
This is causing the Gradle task to crawl inside the `android/app/build` folder
where we store sourcemaps and other files that have .js files. As those files
gets updated when you build, the codegen task gets invalidated over and over
and Gradle is firing warning about it.
Changelog:
[Internal] [Changed] - Exclude generated folders from the GenerateCodegenSchemaTask
Reviewed By: cipolleschi
Differential Revision: D40098418
fbshipit-source-id: fcffbc73e8258c4e9eefda062e1fad77be650002
Summary:
changelog: [internal]
RuntimeScheduler's callbacks previously did not pass down argument `didUserCallbackTimeout`. This was intentionally left out because React team intended to remove it. But, as it turns out, it was not removed and it is needed for Offscreen to not enter infinite render loop. In React, it is used here: https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L1022-L1028
Reviewed By: ryancat
Differential Revision: D40060377
fbshipit-source-id: c45719fbbd0275ab2bcf9a2bbf0191aaa96010cc
Summary:
Fixes Xcode release builds when Hermes is enabled.
The Hermes debugger is loaded by the Hermes executor only if HERMES_ENABLE_DEBUGGER is defined. The hermes-engine Pod would set `HERMES_ENABLE_DEBUGGER=0` in release builds, but of course this would satisfy the HERMES_ENABLE_DEBUGGER ifdef check, leading to build time issues due to missing `hermes::debugger` symbols.
Now, both the `hermes-engine` and `React-hermes` pods only set `HERMES_ENABLE_DEBUGGER=1` in debug builds. No gcc preprocessor definition is added by these pods in release builds.
Changelog:
[iOS] [Changed] - Do not load Hermes inspector in release builds
Reviewed By: cipolleschi
Differential Revision: D40077503
fbshipit-source-id: dd9ce148e8521fc4e43e47e90f29ba8f7c9b7e4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
Automation tests were hitting issues with view recycling enabled because we use the main tag field to lookup views, and not properly resetting it when recycling.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D40076594
fbshipit-source-id: 5f518b979a23562f7e7fc8271488678e78f50e91
Summary:
This PR renames ` hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`, moves it to `packages/hermes-inspector-msggen` and makes the package private as part of RFC480.
Related to https://github.com/facebook/react-native/issues/34692
## Changelog
[General] [Changed] - Move and rename `hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`
Pull Request resolved: https://github.com/facebook/react-native/pull/34850
Test Plan: run `sh ReactCommon/hermes/inspector/tools/run_msggen`
Reviewed By: mattbfb
Differential Revision: D40060406
Pulled By: cortinico
fbshipit-source-id: e018fd88e8374a69fbd8737fbb9abe7565d4a003
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.2
Pull Request resolved: https://github.com/facebook/react-native/pull/34859
Test Plan: N/A
Reviewed By: NickGerleman
Differential Revision: D40056094
Pulled By: NickGerleman
fbshipit-source-id: 1e833b63080351c66dafc4e43f3681220a9738eb
Summary:
Add explicit annotations to useCallback as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Codemod command: `flow codemod annotate-use-callback`
drop-conflicts
bypass-lint
Changelog: [Internal]
Reviewed By: evanyeung
Differential Revision: D40079418
fbshipit-source-id: 59750a5d07b2ac1f440927794a7523682f048a5e
Summary:
Added a new job to testing RNTester app on both architectures
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Added] - Support both architectures to test RNTester iOS app
Pull Request resolved: https://github.com/facebook/react-native/pull/34864
Test Plan: CircleCI jobs
Reviewed By: cortinico, cipolleschi
Differential Revision: D40062371
fbshipit-source-id: 1a28890edc57b64232d647d85694b34d50a9cd64
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`.
Here's the current shape of the options:
```sh
Options:
--help Show help [boolean]
--version Show version number [boolean]
-t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"]
-p, --platform [choices: "iOS", "Android"] [default: "iOS"]
-h, --hermes [boolean] [default: true]
```
The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open.
Some of the key changes:
* tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation
* no need to start the android emulator on the side
* no need to start Metro on the side
* RNTester iOS will open up on the simulator (no Xcode open that then you need to press)
Things that still need work:
* see the #fixme and #todo in comments
* because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Migrate bash E2E local testing script to new JS based command
Pull Request resolved: https://github.com/facebook/react-native/pull/34513
Test Plan:
To test the script, you can run it passing the options showed above; this is the current situation:
* RNTester iOS Hermes ✅
* RNTester Android Hermes ✅
* RNTester iOS JSC ✅
* RNTester Android JSC ✅
* RNTestProject Android Hermes ✅
* RNTestProject iOS Hermes ✅
* RNTestProject Android JSC ✅
* RNTestProject iOS JSC ✅
Reviewed By: cortinico
Differential Revision: D39814692
Pulled By: cortinico
fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34858
Changelog:
[iOS][Fixed] - Fix race condition in RCTLoggingTests integration tests
RCTLoggingTests work in the following way:
* Put a custom hook on logging (logging function) to intercept log messages
* Send several log messages via JS and see whether they hit the hook as expected
The problem with this approach was that there may be unexpected log messages, which squeeze inbetween the points of time when the hook was set and when the first message was sent.
There was a (now 6 years old!!!) fix to mitigate this problem, which was adding a lead pause of 2s to "make sure" that all the other possible log messages had been sent: https://github.com/facebook/react-native/pull/10568
That didn't actually guarantee fixing the problem in general, just partially mitigating it, as the race condition conceptually still remained there.
Here I take a different approach, which should guarantee that we skip all the rogue JS messages before we start sending and reading them on our own:
* Install the hook
* Log a "marker" message
* Pump the log until the marker appears - at this point we know that the hook has been definitely installed
Reviewed By: cipolleschi
Differential Revision: D40043442
fbshipit-source-id: b4aa617d27c2dcff26682dd72e47ec19cb0d11ca
Summary:
I'm handling this TODO i left to unbreak the CI.
We need to make sure all the autolinked libraries are getting the folly flags and other common flags propagated correctly.
## Changelog
[Internal] [Change] - Propagate common flag to autolinked libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/34853
Test Plan: Will rely on a green CI
Reviewed By: cipolleschi
Differential Revision: D40055134
Pulled By: cortinico
fbshipit-source-id: fb9afab954ab402f6a3ab417aba934035580f936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34843
We can now remove a lot of unnecessary code to copy .so
files around as they're consumed via prefab from :ReactAndroid
Changelog:
[Android] [Changed] - Cleanup the Android template after prefab support
Reviewed By: cipolleschi
Differential Revision: D40014642
fbshipit-source-id: 00e69ea62bdb4882b40b8b6f19cdf80235c847b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34831
Historically we had to download an unzip the fbjni Android Archive to use it.
Here I'm updating the way how we consume to use prefab so we can remove a lot
of unnecessary configuration, also from the app template.
Changelog:
[Internal] [Changed] - Consume fbjni via Prefab
Reviewed By: cipolleschi
Differential Revision: D39964574
fbshipit-source-id: 1b18682c2b36aabb1fc1a3819ca09e575182eae4
Summary:
When building and using C # libraries,
EntryPointNotFoundException thrown from YGInteropSetLogger.
so, I added YOGA_EXPORT on YGInteropSetLogger.
X-link: https://github.com/facebook/yoga/pull/960
Reviewed By: yungsters
Differential Revision: D40027238
Pulled By: yungsters
fbshipit-source-id: 6af584a16e66a31c91374a1bb64434888762e3c8
Summary:
When I use libyogacore.so in other programming languages, it crash with message as
> Could not obtain symbol from the library: dlsym(0x20b84d220, YGConfigIsExperimentalFeatureEnabled): symbol not found
This function is defined as `WIN_EXPORT bool YGConfigIsExperimentalFeatureEnabled` in yoga.h, but is not defined using `YOGA_EXPORT` in yoga.cpp.
X-link: https://github.com/facebook/yoga/pull/1127
Reviewed By: yungsters
Differential Revision: D40024450
Pulled By: yungsters
fbshipit-source-id: f6f01eadccb13d593c68300059e96f4b0bbc9fb6
Summary:
Currently the `Content-type` is not defined and defaults to `text/plain`. This makes it more accurate.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[internal] [Changed] - add `headers.Content-type` to `openFileInEditor` call
Pull Request resolved: https://github.com/facebook/react-native/pull/33517
Test Plan: - [x] in development trigger `openFileInEditor`, e.g. by pressing on a line in a stack trace -> code editor opens
Reviewed By: cipolleschi
Differential Revision: D40022413
Pulled By: cortinico
fbshipit-source-id: 00ad3cdcdd1f82436c04aed3643c9f0b55778592
Summary:
Currently, it is not clear how to run codegen tests in the OSS.
## Changelog
[General][Added] - Add instructions about how to add tests in the OSS
Reviewed By: cortinico
Differential Revision: D40020907
fbshipit-source-id: 073ec8bf08d2a9e8b26287763dd881371ecf561d
Summary:
There are two issues from nightly builds.
#### 1. `VERSION_NAME=1000.0.0-main` in _ReactAndroid/gradle.properties_
the solution is to remove unused _ReactAndroid/gradle.properties_ git revert when publishing package.
#### 2. `pod install` error from downloading hermes, e.g. the url is unavailable. `https://github.com/facebook/react-native/releases/download/v0.0.0-20221002-2027-2319f75c8/hermes-runtime-darwin-debug-v0.0.0-20221002-2027-2319f75c8.tar.gz`
fix _hermes-engine.podspec_ to support nightly build and build hermes from main branch.
## Changelog
[General] [Fixed] - Fix nightly build issues
Pull Request resolved: https://github.com/facebook/react-native/pull/34846
Test Plan:
1. i cannot fully test publish-npm.js workflow and it stops at `npm publish`. i can just check at this moment, the _ReactAndroid/gradle.properties_ is right.
2. create a `npx react-native init` project and `yarn add react-native@nightly`. patch `node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec` and try `pod install`
Reviewed By: cipolleschi
Differential Revision: D40021649
Pulled By: cortinico
fbshipit-source-id: c9e2701e524f4b16eab6f2c72b5cfa34883082c3
Summary:
Currently the autorebase feature doesn't work because it fails the `if` validation due to how we distribute permissions.
For now I'm making this action less restricted. We can tweak it if we notice abuse.
Config now is the same as https://github.com/cirrus-actions/rebase
## Changelog
[Internal] - Make autorebase less restrictive
Pull Request resolved: https://github.com/facebook/react-native/pull/34848
Test Plan: Nothing to test
Reviewed By: cipolleschi
Differential Revision: D40022304
Pulled By: cortinico
fbshipit-source-id: 74270b47c61267484c073706fa900f22b3569a94
Summary:
Sync the changes in `types/react-native` https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62394 to here as required by lunaleaps
## Changelog
[Internal] [Added] - Sync new changes in `types/react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/34794
Test Plan: Tested in `types/__typetests__/index.tsx`
Reviewed By: cortinico
Differential Revision: D39846101
Pulled By: cortinico
fbshipit-source-id: cebe62aa97f764d9a10c8371936870c515fb9be3
Summary:
This adds support for the `verticalAlign` style attribute, mapping the already existing `textAlignVertical` attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add support for verticalAlign style
Pull Request resolved: https://github.com/facebook/react-native/pull/34567
Test Plan:
1. On Android open the RNTester app and navigate to the Text page
2. Check the text alignment through the `Text alignment` section
https://user-images.githubusercontent.com/11707729/188051914-bf15f7eb-e53f-4de5-8033-d1b572352935.mov
Reviewed By: jacdebug
Differential Revision: D39771237
Pulled By: cipolleschi
fbshipit-source-id: d2a81bec1edd8d49a0fcd36a42fea53734909739
Summary:
A follow up to D38708718 (https://github.com/facebook/react-native/commit/403fea25f65a38f4b4d8e0edcf89741b29e62059) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
CMake on Windows uses "Visual Studio **" generators are [multi-configuration](https://cgold.readthedocs.io/en/latest/glossary/multi-config.html),
which requires the hermes cli and hermes runtime build flavors to be compatible. Using the "MakeFile" generator will avoid the requirement and keeps the gradle script simpler. Please note that the "Makefile" generator is the default when only "Visual Studio Community edition" with default packages is available.
Use NMake generator for Hermes build on Windows
## Changelog
CMake on Windows uses "Visual Studio **" generators are [multi-configuration](https://cgold.readthedocs.io/en/latest/glossary/multi-config.html),
which requires the hermes cli and hermes runtime build flavors to be compatible. Using the "MakeFile" generator will avoid the requirement and keeps the gradle script simpler. Please note that the "Makefile" generator is the default when only "Visual Studio Community edition" with default packages is available.
[Android] [Fixed] - Use NMake generator for Hermes build on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/34790
Test Plan: Verified that RN build on Windows with multiple SKUs of Visual studio.d
Reviewed By: cortinico
Differential Revision: D39889332
Pulled By: cortinico
fbshipit-source-id: f2d39d981e7c58c8cb93a4322155c844cb6bded3
Summary:
Ensuring the file paths uses forward slashes as separator to avoid the characters from being interpreted as ASCII escape characters.
## Changelog
Fixing build failure building RN codegen CLI on Windows. Ensuring the file paths uses forward slashes as separator to avoid the characters from being interpreted as ASCII escape characters.
[Android] [Fixed] - Fixing failure building RN codegen CLI on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/34791
Test Plan: Ensured RN main branch builds on Windows with new architecture turned on.
Reviewed By: cipolleschi
Differential Revision: D39889468
Pulled By: cipolleschi
fbshipit-source-id: 7d79eac9f433908cc86dd7ca2eec841739ef6365
Summary:
`react.gradle`'s `detectCliPath` was not working correctly for the `cliJsFromNode` check, this fixes it.
## Changelog
[Android] [Fixed] - Fix react.gradle's detectCliPath's for finding the path from Node
Pull Request resolved: https://github.com/facebook/react-native/pull/34808
Test Plan:
Tested manually from a monorepo setup, this incorrect check was preventing the CLI from being found correctly:
```
❯ pwd
/Users/liam.jones/code/monorepo/packages/apps/app1/android
❯ node --print "require.resolve('react-native/cli').bin" # old code
undefined
❯ node --print "require.resolve('react-native/cli')" # new code
/Users/liam.jones/code/monorepo/node_modules/react-native/cli.js
Reviewed By: cortinico
Differential Revision: D39883661
Pulled By: cortinico
fbshipit-source-id: 2120df3443e38631e0fbd9b844aa93a87449186f
Summary:
When using flow syntax like this, the parser would throw an error.
```
const foo = new ClassInstance();
export type {foo};
```
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D39850098
fbshipit-source-id: 28a7748892559c2c4a0fb8afa8612cbeb5568058
Summary:
Works around a crash identified by Sapienz in D39852058 (https://github.com/facebook/react-native/commit/30411ae1a42e46d0e5a2da494a39ed2767ba8808)
These logs will still be logged to the console, as they were before
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39968830
fbshipit-source-id: 5d7a5d935e85a7d67e7780d95b2253e50888ad90
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
Creates a new `valid-flow-typed-signature` ESLint rule that validates the `flow-typed` signatures at the top of each file.
This lint rule will discourage contributors from locally forking the `flow-typed` definitions. Instead, any changes should be submitted as patches to the upstream definition in: https://github.com/flow-typed/flow-typed
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D39868721
fbshipit-source-id: e5e3ffe7568dbe52c9b598b53110b0fcbcad3e38
Summary:
Introduces a portable bundle that implements the `sort-imports` ESLint rule that we use internally at Meta, to the React Native repository.
As a consequence of the rapid changes that occur to this rule internally (and the desire to minimize red tape for Meta engineers), the portable bundle is built with Rollup with a lot of context omitted.
Changelog:
[Internal]
Reviewed By: skinsshark
Differential Revision: D39907799
fbshipit-source-id: 58fb6dc08030f20ac02c0e3fd1b175e22e4d74c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34829
I realized there is a race condition in how prefab headers are prepared and bundled. If the download of boost is not 'fast enough' the headers will be missing during prefab preparation.
This fixes it.
Changelog:
[Internal] [Changed] - Fix broken template tests due to missing boost headers
Reviewed By: cipolleschi
Differential Revision: D39968622
fbshipit-source-id: 4680f84c15f4443a16def45d41a10a1083f4f196
Summary:
This PR bumps the dep version of Metro and the RN CLI to latest, and realigns them to avoid the issue we currently have in 0.70: https://github.com/facebook/react-native/issues/34714 (this commit will be cherry-picked there)
Also, it pins it all down to precise version. See comments for reasoning.
While at it, I gave a cleanup pass to the yarn.lock with [`yarn deduplicate`](https://github.com/scinos/yarn-deduplicate#readme).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to 9.1.3 and Metro to 0.72.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34803
Test Plan: CI is green
Reviewed By: dmytrorykun
Differential Revision: D39967392
Pulled By: dmytrorykun
fbshipit-source-id: 799dd745834c9ba349362f70afb4bdbd1a48260e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34800
The TypeScript parser was not handling negative default values properly. The reason why is because the AST for those values is structurally different and wraps them in a `UnaryExpression` with the `-` operator.
This Diff adds the support for those default values and it also add some tests in both Flow and TS.
## Changelog
[General][Fixed] - Properly parse negative values
Reviewed By: cortinico
Differential Revision: D39847784
fbshipit-source-id: 95fc5768987477c540a54a7c4e4ff785d7a1e5d7
Summary:
I accidentally broke `main` as I added a PRIVATE link for external libraries.
I need to get back to this, but for the meantime I'm disabling this linking
to make the CI green.
Changelog:
[Internal] [Fixed] - Unblock template jobs on main due to accidental PRIVATE linking
Reviewed By: cipolleschi
Differential Revision: D39932205
fbshipit-source-id: 5acbf567e0c194224a01141273665a293ead8e32
Summary:
This adds the YGGutter enum, used to choose between row/column gap variants (row-gap, column-gap, gap).
This used later in changes from https://github.com/facebook/yoga/pull/1116, in the APIs which deal with setting gap on style on yoga node.
Note the original PR called this `YGGap`, but this ending up leading to a couple public method signatures that could appear ambiguous:
1. `SetGap(YGGap gap, float gapLength)`: Enums like `YGAlign` are the vaues for an `align` prop. `YGGap` controls the variant of the gap (like `YGEdge` does for left/right/top/bottom variants). So the enum reads as if it is the `gapValue`, and it looks like we have two of the same parameter.
2. `SetGap(YGGap gapDirection, float gap)`: This is misleading, because the direction gaps flow is the cross-axis of flex-direction.
3. `GetGap(YGGap gap)`: `gap` is the variant, but looks like an out param.
The [CSS Box Alignment](https://www.w3.org/TR/css-align-3/#column-row-gap) spec refers to these gaps as "Gutters", which removes the ambiguity.
Changelog:
[General][Added] - Add YGGutter Enum
Reviewed By: yungsters
Differential Revision: D39922412
fbshipit-source-id: 4b0baf800fecb3d03560a4267c7fb4c4330fd39e
Summary:
https://github.com/facebook/yoga/pull/1116 adds a new enum. The enum generator is out of date with copyright header, and some codemods, but it also looks like there were manual changes, types added, etc since generation. I fixed up the script to incorporate generating the changes folks made manually, and also added an enum that was previously only added manually to the C ABI.
Changelog:
[General][Fixed] - Fixup Yoga Enum Generator
Reviewed By: yungsters
Differential Revision: D39922252
fbshipit-source-id: b678fa9a43a896873d8c434745bdaf3f16fd991f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34819
This is crashing on A12 because of using the regular Context instead of the application context. That said, this probably makes more sense as a log warning.
Reviewed By: javache
Differential Revision: D39852058
fbshipit-source-id: 1ac93f8cc9ecdb14f60baca175c8ecff2ff42ac0
Summary:
Deletes `eslint-config-react-native-community/yarn.lock` because the package source directory is part of the `react-native` Yarn workspace (and therefore does not need its own `yarn.lock`).
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D39934080
fbshipit-source-id: dc00b3934965285208fc2fb066ec8b64e8111e9e
Summary:
This removes the old way of consuming `libreact_nativemodule_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
This is the last mode that we'll have to handle the prefab for.
I'll do the cleanup just after this change landed.
Changelog:
[Internal] [Changed] - Move `react_nativemodule_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39929261
fbshipit-source-id: 61669da2cfd0545160a2a4c596c8e4adb22303ec
Summary:
This removes the old way of consuming `libfolly_runtime.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Moreover, I've exposed a `folly-flags.cmake` file which can be used by libraries
to know which lists of flags they need to use for Folly.
Changelog:
[Internal] [Changed] - Move `folly_runtime` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39928571
fbshipit-source-id: 4864c37813ec681a6a464c97de6dfc078f5553f1
Summary:
This removes the old way of consuming `libyoga.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `yoga` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927496
fbshipit-source-id: f7ab2a3aab3cb42effa648dfeff6711d183260e4
Summary:
This removes the old way of consuming `libreact_renderer_mapbuffer.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_renderer_mapbuffer` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927266
fbshipit-source-id: e82c2bda02c85a2a6747b92a3f20f2a5118bda65
Summary:
This removes the old way of consuming `libfabricjni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `fabricjni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927210
fbshipit-source-id: dbd8814a6cad38d09484561120df911ab24b5f8a
Summary:
This removes the old way of consuming `libglog.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `glog` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927147
fbshipit-source-id: 99f0241da1dece0efc8d928c3d25f30f3fa48a09
Summary:
This removes the old way of consuming `libjsi.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `jsi` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924434
fbshipit-source-id: cb92d3a4ed6cb87e75462082506f310feb7bec9f
Summary:
This removes the old way of consuming `librrc_view.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `rrc_view` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924231
fbshipit-source-id: 231809631f807ea2ea40d2581759f391adfba94d
Summary:
This removes the old way of consuming `libreact_render_graphics.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_graphics` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923620
fbshipit-source-id: 9edb6557b4d195e1703b1ae532ca14126930a43a
Summary:
This removes the old way of consuming `libreact_render_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923551
fbshipit-source-id: b800d4369f0de8edbc68b11d9efecf2cb5ea68c1
Summary:
This removes the old way of consuming `react_newarchdefaults.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_newarchdefaults` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39857115
fbshipit-source-id: 194a75b530b21e593b0390565a3b91155e07f17e
Summary:
This removes the old way of consuming `libreact_render_componentregistry.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_componentregistry` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39856487
fbshipit-source-id: 98006054481a5635ee3241e3281455cd934eca08
Summary:
This removes the old way of consuming `react_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39889945
fbshipit-source-id: e31f3c3027718a54c0a7228db00d145c1f3f7873
Summary:
Moves the `retry3` utility function into its own file so that it can be reused in other steps that are not related to Android.
Changelog:
[Internal]
Reviewed By: rickhanlonii, cipolleschi
Differential Revision: D39889996
fbshipit-source-id: bf79cc19ad6178af0a0d8117a81116e0c32f4333
Summary:
Found and removed duplicates of the word "the" in comments.
## Changelog
[Internal] [Removed] – Removed duplicates of the word "the" in comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/34807
Test Plan: Not applicable.
Reviewed By: yungsters, cipolleschi
Differential Revision: D39880587
fbshipit-source-id: b7277aa70604902929903c31ab69d4c532f2667a
Summary:
This removes the old way of consuming `react_codegen_rncore` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_codegen_rncore` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39855726
fbshipit-source-id: a8ee00ea31422a20832909b9d7e5a8123cf88c84
Summary:
This removes the old way of consuming `runtimeexecutor` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `runtimeexecutor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39852978
fbshipit-source-id: 87795118f1bcf496a3c50791f920d8b230932555
Summary:
This removes the old way of consuming `turbomodulejsijni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `turbomodulejsijni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39851647
fbshipit-source-id: 6201546ad47a53b366a54b022457fce7b744f064
Summary:
This lint rule (and the associated Jest test) fails because `path` on Windows outputs backslashes. This diff fixes the rule.
Changelog:
[Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D39887464
fbshipit-source-id: b75480ccf4dcc384e2f7b91d8dcaf3af5f341434
Summary:
Removes the `error-subclass-name` ESLint rule from `react-native/eslint-plugin`, and implements a new `require-extends-error` ESLint rule inside the React Native repository. This rule was only intended to be used for internal development of React Native.
This will change `react-native/eslint-plugin` to no longer provide the `error-subclass-name` rule.
NOTE: One behavior difference here is that I also implemented the desired behavior of checking classes that extend `Library.SomeError`.
Changelog:
[General][Removed] - `react-native/eslint-plugin` no longer provides the `error-subclass-name` rule.
Reviewed By: lunaleaps
Differential Revision: D39858882
fbshipit-source-id: 27b53216d77a15b3425bd9669dbc9d954c1c61da
Summary:
Moves the `no-haste-imports` ESLint rule into the React Native repository because it was only intended to be used for internal development of React Native.
This will change `react-native/eslint-plugin` to no longer provide the `no-haste-imports` rule.
Changelog:
[General][Removed] - `react-native/eslint-plugin` no longer provides the `no-haste-imports` rule.
Reviewed By: lunaleaps
Differential Revision: D39858883
fbshipit-source-id: b8d91ce5996b615341cf60c6f839afac1e26dac9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34802
This removes the old way of consuming `libreact_render_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39849622
fbshipit-source-id: 45451dfe92ecce94d1b466094baae05a75ed803f
Summary:
Creates an ESLint rule that prohibits (and autofixes) imports from `react-native` or `react-native/path/to/file`, within the React Native repository.
The ESLint rule is configured using the `eslint-plugin-lint` package instead of `react-native/eslint-plugin` because the rule is only applicable to the React Native repository. The rule does not (and should not) be publicly facing, and changes to the rule should not require publishing new versions of `react-native/eslint-plugin`. (As a follow-up, the `no-haste-imports` rule should be migrated over from `react-native/eslint-plugin`.)
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D39831222
fbshipit-source-id: 566330e6df77fdff5ce755324b9f592b9365019e
Summary: We have decided not to go forward yet with using flexlayout in react-native. This change removes it for now.
Reviewed By: JTYim
Differential Revision: D39822037
fbshipit-source-id: 726e8657b62e6b4e55e5f72be3ca5539d317348e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34801
D39796598 (https://github.com/facebook/react-native/commit/8cdc9e7f04e2dd3026d15dcd5765952bfb2c5c08) broke this CircleCI job, causing failures for `dtslint` and `prettier`. This fixes both issues, by upating formatting, and removing types from `legacy-properties.d.ts` that we no longer export.
These were not flagged by sandcastle. It looks like this is because:
1. We run eslint, but not dtslint internally
2. Arcanist will ignore anything under a "vendor" directory, while we do not exlude anything from the prettier check in OSS.
I also updated the eslint config to lint any TypeScript that appears outside the types directory, since typings are now spread out.
Changelog:
[Internal][Fixed] - Fix `analyze_code` CircleCI Job
Reviewed By: cipolleschi
Differential Revision: D39848604
fbshipit-source-id: 844dfe26e4b618059542b29df163402079c39322
Summary:
Interface was supported in component, but it only allows interfaces in limited cases.
In this change, I extended interface support to all places where object literal type is supported.
I also refactor the code so that properties and events are able to share the same implementation.
In order not to mess up the diff, I noticed that implementations are repeated in processing array properties and non-array properties. But I leave it without refactoring. I will do it in future PRs.
I also commented potential problems I found in the code.
## Changelog
[General] [Changed] - Fix interface support in turbo module TypeScript codegen (component only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34778
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D39809230
Pulled By: cipolleschi
fbshipit-source-id: cfb51ce915249b5abceafee1c08b7e5762d03519
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.6
Pull Request resolved: https://github.com/facebook/react-native/pull/34798
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D39848387
Pulled By: dmytrorykun
fbshipit-source-id: a8448f5bb1d3c65337038b9ac270416d34d88cfc
Summary:
Release versions are currently broken on `main`. This happened once we bumped the AGP version to 7.3. It seems like that the path we used to use for assets has changed.
The app build successfully but it fails to start as it can't load the bundle.
This is also causing the hermes e2e test to fail: https://github.com/facebook/hermes/pull/821
## Changelog
[Android] [Fixed] - Fix crash on release versions after AGP 7.3 bump
Pull Request resolved: https://github.com/facebook/react-native/pull/34797
Test Plan:
Tested this locally and it works fine with RN Tester (can run a release version of it).
Plus, inspecting the zip:
### Before
```
$ unzip -l packages/rn-tester/android/app/build/outputs/apk/hermes/release/app-hermes-arm64-v8a-release.apk | grep android.bundle
1248608 01-01-1981 01:01 assets/mergeHermesReleaseAssets/RNTesterApp.android.bundle
```
### After
```
$ unzip -l packages/rn-tester/android/app/build/outputs/apk/hermes/release/app-hermes-arm64-v8a-release.apk | grep android.bundle
1248608 01-01-1981 01:01 assets/RNTesterApp.android.bundle
```
Reviewed By: cipolleschi
Differential Revision: D39847369
Pulled By: cortinico
fbshipit-source-id: 0e21c0b6e58b49ac097c59223649b74b2879b5e5
Summary:
This adds the `alt` prop to the `Image` component as requested on https://github.com/facebook/react-native/issues/34424. Using this new `alt` prop enables the `accessibility` prop and passes down the alt text to `accessibilityLabel`. This PR also updates RNTester ImageExample in order to facilitate the manual QA.
#### Open questions
- ~~On web `alt` text is displayed on the page if the image can't be loaded for some reason, should we implement this same behavior if the `Image` component fails to load `source`?~~ Not for now
## Changelog
[General] [Added] - Add alt prop to Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/34550
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. Test the `alt` prop through the `Accessibility Label via alt prop` section, this can be tested either by enabling Voice Over if you're using a real device or through the Accessibility Inspector if you're using a simulator
https://user-images.githubusercontent.com/11707729/187790249-0d851363-c30e-41b6-8c24-73e72467f4ba.mov
Reviewed By: lunaleaps
Differential Revision: D39618453
Pulled By: cipolleschi
fbshipit-source-id: 0e26b2574514e76ce7e98ddb578f587a9cc30ee9
Summary:
Currently, height is sometimes the only valid option for pushing `TextInput` up in the layout on Android. The problem is when switching keyboards. For instance, switching from ABC to emojis. This will trigger keyboard show events and recalculate the height for the `KeyboardAvoidingView`. Since the keyboard is still showing, the view has the height that was previously calculated and thus `frame` represents that. This means the `frame.height` has adjustments for the keyboard calculated in it, but it is used the same way as if the keyboard was not showing. This results in wrong calculation and the input showing at the incorrect place in the layout (mostly hidden under the keyboard)
This fix simply uses the previous calculation to offset `frame.height`, resulting in the correct height and smooth switching between keyboards. It's also scoped only to height mode since that's where the problem shows.
_Note: I mention android here, but it fixes it for both platforms. It's just that iOS usually works best with different behaviour so it's rarely used there._
## Changelog
[General] [Added] - Include `this.state.bottom` when calculating new keyboard height to fix android keyboard switching
Pull Request resolved: https://github.com/facebook/react-native/pull/34749
Test Plan:
With simple code:
```jsx
import { StatusBar } from "expo-status-bar";
import React from "react";
import {
KeyboardAvoidingView,
StyleSheet,
Text,
TextInput,
View,
} from "react-native";
export default function App() {
return (
<KeyboardAvoidingView style={styles.container} behavior="height">
<Text>Open up App.js to start working on your app!</Text>
<StatusBar style="auto" />
<TextInput style={{ backgroundColor: "red", width: "100%" }} />
</KeyboardAvoidingView>
);
}
const styles = StyleSheet.create({
container: {
padding: 32,
flex: 1,
backgroundColor: "#fff",
alignItems: "center",
justifyContent: "space-between",
},
});
```
Notice the consistency of the TextInput after the changes, while before it would just move around more you switch the keyboards.
| Before | After |
|---|---|
|  |  |
Reviewed By: cipolleschi
Differential Revision: D39718812
Pulled By: NickGerleman
fbshipit-source-id: 2550182e846f3f8e719d727fa8e6d87165faebf6
Summary:
We need to bump & publish a new version of the Gradle Plugin.
This is needed otherwise the template will break as I start to remove
entries from the `Android-prebuilt.cmake` file
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.71.2
Reviewed By: lunaleaps, mdvacca
Differential Revision: D39815785
fbshipit-source-id: b140187971e2f963ef459e9c83ce9a76e67c89bd
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
There was a bug on Android when an Animated.ScrollView had a RefreshControl while an Animated style was applied, ie `transform`:
```
<Animated.ScrollView
refreshControl={<RefreshControl />}
style={{
transform: [{
translateY: new Animated.Value(200, {useNativeDriver: true})
}]
}}
/>
```
The transform value was being incorrectly applied twice. Since the styles were applied once on RefreshControl and once on NativeScrollView, the transform style is effectively applied twice:
**1. ScrollView.js**
- RefreshControl gets the transform through Fabric commit
- [The RefreshControl gets wrapped around ScrollView](https://fburl.com/code/k60krxbj) while on iOS there is no change in the parent/child relationship. [Outer/inner styles are split and applied to RefreshControl/ScrollView](https://fburl.com/code/b2to75er), and transform styles are applied on the parent (RefreshControl)
**2. createAnimatedComponent.js**
- NativeScrollView gets the transform through Animated
- [ScrollView forwards its ref to NativeScrollView](https://fburl.com/code/w1whtl5f), which means AnimatedComponent is setting the transform styles on NativeScrollView and not RefreshControl as ScrollView.js did
This diff fixes this bug by using the `useAnimatedProps` hook which makes both RefreshControl and ScrollView components into animated components. Otherwise, the components don't know what to do with Animated values.
---
Changelog:
[Internal][Fixed] - Animated transform style properties were being applied twice when used on an Animated.ScrollView with RefreshControl on Android
Reviewed By: javache
Differential Revision: D38815633
fbshipit-source-id: 2b76639d2237176b6aae4fb1e22cf1a1ec70a69a
Summary:
Currently, it is possible in one of the "minimum press duration" unit tests for certain instructions to take longer than expected, skewing the return value of `Date.now()` by at least 10ms.
This changes the unit test to mock `Date.now()` more accurately so that the test is no longer flakey.
Changelog: [Internal]
Reviewed By: jacdebug
Differential Revision: D39804152
fbshipit-source-id: ab62fd1921bd015d969da9595bd3267c38c6e59c
Summary:
I've just realized that CMake is ignoring `ccache`, even if you have it
installed. This is the necessary change needed to verify if the user
has `ccache` installed and eventually use it.
While not a necessary change for Prefab supprot, this is a nice to have
that I've discovered while working on it.
Changelog:
[Internal] [Changed] - Make sure ccache is considered as part of the CMake build
Reviewed By: cipolleschi
Differential Revision: D39815089
fbshipit-source-id: be62e5fe98954593fd907ec21c41950a967cff04
Summary:
This is part of the preparatory work for Prefab support for React Native.
I've added a task that will help us copy, filter and prepare the headers to
be consumed by Prefab.
It's not used at the moment. I will use it in the next commit.
Changelog:
[Internal] [Changed] - Add the PreparePrefabHeadersTask.kt inside the Gradle Plugin
Reviewed By: cipolleschi
Differential Revision: D39815101
fbshipit-source-id: 73e48666efa372a1647d08a7586083434d9ebbbb
Summary:
Cleans up the dependencies in `ReactCommon/hermes/inspector/tools/msggen` by
- Analyzing and removing any dependencies that are never referenced.
- Upgrading all dependencies to their latest versions (by deleting `yarn.lock` and re-running `yarn`).
- I only upgraded Babel dependencies to the same version used by the rest of `react-native`.
Notably, this resolves 13 vulnerabilities reported by Dependabot.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34782
Test Plan:
Ran the following successfully:
```
$ cd ReactCommon/hermes/inspector/tools/msggen
$ yarn
$ yarn test
$ yarn build
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D39804478
fbshipit-source-id: c673e80b64fcf49c3f903c5d7f0a68c77d63a4bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34786
This diff is the TS equivalent of D39686251.
It introduces the possibility to parse a custom Native State in Typescript.
The parsing follows the exact same rules as props, as initial heuristic. This should allow enough customization for the developers who needs a custom state.
Currently, we only support using `interface` for the state and the interface must contain the `NativeState` string in its name.
This diff introduces also tests for the TypeScript parser and it aligns the tests between Flow and TS.
## Changelog
[General][Added] - Implement custom Native State parsing in TypeScript
Reviewed By: cortinico
Differential Revision: D39811476
fbshipit-source-id: 1e1b86b50b9632c13157ff6c8115f5ebcbada643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34753
This Diff introduce a the capability to parse custom NativeStates in Flow. To achieve this I also had to define the CodegenSchema.
The parsing follows the exact same rules as props, as initial heuristic. This should allow enough customization for the developers who needs a custom state.
There is only a case I was not able to make it work that is STATE_ALIASED_LOCALLY, from the fixtures. I don't know how diffuse it is and I think we can live with some workarounds for the time being.
This diff also adds tests for the custom Native State Flow Parser.
## Changelog
[General][Added] - Implement custom Native State parsing in Flow
Reviewed By: cortinico
Differential Revision: D39686251
fbshipit-source-id: 446997a39b33b7e9351d5ba12cecaeff33df4d16
Summary:
Brings in line with rest of code base and avoids running into this error
```
‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
```
when `Requires Only App-Extension-Safe-API` is set to Yes.
## Changelog
[iOS] [Fixed] - Update usage of UIApplication.sharedApplication in RCTKeyCommands
Pull Request resolved: https://github.com/facebook/react-native/pull/34787
Test Plan: Setting `Requires Only App-Extension-Safe-API` to Yes before this change means the app will not compile, after the change it does.
Reviewed By: dmytrorykun
Differential Revision: D39812410
Pulled By: cipolleschi
fbshipit-source-id: 78d185ba20301b10609e4a387f000f0cfda55663
Summary:
Within the `hermes-engine.podspec` contained in the RN repo (at `react-native/main/sdks/hermes-engine/`), there's a bit of logic that triggers `./utils/build-ios-framework.sh` and `./utils/build-mac-framework.sh` .
The issue is that we all thought that that `./utils/build-ios-framework.sh` would invoke the React native version of the scripts (since the podspec file lives right next to the `utils` folder) but, in reality, it doesn't. It just so happens that the Hermes repo has a root level `utils` folder which is (you guessed it) where the Hermes variation of those build scripts live.
So, when running the pod install command in a react-native project (build from source), it will go and download the hermes source code (since the `source[:git]` gets set) but then it will use the **hermes** variation of the `build-*.sh` scripts.
[Read more here](https://github.com/facebook/react-native/pull/34513#issuecomment-1248286691).
This PR is taking kudo's proposed [patch here](https://github.com/reactwg/react-native-new-architecture/discussions/68#discussioncomment-3654191) - props for the fix go to him.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Change hermes logic in build scripts for Apple to use the correct files
Pull Request resolved: https://github.com/facebook/react-native/pull/34710
Test Plan: Tested by kudo in his work, and in my PR locally - [see here](https://github.com/facebook/react-native/pull/34513#issuecomment-1249431302).
Reviewed By: cortinico
Differential Revision: D39647057
Pulled By: cipolleschi
fbshipit-source-id: 6520e248801a307ca2f8886a3853dd1ff4af193d
Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34776
CocoaPods is not used when Hermes is built in Circle CI, so we cannot rely on the React Native CocoaPods scripts to be loaded.
The get_hermes_build_type function is removed from the RN CocoaPods scripts and in its place, the ENV['PRODUCTION'] envvar is accessed directly.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D39778190
fbshipit-source-id: 12083b7b4533b4ad7bb7a08612883983a0583616
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34761
Separate debug and release tarballs are built in CI. Use the appropriate Hermes artifacts tarball when building hermes-engine.
Add hermes.rb tests.
Changelog:
[iOS] [Changed] - Remove debugger from Hermes when building for release
Reviewed By: cipolleschi
Differential Revision: D39698499
fbshipit-source-id: e6b10d34c7f94c2f86fc47d8b97466011aaa75cc
Summary:
Fix remaining NDK comment for new architecture
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix remaining NDK comment for new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/34769
Reviewed By: cipolleschi
Differential Revision: D39762860
Pulled By: cortinico
fbshipit-source-id: 35a3c9fed58d32bd6dc16c0d6bb217a3c2849612
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Currently, fbios link groups depend on supermodules to generate. To continue supporting
link groups while allowing us to migrate off supermodules, we'll add a `fbios_link_group` label on all fbios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D39543862
fbshipit-source-id: 2abe5b3ee883e77336076d88436a1c84139b5a97
Summary:
Aside from the log output, these changes do not change the behavior of the hermes-engine Pod.
Removed unused git branch checks.
Use react_native_path var to build filepaths.
Edit Hermes build from source log message to be consistent with other logs.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D39699165
fbshipit-source-id: 7e389eb5315fc5a2510b84eddac2f499a3e65157
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34704
Create separate hermes-engine tarballs for release and debug builds, and only include the debugger in debug builds.
Changes the hermes-engine podspec to use a debug Hermes build by default in order to preserve the inclusion of the debugger.
Upcoming changes should split the hermes-engine Pod to allow Xcode to use release and debug builds as needed.
Changelog:
[iOS][Changed] - Use debug Hermes builds by default
Reviewed By: cipolleschi
Differential Revision: D39326467
fbshipit-source-id: 94c5fe7db80194d22fced6717c5efc7accd36d48
Summary:
In `buildEventSchema` and `buildPropSchema`, they check into property types to see if the given property could be converted into an event schema or a property schema. The original implementation only handles limited cases, I refactor them and make them easier to maintain.
In `getPropertyType` in `events.js`, it handles `(T)` at a wrong place, fixed.
In `getPropertyType` in `props.js`, it doesn't handle `(T)`, fixed.
And I also fixed some other issues to make the codegen reports error better.
There are many duplicated test cases that cover every piece of the code, I changed some of them so that it tests both original cases and new cases.
## Changelog
[General] [Changed] - Handle (T) and undefined properly in turbo module component codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/34693
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: NickGerleman
Differential Revision: D39647075
Pulled By: cipolleschi
fbshipit-source-id: 8e1df2b54aab37b7151d0bf74260e2eba0602777
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34746
The changes made in
https://github.com/facebook/react-native/pull/34694
introduced the need to have the env variable TMP_PUBLISH_DIR for the publishing and set-rn-version scripts to work.
This break any usage of set-rn-version when the env variable is not set upfront.
With this change, we are creating a temp folder in the scope that requires it (e.g. set-rn-version.js) and then passing the path to the save/revert functions.
## Changelog
[Internal] [Added] - Do not depend on an ENV variable when publishing and setting the RN version.
Reviewed By: cipolleschi
Differential Revision: D39683565
fbshipit-source-id: 21d85d1c16c4cb7324636ceb5eba626ff8cbb775
Summary:
This updates the `transform` property to support string values as requested on https://github.com/facebook/react-native/issues/34425. This also updates the existing unit tests of the `processTransform` function ensuring the style processing works as expected and updates the TransformExample on RNTester in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add string support to the transform property
Pull Request resolved: https://github.com/facebook/react-native/pull/34660
Test Plan:
1. Open the RNTester app and navigate to the Transforms page
2. Check the transform style through the `Transform using a string` section
https://user-images.githubusercontent.com/11707729/189550548-ee3c14dd-11c6-4fd1-bd74-f6b52ecb9eae.mov
Reviewed By: lunaleaps
Differential Revision: D39423409
Pulled By: cipolleschi
fbshipit-source-id: 0d7b79178eb33f34ae55a070ce094360b544361f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754
This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components
Reviewed By: cortinico
Differential Revision: D39696435
fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34750
This Diff is the first step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
To allow the generation of custom `NativeState`, we first have to always generate a `ViewEventEmitter`: that's because the `ConcreteShadowNode` template lists the Generics with this order: `Name`, `Props`, `EventEmitter`, Others...
If we skip the `EventEmitters` and we put the `State`, React Native would think that the State is actually an `EventEmitter` and the build step will fail.
## Changelog
[General][Added] - Always generate a ViewEventEmitter for Fabric Components
Reviewed By: cortinico
Differential Revision: D39509869
fbshipit-source-id: 390cc146ef013baf1ed09d55a0182a5aeb5b9d9e
Summary:
This PR adds [verdaccio](https://github.com/verdaccio/verdaccio) to release packages in the `packages` directory during the E2E test on CI.
The rationale behind this is the following:
- Firstly, we wanted to push the [monorepo RFC](https://github.com/react-native-community/discussions-and-proposals/pull/480). We hit an issue when renaming the packages to follow the same convention caused by the e2e test using the template to fail. This is because the template installs packages from the live version of npm – and if you just rename a package in a given PR without releasing it, the package understandably can't be installed since it's not published, yet – as you can see [here](https://app.circleci.com/pipelines/github/facebook/react-native/15286/workflows/149df51f-f59b-4eb3-b92c-20c513111f04/jobs/282135?invite=true#step-108-283).
- Secondly, the current e2e test on `main` does not actually test the latest code of the packages in the `packages` directory as it simply downloads the latest versions from npm. This creates a divide between what's tested and what users should expect when using nightlies or when a new minor is released.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Use verdaccio for template e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/34577
Test Plan: `test_js` CI check should pass. Additionally, I have temporarily updated the [PR](https://github.com/facebook/react-native/pull/34572) renaming `assets` to `assets-registry` to include the verdaccio changes – the `test_js` passes there, additionally proving merging this PR will unblock us with the rename PRs.
Reviewed By: cipolleschi
Differential Revision: D39723048
Pulled By: cortinico
fbshipit-source-id: aeff3811967360740df3b3dbf1df50e506fb72d8
Summary:
when specifying dev server without port, e.g. http://www.example.com/, there are some issues.
1. redbox error
<img src="https://user-images.githubusercontent.com/46429/190540390-8ee420f2-7642-427b-9f2e-e0c6d31015f8.png" width="30%">
2. showing -1 in loading view
<img src="https://user-images.githubusercontent.com/46429/190540727-158f35ad-359f-443a-a4b0-768dd2f7e400.png" width="50%">
the root cause is coming from [`java.net.URL.getPort()` will return -1 when the url doesn't have a port](https://developer.android.com/reference/java/net/URL#getPort()). this pr replaces the parser to [`okhttp3.HttpUrl`](https://square.github.io/okhttp/4.x/okhttp/okhttp3/-http-url/#port) that it will have default port 80 for http or port 443 for https. the two call paths should only serve http/https address, not file:// address. it should be safe to change from java.net.URL to okhttp3.HttpUrl.
not fully related, in the case above, android will connect to `ws://www.example.com/:8097` for react-devtools
we should strip the trailing slash in *setUpReactDevTools.js*
## Changelog
[Android] [Fixed] - Fix port as -1 if dev server without specifying port on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34705
Test Plan:
test on rn-tester with the following steps
1. `yarn start`
2. open another terminal and run `ngrok http 8081` and it will return a tunnel url, e.g. `71a1-114-36-194-97.jp.ngrok.io`
3. open dev setting in app and change the dev server to `71a1-114-36-194-97.jp.ngrok.io`
5. reload the app
Reviewed By: cipolleschi
Differential Revision: D39573988
Pulled By: cortinico
fbshipit-source-id: 397df90ab30533207bd87a3f069132d97c22c7fd
Summary:
## Summary
In the past, NativeAnimatedModule could animate **both** Paper **and** Fabric components.
For Fabric nodes, we needed to manually flush NativeAnimatedModule's operations queue. So, we started tracking which nodes were Fabric owned in NativeAnimatedModule.
## Changes
With bridgeless mode, all components must be Fabric-owned. So, should be able to remove this fabric ownership tracking logic and **always flush.**
## Is this safe?
In the worst case, we over-flush. This doesn't seem bad. cc sammy-SC.
## Do we still need flushing?
Arguably, all this manual flushing should be unnecessary, because we already migrated AnimatedModule's Paper integration to RCTSurfacePresenterObserver, here: D14336760 (https://github.com/facebook/react-native/commit/544d9fb10b5a73bd499feb18dab1a7dc11738748). So, do we still need this flushing?
Yes. Here's what happens when you disable all the manual flushing in bridgeless mode: https://pxl.cl/2dqPf.
Long-term, we need to re-think this operations queuing in NativeAnimatedTurboModule. I left my thoughts in T130668424 (Investigation - Day 5).
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D39592477
fbshipit-source-id: e971edc0d99661a37b5f430bce46c78acaa121c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34747
Just a minor cleanup after the AGP bump.
Changelog:
[Internal] [Changed] - Cleanup of ReactAndroid/build.gradle after AGP 7.3.x bump
Reviewed By: cipolleschi
Differential Revision: D39687286
fbshipit-source-id: 441e449b51b25e4152cf1e7e7e22c7c9f1432d05
Summary:
This behaviour diverges from the original SafeAreaView implementation and causes issues when you try to use SafeAreaView in non-root placements (not recommended)
Changelog: [iOS][Internal]
Reviewed By: sammy-SC
Differential Revision: D39497303
fbshipit-source-id: 03bc288557f611bd4a8c16b3a6df8887e89ee9ec
Summary:
When `GenerateRCTThirdPartyFabricComponentsProviderCpp.js` generates `RCTThirdPartyFabricComponentsProvider.mm` an edge case happens in the following situation:
- The same library exports multiple modules with one component each (i.e. one component per file);
- The **first component** is excluded for iOS via the `excludedPlatforms` property in *codegenNativeComponent*.
A "loose" comma appears in the generated template, breaking the code.
```c++
Class<RCTComponentViewProtocol> RCTThirdPartyFabricComponentsProvider(const char *name) {
static std::unordered_map<std::string, Class (*)(void)> sFabricComponentsClassMap = {
, // <-- the offending comma
{"NativeComponent2", NativeComponent2Cls}, // rnmylibrary
};
}
```
At some point, `GenerateRCTThirdPartyFabricComponentsProviderCpp.js` does not properly filter out empty arrays resulting from excluded components. This does not seem to be a problem when the excluded component is not the first being processed, as the comma gets added at the end of the previous line, after the comment with the name of the library.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix error in the Codegen template for ThirdPartyFabricComponentsProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/34738
Test Plan:
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. -->
This is the schema that leads to the bug. Notice that the first component was excluded for iOS.
```json
{
"modules": {
"ComponentFile1": {
"type": "Component",
"components": {
"NativeComponent1": {
"excludedPlatforms": ["iOS"]
"extendsProps": [
{
"type": "ReactNativeBuiltInType",
"knownTypeName": "ReactNativeCoreViewProps"
}
],
"events": [],
"props": [],
"commands": []
}
}
},
"ComponentFile2": {
"type": "Component",
"components": {
"NativeComponent2": {
"extendsProps": [
{
"type": "ReactNativeBuiltInType",
"knownTypeName": "ReactNativeCoreViewProps"
}
],
"events": [],
"props": [],
"commands": []
}
}
}
}
```
`GenerateRCTThirdPartyFabricComponentsProviderCpp.js` should generate a template without the comma in the wrong position (before NativeComponent2).
I also added an additional test case to cover this problem. All the other tests passed.
Reviewed By: sammy-SC
Differential Revision: D39686573
Pulled By: cipolleschi
fbshipit-source-id: 6054464d024218eb0b2e02974aa5cc7c8aebbbc9
Summary:
Checking if Hermes is enabled is failing because there is no `podfile.lock` file in the directory where this script is executed and `USE_HERMES` will be set to `false` which will prevent building Hermes binary jsbundle.
## Changelog
[iOS] [Fixed] - `HERMES_ENABLED` check fixed in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/34675
Test Plan:
1. Enable Hermes
2. Make a release build
3. Verify the `main.jsbundle` file is Hermes binary bundle
Reviewed By: cortinico
Differential Revision: D39686608
Pulled By: cipolleschi
fbshipit-source-id: 237c77ced484d4ab77e576c7a2bb7b6826228017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34739
AGP 7.3.0 just got released which is glorious!
This allows us to remove a lot of unnecessary boilerplate to handle correct task ordering
inside the template
This requires "react-native-gradle-plugin" version 0.71.1 to be published on NPM.
Changelog:
[Android] [Changed] - Bump AGP to 7.3.0 inside the template
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D39653419
fbshipit-source-id: 517363c952cbad2be0f2766c0a2b7daf3e75048b
Summary:
As we're shipping the AGP 7.3.x bump which requires
changes of the Gradle Plugin, I'm bumping a version so I can use it
already in the new template.
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.71.1
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D39653418
fbshipit-source-id: 9e898530345f1a3461c44c04b4cc5e7736a0f6a5
Summary:
`verifyVirtualizedList` chokes on missing displayName in DEV, due to a mistake in D39648806 (https://github.com/facebook/react-native/commit/a0d1585cdb5ae86e5d4e5bc51fdfa9ae7e049b4b). Not sure why this isn't triggered in Jest tests (maybe it is able to fill displayName via transform?), but this fixes the issue in dev mode.
Changelog:
[Internal][Fixed] - Fix crash in DEV when VirtualizedList_EXPERIMENTAL is loaded
Reviewed By: mdvacca
Differential Revision: D39670991
fbshipit-source-id: b1a784aa3fffdc5f2f025eb1f689307132aad9b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34724
Following on from the recent upgrade from Jest 26->27, this brings us up to present day Jest 29 for tests of React Native itself, Metro, and Meta-internal code. An update to the template for RN apps will follow.
Changelog:
[Internal][Fixed] Update to Jest 29
Reviewed By: huntie
Differential Revision: D39543504
fbshipit-source-id: b47fdb678212b475881ec19085f6cd45a4530333
Summary: Changelog: [Internal] - A refactor to pass the object PointerEventState containing relevant state / and also properties for pointerEvent objects
Reviewed By: vincentriemer
Differential Revision: D39626285
fbshipit-source-id: e2ff5313ef03d7d2d36c35ca459950ec07650df2
Summary:
Changelog: [Internal]
Stop using `TouchEventCoalescingKeyHelper` for tracking and stop making the distinction between traditional touch events (down, up, move) vs hover only events. The only events that currently coalesce are `onpointermove` events. This change uses just one counter now that we increment whenever some non-move event is fired.
Let me know if there's a simpler way to ensure counter doesn't overflow.
This change also ensures we're overriding `getCoalescingKey` which isn't used by Fabric but for old event emitter it might be (which we use for native animations). Part of that requires the `coalescingKey` to be a short so updated to that.
There was also a bug where I forgot to pass `mLastButtonState` to one of the dispatch calls. Will be wrokign on refactor so its less argument soup.
Reviewed By: javache
Differential Revision: D39530927
fbshipit-source-id: 689fa98580b206a480cc08121971cdf96bdbbfaa
Summary:
The prop is removed as part of D39589089 (https://github.com/facebook/react-native/commit/bc5cb7cd7933da707c02ff0dd993c607ba7d40b3) (no longer does anything). Remove from the TS declarations.
Changelog:
[General][Removed] - Remove listKey from TS typings
Reviewed By: lunaleaps
Differential Revision: D39650827
fbshipit-source-id: dd9b5eccba1b9f6964a6d60ea5bae9913e8396e3
Summary: Changelog: [Internal] - Update the base accessibility props to include the added aria props. See https://github.com/facebook/react-native/compare/0.70-stable...main for changes.
Reviewed By: cipolleschi
Differential Revision: D39633224
fbshipit-source-id: 6c08ab8540b8b6e2b57f066a35754376c5ae3d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34707
AGP 7.3.0 just got released which is glorious!
This allows us to remove a lot of unnecessary boilerplate to handle correct task ordering
on both React Android & the template
Changelog:
[Android] [Changed] - Bump AGP to 7.3.0
Reviewed By: mdvacca
Differential Revision: D39553534
fbshipit-source-id: 9680893e9f48cac867206aeb7eb468dbf91c1643
Summary:
This PR refactors the Animated directory to use ESModule imports/exports instead of using a mixture of the 2 module formats, as requested on https://github.com/facebook/react-native/issues/34425.
## Changelog
[Internal] [Changed] - Convert all files in the Animated directory to use ESModule imports/exports
Pull Request resolved: https://github.com/facebook/react-native/pull/34539
Test Plan: This doesn't really add or modify any existing features so checking if CI passes should be enough
Reviewed By: yungsters
Differential Revision: D39235720
Pulled By: yungsters
fbshipit-source-id: 84b4c0a71dc9fca1ab7053263f1cf7c336df58c1
Summary:
VirtualizedList uses a combination of ES6 and CommonJS imports/exports. This moves fully to ES6 imports and exports, in the experimental version (which should soon replace the original).
Changelog:
[Internal][Changed] - Move VirtualizedList_EXPERIMENTAL to ES6 import/export
Reviewed By: rshest
Differential Revision: D39648806
fbshipit-source-id: a5da40f62a6010cd5b9894b02a91af86d3a8b995
Summary:
VirtualizedList is large and complicated, getting larger and more complicated. This splits out a subcomponent, the cell renderer into its own file, since it is relatively isolated already. This uses the copy from VirtualizedList_EXPERIMENTAL, whose only real difference is exposing focus capture events to the containing VirtualizedList.
Changelog:
[Internal][Changed] - Extract VirtualizedListCellRenderer
Reviewed By: rshest
Differential Revision: D39648087
fbshipit-source-id: bb7c2eff0c658713c256650596f86e8788019baf
Summary:
Now that the prop noops, remove the usages of the property. This is the point of no return for the prop.
Replaced listKey usage with a combination of `flow check`, regex replace, manual inspection.
Changelog:
[General][Removed] - Remove usages of listKey
Reviewed By: fred2028
Differential Revision: D39589089
fbshipit-source-id: 722ebb7dce038a2709656394b7d736e72f488bb7
Summary:
The previous approach to set a heading in Android required us to trick the accessibility service into thinking that this element was the heading inside of a list, which used to be the only place you could use headings on Android.
This worked for the most part, but could cause problems in specific circumstances, such as if that element actually *was* part of a list. Since we were overriding its CollectionItemInfo, and presenting it as the first item in a single column list, the parent list could have confusing announcements such as announcing this item as "Item 1" even if it was not the first item in the actual list.
Since API 28, there has been an API to set any view as a heading (https://developer.android.com/reference/android/view/View#setAccessibilityHeading(boolean)).
This switches our implementation to use this new API via the AccessibilityNodeInfoCompat class for backwards compatibility to older API versions.
Changelog:
[Android][Changed] - Simplify Accessibility Heading role implementation.
Differential Revision: D39076827
fbshipit-source-id: 583dc1e9d2779a4efa5f98cabef506df2770d892
Summary:
Following up on the previous diff to remove the only usage of `listKey` for persistent association, we can remove the need for a manual `listKey`, and instead rely on per-instance association via refs.
A followup change will remove the existing usages.
Changelog:
[General][Removed] - Remove VirtualizedList `listKey` prop
Reviewed By: p-sun
Differential Revision: D39466677
fbshipit-source-id: 6b49f45c987fff9836918ba833fbb16f24414ff8
Summary: Changelog: [Internal] - Update changes to Keyboard, Alert from differences in those files from https://github.com/facebook/react-native/compare/0.70-stable...main
Reviewed By: NickGerleman
Differential Revision: D39629997
fbshipit-source-id: 85bb91d00a165e708dbf4e32d7f37ce8a6c02a72
Summary:
Keeping the lowercase values but keeping the conversion values the same.
D39478951 (https://github.com/facebook/react-native/commit/ea1ec29ba67c837c82c74357e313bd4505b81eb8) reverted some changes that moved it back to uppercase but needed to add new values to `____FontWeight_Internal`. This diff removes the need for the uppercase values
Changelog: [Internal]
Differential Revision: D39506944
fbshipit-source-id: 079f73c1adcf2db28b961523b05562e21fcf3630
Summary:
## Changelog
[General] [Added] - Add `types` folder to house TypeScript types.
Release TypesScript types with react-native and eventually deprecate [types/react-native](https://www.npmjs.com/package/types/react-native).
The current plan is to release types/react-native for 0.70 and 0.71 while also maintaining types here. This will result in some double maintenance until 0.72 but will give community time to move off of types/react-native.
After this lands, there have been changes on `main` of types that we need to update. Then, when we release 0.71 from DefinitelyTyped, we can simply copy over the `types` folder from this repo.
Pull Request resolved: https://github.com/facebook/react-native/pull/34614
Test Plan:
`yarn run test-typescript` for linting types
* Created a new project using the TS template and my local clone of `react-native` on this branch.
`npx react-native init MyTSApp --version <path-to-my-local-rn-repo> --template react-native-template-typescript`
* Updated the `package.json` to remove `types/react-native`
* Deleted my node_modules and re-ran yarn
* Opened MyTSApp in VSCode and verified the type suggestions appeared and cmd+click to defnitions took me to the node_module dependency `react-native/types`
## Danger is failing on this PR and it's expected
as it runs off the changes on `main`. [This is expected](https://docs.github.com/en/github-ae@latest/actions/using-workflows/events-that-trigger-workflows?fbclid=IwAR2_AE0Jwndt8Gu-iTQnxGxLJq7nakbi7sz8jwZ6U62JWLSdcZuvjcQ6WvE#pull_request_target). However testing it locally passes. Once merged, and these changes are on `main`, danger will pass again.
```
$ react-native/packages/react-native-bots
❯ yarn danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ ..react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 13.24s.
```
Reviewed By: mdvacca
Differential Revision: D39479137
Pulled By: lunaleaps
fbshipit-source-id: 1d506f812d566b783b6e79104cd6339b077a42a7
Summary:
This diff updates the documentation for enableCppRenderSystem feature flag
This is a follow up of D38725771 (https://github.com/facebook/react-native/commit/399907fe4ad843ac6aa0aa2f553ba3aee3c83006)
changelog: [internal] internal
Reviewed By: cortinico, makovkastar
Differential Revision: D39558834
fbshipit-source-id: e079ee688a912dfa2670c66e5adf347a902a45e1
Summary:
This diff moves Component and ComponentManager classes -> react/cxxcomponents. The purpose is to be able to use these classes from any platform, not only Android
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D39531533
fbshipit-source-id: 4732aa7bf59d82dae11441212975f0e225c6d458
Summary: Changelog: [Internal] Add flow declaration for Alert. Couldn't figure out how to do type statics on interfaces in Flow.
Reviewed By: yungsters
Differential Revision: D39186533
fbshipit-source-id: 928ee76080490a133c9773d2330473a688e0612d
Summary:
Upgrades all of our JavaScript tooling to use `yargs@^17.5.1`.
Of all [release notes](https://github.com/yargs/yargs/releases), these are the major version notes:
- [v17.0.0](https://github.com/yargs/yargs/releases/tag/v17.0.0)
- [v16.0.0](https://github.com/yargs/yargs/releases/tag/v16.0.0)
A cursory inspection suggests that these breaking changes are unlikely to seriously impact our use cases (or can be fixed forward).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D39550338
fbshipit-source-id: 5b2c5265f8c7a95ab0cc9bab62873f9e4355f32f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34694
TL;DR Relax the assumption of having git to build the RN NPM package.
We do have two CI Systems: CircleCI for OpenSource and Sandcastle for Internal. It's crucial that the two CIs are aligned.
We currently don't have a way to test the new app template on Sandcastle for Android & iOS.
This results in scenarios where internal Diffs gets landed and break the public CI externally.
This is preparation work to then be able to build the RN NPM package in Sandcastle (which will be done in a follow-up diff).
With this we also introduce the restoring of all the changed files after the publishing script is done.
## Changelog
[Internal] [Added] - Made it possible to create publishing NPM packages in Sandcastle.
Reviewed By: cortinico, cipolleschi
Differential Revision: D39467471
fbshipit-source-id: b0de88a768b8a2fb798dd684fa8f97f4d0acb751
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34702
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D39550336
Pulled By: dmytrorykun
fbshipit-source-id: 4e6ff93fb419bf08b4c5b1f88312591d79bd3e29
Summary:
This diff creates a new Feature Flag to Enable/Disable C++ Render System in JS
Changelog: [Internal] Internal
Reviewed By: sammy-SC
Differential Revision: D38725771
fbshipit-source-id: 3a238781bec427274dbd8f7c045d360135d1803e
Summary:
This diff integrates the registration of C++ component into React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725769
fbshipit-source-id: 33eb9ebb93983c4038529748758eac3e43eec3e5
Summary:
CppViewMutationWrapper is a class that will be used to execute operations to mutate C++ Components in React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725765
fbshipit-source-id: 3dfe11deb873750a78f6dbbaee82b62134908de4
Summary:
This diff introduces the APIs that will be used to register C++ components in React Native Renderer for Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725768
fbshipit-source-id: a7116b787f83544282230666d9d5acbfb1df4047
Summary:
Customize gradle/buck to be able to build fabric C++ components files
changelog: [internal] internal
Reviewed By: cortinico, sammy-SC
Differential Revision: D39448416
fbshipit-source-id: 3beddf27082728e2316e483c2541c7405e4c57f7
Summary:
Update our internal tests to use Jest 27. If this sticks, we should follow up with updating the RN template.
Changelog:
[Internal][Fixed] Update Jest setup to v27.5.1
Reviewed By: motiz88
Differential Revision: D39383717
fbshipit-source-id: 0fbb5a7b1ab70ccbfaed22b2de92f445f756afe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34690
While working on another part of the codebase I realized that
our Unit Tests are not compiling due to references to missing classes.
I'm cleaning them up + hooking the compileTest task inside the
`buildAll` task so at least they will be compiled on both CIs.
Changelog:
[Internal] [Changed] - Make the Android unitTests compile
Reviewed By: cipolleschi
Differential Revision: D39501945
fbshipit-source-id: 03d3e4872d6c738b8b85d1fef9302ac230e857d2
Summary:
Adding support for application to hook into further tracing methods
## Changelog
[General][Added] - Add additional Systrace support
Reviewed By: NickGerleman
Differential Revision: D38673212
fbshipit-source-id: 55a90a0cd57809bca5f01da7acddcf253e5852ba
Summary:
Changelog: [Internal] Remove unused RuntimeExecutor from UIManagerBinding constructor
Since [UIManager is the class that has a reference to RuntimeExecutor](https://github.com/facebook/react-native/blob/ce50c43986bae05ad62552be46f4d5bb4a46f097/ReactCommon/react/renderer/uimanager/UIManager.h#L35-L36), there's no reason for `UIManagerBinding` to own a reference to RuntimeExecutor too.
The purpose of `UIManagerBinding` is to bind the Fabric `std::shared_ptr<UIManager>` in C++ to `global.nativeFabricUIManager` in JS.
Doing this cleanup to make the next diff easier.
Reviewed By: sammy-SC
Differential Revision: D39490927
fbshipit-source-id: 4c393dccc6985bef44e3b0afc32b9f79bea25f80
Summary:
We already support attaching-on-reload when a debugger was a previously connected, and this connection logic seems to slow down app startup by 2 seconds in debug mode when running on device.
Changelog:
[Internal][Removed]
Reviewed By: jpporto
Differential Revision: D39272704
fbshipit-source-id: deb8651798cb9a13b81e1703920d3f9bd58869d2
Summary:
This task has been created T131775291 that blames D39268920 (https://github.com/facebook/react-native/commit/f1c1f8116ba1cfa9d10c5b8c30b98b796047b9c2). I reverted part of the changes and added the support of capital letters for the font weight. It should make the test pass.
However, I am a bit puzzled: I tried to change the title of the `GemstoneTitleBar` and the test was not showing the changed value. I think I'm missing something.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D39478951
fbshipit-source-id: d3e28336fe52c5c58b49872c3f5b6e63e1e37ca5
Summary:
When `getItemLayout` is not supplied, VirtualizedList doesn't know the measurements for its child items ahead of time. It caches most recent cell measurements so that an item which is virtualized away is associated with its correct height. VirtualizedList will not consume space for an item it has not yet rendered/knows measurements for.
This also means an initially created list will only take up the height of its `initialNumToRender()`. This can cause scroll jumping for the scenario of nested VirtualizedLists of the same orientation, since a virtualized away child list will shrink (compared to the spacer), then re-expand, once returned to.
There is logic in the VirtualizedList constructor to load cached frame metrics based on supplied listKey, to enable reloading most recent state. Though locally it seems to be reading the context too early in the lifecycle (compared to other successful checks during componentDidMount, render). It was moved from `componentDidMount` to `constructor` as part of the initial change (https://www.internalfb.com/diff/D6330846 (https://github.com/facebook/react-native/commit/2668dc8e1be7bf93e65ca2e11c87cbeef3310c3e)?dst_version_fbid=131968984136932&transaction_fbid=1578362385612542), and I think has likely been unreliable or dead since.
Restoring state was the only usage of a durable key for nested lists beyond their lifetime. So removing the dead code lets us remove the need for a `listKey`, which has been error-prone. This still leaves the problem present since inception, but there may be alternate solutions like scroll anchoring.
Changelog:
[Internal][Removed] - Remove dead code for restoring state to nested VirtualizedList
Reviewed By: ryancat
Differential Revision: D39466678
fbshipit-source-id: fc2f39802e5cdf9b920974333be64c74211b99a9
Summary:
This updates `fontVariant` to support space-separated string values, i.e., `'small-caps common-ligatures'`, thus aligning it with the [CSS Fonts Module Level 4](https://drafts.csswg.org/css-fonts/#font-variant-prop) specification as requested on https://github.com/facebook/react-native/issues/34425. This also adds unit tests to the `processFontVariant` function ensuring the style processing works as expected.
## Changelog
[General] [Added] - Add space-separated string support for fontVariant
Pull Request resolved: https://github.com/facebook/react-native/pull/34641
Test Plan:
This can be tested either through `processFontVariant-tests` or by using the following code:
```js
<Text
style={{
fontVariant: 'small-caps common-ligatures',
}} />
```
Reviewed By: javache
Differential Revision: D39423317
Pulled By: cipolleschi
fbshipit-source-id: ad971addb423ed338e178528a11fe9d456c03e6e
Summary:
This Diff adds a couple of APIs to the `react_native_pods.rb` file to simplify further the migration to the New Architecture for the iOS app.
Specifically, it aims to simplify [this](https://reactnative.dev/docs/next/new-architecture-app-intro#ios---build-the-project) steps by offering a RN-managed min version and creating the .xcode.env file for the user if it is missing.
## Changelog
[iOS][Added] - Add new API to simplify app migration
Reviewed By: cortinico
Differential Revision: D39469599
fbshipit-source-id: f0323e86c83c2731671fcd5bb4288071304bb43b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34670
Users can enable the New Architecture on iOS in two way: using the `RCT_NEW_ACRH_ENABLED` env variable or setting the `new_arch_enabled` flag when invoking the `use_react_native` function.
We need to set the `RCT_NEW_ACRH_ENABLED` even when the other method is used because we need to inject that flag into the codebase.
## Changelog
[iOS][Fixed] Make sure to turn on the `RCT_NEW_ACRH_ENABLED` flag
Reviewed By: cortinico
Differential Revision: D39430904
fbshipit-source-id: abb55642b4c72d7dec8b045fb4a43c1763f0ee0f
Summary:
This adds an example FlatList with nested children of both orientations. Debug text is shown for what is detected to be visible, and what is currently being rendered.
Changelog:
[Internal][Added] - Add Nested FlatList RNTester Example
Reviewed By: rshest
Differential Revision: D39466679
fbshipit-source-id: 5d6ce4adb9a862ca96b1a7b268b70101207d2980
Summary:
Small follow up to my template update. Using the namespace in the OnLoad.cpp
should prevent name clashing and make it easier to read.
Changelog:
[Android] [Changed] - Update the OnLoad.cpp to use the facebook::react namespace
Reviewed By: cipolleschi
Differential Revision: D39475773
fbshipit-source-id: 9c0748d37858196d4e8ea6674d9cfd6ef4eff1cd
Summary:
This diff removes the feature flag ReactFeatureFlags.enableSpannableCache and it's already disabled MC
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449840
fbshipit-source-id: 69a514b611c1179f2160a1bfd4c4199538738448
Summary:
Remove feature flag: ReactFeatureFlags.enableScrollEventThrottle
This feature has been disabled for a while
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449184
fbshipit-source-id: c5ad0d43462422d284e14302fb9d7b39aa37da70
Summary:
A previous change made the RuntimeAdapter contain a HermesRuntime (as opposed to an arbitrary JSI Runtime).
Now that it's known to be a HermesRuntime, expose that type information to the Inspector, so a runtime type check can be skipped (which is failing in some builds, despite the concrete type being what's expected).
Changelog: [internal]
Reviewed By: neildhar
Differential Revision: D39429109
fbshipit-source-id: ad5ae0604ac208da2002fd37e38d24319b45aebd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34671
I'm simplifying the template further by:
- Do not expose a configurable dynamic library name. Let's use `appmodules`
and still allow the users to configure it, if needed.
- Move all the initialization logic inside the `JNI_OnLoad` method
- Cleanup the `DefaultReactNativeHost` to don't require a dynamic library
name but just a boolean.
Changelog:
[Android] [Changed] - Further simplify the New App Template by don't requiring the dynamic library name
Reviewed By: cipolleschi
Differential Revision: D39462948
fbshipit-source-id: 737733fc263162a0baf3b7a451e48b8616679d3b
Summary:
This aligns the logic of setting style (width / height) and source of Android with iOS.
iOS handles nullish uris with set width and heigth by passing them through. Android did not.
## Changelog
[Android] [Fixed] - Align android image style / source logic with ios
Pull Request resolved: https://github.com/facebook/react-native/pull/34655
Test Plan:
```
<Image source={{width: 100, height: 100}} />
```
Before this Patch:
* iOS: Renders a blank image with 100x100
* Android: Renders a blank image with 0x0
After this Patch:
* iOS: Renders a blank image with 100x100
* Android: Renders a blank image with 100x100
Reviewed By: sammy-SC
Differential Revision: D39423391
Pulled By: cipolleschi
fbshipit-source-id: 997c06dea42e9b69fda12b678a1b82ad8319537f
Summary:
Fix invalid range "t-5" in string transliteration [iOS] for M1 pod install issue.
This should fix pod install error for M1 machines.
## Changelog
[iOS] [Fixed] - Fix ios pod install error
Pull Request resolved: https://github.com/facebook/react-native/pull/34636
Test Plan: Run pod install on M1 machine.
Reviewed By: sammy-SC
Differential Revision: D39423276
Pulled By: cipolleschi
fbshipit-source-id: 4ec95af7103395792facba0f93fd8de05a3fe78d
Summary:
The folder `/packages/react-native-codegen/android` is not existing anymore, I'm removing it.
## Changelog
[Internal] - Remove :packages:react-native-codegen:android from top level settings
Pull Request resolved: https://github.com/facebook/react-native/pull/34579
Test Plan: Will rely on a green CI
Reviewed By: cipolleschi
Differential Revision: D39440292
Pulled By: cortinico
fbshipit-source-id: 492722b1b697e0bf03cf2803b25fb9604cf0778a
Summary:
allow-large-files
When working on https://github.com/facebook/react-native/pull/34614, danger is failing because it doesn't share `node_modules` with the root directory where `typescript` is installed as we added it as a parser in our eslint config.
By setting `bots` as a yarn workspace, dependencies are all installed under the root `node_modules` folder and in local testing (detailed in test section) we no longer have the `typescript module not found` error. However, danger will continue to fail on https://github.com/facebook/react-native/pull/34614 as the `danger_pr` Github action runs from what's defined on `main`.
Once these changes land, I can rebase https://github.com/facebook/react-native/pull/34614 on it and danger's eslint should pass.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal][Fixed] - Add `bots` directory as a yarn workspace and update `danger_pr` Github action
Pull Request resolved: https://github.com/facebook/react-native/pull/34652
Test Plan:
To verify this fix I had to run:
```
react-native $ yarn && cd bots
react-native/bots$ yarn run danger pr https://github.com/facebook/react-native/pull/34614
```
which resulted in
```
❯ yarn run danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ lunaleaps/react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 12.78s.
```
Verified this also on another PR:
```
yarn run danger pr https://github.com/facebook/react-native/pull/34650
```
Reviewed By: NickGerleman
Differential Revision: D39435286
Pulled By: lunaleaps
fbshipit-source-id: 8c82f49facf162f4fc0918e3abd95eb7e4ad1e37
Summary:
Changelog:
[General][Fixed] In RN devtools, call that method, and then set component state to not inspecting.
Reviewed By: lunaruan
Differential Revision: D38852009
fbshipit-source-id: d14bd4cc4461f0f7ec4ae9cd6098a58eef3e6ab9
Summary:
Changelog:
[General][Fixed] - Currently selectNode doesn't work for Fabric. Passing the instance instead of a tag to `selectNode` works.
Reviewed By: lunaruan
Differential Revision: D38851141
fbshipit-source-id: 7640d0f31fb099346a4d8205981e262da6be4990
Summary:
PlatformColor should work on all *color style attributes on all platform.
Partially fixes https://github.com/facebook/react-native/issues/32942
## Changelog
[Android] [Fixed] - Support PlatformColor in borderColor
Pull Request resolved: https://github.com/facebook/react-native/pull/33544
Test Plan: Open rn tester (USE_FABRIC=false) platform color api examples. Without the changes to ViewProps.java, it will error out.
Reviewed By: lunaleaps
Differential Revision: D39413519
Pulled By: NickGerleman
fbshipit-source-id: 58962ba2956aa3df45144108eec194aedf23886b
Summary:
Changelog: [RNTester][Internal] - Add "move across" test for pointer events
This diff adds a new platform test ported from the wpt's [mousemove-across test](https://github.com/web-platform-tests/wpt/blob/master/uievents/order-of-events/mouse-events/mousemove-across.html) along with a rough port of the wpt's event recorder class which is made to work in a react component environment.
Reviewed By: lunaleaps
Differential Revision: D39221252
fbshipit-source-id: 16b2e03dbc71a2e83cc43af1e950803feaf6657b
Summary:
`getSize` should resolve with an array of `[width, height]` but this mock resolves with `{ width, height }`.
It should be `ReadOnlyArray<number>` instead of `{width: number, height: number}`
The native image loader call is [here](https://github.com/facebook/react-native/blob/main/Libraries/Image/NativeImageLoaderIOS.js#L18):
```js
+getSize: (uri: string) => Promise<$ReadOnlyArray<number>>;
```
but in the [jest setup file](https://github.com/facebook/react-native/blob/main/jest/setup.js):
```js
getSize: jest.fn(url => Promise.resolve({width: 320, height: 240})),
```
My tests were failing on `Image.getSize()` - `TypeError: Invalid attempt to destructure non-iterable instance.`
I managed to trace this down to this object being returned by the Jest mock - looks like it's returning a size object instead of a dimensions array.
## Workaround
If you are hitting this issue, you can work around this mock by using:
```js
ReactNative.NativeModules.ImageLoader.getSize = jest.fn((_) => Promise.resolve([320, 240]));
```
## Changelog
[JavaScript] [Changed]: Changed the mocked return value of `ImageLoader.getSize` to be `[320, 240]` instead of `{ width: 320, height: 240 }`
Pull Request resolved: https://github.com/facebook/react-native/pull/34653
Test Plan: TBD? I think a test with `Image.getSize(path)` will cover it. That's where I hit the error with the ios-specific imageLoader's getSize method.
Reviewed By: robhogan
Differential Revision: D39413522
Pulled By: NickGerleman
fbshipit-source-id: 7f18d7acde0cf94da0b4aec8fe2d0cad3fb0cc55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34666
This diff updates the new app template and reduces the amount of C++ code in user space.
From now on users will have to only:
1. Create a CMakeLists.txt file
2. Create an OnLoad.cpp file with the Modules/Components they want to provide.
Changelog:
[Android] [Changed] - Update the template to Reduce the amount of C++ code in user space for New Architecture
Reviewed By: cipolleschi
Differential Revision: D39381762
fbshipit-source-id: 7309b6c61ba9ddd8856cb4aaa6d923ddd816741c
Summary:
This diff reduces the amount of C++ code in user space by:
- Moving all the C++ implementation of the .defaults package inside a `react_newarchdefaults` shared library
- Exposing only the entrypoint logic inside the RN-Tester's `OnLoad.cpp` file.
Changelog:
[Android] [Changed] - Reduce the amount of C++ code in user space for New Architecture
Reviewed By: cipolleschi
Differential Revision: D39381820
fbshipit-source-id: 9c4b5596b67b5a7ee58824319c80e325348ed06c
Summary:
https://www.internalfb.com/T131530362
We are testing the New App template in CircleCI.
For Android we test the combination of Debug/Release and Old/New Architecture, and always use the Hermes engine.
We don't test the JSC engines (in iOS this is already happening).
We're not automatically testing that we can create a new project with JSC, forcing release managers to do it manually.
## Changelog
[Android] [Added] - Automatic testing of the new project template with the JSC engine.
Pull Request resolved: https://github.com/facebook/react-native/pull/34664
Test Plan:
- Open the circle-ci dashboard
- Verify there are now 8 jobs adeed to the pipeline:
```
test_android_template-Debug-Hermes-false
test_android_template-Debug-Hermes-true
test_android_template-Debug-JSC-false
test_android_template-Debug-JSC-true
test_android_template-Release-Hermes-false
test_android_template-Release-Hermes-true
test_android_template-Release-JSC-false
test_android_template-Release-JSC-true
```
- Verify they are all passing.
Reviewed By: cortinico
Differential Revision: D39426388
Pulled By: vincenzovitale
fbshipit-source-id: e5d606b1cc3ace53f8dab0f7d6d7d06ab11a2b46
Summary:
Changelog: [Internal] - Stop dispatching pointer events when a child view has indicated it wants to handle a native gesture.
In discussion and alignment with web standards, we've decided to not dispatch any pointer events during a native gesture.
Currently, on ACTION_HOVER_MOVE, we remove child views of the native gesture handling view and continue dispatching onPointerMove for ancestor views. This change removes this logic and won't dispatch a onPointerMove event at all.
For all other MotionEvent actions, this is already the case.
Also adding an example in RNTester that involves a scrollView (which handles gestures during scrolling)
Reviewed By: javache
Differential Revision: D39377157
fbshipit-source-id: cb0a719f67136e31b68d6f6e794fee10b256bf21
Summary:
Jest 27 [flips defaults](https://jestjs.io/blog/2021/05/25/jest-27#flipping-defaults), making "modern" fake timers (ie, `sinonjs/fake-timers`) the default, over "legacy", which we currently use.
We're not quite ready for modern timers yet, partly due to Promise polyfills (https://github.com/facebook/react-native/pull/34659), and also some internal issues with specific tests.
This makes our use of legacy timers explicit in preparation for an update to Jest. A switch to modern timers may follow later.
Changelog:
[Internal][Changed] - Prepare for Jest 27+ by making legacy fake timer use explicit
Reviewed By: jacdebug
Differential Revision: D39383719
fbshipit-source-id: 6a3dc6f8547cc76f7702a5a39c9b30a184303f17
Summary:
When I moved the C++ file around I only updated the Android-prebuilt.cmake
I haven't update the Android.mk equivalent. I'm doing it here.
Changelog:
[Internal] [Changed] - Update Android-prebuilt.mk to use the correct paths for turbomodule & fabricjni
Reviewed By: cipolleschi
Differential Revision: D39397567
fbshipit-source-id: f9f412ef4a9402f9528414af24eac06a0657f6f5
Summary:
This test currently uses `jest.runAllTicks()` to execute cached, immediately-resolving promises, under Jest "legacy" timers (the RN default) - this works only because [we polyfill Promise](https://github.com/facebook/react-native/blob/main/jest/setup.js#L24) using a userland JavaScript implementation that internally uses mocked-out timer functions.
Here we change to a more universal approach by adding a new microtask/promise to the end of the queue and awaiting it.
This allows us to remove our Promise polyfill from Jest setup (to follow).
Changelog:
[Internal][Fixed] - Prepare `LogBoxLog-test.js` for native promises
Reviewed By: huntie
Differential Revision: D39418413
fbshipit-source-id: 1384ef385b1e10261754513369af8997d296ffea
Summary:
This test was causing uncaught promise rejections, because the mocked `symbolicateStackTrace` in this test returns a different type from the real one, causing `LogBoxSymbolication`'s unawaited, cached promises to reject.
This wasn't picked up as a test failure because our `promise` polyfill silently swallows uncaught rejections, but it does cause a failure if we use native promises in tests.
Changelog:
[Internal][Fixed] - Fix LogBoxSymbolication-test.js
Reviewed By: huntie
Differential Revision: D39418412
fbshipit-source-id: 0be8f1551c4a58dc47faf1597caf47271af40af2
Summary:
This PR adds support for number values for `fontWeight` as requested in https://github.com/facebook/react-native/issues/34425.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Added] - Added support for number values in fontWeight.
Pull Request resolved: https://github.com/facebook/react-native/pull/34598
Test Plan:
```js
<Text style={{ fontWeight: 900, color: 'red' }}>
Hello World
</Text>
```
Reviewed By: jacdebug
Differential Revision: D39268920
Pulled By: cipolleschi
fbshipit-source-id: 9bb711677bf173f9904b74f382659042856efd83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34514
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 3/n - Move RCTTurboModuleRegistry.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirety of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
Reviewed By: RSNara
Differential Revision: D38971168
fbshipit-source-id: 3b1b23d422f965a5a14bc4178d32b844906f2c8b
Summary:
This adds the `id` prop to `Text`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `nativeID` prop to `id`. As this components are inherited by others this also adds the `id` prop support to `Image`, `TouchableBounce`, `TouchableHighlight`, `TouchableOpacity` and `TextInput`.
This PR also adds android tests ensuring that the `id` property is passed to the native view via the `nativeID` prop, these tests were based on the existing `nativeID` tests ([NativeIdTestCase.java](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/androidTest/java/com/facebook/react/tests/NativeIdTestCase.java)).
## Changelog
[General] [Added] - Add id prop to Text, TouchableWithoutFeedback and View components
Pull Request resolved: https://github.com/facebook/react-native/pull/34522
Test Plan: Ensure that the new `id` prop android tests pass on CircleCI
Reviewed By: lunaleaps
Differential Revision: D39089639
Pulled By: cipolleschi
fbshipit-source-id: 884fb2461720835ca5048004fa79096dac89c51c
Summary:
Changelog: [internal]
This brings back a fix for ScrollView on iOS that we removed because we thought it was no longer necessary, but it actually is.
Reviewed By: jacdebug
Differential Revision: D39382967
fbshipit-source-id: f052b4fb899f4e60e8c530990caf07344a907c43
Summary:
1. In some situation (I don't know exactly how it is triggered but I found that during porting it to `react-native-windows`), `ExportNamedDeclaration.exportKind` is missing. Just skip the checking to `exportKind` because the rest of the checking is sufficient without reading this field.
2. Add `TSParenthesizedType` to module codegen in TypeScript, so that type `(T)` is treated like `T`.
## Changelog
[General] [Changed] - codegen: support TypeScript type `(T)` for turbo module codegen (module only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34621
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: RSNara
Differential Revision: D39322001
Pulled By: cipolleschi
fbshipit-source-id: 1855711da7062a065c05a10f275e26baa88cf75f
Summary:
changelog: [internal]
preemtive view allocation has been disabled on iOS for over a year. We kept the code in but didn't do anything with it. This diff removes the code and related mobile config.
Post where we decided to turn preemtive view allocation off: https://fb.workplace.com/groups/215742978987717/permalink/832644567297552/
jest_e2e[run_all_tests]
Reviewed By: mdvacca
Differential Revision: D37922589
fbshipit-source-id: 1af8949cbbd9d48a2d80ca238b280178cbe2ead5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34619
When it comes to migrate existing libraries, users needs to update their .podspec files with a bunch [of changes](https://reactnative.dev/docs/0.69/new-architecture-library-ios#add-folly-and-other-dependencies).
This diff groups those changes in a single function, so that contributors can just invoke that function to prepare their dependencies.
## Changelog
[iOS][Changed] - Add function to simplify podspecs
Reviewed By: cortinico
Differential Revision: D39312203
fbshipit-source-id: ed631839e07d472a1fdcba33310f9b1d94fe2fd7
Summary:
For some reason the turbomodule example inside RN Tester was not enabled by default. I'm enabling it.
Changelog:
[Internal] - Always enable TurboModuleExample for RN Tester
Reviewed By: cipolleschi
Differential Revision: D39381821
fbshipit-source-id: 711c20a51a2f3b274f1b9396d00898b0f60a6f86
Summary:
Pull request https://github.com/facebook/react-native/issues/34251 only partially worked because I didn't notice that there is ` 1` after the snapshot name. In this change I fixed the issue and find out there is one case that Flow and TypeScript parser generate different result.
It is expected since the test inputs are different. TypeScript removes one member because there is no `{...X, ...}` type in TypeScript. We could make the codegen support intersection type and rewrite it to `X & {...}`, but this will not be included here anyway.
## Changelog
[General] [Changed] - codegen: ensure equivalent Flow and TypeScript TM definition generates the same output
Pull Request resolved: https://github.com/facebook/react-native/pull/34620
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: NickGerleman
Differential Revision: D39321965
Pulled By: cipolleschi
fbshipit-source-id: aec60f5c9c18323cbd833bf5705af544d7db2e73
Summary:
With the IDE autocompletion now working \o/ I was able to apply some suggestions
to the Kotlin code I wrote inside the .defaults package (like remove redudant qualifiers and similar).
Changelog:
[Internal] [Changed] - Cleanup the Kotlin code in the .defaults package
Reviewed By: cipolleschi
Differential Revision: D39348983
fbshipit-source-id: b443a6be179c85d2a4f4293051c4f26af93eb5f1
Summary:
This adds a a couple of tests to run existing behavior where VirtualizedList avoids batched renders until it has seen scroll metrics when the list is not initialized to the zero position.
Changelog:
[Internal][Added] - Add VirtualizedList tests for handling non-zero initialScrollIndex before scroll metrics
Reviewed By: yungsters
Differential Revision: D39247250
fbshipit-source-id: 530f58f9c7421949c388048c376fc5b0ab7835d9
Summary:
Changelog: [Internal] Move Bridge-only constants into a separate file
- Move Bridge only constants from RCTBridge.h into RCTBridgeConstants.h.
- Move shared constants from RCTBridge.h into RCTConstants.h.
This way, new architecture does not need to import RCTBridge.h just for the constants.
Reviewed By: sammy-SC
Differential Revision: D39085713
fbshipit-source-id: 40177cbed72a326b40ec448c98751d1dd3464504
Summary:
In an app using `UIScene`, `Alert` no longer pops up because the window
that gets created are not attached to a scene.
## Changelog
[iOS] [Fixed] - Fix `Alert` not showing in an app using `UIScene`
Pull Request resolved: https://github.com/facebook/react-native/pull/34562
Test Plan: Use the test plan in https://github.com/facebook/react-native/issues/29295. This should not regress that fix.
Reviewed By: cipolleschi
Differential Revision: D39276976
Pulled By: lunaleaps
fbshipit-source-id: e48e985ed4abec77d6f01a6c17292d664ed88f13
Summary:
This PR aims to add support for objectFit a partial equivalent to the resizeMode style and prop of Image.
## Changelog
[General] [Added] - Add support for objectFit style of Image.
Pull Request resolved: https://github.com/facebook/react-native/pull/34576
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. See the Object Fit section.

Reviewed By: rickhanlonii
Differential Revision: D39261176
Pulled By: jacdebug
fbshipit-source-id: 1eefd76b6c11ed5fc52b2c524ad78c91051077f6
Summary:
Changelog: [internal]
This replaces all direct references to the `ReactNative` module (which is the Paper renderer) to `RendererProxy` which would select between Paper and Fabric correctly.
The implementation of these functions is exactly the same right now.
As per the removal of the fix for T55744311 in `ScrollView`, I verified this doesn't cause any issues in the screen where it failed before.
Reviewed By: javache
Differential Revision: D39270691
fbshipit-source-id: 03882748fe4b754b9a2c5e9d4c4f003b94ed49ef
Summary:
This replaces all direct references to `ReactNative` within the `react-native` package to use `findNodeHandle` with a reference obtained from `RendererProxy`, which will allow us to select the correct renderer.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39270689
fbshipit-source-id: a39875281ba7b7b1b00128564124b6adcacebc4d
Summary:
This diff creates a proxy module to interact with the React Native renderer. The goal of this proxy is to decouple usages of several functions (e.g.: `findNodeHandle`, etc.) from the actual renderer used in an app. This way, we can easily switch between renderers without having to change code depending on it.
This will be useful to remove a specific renderer from an app bundle when it's no longer used (e.g.: Paper on the Facebook App).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39205975
fbshipit-source-id: 05289c0c3c8cd26d81aa1d2163097c73ec40c6ad
Summary:
The `Systrace` module implements a polyfill for the User Timing API that's:
1. Incompatible with the Web standard. This polyfill expects `performance.mark` and `performance.measure` to be used exactly like `Systrace.beginEvent` and `Systrace.endEvent` respectively. If not used like those functions, they throw an error at runtime, which is really bad.
2. Never actually used. See below.
This polyfill is only installed if we're actually profiling on startup:
https://www.internalfb.com/code/fbsource/[4d888a933920]/xplat/js/react-native-github/Libraries/Core/setUpSystrace.js?lines=17-21
While the only code that we have that uses this API is actually not installed if we're profiling:
https://www.internalfb.com/code/fbsource/[4d888a933920]/xplat/js/react-native-github/Libraries/Core/setUpDeveloperTools.js?lines=20-21
This should be safe to remove then.
We have plans to add proper support for this API in the short term, so this also gets out of the way of doing that.
Additionally, installing this polyfill was the only reason why we had `setupSystrace`, so we can get rid of that too :)
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39210813
fbshipit-source-id: a90b6237c311d2157069b41975d10b33f1f464ef
Summary:
This unifies the Android only `autoComplete` and the iOS only `textContentType` TextInput props with the web `autoComplete` values as requested on https://github.com/facebook/react-native/issues/34424. I left the `textContentType` prop and the current supported `autoComplete` values untouched in order to avoid having a breaking change. This also updates RNTester to include test cases using the new `autoComplete` values
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Unify TextInput autoComplete and textContentType props
Pull Request resolved: https://github.com/facebook/react-native/pull/34523
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Text Auto Complete` section
https://user-images.githubusercontent.com/11707729/187118267-3b509631-7b84-47b7-a580-567a7f5b483f.mov
Reviewed By: NickGerleman
Differential Revision: D39104545
Pulled By: cipolleschi
fbshipit-source-id: a0d4b1b9ab336854a741a9efe4a62c3da0b5c0f4
Summary:
This adds `aria-live` alias for `accessibilityLiveRegion`, it unifies aria-live and accessibilityLiveRegion and also maps `aria-live='off'` to `accessibilityLiveRegion='none'` as requested on https://github.com/facebook/react-native/issues/34424
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General][Added] - Added aria-live alias for accessibilityLiveRegion.
Pull Request resolved: https://github.com/facebook/react-native/pull/34555
Test Plan:
```js
<View aria-live="polite">
<Text>Clicked {this.state.count} times</Text>
</View>
<View aria-live="off">
<Text>Clicked {this.state.count} times</Text>
</View>
```
Reviewed By: cipolleschi
Differential Revision: D39206291
Pulled By: jacdebug
fbshipit-source-id: fd2019e7047ff7ff6133fed39f1a70b5a9396f89
Summary:
The keys of the current debian version expired again. This PR is an attempt to use a different version
## Changelog
[General] [Fixed] - Update debian version
Pull Request resolved: https://github.com/facebook/react-native/pull/34634
Test Plan: CircleCI is green
Reviewed By: sammy-SC
Differential Revision: D39350344
Pulled By: cipolleschi
fbshipit-source-id: 6c77cc60cbc56a9fe8362ffa0472f96bce58b28e
Summary:
Noticed this marker was not properly ended in the case where an early return happens. The fact that that early return is happening there is problematic too, so added a warning to follow-up on.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39271917
fbshipit-source-id: 86dd5b1a46978629584f7cb0d615f2ad99d5a2f8
Summary:
FillRateHelper accesses frame metrics based on passed state/cellsAroundViewport on scroll. cellsAroundViewport may be [0, -1] for no items. Usually this is captured by the check that item count is zero, but it is possible to have items without yet expanding state to render the items. This adds a check to bail early if we are not yet rendering any viewport-related cells.
Also renamed "state" to "cellsAroundViewport" for more consistent naming with the new list, where it is no longer the only state.
Reviewed By: javache
Differential Revision: D39345705
fbshipit-source-id: 198ab46ff2c8e8fe64076c9150edd4914dd745d7
Summary:
UIImplementation(Provider) is not compatible with the new renderer (Fabric) and the relevant constructors have been marked deprecated for a while. While ReactInstanceManagerBuilder creates a default instance, it's not even used by CoreModulesPackage.
Changelog: [Android][Removed] Removed deprecated UIImplementationProvider
Reviewed By: NickGerleman
Differential Revision: D39271916
fbshipit-source-id: 20a3b02843ea9a2ba4bfc1352037239febbafc64
Summary:
Currently for codegen to work for a library on iOS, it needs to be located
inside `node_modules`. This patch adds support for libraries defined in
`react-native.config.js`.
This is useful when developing libraries as well as monorepos where the library
may exist outside of the `node_modules`.
Example:
```js
// react-native.config.js
const path = require('path');
module.exports = {
dependencies: {
'react-native-library-name': {
root: path.join(__dirname, '..'),
},
},
};
```
## Changelog
[Internal] [Added] - Support custom library paths in `react-native.config.js` for codegen on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/34580
Test Plan:
Tested on a test application and ensured that codegen finds the library specified in `react-native.config.js`
https://user-images.githubusercontent.com/1174278/188141056-bce03730-2a13-4648-8889-9727aaf2c3c4.mp4
I have also added a basic test case for this scenario.
Reviewed By: jacdebug, cortinico
Differential Revision: D39257919
Pulled By: cipolleschi
fbshipit-source-id: 131189f1941128a59b9b1e28af61a9038eb4536b
Summary:
This adds support for the `userSelect` style attribute, mapping the already existing selectable attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android and TestExample.ios on the RNTester in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add support for `userSelect` style
Pull Request resolved: https://github.com/facebook/react-native/pull/34575
Test Plan:
- open the RNTester app and navigate to the Text page
- Check the `Selectable Text` through the Selectable text section
<Image src="https://user-images.githubusercontent.com/22423684/188112863-65acd145-76b0-47ba-8bc6-f72298077096.png" height="600" width="300" />
Reviewed By: yungsters
Differential Revision: D39252798
Pulled By: jacdebug
fbshipit-source-id: f7fabf20ee68778d75461f511c56f94d0d756d9c
Summary: VirtualizedList would more gracefully handle out of range cells than VirtualizedList_EXPERIMENTAL, which treats it as an invariant violation. D39244112 (https://github.com/facebook/react-native/commit/7aa203beda3cd358703c2fa535ed045771761612) attempted to fix an issue where recalculation of cells around viewport can include out of range cells, but it is still showing up later. This change adds a bounds check to the remaining branch we control, and an assertion that `computeWindowedRenderLimits` is not returing something out of range to discover if that is the cause.
Reviewed By: yungsters
Differential Revision: D39267445
fbshipit-source-id: 64c99da28b5b01ef61784079b586e355f73764a1
Summary:
Non-integer `initialScrollIndex` or values to `scrollToIndex` would produce a reasonable result, with the caveat that it always falls back to layout estimation (will only be correct when all items are the same size), and breaks if getItemLayout() is supplied. It has usage though, so this diff adds proper support for non-integer scrollIndex, to offset a given amount into the length of the specific cell.
This overlaps a bit with the optional `viewOffset` and `viewPosition` arguments in `scrollToIndex`, but there isn't really the equivalent API for `initialScrollIndex`.
Changelog:
[General][Added]- Add proper support for fractional scrollIndex in VirtualizedList
Reviewed By: yungsters
Differential Revision: D39271100
fbshipit-source-id: 4d93887eed4497e9f6abcd1a6117ac7fdaebf2b1
Summary:
D38460203 (https://github.com/facebook/react-native/commit/e6ef0836c132d6b798e2ff1fc1e1a66c7e238e0b) was reverted because it broke OSS, the root cause is that OSS doesn't have MapBuffer module.
Fixed the issue in this diff by moving MapBuffer usage to fb internal class (FBReactModule) and will re-land.
Changelog:
[iOS][Changed] Replace Folly with MapBuffer for passing js error data
Reviewed By: sammy-SC
Differential Revision: D39210957
fbshipit-source-id: dda0e8c55dbd13bc96310e10a3b09ea53978e8bc
Summary:
This PR is for adding the support for `crossOrigin`, `referrerPolicy`, `width`, `height` and `srcSet` props to Image Component and mapping the `src` prop to `source.uri` of Image Component for the issue https://github.com/facebook/react-native/issues/34424. An example is also added in the RNTester ImageExample.
## Changelog
[General] [Changed] - Map the `src` prop to `source.uri` prop in Image Component.
[General] [Added] - added `crossOrigin`, `referrerPolicy`, `width`, `height` and `srcSet` props to Image Component.
Pull Request resolved: https://github.com/facebook/react-native/pull/34481
Test Plan:
1. Navigate to Image Component Example in the RNTester app.
2. Contains an example of the Image component using the `src` and `srcSet` prop.
3. For headers, inspect the Image request using Flipper.
<img src="https://user-images.githubusercontent.com/32268377/186153246-d7b72ce3-e082-46d9-87d1-aefacd3af34f.png" height="500" />
Reviewed By: christophpurrer
Differential Revision: D38982041
Pulled By: cipolleschi
fbshipit-source-id: dd6594e39b8f3b36cfcdafa35695254034f1fb7f
Summary:
## Summary
This PR adds expanded support for CSS Colors, as requested on https://github.com/facebook/react-native/issues/34425. It updates the current regex used to match the functional notation for colors, e.g `rgb()` to accept space as a valid separator between values as specified on [CSS Color Module Level 4](https://www.w3.org/TR/css-color-4/) definition. This also adds support for the `hwb` notation.
## Changelog
[General] [Added] - Add expanded support for CSS Colors
Pull Request resolved: https://github.com/facebook/react-native/pull/34600
Test Plan: We can test different color scenarios through the new test cases added to the already existing normalizeColor-test.js
Reviewed By: necolas
Differential Revision: D39269360
Pulled By: cipolleschi
fbshipit-source-id: 449158d17256bbab8bd9fd0da29245660225fb92
Summary:
The `JSDevSupport` module is incompatible with Fabric. Given it's not used internally and it's undocumented in OSS, we decided to remove it altogether.
Changelog: [Internal]
Reviewed By: javache, nlutsenko
Differential Revision: D39305892
fbshipit-source-id: 82455701a0b9ba83e6f971fc774280dceb2b22e0
Summary:
This adds the ` aria-hidden` prop to `Pressable`, `TouchableBounce`, `TouchableHighlight`, `TouchableNativeFeedback`, `TouchableOpacity`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424, being an alias `importantforAccessibility='no-hide-descendants'` on Android and an alias for `accessibilityElementsHidden` on iOS. This PR also updates RNTester AccessibilityExample in order to facilitate the manual QA.
## Changelog
[General] [Added] - Add aria-hidden prop to Pressable, View and Touchables components
Pull Request resolved: https://github.com/facebook/react-native/pull/34552
Test Plan:
1. Open the RNTester app and navigate to the Accessibility page
2. Test the `aria-hidden` prop through the `View with hidden children from accessibility tree` section, this can be tested either by enabling Voice Over if you're using a real device or through the Accessibility Inspector if you're using a simulator
https://user-images.githubusercontent.com/11707729/187814455-6937e33e-7edd-434e-b7d3-ee6c03f635ca.mov
Reviewed By: NickGerleman
Differential Revision: D39206245
Pulled By: jacdebug
fbshipit-source-id: 551dc671fbcedc824f253e22b8d7753c466838c7
Summary:
This PR runs the Jest test for the Codegen package in CI.
## Changelog
[General] [Added] - Run Codegen Tests in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/34596
Test Plan: CircleCI should show a new job for the tests. The job should be green.
Reviewed By: NickGerleman
Differential Revision: D39275645
Pulled By: cipolleschi
fbshipit-source-id: 29133c933f134802029406ff255b62d27681c8ff
Summary:
During the CoreContributor summit, we discovered that the `react-native-codegen` tests cannot be executed in the OSS due to this [issue with Jest](https://github.com/facebook/jest/issues/2567).
This PR moves the required variables inside the proper closure so that we can run tests in the OSS.
## Changelog
[General] [Fixed] - Enable the `react-native-codegen` tests in the OSS.
Pull Request resolved: https://github.com/facebook/react-native/pull/34594
Test Plan:
1. Run `yarn install` in the `react-native-codegen` folder.
2. Run `yarn jest`, see the test fail.
3. Apply the changes in this diff.
4. Run `yarn jest`, see the test pass.
Reviewed By: cortinico
Differential Revision: D39259164
Pulled By: cipolleschi
fbshipit-source-id: 7c4c0a7baa3c9b5e90a7ef75a37a0ec9d1b89db0
Summary:
changelog: [internal]
Add more clang tidy rules to prevent common class of bugs.
Reviewed By: javache
Differential Revision: D39245194
fbshipit-source-id: 5521c5c4653d7005b96ebba494e810ba5075afbc
Summary:
This PR adds some tests to verify that we can build the template in every Debug configuration using Flipper and without Flipper.
## Changelog
[iOS] [Added] - Add CircleCI tests to verify that we can run the Template with and without Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/34595
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D39262137
Pulled By: cipolleschi
fbshipit-source-id: dae45b106cd13fb69442ea216005cee114d861f4
Summary: VirtualizedList would more gracefully handle out of range cells than VirtualizedList_EXPERIMENTAL, which treats it as an invariant violation. This attempts to fix an issue where recalculation of cells around viewport can include out of range cells.
Reviewed By: rshest
Differential Revision: D39244112
fbshipit-source-id: 20fe6ea552035061d9d00720fcab77b29a785771
Summary:
# WIP
Adds changelog for new release.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.0
Pull Request resolved: https://github.com/facebook/react-native/pull/34202
Test Plan: N/A
Reviewed By: cortinico, cipolleschi
Differential Revision: D39258933
Pulled By: dmytrorykun
fbshipit-source-id: 3aa19301b47aa8cacd5afe35015c2820e96ab4fa
Summary:
This adds `pointerEvents` style which is equivalent to `pointerEvents` prop as requested in https://github.com/facebook/react-native/issues/34425
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Added] - Added pointerEvents style equivalent to pointerEvents prop
Pull Request resolved: https://github.com/facebook/react-native/pull/34586
Test Plan:
```
<View
style={{
pointerEvents: 'none'
}}
>
</View>
```
Reviewed By: cipolleschi
Differential Revision: D39252830
Pulled By: jacdebug
fbshipit-source-id: 94f265a6b6940a4371e7985d5de3b8143693e069
Summary:
While working on https://github.com/facebook/react-native/pull/34552 I noticed that a couple of words inside the Accessibility example files were misspelled.
## Changelog
[Internal] [Fixed] - Fix accessibility example typos
Pull Request resolved: https://github.com/facebook/react-native/pull/34559
Test Plan: Shouldn't require much testing as this is just fixing some typos inside Accessibility example
Reviewed By: cipolleschi
Differential Revision: D39252742
Pulled By: jacdebug
fbshipit-source-id: 0d3860f438c55d58d0816b9ae65e52925864c8d3
Summary:
This PR should fix the issues introduced by commit c34659a5d3.
The problem is that `Collections.emptyList` creates a `List<Object>` which is not compatible with the `List<TargetView>` type.
## Changelog
[Android] [Fixed] - Make Android CI build again.
Pull Request resolved: https://github.com/facebook/react-native/pull/34573
Test Plan: test_buck and the "test Docker android" must be green.
Reviewed By: cipolleschi
Differential Revision: D39235674
Pulled By: cortinico
fbshipit-source-id: 574338e74aeb4635c67d91de28780fb784c9f405
Summary:
Changelog: [Internal] - Key cached values between different MotionEvents by pointerId.
Currently the implementation uses one cached list and array to store the last hitPath and event coordinates. We use these to determine if we've entered or left any views.
With more pointers, we need to be tracking these values for each pointer.
As well, clean up usage of `mLastTargetCoordinates`. This doesn't need to be a global as its an array that's updated by reference in `findTargetPathAndCoordinatesForTouch`
Reviewed By: vincentriemer
Differential Revision: D39152528
fbshipit-source-id: 28c18629bf974f41950401c7726a4757ad43ac28
Summary:
Changelog: [iOS][Internal] - Rework button/buttons handling on pointer events & add a new test checking for move events on chorded mouse button presses
This is a larger diff that largely stems from implementing a new pointer event platform test about chorded mouse button presses (adapted from https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointermove_on_chorded_mouse_button.html). In order to implement this test I added a new method, `step`, to an async test instance to allow you to run ad-hoc assertions labeled by the async test (like it's done in the original web platform test).
Once implementing the test I also discovered my current logic for handling the `button` and `buttons` properties was insufficient so I reworked it to handle more/most cases by making the `button` property instead determined by the change in the `buttons` property. This largely works but unfortunately due to what seems to be a bug in UIKit, chorded pointer "up" events receive the wrong button mask values so it's currently impossible to get this test fully passing on iOS. I've since submitted a bug report to Apple but my hopes aren't high that it will be focused on since it's such a niche issue.
Reviewed By: lunaleaps
Differential Revision: D38951159
fbshipit-source-id: 426b7cf7930ed8329151382fafee487493e568de
Summary:
Changelog: [Internal] - Fix more pointer event platform tests.
* Fix the coordinate system to use DIP
* Set some properties for when pointerType="mouse"
Reviewed By: vincentriemer
Differential Revision: D39184713
fbshipit-source-id: d86f798f3e0a377ff1c159fb308329a2c9ae03ff
Summary:
Changelog: [Internal] - Refactor JSPointerDispatcher to group secondary actions (pointer_up, pointer_down) to use same logic and emit non-direct events
This diff re-arranges some code and re-uses some logic for different MotionEvent types.
Specifically, before our code for handling a motionEvent looked like
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) {
handleHoverEvent(event)
}
if (event is ACTION_DOWN) {
// logic for dispatching down, enter, over
}
if (event is ACTION_POINTER_DOWN) { // this represents any secondary pointer going down
// logic for dispatching down
}
if (event is ACTION_MOVE) {
// logic for dispatching touch move
}
if (event is ACTION_UP) {
// logic for dispatching up, out, leave
}
if (event is ACTION_POINTER_UP) { // this represents any secondary pointer going up
// logic for dispatching up
}
....
}
```
now, we've refactored it to be like:
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) { // Still keep this as separate because it does some special things. Will refactor in follow-up diff
handleHoverEvent(event)
}
switch() {
case ACTION_DOWN or ACTION_POINTER_DOWN:
// do same logic
break;
case ACTION_UP or ACTION_POINTER_UP:
// do same logic
break;
case ACTION_MOVE:
// do same logic, we will want to converge this logic with HOVER_MOVE, todo in a follow-up
break;
...
}
....
}
```
This refactor adds the functionality of `enter, over, out, leave` to secondary pointer events in which they weren't fired before.
Reviewed By: vincentriemer
Differential Revision: D39142820
fbshipit-source-id: 8b89db6dc22f24583f8c14dbb8392d4dc8ff6e4d
Summary:
Changelog:
[General][Added] - Added an overlay similar to Inspector.js that allows directly selecting elements on RN from React DevTools
This diff updates DevToolsHighlighter into DevToolsOverlay. It now also allows DevTools user to select an element to inspect directly from DevTools.
Depends on https://github.com/facebook/react/pull/25111 to work.
TODOs:
- Currently once an element selected on RN, the inspector toggle isn't turned off automatically.
- Fabric support depends on https://github.com/facebook/react/pull/25118
Reviewed By: lunaruan
Differential Revision: D38815494
fbshipit-source-id: 7e1e3a78f6594960b5dfaec142bafd3ca4b146af
Summary:
Changelog: [Internal] - Make sure `onChildEndedNativeGesture` is called for view managers that call `onChildStartedNativeGesture`
This affects `JSTouchDispatcher`, `JSPointerDispatcher` as they track what view is reporting native gesturing handling.
This is a bug that view managers never shared the fact that they've stopped managing a native gesture. Both `JSTouchDispatcher`, `JSPointerDispatcher` get around this by manually resetting their internal flag on ACTION_DOWN event (we will get rid of this in a later diff)
Reviewed By: javache
Differential Revision: D38850609
fbshipit-source-id: ef4afb591249bb621f42667608dc1ef20424b65c
Summary:
This PR is the dual of the Matrix Tests we added to the Android Template a couple of weeks ago. It adds the same tests to iOS, to verify that the template builds with both architectures and with both configurations (Debug/Release).. And it tests that the template works with both Hermes and without it.
## Changelog
[iOS] [Added] - Test iOS template with both architectures and configurations
Pull Request resolved: https://github.com/facebook/react-native/pull/34469
Test Plan: CI is green in all the 8 new jobs.
Reviewed By: hramos, cortinico
Differential Revision: D39087876
Pulled By: cipolleschi
fbshipit-source-id: 1205b2339bac87cf11b4f356a2e50e1e93ba52bc
Summary:
Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled
and unfortunelly there isn't much we can do on the native side to fix it.
Closes https://github.com/facebook/react-native/issues/31484
Closes https://github.com/facebook/react-native/issues/29974
## Changelog
[iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34503
Test Plan:
**On iOS 14+**
1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions".
2. Open the RNTester app and navigate to the KeyboardAvoidingView page
3. Focus and blur inputs and observe the keyboard behaving correctly
https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov
Reviewed By: jacdebug
Differential Revision: D39055213
Pulled By: cipolleschi
fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f
Summary:
This adds the `tintColor` prop to the Image component to replace the non-standard `style.tintColor` as requested on https://github.com/facebook/react-native/issues/34424, so that React Native for Web does not have to deopt styles for Image rendering. I didn't have to change anything on Android as `tintColor` was already being passed down to the native component as a prop. This PR also updates RNTester ImageExample in order to facilitate the manual QA.
## Changelog
[General] [Added] - Add tintColor prop to Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/34534
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. Test the `tintColor` prop through the `Tint Color` section
https://user-images.githubusercontent.com/11707729/187444761-ce5fd949-89f3-4d73-9717-31d035c6ee6b.mov
Reviewed By: necolas
Differential Revision: D39133292
Pulled By: jacdebug
fbshipit-source-id: 314e0ed47ab65366153e730667a31554bc2b6aa7
Summary:
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.
- Need to call `registerForProfiling` to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
- `runInExecutor` didn't work and call its callback. Not sure exactly why, but using `executor_->add` like we do in a lot of other places to run code on the executor works.
- `GetHeapUsageRequest` seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. `GetHeapUsageRequest` doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use `runInExecutor` instead.
## 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] - Fix hermes profiler
Pull Request resolved: https://github.com/facebook/react-native/pull/34129
Reviewed By: cortinico
Differential Revision: D37669469
Pulled By: philIip
fbshipit-source-id: 6cf3b2857ac60b0a1518837b9c56b9c093ed222f
Summary:
`JNIEnv`'s `FindClass(..)` function takes the classes in the standard
`foo/bar/Baz` class specification (unless they're special, like arrays).
Specifying them with `Lfoo/bar/Baz;` results in a
`ClassNotFoundException` being raised -- which is especially unhelpful
when intending to re-throw an exception.
The docs for `JNIEnv#FindClass(..)` can be found [here][jnienv].
[jnienv]:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#:~:text=The%20name%20argument,java/lang/String%22
## Changelog
[Android] [Fixed] - Correctly resolve classes with FindClass(..)
Pull Request resolved: https://github.com/facebook/react-native/pull/34533
Test Plan:
No exact test plan. However, if an exception is thrown during the
rendering process, a fatal `ClassNotFoundException` is raised, rather
than having the error be passed up to the `ReactNativeManager`.
Fixes: facebook/yoga#1120
Reviewed By: amir-shalem
Differential Revision: D39133326
Pulled By: jacdebug
fbshipit-source-id: 86283b7d21aed49ed0e9027b2aef85f0108cdf9a
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
This adds the `inputMode` prop to the TextInput component as requested on https://github.com/facebook/react-native/issues/34424, mapping web [inputMode types](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) to equivalent [keyboardType](https://reactnative.dev/docs/textinput#keyboardtype) values. This PR also updates RNTester TextInputExample in order to facilitate the manual QA.
### Caveats
~~This only adds support to `text`, `decimal`, `numeric`, `tel`, `search`, `email`, and `url` types.~~
#### `inputMode="none"`
**Currently mapped to `default` keyboard type.**
The main problem with this input mode is that it's not supported natively neither on Android or iOS. Android `TextView` does accept `none` as `android:inputType` but that makes the text not editable, which wouldn't really solve our problem. `UITextInput` on iOS on the other hand doesn't even have something similar to avoid displaying the virtual keyboard.
If we really want to add the support for `inputMode="none"` one interesting approach we could take is to do something similar to what WebKit has done (https://github.com/WebKit/WebKit/commit/3b5f0c8ecf9de23f79524ed02e290837ab8334cd). In order to achieve this behavior, they had to return a `UIView` with a bounds of `CGRectZero` as the inputView of the `WKContentView` when inputmode=none is present.
~~I guess the real question here should be, do we really want to add this? Or perhaps should we just map `inputMode="none"` to `keyboardType="default"`~~
Android docs: https://developer.android.com/reference/android/widget/TextView#attr_android:inputType
iOS docs: https://developer.apple.com/documentation/uikit/uikeyboardtype?language=objc
#### `inputMode="search"` on Android
**Currently mapped to `default` keyboard type.**
Android `TextView` does not offers any options like `UIKeyboardTypeWebSearch` on iOS to be used as `search` with `android:inputType` and that's probably the reason why `keyboardType="web-search"` is iOS only. I checked how this is handled on the browser on my Android device and it seems that Chrome just uses the default keyboard, maybe we should do the same?
### Open questions
- ~~What should be done about `inputMode="none"`?~~ Add it and map it to `default` keyboard type.
- ~~Which keyboard should we show on Android when `inputMode="search"`?~~ Use the `default` keyboard the same way Chrome does
## Changelog
[General] [Added] - Add inputMode prop to TextInput component
## Test Plan
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Input modes` section
https://user-images.githubusercontent.com/11707729/185691224-3042e828-a008-4bd0-bb3d-010a6a18dfd5.mov
Pull Request resolved: https://github.com/facebook/react-native/pull/34460
Reviewed By: necolas
Differential Revision: D38900724
Pulled By: cipolleschi
fbshipit-source-id: 60d405ccdbfad588b272fbb6b220b64ffdfc4b14
Summary:
When the webview is updated by play store, all apps that has loaded webview gets killed. For background see https://issuetracker.google.com/issues/228611949?pli=1
We have a long-running app and don't want this to happen and while we are not using webview anywhere, we are using websockets that loads it for reading cookies, however we are not using cookies to authenticate the websocket and thus want to disable the webview to avoid loading it unnecessarily and then getting killed unnecessarily.
The webview has support for beeing disabled https://developer.android.com/reference/android/webkit/WebView#disableWebView() however as-is this crashes React Native. It seems to me like this case is very similar to not having web view installed and should be handled in the same way.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Avoid crash in ForwardingCookieHandler if webview is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34483
Test Plan: Add `WebView.disableWebView();` as the first line in `MainActivity.onCreate`.
Reviewed By: christophpurrer
Differential Revision: D38981827
Pulled By: cipolleschi
fbshipit-source-id: 335a8420568ad0c80b834ae8a3b164e55ebe26f3
Summary:
Configure the runtime to allow use of the sampling profiler in the Chrome Debug Server.
Note: this does not actually start and stop the profiler; this change just makes the sampling profiler available to the runtime.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D39100833
fbshipit-source-id: 60d1f4e5ea2191fdf88b7f2e733557fa6128e205
Summary:
The `sed` workaround here in `__apply_Xcode_12_5_M1_post_install_workaround`:
https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L293-L298
does not work when the react native project has a parent folder with a space in the the name, for example:
`/Users/myuser/Some Folder/my-project/ios/Pods/RCT-Folly/folly/portability/Time.h`
This is because the `sed` command thinks that the part after the space is a separate argument.
This bug caused one of our engineers to not be able to run our React Native project through no fault of his own, so I would like to propose this change to help other engineers avoid this in the future.
## Changelog
Add single quotes around the file parameter in the `sed` command
[iOS] [Fixed] - Fixed Time.h:52:17: error when a folder in the file path has a space
Pull Request resolved: https://github.com/facebook/react-native/pull/34510
Test Plan:
Checkout the main branch.
Create a React Native project in a folder that has a space in the name.
When you run `pod install`, you should notice a `sed` error indicating that the text replacement failed.
Run the build to reproduce the `Time.h:52:17: error`.
Checkout this branch.
Run `pod install` and notice the `sed` error is gone.
Run the build, the error should be gone.
Reviewed By: sammy-SC
Differential Revision: D39082262
Pulled By: cipolleschi
fbshipit-source-id: 211099234edc6c9ee959bb61a760a6ca04a7a301
Summary:
when integrates with swift, the compiler will build clang module based on the *React-Core-umbrella.h*. however, the include chain reaches some c++ headers that are not available from swift. it will cause build error.

this pr adds `#ifdef __cplusplus` guard for it.
## Changelog
[iOS] [Fixed] - Fix React module build error with swift integration on new architecture mode
Pull Request resolved: https://github.com/facebook/react-native/pull/34527
Test Plan:
one thing we didn't figure out is that we require reanimated to repro the build error.
1. `npx react-native init RN070 --version 0.70.0-rc.4`. # can also repro this issue on 0.69
2. `cd RN070`
3. `yarn add react-native-reanimated@next`
4. `cd ios && rm -rf Pods build && RCT_NEW_ARCH_ENABLED=1 pod install`
5. add `import React;` in `main.m` for clang module generation
```diff
--- a/ios/RN070/main.m
+++ b/ios/RN070/main.m
@@ -1,5 +1,6 @@
#import <UIKit/UIKit.h>
+@import React;
#import "AppDelegate.h"
int main(int argc, char *argv[])
```
6. `yarn ios`
Reviewed By: cipolleschi
Differential Revision: D39128716
Pulled By: jacdebug
fbshipit-source-id: d9e9130f99e3b9e5f7807c475a24cdd84880e720
Summary:
There are cases where we want to pass an enum type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```enum Quality { SD, HD, }```
Approach:
- We are not generating an ```enum``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed enum types at this time, e.g. ```export enum StringOption { One = 'one', Two = 2, Three = 'three', };``` will not work. See: https://www.typescriptlang.org/docs/handbook/enums.html#heterogeneous-enums
- We only support untyped (default to String), String, and Number enum properties
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Enum Type support for C++ TurboModules
Reviewed By: RSNara
Differential Revision: D38880963
fbshipit-source-id: f2399b29948306bc555429b6f96c43ea4c39c46e
Summary:
This adds the `tabIndex` Android only prop to View as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `focusable` prop to `tabIndex` so that `tabIndex={0}` maps to `focusable={true}` and `tabIndex={-1}` represents ` focusable={false}`.
## Changelog
[Android] [Added] - Add tabIndex prop to View component
Pull Request resolved: https://github.com/facebook/react-native/pull/34486
Test Plan: I'm still investigating the best way to test this but we're are just mapping this to an existing prop
Reviewed By: GijsWeterings
Differential Revision: D38957303
Pulled By: necolas
fbshipit-source-id: d00db854e11cb3457329c1547b69cff60afb34cf
Summary:
## Context
```isRootViewVisible``` doesn't work as expected for non-Venice: when enter Marketplace tab, ```isRootViewVisible``` should returns true with Marketplace tab's rootViewTag, but it returns false.
## Root cause
```rootViewTag``` is added to "mVisibleRootTags" in "FbReactRootVisibilityTracker" when ```BaseFbReactFragment.onViewDidAppear()``` gets called, but ```BaseFbReactFragment.onViewDidAppear()``` is called earlier than when the ```rootViewTag``` is set.
## Fix
Move setRootViewTag to earlier when RootView is created instead of in startSurface or mounting.
Changelog:
[Android][Changed] - Move setRootViewTag to earlier when RootView is created
Reviewed By: RSNara
Differential Revision: D38586584
fbshipit-source-id: aec3ed37eb62289a19794e68b1a6b5ca213cb14a
Summary:
This diff introduces the API that will be used to describe React Native Components written in C++
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725766
fbshipit-source-id: 292e28409ac6be8f9a1c2209b8c558e0e2cb96ea
Summary:
Implement Runtime.compileScript, which is a dev tools request to compile a given script, optionally persisting the compiled result.
There are 3 main cases:
- Unsuccessful compilation, populates the exception details output. (We could retrieve the line and column number from the exception message, but it felt a bit too hacky.)
- Successful unpersisted output, returns an empty result, indicating success
- Successful persisted output, returns a result with a unique scriptID that identifies the prepared script.
The script IDs end with an index that can be used to infer the location in the vector storing persisted scripts.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38761119
fbshipit-source-id: 504faad0149d1637682fa11d285f71736c3133e5
Summary:
Small typo fix.
## Changelog
[General] [Fixed] - Typo in AssetSourceResolver
Pull Request resolved: https://github.com/facebook/react-native/pull/34520
Test Plan: No test plan is required. Just check the file changes.
Reviewed By: NickGerleman
Differential Revision: D39087572
Pulled By: cipolleschi
fbshipit-source-id: a79253d2486ee21fbf5683177b21ec534607d65d
Summary:
- Just a small typo fix
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Typo in build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/34517
Test Plan: - Check out the diff changes
Reviewed By: lunaleaps
Differential Revision: D39082272
Pulled By: cipolleschi
fbshipit-source-id: d62938d5a1e6802c6e7f44186adbbfa1a6715cf8
Summary: Changelog: [Internal] - Make AccessibilityInfo public type an exact object
Reviewed By: NickGerleman
Differential Revision: D38921820
fbshipit-source-id: 6f264595814a817fb1101788942f9127d9cc85c1
Summary:
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 1/n - Move RCTBundleManager.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirely of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
The other benefit of splitting up the headers like this is that it'll be much easier for developers to navigate between the .h and .mm files.
Reviewed By: philIip
Differential Revision: D38943262
fbshipit-source-id: 90876324de9fae25bf33c7aef820a32d7c6ce2f8
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.5
Pull Request resolved: https://github.com/facebook/react-native/pull/34499
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D39051081
Pulled By: cipolleschi
fbshipit-source-id: 857e24a19a77b85f0593945e6838216ceb5b0f5d
Summary:
This adds the Android only `rows` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `numberOfLines` prop to `rows`. This PR also updates the TextInputExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add rows prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34488
Test Plan:
1. On Android open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Fixed number of lines` section
https://user-images.githubusercontent.com/11707729/186300173-7de79799-25b8-48af-99c0-8e3abeae334f.mov
Reviewed By: christophpurrer
Differential Revision: D38981953
Pulled By: cipolleschi
fbshipit-source-id: d4d84b3c0dac7342ba9a65e2491928fbc61ff4f1
Summary:
https://github.com/facebook/react-native/issues/31056#issuecomment-786349025
>Re-implement accessibilityHint on Android so that rather that concatenate into the contentDescription, it sets the toolTipText property on the AccessibilityNodeInfo (not on the view). This is the closest analog to iOS's hint that Android has, as the text is announced after the contentDescription rather than part of it. It will will not adhere to users preferences on whether they want hints disabled or not, and still has no pause before it like real hints have, but it's far closer than using the contentDescription directly.
fixes https://github.com/facebook/react-native/issues/31056
## Changelog
[Android] [Fixed] - Re-implement accessibilityHint on Android to use AccessibililltyNodeInfo#setToolTipText instead of contentDescription
Pull Request resolved: https://github.com/facebook/react-native/pull/34427
Test Plan: https://user-images.githubusercontent.com/24992535/184837154-5c65dbf1-1031-4d56-ac1e-066af7e08edc.mp4
Reviewed By: christophpurrer
Differential Revision: D38982158
Pulled By: cipolleschi
fbshipit-source-id: 7a616e6df9f83bd21ca02cc26b5918986a1d64f8
Summary:
from the original design of `StyleSheet.setStyleAttributePreprocessor()` in https://github.com/facebook/react-native/issues/11138, the overwriting warning shows when the existing preprocess is be overwritten. the behavior changes from https://github.com/facebook/react-native/commit/33b385825c72. This PR revises the logic back to original design.
## Changelog
[Internal] [Fixed] - Show warning only when overwriting existing preprocessor in `StyleSheet.setStyleAttributePreprocessor()`
Pull Request resolved: https://github.com/facebook/react-native/pull/34479
Test Plan:
Unit Test
```
PASS Libraries/StyleSheet/__tests__/StyleSheet-test.js
setStyleAttributePreprocessor
✓ should not show warning when set preprocessor first time (2 ms)
✓ should show warning when overwrite the preprocessor (1 ms)
```
Reviewed By: dmitryrykun
Differential Revision: D38940676
Pulled By: cipolleschi
fbshipit-source-id: 80cf30fff62f4a02c17f7f42b3260a6011d5fc82
Summary:
When a view is rendered with a combination of `overflow: hidden` and `borderRadius: >0`, the `ReactViewGroup` would apply the border radius using Canvas `clipPath`. In Android graphics, clipPath is not an anti-aliased operation and caused aliasing artifacts.
Changing the method to a bitmask using the `PorterDuff` method results in the same functionality, but with hardware accelerated antialiasing.
https://github.com/facebook/react-native/issues/24486
Changelog:
[Android][Change] - Views with overflow: hidden and borderRadius: >0 now render anti-aliased borders.
Reviewed By: javache
Differential Revision: D38914878
fbshipit-source-id: 45ac7e4aece7a76c4216412175e49d3d73b6f391
Summary:
The motivation of this PR is for the Alert to follow the same style override (`overrideUserInterfaceStyle` being light/dark) as the one used by the root window (`UIApplication.sharedApplication.delegate.window`).
This is something that has worked previously because `RCTPResentedViewController()` was used to present the Alert (the behavior has changed in https://github.com/vonovak/react-native/commit/f319ff321c4b7c0929b99e3ebe7e1ce1fa50b34c). With the former approach, the alert would "inherit" the `userInterfaceStyle` of the view controller it was presented within (and that one, in turn, would "inherit" from `UIApplication.sharedApplication.delegate.window`).
With the current approach, the "style inheritance" does not work with the view controller being created [here](https://github.com/facebook/react-native/blob/f3db6cc52792e3006a16408df4ae40f3aee19a86/React/CoreModules/RCTAlertController.m#L24).
Because this viewcontroller instance does not have where to "inherit" the styling from, the styling might be different from the rest of the app. This PR fixes that.
## Changelog
[iOS] [Fixed] - fix: RCTAlertController's UserInterfaceStyle to follow root window
Pull Request resolved: https://github.com/facebook/react-native/pull/34218
Test Plan:
Instead of
```
self.overrideUserInterfaceStyle = UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle;
```
you can do
```
self.overrideUserInterfaceStyle = UIUserInterfaceStyleDark;
```
and observe the result. So if the override is set, it'll manifest itself. If it's not set, the value of `UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle` will be `UIUserInterfaceStyleUnspecified`, and it'll have no effect.
<details>
<summary>screenshot</summary>

</details>
Reviewed By: dmitryrykun
Differential Revision: D38660799
Pulled By: cipolleschi
fbshipit-source-id: c979266900e27be7a4732bdb6e9a496906534931
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
There are cases where we want to pass a union type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```'low'```, ```high``` or resolution to ```720```, ```1080```.
- We are not generating an ```union``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed primitive union types at this time, e.g. ```export type ChooseSomething = 'One' | 'Two' | 3 | false;``` does not work.
- We can support mixed object union types such as ... ```export type ChooseObject = {} | {low: string};``` - which need special logic in the C++ TM to correctly parse the resulting jsi::Object
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Union Type support for C++ TurboModules
Reviewed By: javache
Differential Revision: D38919688
fbshipit-source-id: 0fd37545b32b4f2059a8babda62dab4a85de37a9
Summary:
This PR bumps the Hermes cache keys because they got corrupted due to some sync delay between Hermes and React Native.
## Changelog
[iOS] [Fixed] - CI broken due to Hermes Commit
Pull Request resolved: https://github.com/facebook/react-native/pull/34491
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38976132
Pulled By: cipolleschi
fbshipit-source-id: 16df11ede8947d8376d316b126eefcf0177d16de
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
This adds the `readOnly` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `editable` prop to `readOnly` so that `readOnly={false}` maps to `editable={true}` and `readOnly={true}` represents ` editable={false}`. This PR also updates the TextInputExample on the RNTest in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add readOnly prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34444
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Editable and Read only` section
https://user-images.githubusercontent.com/11707729/185295132-036443c8-1d5e-4567-a15e-5f1173cb0526.mov
Reviewed By: lunaleaps
Differential Revision: D38912786
Pulled By: necolas
fbshipit-source-id: faeb59ed8695732be682ec55406a2de0cb7e619a
Summary:
Changelog: [iOS][Internal] - Fix buttons property value for non-hoverable pointers
The previous diff ensured that on iOS you could run through the entirety of the non-hoverable pointer event attributes test but that also revealed some failing tests related to the `buttons` property when using a non-hoverable pointer. This diff fixes that by ensuring that we only forward the result of the `buttonMask` to `buttons` when the pointer is a mouse, and assume that it is an emulated left click otherwise.
Reviewed By: lunaleaps
Differential Revision: D38914239
fbshipit-source-id: c573e934d0e9c0ac2af4945dc5360840ddc87d4d
Summary:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
Summary:
X-link: https://github.com/facebook/hermes/pull/793
Add a JSI API for constructing `ArrayBuffer`s from a user provided
`jsi::MutableBuffer`.
Changelog: [General][Added] Added ability to construct ArrayBuffers from existing memory buffers.
Reviewed By: jpporto
Differential Revision: D37744467
fbshipit-source-id: 9d9ece00d1dbde341846c45fa30c935b5fa81e9a
Summary:
As per title, the shallow checkout was breaking some workflows, so we are reverting it
## Changelog
[General] [Changed] - Revert shallow checkout
Pull Request resolved: https://github.com/facebook/react-native/pull/34480
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38940528
Pulled By: cipolleschi
fbshipit-source-id: 691faf2749911278923ca2d42c974e5307a06261
Summary:
ScrollView has special-case logic to dismiss keyboard on tap, controlled via the `keyboardShouldPersistTaps` property. The first click does not propagate to children of the scrollview if the tap causes the keyboard to be dismissed. This behavior is motivated by a soft keyboard on phones which takes away space from the viewport.
ScrollView historically determined if a soft-keyboard was open via querying if there was a focused TextInput. This meant that clicks to a ScrollView would be eaten, even on form factors using phsyical keyboards.
A couple years ago I added https://github.com/facebook/react-native/pull/30374 to only eat clicks when keyboard events have indicated that a soft keyboard is present. I special-cased Android out of the change, because of platform issues with its reliability of keyboard events.
After D38500859 (https://github.com/facebook/react-native/commit/1e48274223ee647ac4fc2c21822b5240f3c47e4c) rolls out we can start to remove that special-casing, of devices which report "android" for Platform.OS.
Reviewed By: javache
Differential Revision: D38528887
fbshipit-source-id: a745b478b18abe4ef32cbdd8a14ca6dfdb5e738f
Summary:
If currently focused on a TextInput, clicking an item in a ScrollView takes two clicks.
This is because of `keyboardShouldPersistTaps`, which will fire despite a lack of keyboard events on Android due to special-casing.
This behavior is jarring in scenarios like VR where the soft keyboard is detached from the application. This change avoids eating taps, in this case, where a soft keyboard is open but not inset.
Reviewed By: genkikondo
Differential Revision: D38529237
fbshipit-source-id: a10c5dbf04e6288e0e9e0c805215054bc883339f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of `convertRawProp` for `std::optional` since we can handle that in a `fromRawValue` specialization instead.
To make this work, we need to remove `noexcept` from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D37055069
fbshipit-source-id: 8ce121a9b187f068d3ab790c6fae66d53e6338d2
Summary:
- Fix a typo in the word "feture" (-> "feature")
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Typo in AppDelegate.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/34462
Test Plan: - Read the diff change
Reviewed By: dmitryrykun
Differential Revision: D38900680
Pulled By: cipolleschi
fbshipit-source-id: cdc5fb183cb7f5485a553dde7ea381f27f83e903
Summary:
Changelog:
[iOS][Fixed] - When source maps are enabled, clean up temporary files from the build directory. Reduces bundle size by at least 1MB.
Reviewed By: cipolleschi
Differential Revision: D38866158
fbshipit-source-id: 0f46faf4e767bb7417b24f283fbe19cfa022941a
Summary:
This PR removes unused variable `NODE_MODULES_DIR` passed from `build.gradle` to `CMakeLists.txt` which causes the following CMake warnings to appear in the logs:
```
> Task :app:configureCMakeDebug[arm64-v8a]
C/C++: debug|arm64-v8a :CMake Warning:
C/C++: debug|arm64-v8a : Manually-specified variables were not used by the project:
C/C++: debug|arm64-v8a : NODE_MODULES_DIR
```
First I changed the value of `NODE_MODULES_DIR` to some non-existent path (i.e. `-DNODE_MODULES_DIR=/foo/bar`) to confirm that the variable is indeed unused. Then I completely removed it from `arguments` and the CMake warning disappeared.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Removed unused variable `NODE_MODULES_DIR` from `build.gradle` in app template
Pull Request resolved: https://github.com/facebook/react-native/pull/34459
Test Plan:
1. Create a new RN 0.70.0-rc.3 app from template with `npx react-native@next init RN070RC3 --version 0.70.0-rc.3`
2. Set `newArchEnabled=true` in `settings.gradle`
3. Open `android` directory in Android Studio
4. Run Gradle Sync
5. Build the app
6. Search for `NODE_MODULES_DIR` in the logs
7. Notice the CMake warning
8. Remove the line from this PR
9. Build the app again
10. Search for `NODE_MODULES_DIR` in the logs
11. Confirm there are no occurrences
Reviewed By: neildhar
Differential Revision: D38864127
Pulled By: cortinico
fbshipit-source-id: b41440edcdba63945e3b08cef897a250686c13ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34452
This will unblock the RN `test_android` CI Job as currently two versions
of `hermes-parser` are picked up during package resolution.
Changelog:
[Internal] [Fixed] - Blacklist sdks/hermes from Metro resolution
Reviewed By: cipolleschi
Differential Revision: D38856931
fbshipit-source-id: 49d941f762ba0ef953c5c42b0ca13ac1c74b5ba5
Summary: Changelog: [Internal] - Create a type declaration for AccsesibilityInfo for clearer signal when our public API types change
Reviewed By: yungsters
Differential Revision: D38712552
fbshipit-source-id: cc7c727d41fb03ca714cb05fd10dc32038374fd0
Summary:
Changelog: [iOS][Internal] - Apply pointer entering/leaving tracking to touch-initiated pointer events
This diff takes the refactoring done in the previous diff in this stack and applies it to the pointer events which are converted from discrete touch events. In addition this adds a check when an ActiveTouch is created to see if the pointer in question was hovering before the touch started or not, which is stored and leveraged once the touch is lifted to determine if we should treat the pointer as leaving the screen entirely or not.
Reviewed By: lunaleaps
Differential Revision: D38762330
fbshipit-source-id: 08452783e01bf5944c57b94a292805b2d69d4384
Summary:
Changelog: [iOS][Internal] - Refactor hover tracking to prepare for support of tracking the entering/leaving of poitners on non-hover pointer events
This diff begins the work in preparing the touch handler class to track pointer's entering & leaving of views on events other than a hover move by refactoring it to 1) support multiple/simultaneous pointers and 2) abstract the pointer tracking out of the hover recognizer callback so that it can be used for other events in the future (to be done in future diffs, this diff is simply a refactor and keeps the status quo).
Reviewed By: lunaleaps
Differential Revision: D38760358
fbshipit-source-id: f05629ddaa76daed9a3e59ce5d4af6f62ba83755
Summary:
ScrollView has special behavior when the keyboard is open, but starts listening to keyboard events on mount. This means a ScrollView mounted after the keyboard is already up (e.g. for a typeahead) is not initialized to the keyboard being up.
This change adds `Keyboard.isVisible()` and `Keyboard.metrics()` APIs to allow seeding initial keyboard metrics.
Changelog:
[General][Fixed] - Inform ScrollView of Keyboard Events Before Mount
Reviewed By: JoshuaGross, yungsters
Differential Revision: D38701976
fbshipit-source-id: 42b354718fbf5001ca4b90de0442eeab0be91e7a
Summary:
As title, replace json serialization/deserialization and folly with MapBuffer for js error handling in Android.
Changelog:
[Android][Changed] Replace Folly with MapBuffer for passing js error data
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D38460202
fbshipit-source-id: e13a47722964baa9e0a16bb138456a19350f809e
Summary:
Updating flow-parser to a more recent version which also supports parsing enums
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D38832380
fbshipit-source-id: e3ef477abf85939ce3c9d92844e28dc59d8231c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34446
I'm adding another class to the .defaults package. This will take care of setting the RootView
with Fabric enabled/disabled as well as controlling concurrent root.
Changelog:
[Android] [Added] - Introduce the DefaultMainActivityDelegate to simplify enabling/disabling Fabric for new apps.
Reviewed By: cipolleschi
Differential Revision: D38823181
fbshipit-source-id: 2293b9df6b0d8fa79695bd52a8e0bb46b44c43c8
Summary:
With react-native 0.70-rc.3 and new arch, codegen may fail if it encounters `.d.ts` files because specs may appear to be unused.
## Changelog
[General] [Fixed] - Codegen should ignore `.d.ts` files
Pull Request resolved: https://github.com/facebook/react-native/pull/34439
Test Plan:
See repro in https://github.com/microsoft/react-native-test-app/pull/1052. The build will fail without manually patching this in.
If you prefer to use your own test app, try adding [react-native-safe-area-context](https://github.com/th3rdwave/react-native-safe-area-context) as a dependency.
Reviewed By: cipolleschi
Differential Revision: D38826388
Pulled By: cortinico
fbshipit-source-id: eb7c9be2d49286bae86b2428862fbf20f6f32ca5
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for turbomodule
I've also updated all the internal usages and references to the new path.
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - turbomodule
Reviewed By: cipolleschi
Differential Revision: D38820638
fbshipit-source-id: febb3f8cef18b30e82c3a4776baa85d0c0d19e4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34445
This commit simplifies the new app template by encapsulating a lot of configuration
by using the `DefaultReactNativeHost` from the .defaults package.
This should work for most of the users while still allowing advanced use cases
by using the good old ReactNativeHost.
Changelog:
[Android] [Changed] - Simplify the template for New Architecture using the .defaults package
Reviewed By: cipolleschi
Differential Revision: D38820111
fbshipit-source-id: 4e9529a92e1681610e3a1a89fdf82e6d10a18809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34440
While testing some recent changes on a nightly, I realized that if we install the dependencies using RCT_NEW_ARCH_ENABLED=1 and we forget to change the flag in the Podfile, Fabric dependencies won't be installed.
However, Fabric is required by the New Architecture. This fix makes sure that we install Fabric dependencies when the New Architecture is enabled.
## Changelog
[iOS][Changed] Install Fabric dependencies when RCT_NEW_ARCH_ENABLED=1
Reviewed By: cortinico
Differential Revision: D38786978
fbshipit-source-id: 664151de0250577a19af949f8850e5efa8a13373
Summary:
This is an attempt to fix the broken `test_buck` as the `/textinput` target now needs to access the Kotlin stdlib dependencies
## Changelog
[Internal] - Fix test_buck by providing exported deps for textinput target
Pull Request resolved: https://github.com/facebook/react-native/pull/34436
Test Plan: Will wait for a CircleCI result
Reviewed By: cipolleschi
Differential Revision: D38782473
Pulled By: cortinico
fbshipit-source-id: 72265c34092372189d75df732b64a1e370453472
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34435
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for fabricjni
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - fabricjni
Reviewed By: cipolleschi
Differential Revision: D38741130
fbshipit-source-id: f9e3e4514d3ae0ddeac65256928d71d5134d08f8
Summary:
CMake gens running debug
- `android/app/.cxx/Debug/*`
- `android/app/.cxx/RelWithDebInfo/*`
Neither/nothing during release.
So probably want the 87 debug files untracked.
Follow-up: https://github.com/facebook/react-native/pull/34354
_macOS 13b, RN 0.70.0-rc.3_
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Update template to gitignore `android/app/.cxx`
Pull Request resolved: https://github.com/facebook/react-native/pull/34430
Test Plan: Everything builds and runs as expected
Reviewed By: cipolleschi
Differential Revision: D38752097
Pulled By: cortinico
fbshipit-source-id: 61c31317d5e45f831445841f3e14da871b3903e5
Summary:
Currently the PropSetter parser parses all border{TopLeft,TopRight,...}Radius props except for `borderRadius`.
This is the fix.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678226
fbshipit-source-id: 8c5d67a652c2b327aa50a997e8e886630fe139c0
Summary:
Unfortunately my last diff didn't completely fix this; now there are more printed parameters than arguments provided to the formatter.
Easy fix, confirmed this works by running internally.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678116
fbshipit-source-id: 51f32905debc1946bc260f06a5bdc2f43141ddf4
Summary:
Changelog:
[General][Changed] - Copied and refactored the current devtools highlighting code from Inspector into its own module and add to the top level `AppContainer`. The effect is that the highlight stills shows without Inspector opened.
This diff copies the current devtools highlighting logic from Inspector into a module and add to the top level `AppContainer`. The effect is without Inspector opened, the highlight will still show.
## Context
This is the first diff for "Component Tab Automatically Highlight Elements". The idea is to replicate the behavior on Web to RN.
## Behavior
on Web:
- highlight shows whenever an element in the component list is hovered
- Selecting an element doesn't keeps the highlight showing.
on RN (before this diff):
- when RN inspector opens: selecting an element keeps the highlight showing
- when RN inspector closes: stop showing highlihgintg.
on RN(this diff)
- selecting an element keeps the highlight showing
## TODO
- See if highlighting event can be sent on hover, instead of when an element is selected.
Reviewed By: lunaruan
Differential Revision: D38568135
fbshipit-source-id: d168874677d08a9c5526a7f896943579da804565
Summary:
Changelog: [RNTester][Internal] nohover pointerevent attributes platform test fixes
In implementing full support of nohover pointerevents I discovered a couple issues with my initial port of the web platform test — specifically I forgot to update the calls to `checkPointerEventAttributes` to be "touch" instead of "mouse" and I had forgotten to remove the `pointerMove` event from the expected pointer event order.
Reviewed By: lunaleaps
Differential Revision: D38718994
fbshipit-source-id: d189a4b5cf3042c9f493ac876062f4f60219ae2b
Summary:
I'm applying the same fix I applied to the Template.
This allows us to load Flipper without using reflection on RN Tester.
Changelog:
[Internal] [Changed] - Do not use reflection to load Flipper on RN Tester
Reviewed By: cipolleschi
Differential Revision: D38745404
fbshipit-source-id: c17fbd74df31441467e448f21c35171a7f2532ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34418
This is an attempt to relax the need of specifying a custom `TurboModuleManagerDelegate` and a `JSIModulePackage` in new apps for New Architecture.
Users can just specify the name of the dynamic library to load and they'll default to use the `DefaultTurboModuleManagerDelegate` and `DefaultJSIModulePackage`.
Users will still have to provide a C++ implementation for it for the time being, but this at least removes
one extra file that we requested them to create and maintain.
If we're fine with this approach, I'll replicate it inside the default template.
Changelog:
[Android] [Added] - Provide defaults for TurboModuleManagerDelegate and JSIModulePackage
Reviewed By: cipolleschi
Differential Revision: D38701180
fbshipit-source-id: eec302c5789990700eb75353d97751358ca6799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34421
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for reactnativeblob
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - reactnativeblob
Reviewed By: cipolleschi
Differential Revision: D38703092
fbshipit-source-id: 3d4391d8ee5587b199efa4001f68c6d4ed3ce2c2
Summary:
This is a nit cleanup of RNTester's build.gradle.
1. We should not create new configurations such as `hermesDebugImplementation` as those are automatically created by AGP.
2. We should not add imports of external .jar as we don't have them (and this generates a warning on console).
Changelog:
[Internal] [Changed] - Remove unnecessary configs from RNTester
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D38737330
fbshipit-source-id: e23f234f68c839af065d4948af6c780186cbdf3d
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for mapbuffer
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - mapbuffer
Reviewed By: cipolleschi
Differential Revision: D38699253
fbshipit-source-id: c1c8f8693b6da4e3428f8f280e1ca4d5c5d0f853
Summary:
Changes the React Native base ESLint configuration to consume `react-native-community/eslint-config` as a [yarn workspace](https://classic.yarnpkg.com/lang/en/docs/workspaces/), so that any dependencies of `react-native-community/eslint-config` can also be resolved from the root directory of `react-native`.
Previously, `~/.eslintrc.js` extended `react-native-community/eslint-config` using a relative file path. This is problematic because if any dependencies (notably, optional peer dependencies such as some of the TypeScript dependencies) are not already installed at the root directory of `react-native`, running ESLint could fail to resolve any required dependencies. In other words, there was an implicit dependency that `react-native/yarn.lock` would also contain any dependencies required by `react-native/packages/eslint-config-react-native-community/yarn.lock`.
With this change, running `yarn` from the root directory of `react-native` will also install any dependencies of `react-native-community/eslint-config`, and it will also symlink `react-native/node_modules/react-native-community/eslint-config` to `../../packages/eslint-config-react-native-community` (meaning any local changes to the config will still be reflected during active development).
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34423
Test Plan:
Successfully install dependencies and run ESLint.
```
$ cd react-native
$ yarn
$ yarn lint
```
Successfully run Danger on https://github.com/facebook/react-native/pull/34401 (which would previously fail because `typescript-eslint/eslint-plugin` could not be resolved from the root directory of `react-native`):
```
$ cd react-native/bots
$ yarn
$ node ./node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34401
```
Reviewed By: NickGerleman
Differential Revision: D38710285
Pulled By: yungsters
fbshipit-source-id: a06ceea0884a90be60f6f5db9a5d42be52a951d5
Summary:
Changelog: [iOS][Internal] - Add iOS implementation of the button property of the PointerEvent object
This implements the `button` property on the PointerEvent object by storing the button which caused the down event in the `ActiveTouch` and reporting that button through `pointerdown` and `pointerup` events and -1 on all others. This diff also includes a small fix to the `pressure` property which was introduced due to `button` being correctly implemented.
Reviewed By: yungsters
Differential Revision: D38632543
fbshipit-source-id: 9dbbb23a9251f2e661faf37fdf206b9f0b26bc5f
Summary:
This adds an option to the Error Reporting pipeline of React Native to attach custom extra data to Exceptions passed to the native ExceptionsManager. This allows for error logging abstractions such as Meta's FBLogger to attach extra fields to the reported error. This can help with more detailed error reports without having to stringify all data in the error message.
Note: The field (which is technically on ExtendedError) is keyed using a Symbol. This is to make sure that any use of this ability is extremely deliberate, as (accidentally) adding tons of data (or unserializable data) can cause issues we send down the data to the native ExceptionsManager implementation. Data sent using this method should be strictly controlled, hence opting in is a concious effort using the symbol in ExceptionsManager
Changelog:
[Internal] [Added] - Ability to add custom data to extraData field of exceptions passed to the ExceptionsManager
Reviewed By: yungsters
Differential Revision: D36099191
fbshipit-source-id: ce3f0dae52acd742de98b71868323c5878eaa677
Summary:
Changelog:
[General][Fixed] - Run ExceptionsManager unit tests in both __DEV__ and prod mode
This suite of unittests use a `__DEV__` check in various places to check that the correct data is sent to either LogBox (in __DEV__) or the Native ExceptionsManager (in PROD). However, we're not actually running both modes, so half of the assert branches in these tests aren't ever utilized.
This diff uses the same approach as ReactNativeVersionCheck-test.js to execute this test suite twice: Once in DEV and once in PROD mode.
Reviewed By: motiz88
Differential Revision: D36099190
fbshipit-source-id: 40b8ea26f1d9e093202f3c3f3b55111110a8d64c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34420
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for hermes/reactexecutor and hermes/instrumentation
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - hermes modules
Reviewed By: yungsters
Differential Revision: D38700760
fbshipit-source-id: 50cf38a0dae4f617e6d78317e5fe2a858290d0c0
Summary:
Those flags are always true and it doesn't really make sense to keep them around at this
moment as the Template setup relies on a single flag (newArchEnabled) and this adds
yet another discrepancy.
Changelog:
[Internal] [Changed] - Remove unused flags `ENABLE_FABRIC` and `ENABLE_TURBOMODULE` inside RN Tester
Reviewed By: cipolleschi
Differential Revision: D38701673
fbshipit-source-id: f7309e00b61fb56465ee0ec738d6cccc540ac1bf
Summary:
Currently both iOS and Android send over the list of transforms as an array. But there is an if statement that causes other platforms to get a matrix. This prevents other platforms from being able to use the fabric ViewProps class and the conversion functions as they exist in core, as those expect the transforms to be an array.
Stop special casing iOS and android. - Which will allow for example Windows to be able to share more fabric code.
## Changelog
[Internal] [Changed] - All platforms should get transform sent to native as an array of transform operations instead of a matrix
Pull Request resolved: https://github.com/facebook/react-native/pull/33579
Test Plan:
Similar change made in react-native-windows.
https://github.com/microsoft/react-native-windows/issues/9797
Reviewed By: NickGerleman
Differential Revision: D38615676
Pulled By: cortinico
fbshipit-source-id: 8861afe6bf34bebb09dd82f7365faf007dd79cbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34396
Current we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for jscexecutor
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - jscexecutor
Reviewed By: sshic
Differential Revision: D38615007
fbshipit-source-id: e5085130579f37f052b5c8a5702d2c0f1b332bee
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for uimanager
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - uimanager
Reviewed By: dmitryrykun
Differential Revision: D38656400
fbshipit-source-id: f52487160fa6c05ec382842e2a6125a5c4cb1e86
Summary:
Make sure the new app template uses the correct project CMake project name: `helloworld_appmodules`, otherwise the app will fail to load the dynamic library.
This was a copy-n-paste error from RNTester.
## Changelog
[Internal] - Make sure the template project name is `helloworld_appmodules`
Pull Request resolved: https://github.com/facebook/react-native/pull/34417
Test Plan: Will test an app created with the New App template
Reviewed By: cipolleschi
Differential Revision: D38698682
Pulled By: cortinico
fbshipit-source-id: b09331a52989b3b131ea8ba627057febcb535ef8
Summary:
As the title says, android.sourceSets.main.jni is deprecated in AGP. We should not be accessing it. Here we were setting it to the empty array (the default value).
It will cause the build to break in a future AGP bump, hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove deprecated jni.srcDirs from ReactAndroid build file
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D38655857
fbshipit-source-id: 2eb6897964554da462bde58937a6de708bc047dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34384
This Diff aims to create a RCTAppDelegate library to offer a subclass which automates some operations required to set up the new architecture.
## Changelog
[iOS][Added] - Added the RCTAppDelegate library
Reviewed By: cortinico
Differential Revision: D38580424
fbshipit-source-id: 38f6c4b8ff2790a2ce9e23d385b36307701cffb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34398
This Diff cleans up the codegen folder for iOS when we install the pods. This is useful to start from a clean situation. The codegen runs after this step and we make sure that the file system is clean
## Changelog
[iOS][Changed] - Cleanup codegen build folder before installing the pods
Reviewed By: cortinico
Differential Revision: D38657027
fbshipit-source-id: 8a914457d7963521d6d8dc7819eba864736f50a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34403
This change mirrors D38457812 (https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690) which added -Wpedantic to ReactCommon targets, but for the Android build used by OSS. This should ensure contributors see the same warnings locally as the internal build would produce.
Changelog:
[Android][Changed] - Enable -Wpedantic in OSS Android Targets
Reviewed By: cortinico
Differential Revision: D38632454
fbshipit-source-id: 19a036ee3f902eb9d47c568aef448af9d8562358
Summary:
Sometime over the past few months (and with changes such as migrating to the `hermes-eslint` parser), a bunch of lint warnings crept into the codebase.
This does a pass to clean them all up, ignore generated files, and refactor some code to be... better.
There should be no observable behavior changes as a result of this.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646643
fbshipit-source-id: a7b55d1e4cd5700340cc5c21f928baf3ea1d5a58
Summary:
Cleans up a few minor Flow suppression comments in `FlatList`. This reveals a new Flow error that is the result of `FlatList`'s props object being inexact whereas `VirtualizedList`'s props object is exact. For now, I introduce another -- but more specific -- Flow suppression for that type error.
The code changes should not have any consequential behavior change.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646228
fbshipit-source-id: f4f9b0ad95323157ff1519353b38e8486adc841d
Summary:
The `RuntimeAdapter` may be used after `disableDebugging` has been called. To ensure the `RuntimeAdapter` is alive long enough for this use, the Inspector should continue to control `RuntimeAdapter`'s lifetime (which is currently done via a `unique_ptr` that's moved into the Inspector).
Callers need a way to identify the `RuntimeAdapter` after it has been moved into the Inspector so that debugging can be disabled via `disableDebugging`.
This could be done by switching from a `unique_ptr` to a `shared_ptr` (so the caller can keep a copy), but consumers don't really have a reason to hang onto the `RuntimeAdapter` instance. Instead, leave the `RuntimeAdapter` inside a `unique_ptr`, and have consumers use a token to identify instances.
Update all consumers of this API to use this new token interface.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38513256
fbshipit-source-id: 33580747cd8365d25dbddbe289f0c41141e3bc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34386
Current we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from `ReactAndroid/src/main/java/com/facebook/...` to `ReactAndroid/src/main/jni/react/...`
This is the diff for reactperflogger
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - reactperflogger
Reviewed By: cipolleschi
Differential Revision: D38584681
fbshipit-source-id: 8b65b3fa47a7f106c7fea79fd739f0e4e37efa2a
Summary:
Improves upon the existing prop types error messages to first recommend migrating to a type system (before recommending the usage of `deprecated-react-native-prop-types`).
## Changelog
[General][Changed] - Minor change to PropTypes error message.
Pull Request resolved: https://github.com/facebook/react-native/pull/34392
Test Plan: Careful code inspection.
Reviewed By: rickhanlonii
Differential Revision: D38632723
Pulled By: yungsters
fbshipit-source-id: 88e44116475c7d93bc561c9ab6883855d6d79a7e
Summary:
needsOffscreenAlphaCompositing is supported on both iOS and Android, but was missing from the view config for Android.
https://reactnative.dev/docs/view#needsoffscreenalphacompositinghttps://fburl.com/code/hfxkrur1
Changelog:
[Internal][Fixed] - Add needsOffscreenAlphaCompositing to view config
Reviewed By: NickGerleman
Differential Revision: D38580371
fbshipit-source-id: 9b577079e575d73c94d7c0d0298ba880c1438099
Summary:
This is an attempt to fix the `test_buck` CI after the land of https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690
There were references to internal args that are causing Buck OSS to fail. I'm removing them all.
## Changelog
[Internal] - Do not use kwargs which are not known in Buck OSS
Pull Request resolved: https://github.com/facebook/react-native/pull/34388
Test Plan: If CI is green, we can merge this 👍
Reviewed By: motiz88
Differential Revision: D38619542
Pulled By: cortinico
fbshipit-source-id: e00b4b5da7e181365e63e10aa50d0ecde8024359
Summary:
Add ability to store and retrieve a list of MapBuffer as an entry of MapBuffer.
```
Example:
MapBuffer1
{
key1: "test string",
key2: MapBuffer2,
key3: [MapBuffer3, MapBuffer4]
}
```
Changelog:
[General][Added] Add ability to store and retrieve a list of MapBuffer
Reviewed By: JoshuaGross
Differential Revision: D38460204
fbshipit-source-id: 3e721418be2dca6d5f15f665753844d6f531e31c
Summary:
Bump CLI to latest v9 alpha so that I can then chery-pick in 0.70-stable branch for next RC
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to latest v9-alpha11
Pull Request resolved: https://github.com/facebook/react-native/pull/34385
Test Plan: N/A
Reviewed By: robhogan
Differential Revision: D38615615
Pulled By: dmitryrykun
fbshipit-source-id: ea5dd7b93f4ed3bb82347fd730b8e65e8a89a6ca
Summary:
Followup to https://github.com/facebook/react-native/issues/34379 by danilobuerger
Loading Flipper via reflection is type unsafe and requires extra code + exception handling that we can get rid of. The recommended way to use Flipper on Android is either via a `no-op` artifact or by using build flavors.
As we already had a setup for Flipper for `debug`, I'm creating the `release` equivalent which is just a stub. This allows us to get rid of some code inside `MainApplication.java`
## Changelog
[Android] [Changed] - Do not load Flipper via reflection
Pull Request resolved: https://github.com/facebook/react-native/pull/34383
Test Plan: Will wait for a CI result on this.
Reviewed By: cipolleschi
Differential Revision: D38615257
Pulled By: cortinico
fbshipit-source-id: 66bb2c46c5df36a15c1b27512209a849f55d64c9
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
This isolates and parallelize all the BUCK related work inside a `test_buck` job, so it's immediately clear where a failure happend.
I've also added a couple of minor improvements:
- Don't clone okbuck just to consume a script. I've copied the script over instead.
- Removed unnecessary `buck_cache_key`
This should reduce ~5 minute of build time from Test Android which was already beyond 10 minutes.
## Changelog
[Internal] - Isolate the buck OSS commands inside test_buck
Pull Request resolved: https://github.com/facebook/react-native/pull/34378
Test Plan: Let's wait for a `test_buck` and `test_android` output.
Reviewed By: cipolleschi
Differential Revision: D38580359
Pulled By: cortinico
fbshipit-source-id: 8b3915bbc28b4a7a169011fe9047f402c2d1f6ee
Summary:
Calling `setPivotX` and `setPivotY` internally sets `isPivotExplicitlySet` in Android UI, which causes some transforms to no longer use the right transform. Instead use `resetPivot` to get the desired behaviour.
Changelog: [Android][Fixed] Bug with view transforms when view recycling is enabled
Reviewed By: NickGerleman
Differential Revision: D38579267
fbshipit-source-id: 36186286c6765f92aabaa44994546e06f34c2be0
Summary:
RN for Android fires `keyboardDidShow` and `keyboardDidHide` by observing changes to viewable window size. This isn't always reliable, such as when an activity has `awindowSoftInputMode` set to not have the system adjust the viewport when a keyboard is opened.
Android 11 added the direct ability to measure and check visibility of the soft keyboard via `WindowInsets`, which fixes these issues. This is exposed downlevel to API 23 via WindowInsetsComapt` with the same limitations as previously, but using it simplifies our calculations a lot.
Changelog:
[Android][Fixed] - Use WindowInsetsCompat for Keyboard Events
Reviewed By: javache
Differential Revision: D38500859
fbshipit-source-id: d4ad41d7e75e4b9c14a485539a5f9de19de74362
Summary:
Changelog: [iOS][Internal] - Fix ghost pointer leave/out events firing due to view recycling on iOS
While implementing the properties on the PointerEvent object on iOS I noticed that in certain specific scenarios I was seeing pointerLeave events being fired seemingly without corresponding pointerEvent events and even more strangely, when the pointer wasn't even close to the view in question.
After a lot of research I discovered that this was caused by an incompatibility between my strategy of keeping track/identifying views which are being hovered and RN's handling of creating/deleting views on iOS. See on iOS RN has the `RCTComponentViewRegistry` class which manages the creation & deletion of UIViews and adds an optimization of recycling views instead of outright deleting them.
This is causing issues with my tracking of which views are hovered because I compare the view's object references which, while accurate towards confirming equality of an underlying UIView — isn't accurate in confirming the equality of views from react's perspective.
This diff addresses this issue by adding a simple wrapper class that can be used around the UIViews which stores the view's react ID at initialization time ensuring it doesn't get updated even if the underlying view's react id is. As an additional precaution the wrapper class will also not return the view it's wrapping if their react tags do not match.
Reviewed By: lunaleaps
Differential Revision: D38546628
fbshipit-source-id: 8b732d52da0e61a5447001e8940e4439f49c6baf
Summary:
BaseViewManager.setPointerEnter was never called on ReactTextViews, and thus text views would not receive hover events.
Changelog:
[Internal][Fixed] - Add pointer events to text view config
Reviewed By: lunaleaps, javache
Differential Revision: D38557546
fbshipit-source-id: cfc0e5442efbd7c76d1b47acf56496d10ef78cf5
Summary:
Previously published by [grgr-dkrk][2] as [https://github.com/facebook/react-native/issues/31296][3], fixes the following issues:
1) ImportantForAccessibility="no" does not work on Text, Button
2) ImportantForAccessibility="no-hide-descendants" does not work on Text, Button, or ImageBackground.
Note: On ImageBackground, focus is prevented on the imageBackground node itself, but focus is not prevented on its descendants.
Note: [Button component expected behavior for prop importantForAccessibility][4]
>Some components like Button seem like atomic units, but they end up rendering a hierarchy of components for example a wrapper View with a Text inside them. Allowing those descendants to become focusable, breaks the model of these being a single component to consider and forcing no-hide-descendants makes sense here.
>The other option is always to render any descendants of these elements with importantForAccessibility="no", so they can never be focusable on their own. This would have the same result, **BUT may potentially cause issues when the descendant content is supposed to automatically get moved up to the focusable ancestor to act as a label** (which is what Talkback does with unfocusable text elements by default).
Note: [importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images][5]
fixes https://github.com/facebook/react-native/issues/30850 related https://github.com/facebook/react-native/pull/33690
## Changelog
[Android] [Fixed] - adding importantForAccessibility for Text, Button, ImageBackground
Pull Request resolved: https://github.com/facebook/react-native/pull/34245
Test Plan:
1) testing ImageBackground importantForAccessiblity ([link to test][1])
2) importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images ([link to test][5])
3) testing ImageBackground importantForAccessiblity ([link to test][6])
4) Button with importantForAccessibility=no ([link to test][7])
[1]: https://github.com/facebook/react-native/pull/31296#issuecomment-1192341626 ""
[2]: https://github.com/grgr-dkrk "grgr-dkrk"
[3]: https://github.com/facebook/react-native/pull/31296 "https://github.com/facebook/react-native/issues/31296"
[4]: https://github.com/facebook/react-native/pull/31296#discussion_r616184584 "expected behaviour with prop importantForAccessibility in Button component"
[5]: https://github.com/facebook/react-native/issues/30850#issuecomment-1192286477 "importantForAccessibility=no does not allow screenreader focus on nested Text Components with accessibilityRole=link or inline Images"
[6]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192446124 "testing ImageBackground importantForAccessiblity"
[7]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192443589 "Button with importantForAccessibility=no"
Reviewed By: cipolleschi
Differential Revision: D38121992
Pulled By: dmitryrykun
fbshipit-source-id: 368b4dcb47d7940274820aa2e39ed5e2ca068821
Summary:
Hermes is enabled by default. We set `USE_HERMES` envvar to `false` to explicilty disable Hermes. The only valid way to check it would be to compare it against `false`. Everything else will produce invalid results if `USE_HERMES` is not defined. For example `$USE_HERMES != true` will turn into `'' != true`, which evaluates to `true`.
Due to this bug source maps were not generated by default.
Changelog:
[iOS][Fixed] - USE_HERMES envvar check fixed in react-native-xcode.sh. Now source maps are generated by default.
Reviewed By: cipolleschi
Differential Revision: D38571971
fbshipit-source-id: bc6b505c225c56d62ee773b401b66d821965e106
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38355134
fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
Summary:
After https://github.com/facebook/react-native/issues/34370, Danger started failing because the `DANGER_GITHUB_API_TOKEN` was not properly set.
This PR fixes it.
## Changelog
[General] [Changed] - Set back the `DANGER_GITHUB_API_TOKEN`.
Pull Request resolved: https://github.com/facebook/react-native/pull/34375
Test Plan: Danger GitHub action is executed correctly.
Reviewed By: cortinico
Differential Revision: D38571718
Pulled By: cipolleschi
fbshipit-source-id: 51168098b4f910f6fefd2872f917e12daad1ec4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34373
By introducing a RCTAppDelegate base class, we can simplify the migration step to supports TM
## Changelog
[iOS][Changed] - Simplified migration steps for TM
Reviewed By: cortinico
Differential Revision: D38509891
fbshipit-source-id: 716c1e668a05ecbd9c679558889564780816e491
Summary:
`toJs()` resolution trips up on converting the plain old jsi values.
In order to help it - remove the automatic inference of template types, since we already know that `T` in this case is going to be the concrete jsi type.
This allows using implicit conversions on Sync/Async Callback types, as well as AsyncPromise.
Without it - AsyncPromise/Callback trip up on trying to convert Convertor<T> to jsi type.
Changelog:
[General][Added] SyncCallback/AsyncCallback/AsyncPromise bridging types in C++ now allow wrapping JSI types.
Reviewed By: JoshuaGross
Differential Revision: D38529799
fbshipit-source-id: 860de2d771899f331bf1a4ff0dade4eccc875618
Summary:
Changelog: [RNTester][Internal] - Add a pointer event attributes test variant for no-hover pointers
This adds a slightly different version of the existing PointerEventAttributesHoverablePointers test but for pointers that cannot hover (such as touches)
Reviewed By: lunaleaps
Differential Revision: D38401888
fbshipit-source-id: 4ed782cc2157dcaa8f6c294ae3589843d020bc92
Summary:
Fixed Flipper not recognizing app when using custom Xcode configuration names.
This fixes the problem that renaming the "Debug" Xcode configuration causes Flipper to not work. Despite using the recommended `:configurations` parameters and instructing Cocoapods that it was a debug build (see https://github.com/facebook/react-native/issues/34332), it still wouldn't recognize the app due to missing C preprocessor flags, specifically it was missing `-DFB_SONARKIT_ENABLED=1`.
## 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] - Flipper now supports custom Xcode build configuration names
Pull Request resolved: https://github.com/facebook/react-native/pull/34333
Test Plan:
I applied the PR change to 0.68.2 (which work similarly but code was refactored since then). I then used `patch-package` to test the change and the fix worked on 2 separate projects.
Patch-package change equivalent:
```diff
diff --git a/node_modules/react-native/scripts/react_native_pods.rb b/node_modules/react-native/scripts/react_native_pods.rb
index f2ceeda..2ea57d6 100644
--- a/node_modules/react-native/scripts/react_native_pods.rb
+++ b/node_modules/react-native/scripts/react_native_pods.rb
@@ -180,7 +180,7 @@ def flipper_post_install(installer)
# Enable flipper for React-Core Debug configuration
if target.name == 'React-Core'
target.build_configurations.each do |config|
- if config.name == 'Debug'
+ if config.debug?
config.build_settings['OTHER_CFLAGS'] = "$(inherited) -DFB_SONARKIT_ENABLED=1"
end
end
```
**Screen shot of Xcode after the patch has been applied, for RN v0.68.2:**

Reviewed By: dmitryrykun
Differential Revision: D38373812
Pulled By: cipolleschi
fbshipit-source-id: d2949927084160bf0c6f8af37a7966dd22fea9a6
Summary:
This is a nit. Did some cleanups on our Danger setup.
The most substantial work is:
- Moved over danger to run on `pull_request_target`. This allow us to re-use the Github Action access token without having to provide one.
- Fixed an issue with the `Pick Request` label which was not applied correctly.
- Removed the danger_id as we were not passing it correctly.
## Changelog
[Internal] - Let danger run on `pull_request_target`
Pull Request resolved: https://github.com/facebook/react-native/pull/34370
Test Plan: Tested locally with `yarn danger pr https://github.com/facebook/react-native/pull/34197`
Reviewed By: cipolleschi
Differential Revision: D38533144
Pulled By: cortinico
fbshipit-source-id: 178ce411eb956870563c4d51719ed4dae1f1536d
Summary:
This is a nit, but at least will help us reduce requests to rebase for PRs which maybe have a broken CI due to a stale base commit.
I've limited the scope to members and owners. A `/rebase` will trigger a rebase authored by Github Action bot.
We can play a bit around with it, and remove it if it doesn't really work well for us.
## Changelog
[Internal] - Setup Automatic Rebase given a /rebase comment
Pull Request resolved: https://github.com/facebook/react-native/pull/34369
Test Plan: Nothing to test here.
Reviewed By: cipolleschi
Differential Revision: D38509480
Pulled By: cortinico
fbshipit-source-id: 1df3927638b162d4a787c81372a835d583159498
Summary:
The Android version of PlatformConstants exposes the device's [UI Mode]( https://developer.android.com/guide/topics/resources/providing-resources#UiModeQualifier). It is missing the case for 'vrheadset', added in Android API 26. We should return the expected result when this is queried.
Changelog:
[Android][Added] - Expose UI_MODE_TYPE_VR_HEADSET in PlatformConstants
Reviewed By: rshest
Differential Revision: D38495875
fbshipit-source-id: fd904bd11213448415b7d75145d9ba6311ed407b
Summary:
This adds a simple debug UI to verify the keyboard events "keyboardDidShow" and "keyboardWillShow"
Changelog:
[Internal][Added] - Add "KeyboardExample" to RNTester
Reviewed By: cortinico
Differential Revision: D38500869
fbshipit-source-id: 99913a05849a7dd27dfdee2d622058b9c2604a7f
Summary:
- Current version of clang-format does not work on Apple M1/M2/... chipsets https://github.com/angular/clang-format/issues/78
Changelog:
[General][Fixed] - Make clang-format work in M1 (Apple Silicon)
Reviewed By: cortinico
Differential Revision: D38505844
fbshipit-source-id: c94a71dea82217e725a3609d72692a15a8fe22e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34368
When a user runs `RCT_NEW_ARCH_ENABLED=1 pod install` to install the dependencies for the New Architecture, Cocoapods prints a warning because of React Native is still set up with a legacy configuration.
This diff silences these warnings because they can confuse the final user.
**Note:** We need to keep this legacy configuration to support both the legacy and the New Architecture.
## Changelog
[iOS][Changed] - Silence warning due to react-native internal details.
Reviewed By: cortinico
Differential Revision: D38503405
fbshipit-source-id: b89857aa88435b1c64da52875606003239ff2e05
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34366
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D38500055
Pulled By: dmitryrykun
fbshipit-source-id: 0ef857ef1822522372a5743e9471b791d11e0181
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34354
This change simplifies the setup for New Architecture for users on Android.
Instead of using the Android.mk file, users can now use a CMake file which
encapsulate a lot of the complexities and reduces the maintainance cost.
Android.mk support is kept for backward compatibility.
Changelog:
[Android] [Changed] - Update the new app template to use CMake instead of Android.mk
Reviewed By: cipolleschi
Differential Revision: D38460536
fbshipit-source-id: 9d4c3b15be751921d34023b24c174044537e6f02
Summary:
Fixes https://github.com/facebook/react-native/issues/34229
Basically, the react android conflicts with the kotlin version that's defined in the top level build.gradle. To resolve it, the approach was to get the `kotlinVersion` defined in top level build.gradle and use it. If it's not defined, we use the default(1.6.10 as of now).
The reason behind not using the DSL is that it doesn't allow us to use the variables due to it's constrained syntax.
See [here](https://docs.gradle.org/current/userguide/plugins.html#sec:constrained_syntax)
So the idea was to use the build script to resolve the kotlin plugin and it works 👍 .
Kindly asking for review cortinico :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - refactored usage of kotlin plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/34255
Test Plan: Ran the node ./scripts/run-ci-e2e-tests.js --js --android --ios to verify it doesn't introduce any unexpected issues.
Reviewed By: dmitryrykun
Differential Revision: D38468567
Pulled By: cortinico
fbshipit-source-id: f9ab635fcf033f1d337ed90793ba1667957b8e01
Summary:
## Summary
Fixes https://github.com/facebook/react-native/issues/32497
Fixes https://github.com/facebook/react-native/issues/34212
The assigned HBC_SOURCEMAP_FILE path is incorrect as it does not reference the hermes bundle source map file
See: https://github.com/facebook/react-native/issues/32497#issuecomment-1171379674
## Changelog
[General] [Fixed] - using SOURCEMAP_FILE during xcode build phase with Hermes enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34111
Test Plan:
1. In a blank react-native project
1. Enable Hermes
1. Go to xCode -> Project -> Build Phases -> Bundle React Native code and images
3. Add `export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"` before `react-native-xcode.sh`
e.g.
```sh
export NODE_BINARY=node
export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"
../node_modules/react-native/scripts/react-native-xcode.sh
```
4. Make a release build `npx react-native run-ios --configuration Release` or `CMD + I` in xCode
5. Verify the build is successful
6. Verify the `.map` file is outputted at the specified path (`ios.jsbundle.map` in project root for the example above)
Reviewed By: cipolleschi
Differential Revision: D38460586
Pulled By: dmitryrykun
fbshipit-source-id: 54c1594b37fa2253896ce9739c1a9a712deecd0f
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34367
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D38500554
Pulled By: huntie
fbshipit-source-id: f2fd48b3a0a608d488c1edb85ea8c424029bd9c9
Summary:
changelog: [internal]
`_forceDispatchNextScrollEvent` is already called inside `- (void)scrollToOffset:(CGPoint)offset animated:(BOOL)animated`. No need to call it before.
Reviewed By: cipolleschi
Differential Revision: D38499299
fbshipit-source-id: cf6635e02bf582346869f77194cf06be7939351f
Summary:
I'm extending `test_android_template` to use a CI Matrix. This will allow us to make sure that we test a new app template against Debug/Release and against New/Old Arch.
This will make sure we catch a lot of bugs early on 👍
## Changelog
[Internal] - Setup a build matrix for test_android_template
Pull Request resolved: https://github.com/facebook/react-native/pull/34355
Test Plan: Will wait for a green CI
Reviewed By: cipolleschi
Differential Revision: D38499773
Pulled By: cortinico
fbshipit-source-id: 5a24c21d111fb4ae0f4600d86b786021f6ad2abe
Summary:
https://github.com/facebook/react-native/pull/34310 introduced Gradle 7.5.0, but I noticed that the Gradle team actually missed to remove the `Incubating` annotation for the Java 18 support. The latest 7.5.1 is fixing that. More details can be found here: https://github.com/gradle/gradle/releases/tag/v7.5.1
## Changelog
[Android] [Changed] - Bump Gradle to 7.5.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34359
Test Plan: Successfully build on a local project. I can share the actual branch if needed.
Reviewed By: cipolleschi
Differential Revision: D38497804
Pulled By: cortinico
fbshipit-source-id: 792b83707d5b6aaf7ef29531f82a1bc9224b3204
Summary:
We have a older version of caniuselite in the yarn.lock.
This is causing several warnings on console which I'm resolving with:
`npx browserslist@latest --update-db`
Changelog:
[Internal] [Changed] - Update caniuse-lite with `npx browserslist@latest --update-db`
Reviewed By: cipolleschi
Differential Revision: D38459471
fbshipit-source-id: 4476e2f925f693e4aff457b80906faa51247772c
Summary:
Use of `__attribute__` and `__unused` is compiler specific. Opt for standard `[[maybe_unused]]` instead.
## Changelog
[General] [Fixed] - Remove compiler-specific syntax.
Pull Request resolved: https://github.com/facebook/react-native/pull/34357
Test Plan: Built on react-native-windows.
Reviewed By: cipolleschi
Differential Revision: D38498481
Pulled By: javache
fbshipit-source-id: af43206788f54dda3b747b6417e20096c7d520e8
Summary:
After. D38153924 (https://github.com/facebook/react-native/commit/e24ce708abffee8ec4521ba8162ea8964eb4429f), layout mount items have 7 int arguments but the logger only pulls out and displays 6, which leads to the following exception: "Caught exception trying to print java.lang.IllegalArgumentException: Invalid type argument to IntBufferBatchMountItem"
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Differential Revision: D38472664
fbshipit-source-id: 1583a5514c2ab662eaf5c4ce4bf33c958cb05282
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This adds a `StateSafePureComponent`, which will override `setState`, along with `this.props` and `this.state`, in order to add runtime enforcement that `this.props` and `this.state` are not accessed during a state update where we should be relying on parameter instead. This should be landed after the fixes for unsafe `this.props`/`this.state` usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Enable setState() hooks
Reviewed By: rshest
Differential Revision: D38294338
fbshipit-source-id: d04ff39f68df90adc9f4680887d308d997903675
Summary:
Current creation of the errorProcessor lambda does a full copy of folly::dynamic object, which for large objects can cause 1000's of memory allocations, and thus increasing app's memory footprint and speed.
Changelog:
[General][Fixed] - Avoid full copy of large folly::dynamic objects in JSIExecutor#defaultTimeoutInvoker
Reviewed By: sammy-SC
Differential Revision: D38368392
fbshipit-source-id: 88579a7069891828cf6dae130c4964db6b494565
Summary:
Make the interface to enable/disable debugging symmetrical; both enabling and disabling are done by passing in a reference to the RuntimeAdapter.
Doing so requires moving ownership of the RuntimeAdapter, so each caller (java2js, arfx engine, React Native, react-native-github, and venice) has been updated to own their adapter.
Additionally, the two implementations of the Inspector connection (react-native-github and arfx engine) have been updated to expect and use the new argument.
`Connection::getRuntime` could be removed and replaced with calls to `Connection::getRuntimeAdapter::getRuntime`. I've left that choice to a followup diff, as this one is getting messy enough as it is.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38242964
fbshipit-source-id: f2a3354f9d424b203a76d2c15122a6515a0926f2
Summary:
Changelog: [Internal]
Debugging is enabled via `enableDebugging` with a `RuntimeAdapter` that provides a `HermesRuntime`. This same `HermesRuntime` should be passed to `disableDebugging`, not a decorated version. Change the argument type of `disableDebugging` to steer callers in the right direction.
Reviewed By: jpporto
Differential Revision: D38051662
fbshipit-source-id: ae436a4af12fa01143bfbcdb97e65e4fca90154d
Summary:
Changelog: [Internal]
Provide a `HermesRuntime` from the `RuntimeAdapter` (instead of a decorated Hermes runtime).
As the Inspector can now directly access the `HermesRuntime` (which exposes access to the debugger), `RuntimeAdapter::getDebugger` is no longer necessary; remove it.
Reviewed By: jpporto
Differential Revision: D38050821
fbshipit-source-id: fa83165a9348bdff0dce1b04ec1afb81d2b1c3e2
Summary:
Changelog: [Internal]
Make runtime use more consistent, always using the same undecorated runtime. This prevents the previous mixing of decorated and undecorated runtimes.
Reviewed By: jpporto
Differential Revision: D38035166
fbshipit-source-id: 81929e42ccc4de6d5c5c09ee7ee31f055af82735
Summary: Changelog: [Internal] Add logic for `isPrimary` for PointerEvent object and set other properties to their default value
Reviewed By: javache
Differential Revision: D38363163
fbshipit-source-id: 5ec9de69fb5b34295f1da6daedd5c67e3bd3727e
Summary:
Changelog: [Internal] - Instead of using toolType which is a property per pointer in the MotionEvent, let's use [getSource](https://developer.android.com/reference/android/view/MotionEvent#getSource()) which is the source for the entire event (all pointers).
This aligns with what we've seen on Android when we have a mouse and touch input, there is only one active source input device.
And removes the need for checking a flag we set here: D36958947
Reviewed By: NickGerleman
Differential Revision: D37702090
fbshipit-source-id: ba2a4f0c28e1aff2b8b04314fe6f737b66ed0be3
Summary:
Expo Go was using `nativeInjectHMRUpdate` for [snack](https://snack.expo.io/) to provide stack traces to OTA errors. `nativeInjectHMRUpdate` was replaced with `globalEvalWithSourceUrl` [here](https://github.com/facebook/react-native/commit/71c84cf6bebba701bb23b135e079aa68c05f4441). The issue with `globalEvalWithSourceUrl` is that it is stripped in RELEASE builds, and Expo Go is installed via the App Store, making it a release build.
I propose we keep the method, `eval` is still exposed in production so there's no increase in security risk, simply provides a better DX for multipurpose development clients.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Expose `globalEvalWithSourceUrl` in production builds.
[iOS] [Added] - Expose `globalEvalWithSourceUrl` in production builds.
Pull Request resolved: https://github.com/facebook/react-native/pull/34319
Test Plan: - Function should be available as `global.globalEvalWithSourceUrl` in a production build.
Reviewed By: christophpurrer
Differential Revision: D38312111
Pulled By: motiz88
fbshipit-source-id: adcd83ad1103c8fd4c6d5d7aec765f27881e0432
Summary:
Resolves https://github.com/facebook/react-native/issues/34116.
In a nutshell, the problem was a missing `.exe` extension on the `hermesc` binary path when running on Windows OS. The missing extension causes the method `.exists()` of the File instance to always return false, so none of the conditions ever met and an error was thrown whenever a release build with Hermes enabled was run on Windows. More details can be found in the comments on the above issues.
## 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
-->
[Android] [Fixed] - Fix error of release builds with Hermes enabled for Windows users
Pull Request resolved: https://github.com/facebook/react-native/pull/34151
Test Plan:
### Reproduce
Changes on Gradle scrips are better tested on an actual application. To reproduce the issue you can:
1. Create or reuse a React Native application with version `v0.69.1` on a Windows machine
2. Enable Hermes on Android following the steps on the [documentation](https://reactnative.dev/docs/hermes#enabling-hermes)
3. Clean the build folder: `cd android && ./gradlew clean`
4. Bundle the JS and assets for a release version: `./gradlew bundleReleaseJsAndAssets`
5. The build fails with the following error:
```shell
Execution failed for task ':app:bundleReleaseJsAndAssets'.
> java.lang.Exception: Couldn't determine Hermesc location. Please set `project.ext.react.hermesCommand` to the path of the hermesc binary file. node_modules/react-native/sdks/hermesc/%OS-BIN%/hermesc
```
### Test the changes
Follow the same steps above using the fix on this PR and the error should disappear 🙂
Reviewed By: NickGerleman
Differential Revision: D37755468
Pulled By: cortinico
fbshipit-source-id: 2ad0ced583555b907259df116f64a45da6d153f3
Summary:
This Pull Request aims at removing the making of reactnativeutilsjni as it is built from the same sources as reactnativejni. It also replaces references to reactnativeutilsjni with reactnativejni.
This should get rid of `reactnativeutilsjni.so` while reusing `reactnativejni.so` in it's place. This should give us some size improvements in the finally built apk.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Replaced reactnativeutilsjni with reactnativejni in the build process to reduce size
Pull Request resolved: https://github.com/facebook/react-native/pull/34339
Test Plan:
1. Ran the CMakelist.txt file using CMake and I could see that reactnativeutilsjni.dir is no longer generated with my changes.
2. Built the aar from this branch in Android Studio and build happened successfully.
I am not sure if we could run any more tests. Please let me know in case anymore testing is required and I can do accordingly
Reviewed By: cortinico
Differential Revision: D38400481
Pulled By: genkikondo
fbshipit-source-id: 592736e56441328389ae89135667c336ff8018e6
Summary:
This PR fixes an edge case where `prepare_hermes_workspace` job was using a commit to build hermes but `build_hermes_macos` was using a different one. This resulted in cache poisoning where subsequent jobs thoughts to be using a version of Hermes while the restored cache was loading a different one.
<img width="1440" alt="Screenshot 2022-08-03 at 06 26 14" src="https://user-images.githubusercontent.com/11162307/182570809-5c6d9323-c3fb-4834-952f-7d07b99c4880.png">
This PR simplifies the flow, creating a single `.hermesversion` file in the `prepare_hermes_workspace` workspace and using that file as key for all the caches.
## Changelog
[iOS] [Changed] - upload test result as artifact
Pull Request resolved: https://github.com/facebook/react-native/pull/34329
Test Plan:
CircleCI is now green and all the caches are using the same file to create the checksum.
We can verify that by looking at the `Save cache`/`Restore cache` commands related to Hermes. (In the workflow, their hash is always `B1NEL0P0OKhQYtk8DE150bXSoGrdWUweedHKmqNqnjo`)
Also, we removed completely the code that could create a version misalignment.
Reviewed By: cortinico
Differential Revision: D38382895
Pulled By: cipolleschi
fbshipit-source-id: 5f5501a7ef313eb56abda336716b24b486a34a1f
Summary:
Fixes https://github.com/facebook/react-native/issues/34034.
The FlatList doesn't call renderItem on nullish values when numColumns > 1, but it does when numColumns is not set (or equals 1).
I think the behavior should be consistent, so I updated the code so renderItems is called for every items.
I believe the condition `item != null` was here to make sure renderItem isn't called for index outside of data range, so I replaced it with `itemIndex < data.length`.
## 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] - Fix FlatList not calling render items for nullish values when numColumns > 1
Pull Request resolved: https://github.com/facebook/react-native/pull/34205
Test Plan:
- I added a failing test corresponding to the issue, and the test now succeeds.
- I used the same code as in the test on a newly initialized app on RN 0.69 and made sure renderItem was called for every items as expected.
Reviewed By: NickGerleman
Differential Revision: D38185103
Pulled By: lunaleaps
fbshipit-source-id: 4baa55caef9574c91c43c047f9e419016ceb39db
Summary:
Changelog:
[Android][Fixed] - Fix regression when setting shadow node properties.
Also simplified the corresponding macros to avoid using lambdas altogether, as they are not required.
Note that this **does not** modify any constexpr-related semantics of the existing code, as the main constexpr macro, `CONSTEXPR_RAW_PROPS_KEY_HASH` evaluation result is still contstexpr value, and the other ones already involved non-const parts (see my comments).
Reviewed By: NickGerleman
Differential Revision: D38356411
fbshipit-source-id: 22c330d3425c8aed36693f4652f1b257d2dc96be
Summary:
Some custom logic is applied to workaround a platform bug where velocity may be incorrect on Android P. [The bug in question](https://issuetracker.google.com/issues/112385925) appears to have been fixed before Android `Q` was released, so we shouldn't *need* to apply the workaround on other versions.
As described in https://github.com/facebook/react-native/issues/34226 the workaround can adversely affect certain scroll behaviors, which can easily be reproduced when you briefly scroll one direction then quickly fling the opposite direction (see the video in the linked ticket).
This PR changes the workaround to *only* be applied on Android P, in order to avoid causing weird scroll behavior on versions that are not actually affected by the bug the workaround is working around.
## Changelog
```
[Android] [Fixed] - Fix occasionally incorrect ScrollView fling behavior
```
Pull Request resolved: https://github.com/facebook/react-native/pull/34233
Test Plan:
- Repro the strange fling behavior in the current version (See video attached in https://github.com/facebook/react-native/issues/34226)
- Verify that the string fling behavior is fixed with this patch
- Verify that fling behavior still works as expected on Android versions affected by the [original bug](https://issuetracker.google.com/issues/112385925), and those immediately following it (to verify that the bug being worked around was, in fact, fixed as expected).
Reviewed By: javache
Differential Revision: D38287277
Pulled By: ryancat
fbshipit-source-id: 2c786872c4d41655b3849bb92e02f1f16c663b41
Summary:
This PR runs eslint in PR using Danger.
## Changelog
[General] [Changed] - Run ESLint in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/34305
Test Plan:
1. Add a JS lint error in the package/react-native-codegen package.
2. Observe the CI task post a message with the errors
3. Fix the errors
4. Observe the CI task report completion with no errors
Reviewed By: cortinico
Differential Revision: D38315268
Pulled By: cipolleschi
fbshipit-source-id: 9984402ee427dd62d47dd716f73c030e6d0f7b5e
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
`_createViewToken()` is called during state changes. Use explicit props passed in.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to _createViewToken()
Reviewed By: genkikondo
Differential Revision: D38294339
fbshipit-source-id: dc215e267f126a3789742c14c35479f509822710
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
`_onCellFocusCapture()` derives state from existing state, so it should be wrapped in a state updater to compare against the latest value in the batch.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Use correct form of setState() in _onCellFocusCapture()
Reviewed By: genkikondo
Differential Revision: D38293583
fbshipit-source-id: 1d0e5152e6c1757408e39dff225e07accc5ee49f
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Use supplied props in `_keyExtractor()`, which is used to map between frame index and identity.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to _keyExtractor()
Reviewed By: genkikondo
Differential Revision: D38293586
fbshipit-source-id: e50823bacdf45adad3b8b655d66d305a1762e9b8
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This forwards props to `__getFrameMetricsApprox()` and `_getFrameMetrics()` . This is called in a variery of places, so we need to pass `FrameMetricProps` through more places, and update public/test usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to __getFrameMetrics()
Reviewed By: genkikondo
Differential Revision: D38293591
fbshipit-source-id: c1499d722b69eb4b5953124ee8b8c3d15e912d93
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Use passed props in `computeWindowedRenderLimits()`, which is called during a state update.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to computeWindowedRenderLimits()
Reviewed By: genkikondo
Differential Revision: D38293588
fbshipit-source-id: 1330a003c1354bbd63c0b7b33a013e85e96fdc64
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Change `_updateViewableItems()` to accept an explicit set of props, and a CellRenderMask, instead of using `this.props` and `this.state`. The eventual sink are the `_getFrameMetric*` functions, so a minimal projection of props is added that we can pass through to it.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Move Props to VirtualizedListProps
Reviewed By: genkikondo
Differential Revision: D38293587
fbshipit-source-id: 164fd4af7c370d905af53b0e9aafb3592d8659cc
Summary:
Fix macro errors for Windows. Current syntax breaks the build of the React Common project on Windows because the ({...}) syntax is not supported; must be replaced with lambda expressions.
Resolves https://github.com/facebook/react-native/issues/34090
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix macro errors for Windows.
lyahdav JoshuaGross
Pull Request resolved: https://github.com/facebook/react-native/pull/34299
Test Plan: Build on react-native-windows repo. Tested in RNW app.
Reviewed By: javache
Differential Revision: D38272966
Pulled By: NickGerleman
fbshipit-source-id: e76eac11cde173ef49465d01d793c593017f2ab7
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Remove `this.props` usage during state update where we can just use the props directly.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Remove _isVirtualizationDisabled()
Reviewed By: genkikondo
Differential Revision: D38293589
fbshipit-source-id: af18f867fc880d5363134fe0d6f985efaf8be6c5
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This moves public VirtualizedList types to a new file, shared between both `VirtualizedList`, and `VirtualizedList_EXPERIMENTAL`. This allows us to make public interface changes in a single place.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Move Props to VirtualizedListProps
Reviewed By: genkikondo
Differential Revision: D38293585
fbshipit-source-id: 344d94466a2741ee67eb5754de5506eb3e265c5b
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Replace usages of `this.state` and `this.props` where we are already passed the newer revision of the state we want.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Remove bad usage in _adjustCellsAroundViewport()
Reviewed By: genkikondo
Differential Revision: D38293584
fbshipit-source-id: 807f36600d2fd82c87205195dd61956785bdbd2c
Summary:
This diff fixes the bug T127619309 by exit early during calculateTransformedFrames if currentShadowNode cannot be casted
This is a bug that fired in fb4a but we didn't have a way to reproduce locally.
We are going to release this and enable feature flag with a MC
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38280674
fbshipit-source-id: 1c42c17678d8473564e4075a78d3c688efed1a23
Summary:
While doing some testing with cipolleschi on React Native 0.70.0 we realized that custom Java Package is not properly propagated when invoking codegen for external libraries.
This PR fixes it.
## Changelog
[Internal] - Introduce findPackageJsonFile to address issue with GenerateCodegenArtifactsTaskTest
Pull Request resolved: https://github.com/facebook/react-native/pull/34321
Test Plan: Added JUnit tests + Tested locally with cipolleschi
Reviewed By: cipolleschi
Differential Revision: D38314770
Pulled By: cortinico
fbshipit-source-id: ec2de1ba59ffc8fb0644f422521ced642b38d2c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34307
There are unreleased changes on eslint-config-react-native-community, I'm bumping the version for this package so we can publish it.
Changelog:
[General] [Changed] - Bump eslint-config-react-native-community
Reviewed By: dmitryrykun
Differential Revision: D38279512
fbshipit-source-id: 46492f7e99d31c0a5917d41726ecc20fada1582f
Summary:
Calculation of TransformedFrames was a method introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61) to fix rendering of inverted flat lists.
We found that this operation is crashing in fb4a causing the UBN T127619309
This diff creates a feature flag to disable the calculation of TransformedFrames in Layoutable ShadowNodes. **The goal of this diff is to revert the behavior introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61)**
The featureFlag is disabled in fb4a and enabled in react AR (because ReactAr apps relies on the calculation of TransformedFrames and these apps are not affected)
The root cause of the bug will be fixed by D38280674 (which still requires more testing and investigation)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D38286857
fbshipit-source-id: 721cd0554ae6a6b369b3f8dbb584160a270d0f18
Summary:
This change adds the following methods to jsi::BigInt
* [static] fromInt64(value): creates a jsi::BigInt from a signed 64-bit value
* [static] fromUint64(value): creates a jsi::BigInt from an unsigned 64-bit value
* [static] strictEquals(a, b): return a === b, a and b are BigInts
* asInt64(): truncates the BigInt to a single signed 64-bit integer; throws a JSIException if the truncation is lossy.
* getInt64(): truncates the BigInt to a single signed 64-bit integer
* isInt64(): returns true if the BigInt can be truncated losslessly to an int64_t
* asUint64(): truncates the BigInt to a single unsigned 64-bit integer; throws a JSIException if the truncation is lossy.
* getUint64(): truncates the BigInt to a single unsigned 64-bit integer
* isUint64(): returns true if the BigInt can be truncated losslessly to an uint64_t
* toString(radix): converts the BigInt to a string representing the number in the given radix.
A lossy truncation is one that yields a result from which the BigInt cannot be reconstructed from, i.e.,
* BigInt::fromInt64(b.toInt64()) !== b
* BigInt::fromUint64(b.toUint64()) !== b
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D37909139
fbshipit-source-id: 172848024f8367aed73cc602f38cde22f03cac8f
Summary:
The `codegenConfig` unified configuration for New Architecture on Android relies on the Gradle plugin finding the package.json correctly. Currently we use the `root` folder to resolve the package.json. This works fine when invoking the codegen for the app module, but it doesn't work well when invoking the codegen for modules.
This extends the algo to make sure we first, look for a `package.json` in `..` and fallback to the one in the root if not found.
## Changelog
[Internal] - Improve package.json search mechanism for codegenConfig support
Pull Request resolved: https://github.com/facebook/react-native/pull/34298
Test Plan: It's hard to write a unit test for this as it's inside a lambda, I'll look into doing this though. I've tested this on RNNewArchitectureApp and it works fine.
Reviewed By: cipolleschi
Differential Revision: D38249663
Pulled By: cortinico
fbshipit-source-id: 3cfd6a31e9f75d7b19b15f77bbd5131af42be9d3
Summary:
While I was working on rewriting `react-native-slider` to Fabric I found a weird bug that prevented the slider to be set as disabled (to be exact: call the method `slider.setEnabled(false)`. As it turned out the `accessibilityState` (with value: `accessibilityState={{disabled: true}}` prop occurred after the `enabled={false}` prop that I was passing to the slider, which lead to both of this props overwrite each other.
Handling of `accessibilityState` props inside view leads to always overwriting the enabled prop to true (even if we explicitly set it to `{disabled: false}`.
Workaround for this was to reorder the props, so that the `accesibilityState` occur before `disabled`, but I think it's better to not set `view.setEnabled(true)` if we are passing a disabled property.
## Changelog
[Android] [Fixed] - Fix accessibilityState overwriting view's disabled state on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34287
Test Plan:
Change order of props inside native component implementation (that `disabled` occurs before `accesibilityState`). For example: `Libraries/Components/Slider/Slider.js`
<details>
<summary>Video showing the bug in RNTester (using Switch component)</summary>
https://user-images.githubusercontent.com/52801365/181287547-964f50e2-55dc-450f-b413-0d1c14d4bb83.mp4
</details>
Reviewed By: NickGerleman
Differential Revision: D38209232
Pulled By: dmitryrykun
fbshipit-source-id: 93d423716f89b45251be9d5aefcf01f7bd776f2c
Summary: Changelog: [General][Changed] - `eslint-plugin-specs` package has prepack hook that changes `PACKAGE_USAGE` variable of `react-native-modules.js` to `true`. This changed file is can then be published to NPM, but should not be committed to the repo. This diff adds postpack hook that reverts the change, so we do not have to do it manually.
Reviewed By: cipolleschi
Differential Revision: D38244367
fbshipit-source-id: 818dbdea82e7e4b89094b3e27ae2d63b9e736659
Summary:
I've realized that the gradle plugin is currently looking at `.js` files for task re-execution. This means that, while the *.ts would still be considered when the codegen is invoked, an edit on one of those file, won't retrigger the codegen on Android.
This change fixes it so that we consider both `*.ts` and `*.js` files.
## Changelog
[Android] [Fixed] - Make sure *.ts files are considered for task avoidance in the Gradle Plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/34296
Test Plan: Tests are attached.
Reviewed By: cipolleschi
Differential Revision: D38246125
Pulled By: cortinico
fbshipit-source-id: 80efcc9ef747c598ca040d65b25d270593c8aed2
Summary:
VirtualizedList state is represented in terms of [first, last] ranges, where it is possible to express a zero-cell range by having [n, n-1]. This includes some awkward examples, like [0, -1] being valid.
CellRenderMask assumes `addCells` is called with at least one cell, with VirtualizedList previously guarding against adding the no cell case. This guard is present for adding main cell regions, but not for `_initialRenderRegion()`, which can be overridden to have a zero length as well.
This moves the `CellRenderMask` to be permissive of zero-length cell regions, and removes the caller guard.
Changelog:
[Internal][Fixed] - Allow empty cell ranges in CellRenderMask
Reviewed By: rshest
Differential Revision: D38184444
fbshipit-source-id: d2dadfdd9628b24f894126d63b1eb93f6387b877
Summary:
Fixes https://github.com/facebook/react-native/issues/34120
The new React Native architecture doesn't check `needsCustomLayoutForChildren` so it wrongly positions native views on Android. In https://github.com/facebook/react-native/issues/34120 there are videos comparing the positioning of a native action view in the old and the new architecture.
This PR passes the parent tag to the `updateLayout` method of the `SurfaceMountingManager`. The `SurfaceMountingManager` calls `needsCustomLayoutForChildren` on the parent view manager (copied the code from the `NativeViewHierarchyManager` in the old architecture).
**NOTE** - I wasn't sure where to get the parent shadow view from so I've put in my best guesses where I could and left it as `{}` otherwise.
## Changelog
[Android] [Fixed] - Migrate `needsCustomLayoutForChildren` check to the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/34254
Test Plan:
I checked the fix in the repro from https://github.com/facebook/react-native/issues/34165. Here is a video of the action view closing using the native button that is now visible in the new architecture.
https://user-images.githubusercontent.com/1761227/180607896-35bf477f-4552-4b8a-8e09-9e8c49122c0c.mov
Reviewed By: cipolleschi
Differential Revision: D38153924
Pulled By: javache
fbshipit-source-id: e2c77fa70d725a33ce73fe4a615f6d884312580c
Summary:
The current `test-manual-e2e.sh` script is broken on Android + Hermes + New App Template.
This commit fixes it. Specifically:
- There is no need to generate Maven Artifacts for RN Tester, as RN Tester consumes them from source.
- There is instead a need to generate Maven Artifacts for New App Template, as they need to be included inside the NPM package.
- The `:ReactAndroid:hermes-engine:installArchives` task needs to invoked to also generate the Hermes-engine .aar for bundling.
## Changelog
[Internal] - Fix test-manual-e2e on Android/Hermes for New App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34294
Test Plan: I've tested this against the `0.70-stable` branch and I was able to run an App from the New Template properly.
Reviewed By: dmitryrykun
Differential Revision: D38239238
Pulled By: cortinico
fbshipit-source-id: b3d95bad21515b12a91e29147e70ba8323896660
Summary:
Existing code may pass negative values for `initialScrollIndex`, which the previous implemnentation handled gracefully. Handle the case gracefully in VirtualizedList_EXPERIMENTAL as well.
Changelog:
[Internal][Fixed] - Gracefully handle negative initialScrollIndex in VirtualizedList_EXPERIMENTAL
Reviewed By: rshest
Differential Revision: D38183625
fbshipit-source-id: 9aea91c4cf3ce2190d769f34ce728a109efc88d4
Summary:
If FlatList is passed non-array data it will return `undefined` as the result of `getItemCount()` to VirtualizedList. This change makes it return `0` instead, to signify there are no valid items to attempt to accces.
There are a set of invariants on properties passed to FlatList, to curb incorrect types at runtime, but there is existing code which runs into the condition.
Changelog:
[Internal][Fixed] - Guard FlatList getItemCount() against non-array data
Reviewed By: javache
Differential Revision: D38198351
fbshipit-source-id: 9efd0df7eeeba17078e2c838d470c4b0d621b9a0
Summary:
VirtualizedList_EXPERIMENTAL has a different flow signature from VirtualizedList. This does not cause an error in unit tests, which are untyped, but prevents injecting VirtualizedList_EXPERIMENTAL via the current API from flowtype. This diff updates the injection interface to allow a more relaxed type, validating safety at runtime.
Changelog:
[Internal][Changed] - Allow injecting looser VirtualizedList
Reviewed By: javache
Differential Revision: D38143682
fbshipit-source-id: 054bbc5092823f4e4413d69d3d72a7ecdd71a6a2
Summary:
Implements most of systrace using androidx.tracing, this makes it usable using Android Studio profiler systrace.
## Changelog
[Android] [Added] - Improve OSS systrace
Pull Request resolved: https://github.com/facebook/react-native/pull/34252
Test Plan:
Run a systrace in Android Studio for RN Tester and make sure RN specific sections are there.
<img width="1263" alt="image" src="https://user-images.githubusercontent.com/2677334/180593493-fc087b4a-2253-43e1-b246-bed3e7bba7ac.png">
Reviewed By: NickGerleman
Differential Revision: D38116890
Pulled By: dmitryrykun
fbshipit-source-id: 744bedbf9ad4004488340a5b4e93d936d9a1e582
Summary:
Flow and TypeScript are two very similar programming languages. They are both recognizable as inputs for turbo module codegen. It is reasonable to require equivalent Flow and TypeScript turbo module definition generates the same output.
I add some test cases to ensure this. Glad that no functional inconsistency is found here.
## Changelog
[General] [Changed] - codegen: ensure equivalent Flow and TypeScript TM definition generates the same output
Pull Request resolved: https://github.com/facebook/react-native/pull/34251
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: dmitryrykun
Differential Revision: D38116756
Pulled By: cipolleschi
fbshipit-source-id: 476adbd171a35813923f2020c826d21b1fc2eeed
Summary:
cherry-pick changes from https://github.com/facebook/react-native/issues/34214 to main. because the `react_native_pods.rb` on main is quite different from 0.69, i have separated pr for the change.
## Changelog
[iOS] [Fixed] - Fix React-bridging headers import not found
Pull Request resolved: https://github.com/facebook/react-native/pull/34271
Test Plan: RNTester + pod install and verify pod targets to have `React-bridging` in header search paths.
Reviewed By: cipolleschi
Differential Revision: D38122074
Pulled By: dmitryrykun
fbshipit-source-id: 64569abbfa3a684f0d6b84c9e3222bfc9a171061
Summary:
I've noticed that `BackHandler.removeEventListener()` performs two same `indexOf()` calls on an array that is not changing. By removing extra `indexOf` we can slightly improve time complexity of `BackHandler.removeEventListener()` from O(2n) to O(n)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Remove extra indexOf call in BackHandler.removeEventListener
Pull Request resolved: https://github.com/facebook/react-native/pull/34281
Test Plan:
1. Add the following code to any function component
```javascript
BackHandler.addEventListener('hardwareBackPress', () => true).remove();
```
2. Press on hardware back button
Expected result: Application closes
Reviewed By: dmitryrykun
Differential Revision: D38198510
Pulled By: javache
fbshipit-source-id: eab6a57689a536623138a4b3ebddbf9ba87d281f
Summary:
At the moment we are having a bug that whenever we hit a "Done" button in an input field, a value is not submitted back, so the users cannot complete their work. Here is an example:
https://pxl.cl/28xFq
To fix it, we call a textInputShouldSubmitOnReturn method on Accessory button click.
Changelog
[IOS][Fixed] - Fix keyboard accessory button not triggering onSubmitEditing
Reviewed By: dmitryrykun
Differential Revision: D38152974
fbshipit-source-id: fc026dffd641966cd3d342d95a56c43c71008036
Summary:
The removeEventListener method has been removed from AccessibilityInfo and Linking in this PR: https://github.com/facebook/react-native/issues/33580, so I believe we can remove it from the mocks.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Removed] - Remove removeEventListener from AccessibilityInfo and Linking mocks
Pull Request resolved: https://github.com/facebook/react-native/pull/34260
Test Plan: I executed jest and everything is still green.
Reviewed By: dmitryrykun
Differential Revision: D38198653
Pulled By: GijsWeterings
fbshipit-source-id: 72d10ca54cd505d7c76e7531c9df718b1a9b9ed1
Summary:
# This Change
https://github.com/react-native-community/discussions-and-proposals/pull/335 discussed a set of problems with VirtualizedList and focus. These were seen as severe externally for a11y on desktop. The issues center on users of keyboard and accessibility tools, where users expect to be able to move focus in an uninterrupted loop.
The design and implementation evolved to be a bit more general, and without any API-surface behavior changes. It was implemented and rolled out externally as a series of changes. The remaining changes that were not upstreamed into RN are rolled into https://github.com/facebook/react-native/pull/32646
This diff brings this change into the repo, as a separate copy of VirtualizedList, to measure its impact to guardrail metrics, without yet making it the default implementation. The intention is for this to be temporary, until there is confidence the implementation is correct.
## List Implementation (more on GitHub)
This change makes it possible to synchronously move native focus to arbitrary items in a VirtualizedList. This is implemented by switching component state to a sparse bitset. This was previously implemented and upstreamed as `CellRenderMask`.
A usage of this is added, to keep the last focused item rendered. This allows the focus loop to remain unbroken, when scrolling away, or tab loops which leave/re-enter the list.
VirtualizedList tracks the last focused cell through the capture phase of `onFocus`. It will keep the cell, and a viewport above and below the last focused cell rendered, to allow movement to it without blanking (without using too much memory).
## Experimentation Implementation
A mechanism is added to gate the change via VirtualizedListInjection, mirroring the approach taken for Switch with D27381306 (https://github.com/facebook/react-native/commit/683b825b327e7fa71e87e3d613cb9acd37c24288).
It allows VirtualizedList to delegate to a global override. It has a slight penalty to needing to import both modules, but means code which imports VirtualizedList directly is affected the changes.
Changelog:
[Internal][Added] - Add VirtualizedList_EXPERIMENTAL (CellRenderMask Usage)
Reviewed By: lunaleaps
Differential Revision: D38020408
fbshipit-source-id: ad0aaa6791f3f4455e3068502a2841f3ffb40b41
Summary:
This change is in preparation of adding a separate `VirtualizedList_EXPERIMENTAL` component.
Both the original, and experimental lists use `VirtualizedListContext`, which itself references back to the VirtualizedList class type. VirtualizedList private methods are currently included in the type system, and are called in other VirtualizedList code (see https://github.com/facebook/react-native/commit/b2f871a6fa9c92dd0712055384b9eca6d828e37d). This prevents Flow from seeing the two classes are compatible if "private" methods change.
My first attempt was to parameterize the context, to allow both `VirtualizedList`, and `VirtualizedList_EXPERIMENTAL` to use the same code without sacrificing type safety or adding further duplication. This added more complexity than it is worth, so I am instead loosening the type on VirtualizedListContext to pass around a more generic handle.
Changelog:
[Internal][Changed] - Allow VirtualizedListContext to support different component type
Reviewed By: javache
Differential Revision: D38017086
fbshipit-source-id: 91e8f6ab2591d3ae9b7f9263711b4a39b78f68e0
Summary:
Bumping main to latest version of CLI available; in particular, we want to ensure to propagate this fix https://github.com/react-native-community/cli/pull/1655.
After merging, we'll cherry-pick in the `0.70-stable` branch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to v9.0.0-alpha.5
Pull Request resolved: https://github.com/facebook/react-native/pull/34275
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D38151383
Pulled By: dmitryrykun
fbshipit-source-id: afdafb496a159ad766dd322a4aab4bda6146edf0
Summary:
The `NSMutableAttributedString` was initialized with the same backing store as the cached attributed string on the shadow queue (background thread), but then passed to the main thread and ultimately the JS thread.
This explicitly copies the mutable attributed string into an immutable one on the shadow thread before passed off to other threads, which hopefully will address the `convertIdToFollyDynamic` crash that always includes `RCTBaseTextInputShadowView` touching an attributed string on the shadow queue in the trace.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38133150
fbshipit-source-id: f371da5d17a32c3341287cd3e9730b31a98495f9
Summary:
Changelog: [iOS][Internal] - Add isPrimary property implementation to the PointerEvent object
This diff adds the `isPrimary` property to the PointerEvent object iOS implementation. In addition this adds a related change where we "reserve" the 0 touch identifier for mouse events and the 1 identifier for apple pencil events. This is an easy way to ensure that these pointers are always consistent no matter what happens. Since mouse & pencil pointers should always be considered the primary pointer, that allows us to focus the more advanced primary pointer differentiation purely on touch events.
The logic for this touch event primary pointer differentiation is essentially setting the first touch it recieves as a primary pointer, setting it on touch registration, and sets all subsequent touchs (while the first touch is down) as not the primary pointers. When that primary pointer is lifted, the class property keeping track of the primary pointer is reset and then the **next** pointer (secondary pointers which had already started before the previous primary pointer was lifted are not "upgraded" to primary) is marked as primary. A new platform test is also included in this diff in order to verify the aforementioned behavior.
Reviewed By: lunaleaps
Differential Revision: D37961707
fbshipit-source-id: ae8b78c5bfea6902fb73094fca1552e4e648ea44
Summary:
In `0.70-stable` we started seeing `yarn run lint` fail; turns out, this is happening because the latest release of `react-native/eslint-plugin-specs` 0.0.4 (from https://github.com/facebook/react-native/commit/ea8d8e2f49ea3ce15faeab500b661a1cacacf8a8) is faulty: the underlying reason is that since 0.0.2 there was this local workaround in place https://github.com/facebook/react-native/commit/2d06e6a4c9261bb7790cf217b66145415301bc54 (that changes a flag from false to true) but in NPM 8 the lifecycle hook `prepublish` has [been deprecated](https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts) so this pre publishing script to change the flag was not run (you can easily verify by checking the node_module and see `react-native-modules.js` the flag on L17 is set to false).
This PR addresses it by moving to the new lifecycle hook `prepack` (and modifies the other files accordingly).
After this PR is merged, we'll need to cherry pick it into 0.70 and do both a new release from the 0.70 branch and one from the main branch to have new versions of this module with the flag set correctly.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix eslint-plugin-specs prepack npm lifecycle hook now that we use npm 8
Pull Request resolved: https://github.com/facebook/react-native/pull/34273
Test Plan: Go in the `eslint-plugin-specs` folder, run `npm pack`, unzip the generated tar file, go into `package`, verify that L17 of `react-native-modules.js` is correctly changed to `const PACKAGE_USAGE = true;` (instead of false - which is what happen without this fix).
Reviewed By: GijsWeterings
Differential Revision: D38151433
Pulled By: dmitryrykun
fbshipit-source-id: 7c4f13dae70eb731d57cbafa90f7be05c9bb8576
Summary:
Add capture-phase focus events to the type system, for use in the refactored VirtualizedList https://github.com/facebook/react-native/pull/32646/files
Tracking the last focused child is done via focus events. Focus events are bubbling (vs direct events like onLayout), and are given both a "capture" phase, and "bubbling phase", like DOM events on the web. https://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing
The VirtualizedList change wants to know if a child will receive focus. This is not possible to reliably capture in the bubbling phase, since a child may stop propagation.
See https://github.com/react-native-community/discussions-and-proposals/pull/335#discussion_r584851337 for some discussion with Scott Kyle about this issue back in the day
This is done by convention in React by adding a "capture" variant of the `onXXX` method. For all platforms I've seen with focus events, these map the `topFocus` native event to `onFocus` for bubbling phase, and `onFocusCapture` for capture phase. See https://reactjs.org/docs/events.html#supported-events
Changelog:
[General][Added] - Add types for onFocusCapture/onBlurCapture
Reviewed By: javache
Differential Revision: D38013861
fbshipit-source-id: 7bda22e1a4d5e36ac5e34e804abf6fb318a41baf
Summary:
We are already returning the `remove` function, and the `removeEventListener` method has been removed in this PR: https://github.com/facebook/react-native/issues/33580. So I believe this comment is now outdated and no longer relevant.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Removed] - Remove outdated TODO in AppState
Pull Request resolved: https://github.com/facebook/react-native/pull/34264
Reviewed By: dmitryrykun
Differential Revision: D38120344
Pulled By: GijsWeterings
fbshipit-source-id: c6c4d42f5b631a67bb6ad49c14df1a772f1cc71b
Summary:
A crash encountered in react-native-macOS is very similar to one fixed by https://github.com/microsoft/react-native-macos/pull/489#discussion_r451789471 (see discussion), and it's possible this `replacement` string also suffers from sharing the same backing store as the attributed string (maybe only when the range encompasses the entire string?) and therefore should be copied as well.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38064551
fbshipit-source-id: 9c15f2a980155ab3cbb3fde79fcb93b24ee2091a
Summary:
The purpose of this diff is to un-deprecate the method DisplayMetrics.getWindowDisplayMetrics().
As React Native is used in devices with multiple screens and displays, we need to provide a non-deprecated way to access display metrics (e.g. screen density) for the window that's used to render react native views.
This diff doesn't make any change in behavior, but it un-deprecates the API
changelog: [Android][Added] Un-deprecate DisplayMetrics.getWindowDisplayMetrics() method
Reviewed By: javache
Differential Revision: D37871954
fbshipit-source-id: d8eb97cfae096f2f62ed1389a6de17a892a46b43
Summary:
This method assumes a semicolon existed before the closing bracket (`>`), but only does on iOS. This instead puts the content before the closing bracket, which is always there on both platforms.
Changelog:
[macOS][Fixed] - Fix exception thrown by [RCTTextView description] on macOS
Reviewed By: sammy-SC
Differential Revision: D38074642
fbshipit-source-id: f46d15c2bf2d966d1c1430568f083e4d501d4b40
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34270
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D38116297
Pulled By: dmitryrykun
fbshipit-source-id: 962e34b4cfd58947cf6d95ae05affda7b9271716
Summary:
In D37873933, we update the buildifier binaries, which apply some minor changes to existing lint. Specifically, entries are now properly sorted.
Update the files in xplat such that updating buildifier does not cause lint changes in users diffs.
drop-conflicts
allow_many_files
#nocancel
#forcetdhashing
(Note: this ignores all push blocking failures!)
Reviewed By: d16r
Differential Revision: D37873936
fbshipit-source-id: f31d9c50d64ae99f99298977b471bf13e7ed5262
Summary:
Currently, with the Alert API on iOS, the only way to bold one of the buttons is by setting the style to "cancel". This has the side-effect of moving it to the left. The underlying UIKit API has a way of setting a "preferred" button, which does not have this negative side-effect, so this PR wires this up.
See preferredAction on UIAlertController https://developer.apple.com/documentation/uikit/uialertcontroller/
Docs PR: https://github.com/facebook/react-native-website/pull/2839
## Changelog
[iOS] [Added] - Support setting an Alert button as "preferred", to emphasize it without needing to set it as a "cancel" button.
Pull Request resolved: https://github.com/facebook/react-native/pull/32538
Test Plan:
I ran the RNTesterPods app and added an example. It has a button styled with "preferred" and another with "cancel", to demonstrate that the "preferred" button takes emphasis over the "cancel" button.

Luna:
* Also tested this on Catalyst
{F754959632}
Reviewed By: sammy-SC
Differential Revision: D34357811
Pulled By: lunaleaps
fbshipit-source-id: 3d860702c49cb219f950904ae0b9fabef03b5588
Summary:
When building `igios-no-extensions` with buck2 on linux, we the following analysis error:
```
When running analysis for `fbsource//fbobjc/Apps/Instagram/Instagram:InstagramNoExtensions (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
Caused by:
0: When running analysis for `fbsource//fbobjc/Apps/Instagram/Instagram:InstagramARVRFrameworkDylibFramework (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
1: When running analysis for `fbsource//fbobjc/Apps/Instagram/Instagram:InstagramDependencyPoolForLinkGroupsFramework (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
2: When running analysis for `fbsource//fbobjc/Libraries/FBReactKit:RCTNetInfo (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
3: When running analysis for `fbsource//xplat/js/RKJSModules/Libraries/NetInfo:FBReactNativeNetInfoSpecApple (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
4: When running analysis for `fbsource//xplat/js/react-native-github:RCTTypeSafety (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
5: Traceback (most recent call last):
* fbcode/buck2/prelude/apple/apple_library.bzl:48, in <module>
constructor_params, swift_providers = apple_library_rule_constructor_params_a...
* fbcode/buck2/prelude/apple/apple_library.bzl:111, in apple_library_rule_constructor_params_and_swift_providers
args = [cmd_args(get_framework_search_path_flags(ctx))],
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:46, in get_framework_search_path_flags
return _get_framework_search_path_flags(_get_non_sdk_framework_directories(ct...
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:59, in _get_non_sdk_framework_directories
return dedupe(filter(None, [_non_sdk_framework_directory(ctx, x) for x in fra...
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:95, in _non_sdk_framework_directory
expanded_framework_path = _expand_sdk_framework_path(ctx, framework_path)
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:81, in _expand_sdk_framework_path
expanded_path = expanded_path.replace(path_variable, path_value)
error: Type of parameter `new` doesn't match, expected `str`, actual `artifact`
--> fbcode/buck2/prelude/apple/apple_frameworks.bzl:81:25
|
81 | expanded_path = expanded_path.replace(path_variable, path_value)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
```
This is related to running on Linux with buck2 and how we get the framework paths for linux/pika toolchains for non SDK frameworks. However, Foundation is an SDK framework, and updating it to be as such allows us to build, both with buck1 and buck2.
Differential Revision: D38080376
fbshipit-source-id: b226c3511e3312d0bf0ddb792dbe4ca99768cad1
Summary:
How the Hermes cache worked had a concurrency issue. It used to work by asking the Hermes repository for the latest commit and using that commit as cache key to try and retrieve a built version of Hermes to avoid to compile it more than once.
The problem happened when the `build_hermes_macos` was building Hermes using a commit A.
While building, another PR could be merged into `hermes:main`, creating commit B.
When this happened, the tasks `test_ios` and `test_ios_rntester`would try to retrieve a cached version of Hermes using commit B. That version did not exist because Hermes was created using commit A, and the job would either fail or trying to build Hermes from source, ending up taking a lot of time.
This PR attaches the `.hermes-cache-key-file` to the workspace and restores it in the other jobs, making sure that the same cache key is used in all three jobs.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Attach the `.hermes-cache-key-file` to the workspace to avoid race conditions for new PR landing on Hermes and changing the head commit between the time Hermes is built and the time it has to be consumed.
Pull Request resolved: https://github.com/facebook/react-native/pull/34235
Test Plan:
Tested manually, looking at the messages in CI.
**build_hermes_macos**
<img width="881" alt="Screenshot 2022-07-21 at 15 40 02" src="https://user-images.githubusercontent.com/11162307/180241834-776f2291-63bb-4bb2-8837-14434b50fe61.png">
**test_ios_rntester**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached.
<img width="956" alt="Screenshot 2022-07-21 at 15 40 52" src="https://user-images.githubusercontent.com/11162307/180242004-d9db0336-18d3-4321-a997-b538baa6beee.png">
**test_ios**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached.
<img width="900" alt="Screenshot 2022-07-21 at 15 46 33" src="https://user-images.githubusercontent.com/11162307/180243359-79de5c7a-d2f0-4331-90c6-5bd2c0b5e1ac.png">
Reviewed By: cortinico
Differential Revision: D38037386
Pulled By: cipolleschi
fbshipit-source-id: 4db4f7c478e1afb2e4a18ba3d3f70896ed41d235
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34232
This diff simplify the logic to decide whether we want to build hermes from source or not.
The requirement we have is that we don't want our users to build hermes.
So, we don't want to build hermes when there is a precompiled tarball available, while we want to build hermes in CI.
## Changelog
[General][Changed] - Build hermes when in CI and not when there is a tarball
Reviewed By: cortinico
Differential Revision: D37999748
fbshipit-source-id: 7d9cab51c37fb47db216055c057a22081e10df07
Summary:
Minor improvements to NativeState implementation and test. Does not change the API.
Changelog:
[Internal][Changed] - Minor improvements to jsi::NativeState
Reviewed By: neildhar
Differential Revision: D37961515
fbshipit-source-id: b87dcf2458ace883c784f3127a13f5a6c296d4a2
Summary:
Turbo module codegen for component parse `readonly T[]` and `readonly Object[][]` incorrectly. In this change, it is fixed, with necessary test cases added.
## Changelog
[General] [Added] - Support TypeScript array types for turbo module (component only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34216
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: sammy-SC
Differential Revision: D37953004
Pulled By: cipolleschi
fbshipit-source-id: b71ea35eb9c4bd5dc41130f1dcf9201704ec298e
Summary:
changelog: [internal]
This was used as a kill switch, it has been in place for over 4 months, let's get rid of it.
Reviewed By: mdvacca
Differential Revision: D37921377
fbshipit-source-id: 594586033694766e13d0f2ab2bcd73b28ba180a9
Summary:
changelog: [internal]
Vertical and horizontal inversion was not taken into account in `computeRelativeLayoutMetrics`. To fix it, we precompute frames to include inversions.
Reviewed By: mdvacca
Differential Revision: D37994809
fbshipit-source-id: 043e6f19b6fa577f61fa3c739ce2d751ef973cc3
Summary:
Changelog: [Android][Fixed] - Fix such that when the scrollviews call `onChildStartedNativeGesture`, they appropriately call `onChildEndedNativeGesture` to unlock the native gesture such that `JSTouchDispatcher` or `JSPointerDispatcher` will continue to emit events.
### How did we find this issue?
As React Native is adding pointer event support for different input types, we noticed after pressing and dragging on a ScrollView, hover events would not fire.
### Why was this not an issue before?
This was always an issue -- it was just that `JSTouchDispatcher` worked its way around it by explicitly setting `mChildIsHandlingNativeGesture = false` on a `ACTION_DOWN` event, [code pointer](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSTouchDispatcher.java#L76). Similarly, `JSPointerDispatcher` [copied this logic](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSPointerDispatcher.java#L106).
With new hover support in `JSPointerDispatcher` no similar workaround was put in (or even a good place to insert).
### What's next?
* As a follow-up, we should look at removing this workaround (at least for `JSPointerDispatcher`)
* By searching for usages of where we `notifyNativeGestureStarted`, it looks like `ReactDrawerLayout` and `ReactSwipeRefreshLayout` both do and don't call the symmetric `notifyNativeGestureEnded`. This will likely be an issue in the future (or maybe if we remove the workaround)
Reviewed By: mdvacca
Differential Revision: D37977982
fbshipit-source-id: 0d18767f4debbf24cfb24b54df1310f6f96a0d03
Summary:
Currently, iOS jobs takes up to 2 hours to run.
This is firstly due to Hermes being rebuilt at least 3 times during the CI process.
One issue I discovered is that the `Hermes-SDK-Cache-Key` was depending on the `{{ .Environment.CIRCLE_JOB }}` which is different from all the jobs (`test_ios_rntester`, `test_ios` and `build_hermes_macos`) which forced hermes to be build 3 times.
Another issue I found was that we were not caching hermes at all the first time we build it, during the `build_hermes_macos` step.
To ensure that `test_rn_tester` and `test_ios` has a valid version of Hermes from the cache, they now depend on the `build_hermes_macos` job
## Changelog
[iOS] [Changed] - Add caching for Hermes when we build it, updated the hermes_sdk_cache_key, update job dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/34209
Test Plan:
CircleCI must be green and take less than 2 hrs
**Before**
{F753846143}
**After**
{F753846214}
Reviewed By: cortinico
Differential Revision: D37959500
Pulled By: cipolleschi
fbshipit-source-id: c3435717bfa71e7488326894cd1ad7638044004e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34224
This Diff is a copy of this [PR](https://github.com/facebook/react-native/pull/34228) that we have against 0.69-stable.
This Diff makes sure we can build Hermes also in PR that are created against a stable branch
## Changelog
[General] [Changed] - Make sure we can build Hermes from source when PR are opened agains -stable
Reviewed By: cortinico
Differential Revision: D37961092
fbshipit-source-id: 65577fcc69f0e2a68377cbd46e3bd3a6af24e7c3
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.2
Pull Request resolved: https://github.com/facebook/react-native/pull/34227
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D37993752
Pulled By: cortinico
fbshipit-source-id: 339f2b6bf42547360d0bca9984e2a3fd45299cc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34230
The OS static class is accessed inside app/build.gradle but the import is on
the top level Gradle file. This is causing an app created from template to fail
building.
This is needed to be cherry-picked on the 0.70-stable branch.
Changelog:
[Android] [Fixed] - Fix missing import on New Architecture build script in template
Reviewed By: cipolleschi
Differential Revision: D37995897
fbshipit-source-id: aad22100cee004944c4fa0841f5ef0dfc6ea1e94
Summary:
The native module might be null, and that should not be an exception thrown by the subclassed method.
Changelog:
[Android][Internal] - Mark getModule API to be nullable
Reviewed By: mdvacca, makovkastar
Differential Revision: D37900294
fbshipit-source-id: a4ecc9804b95bf0512554e96985f272b435e33b2
Summary:
There are many files across fbobjc relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff was generated by a codemod and fixes these missing includes.
More details on the missing imports https://fb.workplace.com/groups/929548250966094/permalink/981237982463787/
Changelog: [Internal]
Reviewed By: yannickl
Differential Revision: D37282740
fbshipit-source-id: 0f419025b3cf2f811e96ff464cb19e8e5a25aa09
Summary:
This resolves issues where the node_modules structure is not hoisted (like with pnpm). Since the template does not directly depend on the cli, it doesn't exist in the pnpm node_modules root. Moving it to the rn scripts makes sure that the relative require starts in the correct directory for both hoisted and pnpm structures.
## Changelog
[iOS] [Fixed] - Fix cocoapods cli native_modules require for pnpm node_modules
Pull Request resolved: https://github.com/facebook/react-native/pull/34215
Test Plan:
1. react-native init
2. rm -rf node_modules
3. pnpm i
4. bundle install
5. bundle exec pod install --project-directory=ios
This should succeed. Without the patch, it will fail with
```
[!] Invalid `Podfile` file: cannot load such file -- /.../node_modules/react-native-community/cli-platform-ios/native_modules.
# from /.../ios/Podfile:2
# -------------------------------------------
# require_relative '../node_modules/react-native/scripts/react_native_pods'
> require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules'
#
# -------------------------------------------
```
Reviewed By: cortinico
Differential Revision: D37959152
Pulled By: cipolleschi
fbshipit-source-id: 7fa9af4a8c153cfd38360f57eca415a8c252dbd5
Summary:
This fix is necessarly to ensure that when working on the codebase in the `0.XX-stable` branches (ex. when you are working on a release) the Hermes podfile is correctly set against the right commit for that branch, and not latest commit from main branch of Hermes repo.
I didn't add a check to verify that the file `.hermesversion` exists because I think it's safe to assume that the file and the tag correctly exists when this step (doing a pod install on the `0.XX-stable` branch).
Once this is merged, we need to cherry pick it on both the 0.69 and 0.70 branches
## Changelog
[iOS] [Fixed] - Hermes pod: change logic to use the hermes tag to set the pod source correctly
Pull Request resolved: https://github.com/facebook/react-native/pull/34221
Test Plan:
* git clone the repo
* checkout 0.69-stable branch
* follow https://reactnative.dev/contributing/release-testing
* without this commit, when testing RNTester + iOS + Hermes the app will insta-crash on opening
* with it, the app gets build successfully
Reviewed By: cortinico
Differential Revision: D37957660
Pulled By: cipolleschi
fbshipit-source-id: 4e50099ed712b1ad8e6439822e3f530142982c1b
Summary:
I just opened another PR and noticed the changelog page in the wiki redirected to the react native documentation.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - Update link to changelog documentation in PULL_REQUEST_TEMPLATE
Pull Request resolved: https://github.com/facebook/react-native/pull/34206
Reviewed By: NickGerleman
Differential Revision: D37920424
Pulled By: cortinico
fbshipit-source-id: f4e47172a13fe5b42c29e320d34816b490a14b6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34177
This Diff destructures the parameters of the use_react_native! function. It does that in a backward compatible way, so we there should be no disruptions.
It also adds documentation to the various public method we want to export to our users.
## Changelog
[iOS][Changed] - Destruct use_reactnative parameters and ad ddocumentation
Reviewed By: cortinico
Differential Revision: D37787365
fbshipit-source-id: 27f9030db2e8c6c66b9548b4c1287eb8165ae5fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34176
It extracts the code related to the codegen from the main `react_native_pods` script to a dedicated file, adding also tests.
## Changelog
[iOS][Changed] - Move codegen in separate files
Reviewed By: cortinico
Differential Revision: D37755818
fbshipit-source-id: 99760d1def26ddbf065fdd234e0d183c2795513c
Summary:
D37801394 (https://github.com/facebook/react-native/commit/51f49ca9982f24de08f5a5654a5210e547bb5b86) attempted to fix an issue of TextInput values being dropped when an uncontrolled component is restyled, and a defaultValue is present. I had missed quite a bit of functionality, where TextInput may have child Text elements, which the native side flattens into a single AttributedString. `lastNativeValue` includes a lossy version of the flattened string produced from the child fragments, so sending it along with the children led to duplicating of the current input on each edit, and things blow up.
With some experimentation, I found that the text-loss behavior only happens on Fabric, and is triggered by a state update rather than my original assumption of the view manager command in the `useLayoutEffect` hook. `AndroidTextInputShadowNode` will compare the current and previous flattened strings, to intentionally allow the native value to drift from the React tree if the React tree hasn't changed. This `AttributedString` comparison includes layout metrics as of D20151505 (https://github.com/facebook/react-native/commit/061f54e89086af1c80e5b0460ec715533f99bdb7) meaning a restyle may cause a state update, and clear the text.
I do not have full understanding of the flow of state updates to layout, or the underlying issue that led to the equality check including layout information (since TextMeasurementCache seems to explicitly compare LayoutMetrics). D18894538 (https://github.com/facebook/react-native/commit/254ebab1d2b6fac859ab1ae0c9503328fc99a6d0) used a solution of sending a no-op state update to avoid updating text for placeholders, when the Attributed strings are equal (though as of now this code is never reached, since we return earlier on AttributedString equality). I co-opted this mechanism, to avoid sending text updates if the text content and attributes of the AttributedString has not changed, disregarding any layout information. This is how the comparison worked at the time of the diff.
I also updated the fragment hashing function to include layout metrics, since it was added to be part of the equality check, and is itself hashable.
Changelog:
[Android][Fixed] - Fix `AttributedString` comparison logic for TextInput state updates
Reviewed By: sammy-SC
Differential Revision: D37902643
fbshipit-source-id: c0f8e3112feb19bd0ee62b37bdadeb237a9f725e
Summary:
Log whether bridgeless mode is enabled or not when calling into a JavaScript module method fails.
We are seeing a surge of these crashes in MessageQueue.js bridgeless mode. This temporary log will help us drill down into the issue.
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
This should not mess with the sitevar overrides.
These are the two diffs where we mapped the venice and bridge errors to the same mid: D36649249, D36649249.
Reviewed By: fkgozali
Differential Revision: D37898744
fbshipit-source-id: 0ab337c8c0d73bd70c4756a16b8ece8ba8730c47
Summary:
Add API for setting/getting native state.
When present, the internal NativeState property of an object always stores a NativeState with a pointer to a heap-allocated shared_ptr + a finalizer that simply `delete`s it.
Changelog:
[Internal][Added] - JSI API for setting/getting native state on a JS object
Reviewed By: jpporto
Differential Revision: D36499239
fbshipit-source-id: a1ff1905811db1aac99ece3f928b81d0abfb342b
Summary:
Changelog: [RNTester][Internal] - Add the ability for platform tests to be marked as skipped
There are some properties/tests in the web platform tests that we don't want to especially priorities (especially if they aren't especially relevant to the specification and just legacy browser compat) so this adds the ability for us to mark these tests as skipped. This is so that we can ensure that our platform tests are "complete" while decreasing the noise and distraction from failing tests that don't really apply to RN.
Reviewed By: lunaleaps
Differential Revision: D37889470
fbshipit-source-id: 6516ac90c242d662518a95cb9ba8ce643f6bb09c
Summary:
Changelog: [iOS][Internal] - Add key modifier properties to the PointerEvent interface
This diff adds implementations of the `ctrlKey`, `shiftKey`, `altKey`, and `metaKey` properties on the PointerEvent interface for iOS.
Reviewed By: lunaleaps
Differential Revision: D37869377
fbshipit-source-id: b187bae93fbfc97b6ca1d8d9786ad85343484b3d
Summary:
Changelog: [internal]
- Upgrade ESLint version to the latest
- Upgrade ESLint plugin versions to the latest to ensure compatibility
- Switch from eslint-plugin-flowtype to eslint-plugin-ft-flow
- Updates lint suppressions - all `flowtype/` rules to `ft-flow/`
### `flowtype` vs `ft-flow`
`eslint-plugin-flowtype` is well out of date and no-longer maintained. It's been abandoned by its owner. This means it crashes on ESLint v8.
`eslint-plugin-ft-flow` is a fork of the above and is maintained by the same people that own the `flow-typed` project.
Reviewed By: jacdebug
Differential Revision: D37727177
fbshipit-source-id: 516be42f947fec9c886526c182a608b3311c0b50
Summary:
According Flow's document, a maybe type of T means `T | null | undefined`, instead of `T | null | void`.
I think keeping TypeScript and Flow being consistent to each other is better.
## 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] - Accept TypeScript type `T | null | undefined` as a maybe type of T in turbo module.
Pull Request resolved: https://github.com/facebook/react-native/pull/34158
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: yungsters
Differential Revision: D37731169
Pulled By: philIip
fbshipit-source-id: b6d9b7e8991f60e12c1004bed5b937b34fb02c47
Summary:
changelog: [internal]
Original commit changeset: 290ae428a720
Original Phabricator Diff: D37881453 (https://github.com/facebook/react-native/commit/e98a835bfc7b01bccb1b7cdee94db248a0a90607)
in the original diff I made a mistake. The default value for RN is never, we override it in one of our subclasses.
Reviewed By: cortinico
Differential Revision: D37884715
fbshipit-source-id: 3c5b5ef5550120034e33ae9047292f38159dea3e
Summary:
Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent.
1) Run my one-off jscodeshift codemod
2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change)
drop-conflicts
Reviewed By: bradzacher
Differential Revision: D37834078
fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581
Summary:
Changelog: [RNTester][Internal] - Fix incorrect pointer event name in move test
We recently removed the '2' suffix from certain pointer event names and I forgot to update this test.
Reviewed By: lunaleaps
Differential Revision: D37857862
fbshipit-source-id: 6f37dce139772cd16d663961dbcbbf68dde83101
Summary:
Changelog: [iOS][Internal] - Implement offsetX/offsetY properties on the PointerEvent interface
Simple diff implementing the offsetX/offsetY properties on PointerEvent — thankfully the touch events already kept track of these so it was mostly a matter of forwarding that data to the pointer events.
Reviewed By: lunaleaps
Differential Revision: D37830139
fbshipit-source-id: 77f33a99393350d32cbe449e6a009bdeb2a12d08
Summary:
Automatically create a GitHub Release draft when a new React Native release is created.
The GitHub Release will be created by the same Circle CI job that publishes the package to npm.
This job will also upload the built Hermes binaries to the GitHub release.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36646696
fbshipit-source-id: 0a863dc4e3215fc95f7852f8dc43858cdd852aaa
Summary:
This cleans up a bit our dependency list inside `ReactAndroid`. I've re-sorted the lists, and exported everything I could in the `gradle.properties`.
I wish we could move to the Gradle Version Catalog for Android, but that's not possible at the moment (it will make impossible for users to build from source).
## Changelog
[Internal] - Cleanup some of the dependencies inside ReactAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/34191
Test Plan: Will rely on a Green CircleCI
Reviewed By: huntie
Differential Revision: D37828614
Pulled By: cortinico
fbshipit-source-id: f433d08d691db4145e0c72ca4dab2f0350e4101f
Summary:
Changelog:
[general][change] - Use RuntimeConfig instead of VM Experiment Flag to set up the micro task queue.
Reviewed By: neildhar
Differential Revision: D37353947
fbshipit-source-id: 5c8f35c0a79d70cb0d234e881e55058cffb44ac8
Summary:
Changelog: [iOS][Internal] - Implement screenX/screenY properties on the PointerEvent interface
This diff implements the screenX/screenY properties which report the position of a pointer in the device's physical screen coordinates.
Reviewed By: lunaleaps
Differential Revision: D37794415
fbshipit-source-id: 6c39c3651812f99e66b93647579a2935598ef6f2
Summary:
The empty object literal `{}` now has the type `{}` - i.e. an exact empty object - rather than being unsealed.
Enable the option in the github flowconfigs
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D37836634
fbshipit-source-id: 8ef0cfaf1d0420ae71723e04163f00c43c550e07
Summary:
A layout-impacting style change will trigger a layout effect hook within `TextInput`. This hook fires a ViewManager command to set the text input based on the known JS value: https://github.com/facebook/react-native/blob/d82cd3cbce1597512bb2868fde49b5b3850892a0/Libraries/Components/TextInput/TextInput.js#L1009
The JS value is determined using `value` if set, falling back to `defaultValue`. If a component uses `TextInput` as an uncontrolled component, and does not set this value, the command wipes text input back to the default value. This does not happen on re-render of the JS side, despite setting text prop, since the underlying native property never changes/triggers a rerender.
This change alters the logic to prefer `lastNativeText` instead of `defaultValue` when available, to retain the updated `TextInput` content on relayout.
Reviewed By: javache
Differential Revision: D37801394
fbshipit-source-id: d56c719d56bebac64553c731ce9fca8efc7feae9
Summary:
Turbo module codegen supports arrays in both Flow and TypeScript, but it only recognize `Array<T>` and `ReadonlyArray<T>` in TypeScript.
In this change, `T[]` and `readonly T[]` are made recognizable in codegen.
## Changelog
[General] [Added] - Support TypeScript array types for turbo module (module only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34183
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: lunaleaps
Differential Revision: D37812638
Pulled By: cipolleschi
fbshipit-source-id: d63b0585497a43c274d50e1877baab5d1cc3f8fa
Summary: Changelog: [Internal] - Add an example of pointermove using AnimatedEvent
Reviewed By: vincentriemer
Differential Revision: D37769263
fbshipit-source-id: 25de0ae88b55148d23fa388768707ea859e9ae4d
Summary:
The RN Hermes Inspector keeps a mapping of pageId to
Connection. This mapping is created in the call to
enableDebugging. Later, when disableDebugging is invoked,
the inspector will iterate over the pageId to Connection map
to find which page to is being disabled.
The DecoratedRuntime enables debugging on construction, and
disables on destruction. When disabling debugging, the
DecoratedRuntime then passes the "naked" hermesRuntime,
which in turn gets checked against all connections' runtimes.
It turns our that ```HermesExecutorRuntimeAdapter::getRuntime```
returns the runtime **wrapped** by the DecoratedRuntime, and
not hermesRuntime itself.
This means that no connections match the request for
disabling debugging. Which means the Connection never
gets deleted, which in turns keep its underlying adapter (in
this case, the ```HermesRuntimeExecutorAdapter```) alive,
which has a shared_ptr to the runtime wrapped by the DecoratedRuntime.
Other than effectively leaking this connection (and thus the runtime),
this also causes an issue when the app tries to re-load the page -- at
which point the inspector will remove the old entry from the page to
connection mapping, thus initiating the destruction of the (leaked)
Runtime in a thread other than the thread that created the runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37809467
fbshipit-source-id: e73caa357a300a0d48e69aa3a1a8b00a97519f24
Summary:
Changelog: [iOS][Internal] - add x/y & pageX/Y implementations to PointerEvent interface
This diff adds the x/y properties, which are defined as aliases of clientX/clientY respectively. In addition this diff adds pageX/pageY which, while not definted as aliases of clientX/clientY, are effectively aliases in React Native since the root view is not scrollable (client and page points only differ on the web when a user has scrolled the document element).
Reviewed By: lunaleaps
Differential Revision: D37766818
fbshipit-source-id: c7ad3750460b1913889c6d1a55b4c1edc6918f5b
Summary:
Changelog: [RNTester][Internal] - Fix layout measurement in hoverable pointer attributes test
This diff addresses an issue I've found with the hoverable pointer attributes test where before it was measuring the view seemingly on mount and it appears that for *some reason* that would be incorrect on the first mount of the view. This diff ensures that doesn't happen by measuring the view JIT when an event is recieved instead.
Reviewed By: lunaleaps
Differential Revision: D37765614
fbshipit-source-id: 8594677d98be8d3d4e75dbf5394c92ca49355d6d
Summary:
Changelog: [iOS][internal] - Add twist property to PointerEvent interface
This adds the twist property to the PointerEvent implementation on iOS which similarly to tangentialPressure doesn't really apply so we default to a hard-coded value of 0.
Reviewed By: lunaleaps
Differential Revision: D37760511
fbshipit-source-id: f1fccfd6b5d07024cea83d86925a9bfc2e6cc8cf
Summary:
Changelog: [iOS][internal] - Add tangentialPressure property to PointerEvent interface
This diff adds the tangentialPressure property to the PointerEvent implementation on iOS. This one is pretty simple considering iOS doesn't have the concept of tangential pressure so we just hard code it to 0 as defined by the spec.
Reviewed By: lunaleaps
Differential Revision: D37759634
fbshipit-source-id: 7ca0e47267f5fde76ace2b96d05ea2e154cb4b8f
Summary:
This change replaces the text in `ColorStylesExample` with two different spans of nested text, which requires special attention with the native driver.
Changelog:
[Internal][Added] - Add Nested Text Animated Color RNTester Example
Reviewed By: genkikondo
Differential Revision: D37762708
fbshipit-source-id: 755e6dd922432781645cd84749a77f29ec57665d
Summary:
Before this change, during the "Start Packager" Xcode build step that runs the packager, `packager.sh` was using my system node version and not the one from `nvm` that is meant to be used with the project.
## Changelog
[iOS] [Fixed] - Use `NODE_BINARY` from `.xcode.env` when running packager from Xcode
Pull Request resolved: https://github.com/facebook/react-native/pull/34121
Test Plan: Perform a build using Xcode and confirm that the packager is using the correct version of node.
Reviewed By: cortinico
Differential Revision: D37746951
Pulled By: cipolleschi
fbshipit-source-id: de697c27fe86ce65e8e3646cb30309ecc7f6c247
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34161
This is a follow up to D37648363 (https://github.com/facebook/react-native/commit/64fe67695be3c038414c5ed3e02d487c449702b6) which breaks up `TestBundle.js` into two modules. This enables `TestApps.js` (which defines and exports the set of integration test apps) to be required in the Meta-specific dependency graph without violating our internal naming pattern for JS entry points.
`force_include_bundles` is removed from the `js_glob` macro signature.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D37686883
fbshipit-source-id: 492c13dfcdd76ea8347d4d11c85818e31777c663
Summary:
Fix todo and inconsistency across codebase. It's better to have just one way to refer to these types.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D37653146
fbshipit-source-id: e82f09caa6cd6eec5512b78f413708d9c04a7a83
Summary:
Ahead of enabling the `exact_empty_objects` option, suppress errors so that actually enabling the option is easier. We can do this without enabling the option by codemoding `{}` to `{...null}` in files that have errors.
Process:
1) Get list of files with errors when enabling the option
2) Codemod `{}` to `{...null}` in those files
3) Suppress resulting errors
4) Land diff with `drop-conflicts` flag
5) Announce and enable option (with many fewer files to edit)
6) Codemod all `{...null}` to `{}`
drop-conflicts
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
More info in these posts: https://fb.workplace.com/groups/flowlang/posts/903386663600331, https://fb.workplace.com/groups/floweng/posts/8626146484100557
Reviewed By: pieterv
Differential Revision: D37731004
fbshipit-source-id: a9305859ba4e8adbdb8ae8feff3ec8a2f07ed236
Summary:
Subclassing a ViewManager means an additional PropsSetter class is generated (and other overheads). Instead we can use a Factory/Provider to construct ReactTextViewManager, since we don't actually need a subclass.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36411098
fbshipit-source-id: 11c5ba5c9683a3ae4741cf61338f1983c69d9b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34171
Changelog:
[General][Added] - Added files for `avn`, `nodenv`, and other managers that set the node.js version in reactive native project including testing
Reviewed By: cortinico
Differential Revision: D37683291
fbshipit-source-id: ef0df0fb07f5cc0fa3591dde487f65e4b1b5f73f
Summary:
Changelog: [Internal][iOS] Minor: Rename RCTNotAllowedInAppWideFabric to RCTNotAllowedInFabricWithoutLegacy
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless.
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInFabricWithoutLegacy` is to track legacy APIs that should not exist if the app was using Fabric **without any legacy architecture**. e.g. RCTBridgeModule, legacy interop view components.
Reviewed By: fkgozali
Differential Revision: D37659105
fbshipit-source-id: aee4e083820e83a8dac19eb3b5efc49b37d90039
Summary:
Changelog: [RNTester][Internal] - Create more mobile-friendly version of the platform test results UI
The original UI design for displaying the test results was done with only really tablets in mind so in order to better accomidate mobile screen sizes this diff adds a new expanding UI for the test results.
Reviewed By: lunaleaps
Differential Revision: D37701638
fbshipit-source-id: a1789abb15db7ab162fe90afc32d23c435f1bdb5
Summary:
Changelog: [RNTester][Internal] - Add README for RNTesterPlatformTest framework
This diff adds some initial documentation for `RNTesterPlatformTest` to give other pointers on how to contribute their own platform tests (both internally and externally).
Reviewed By: lunaleaps
Differential Revision: D37566632
fbshipit-source-id: c203045f79c3c5488fd0dcbb8077e9041bd62b0f
Summary:
Changelog: [iOS][Internal] - Add `buttons` implementation to the PointerEvent interface
This diff adds an implementation of the `buttons` property by leveraging `UIEvent`'s `buttonMask` property.
Reviewed By: lunaleaps
Differential Revision: D37430270
fbshipit-source-id: 69fd3aebcb403e665349a24283a04c0eb82ff3e2
Summary: Changelog: [Internal] - If any relevant view events (pointer, touch events, gesture responder, etc.) are declared on view, then the view must form stacking context. We need this change for pointer events specifically to determine whether we've entered/exited a view
Reviewed By: vincentriemer
Differential Revision: D37678352
fbshipit-source-id: 02641549ef608b1c9468ac693c7da629143212cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34100
This Diff continue the effort of refactor and test the cocoapods script, moving hermes setup in a dedicated `hermes.rb` file and adding some tests on the logic of the hermes handling.
## Changelog
[iOS][Changed] - move and test Hermes setup from react_native_pods script into a dedicated file
Reviewed By: cortinico
Differential Revision: D37522432
fbshipit-source-id: 91112476aac576a30110e5dcd4e46fa12241962a
Summary:
These changes are a side-effect of a Meta-internal Buck macro change. This does not affect how RNTester is built in open source.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D37648363
fbshipit-source-id: 6fd5d56a7a7a9ea71dc3d0df91e510fcd45a1e17
Summary:
This diffs replaces uses of the deprecated fields from HermesInternal.getInstrumentedStats() with the ones from Hermes' TimedRuntime.
Changelog:
[General][Added] - JSITimerInternal descriptor
Reviewed By: rubennorte
Differential Revision: D36625701
fbshipit-source-id: fbdb554e5cfb0b3556fcbe01f9e2930ace66a619
Summary:
Changelog: [Internal]
Add `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInAppWideFabric)` to track RCTViewManagers used in Fabric using the legacy interop layer. They work for now in the interop layer, but they need to be migrated to Fabric to remove potential issues with using the legacy architecture and the new architecture simultaneously. RCTNewArchitectureValidationPlaceholder is a no-op used for tracking unmigrated callsites that may be used often.
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless.
This diff adds the validation placeholder to legacy components registered in [RCTLegacyViewManagerInteropComponentView.mm](https://github.com/facebook/react-native/blob/743d0706e2099514b4603855bfc2b6505fcc10a5/React/Fabric/Mounting/ComponentViews/LegacyViewManagerInterop/RCTLegacyViewManagerInteropComponentView.mm#L92-L99).
Reviewed By: fkgozali
Differential Revision: D37635613
fbshipit-source-id: 5399dad822c8f5c11ef3b32297bf25214fd857dd
Summary:
This diff fixed a NPE in horizontal scroll view when calling scrollToEnd API in side effect.
The problem here is we may trigger side-effects before the required view got mounted for performance reasons. We've been fixing this with retry logic on those side-effects and we've already done this in vertical scroll view. This is to fix on the horizontal scroll as well.
Changelog:
[Android][Fixed] - Fixed HorizontalScrollView API scrollToEnd causing NPE in side-effects.
Reviewed By: lunaleaps, JoshuaGross
Differential Revision: D37571847
fbshipit-source-id: 0a4dc38381008350fd09908aa3ebb64e3e65a424
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.71.2 to 0.71.3
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.71.3
Changelog:
[General] Update direct Metro dependencies to 0.71.3
Reviewed By: robhogan
Differential Revision: D37647746
fbshipit-source-id: cb798c2c0d0d763ce5dd2af48f3877fab8e9fc0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34142
The `||=` operator in an expression like `x = a ||= b` works in a way that:
- if a is null, it assigns b to x
- if a is `falsy`, it assigns b to x
- otherwise, it assigns a to x.
In our setup, if the user set `hermes_enabled` to `false` in the Podfile (one of the suggested way to disabled Hermes), the `options[:hermes_enabled]` part will evaluate to false and, therefore, `hermes_enabled` will obtain the value of `true`.
## Changelog
[iOS][Changed] - Use the correct operator to decide whether Hermes is enabled or not.
Reviewed By: cortinico
Differential Revision: D37643845
fbshipit-source-id: 387f7bd642250c40873400d22d7d85451462c073
Summary: Changelog: [Internal] Allow for MotionEvents to indicate whether they are dispatched from an input device that supports hoverability
Reviewed By: javache
Differential Revision: D37543296
fbshipit-source-id: 4f70d2bf69ff1c563d8e4a6b5eb6b13b53996b9a
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary:
Internal tests are indicating that there's an OOM that happens during the RemoveDeleteTree worker loop while trying to expand the size of the tag stack.
In practice during manual testing I was not able to get the capacity beyond 40, but for deletions of very large trees, it's easy to imagine the size of the stack growing to at least the number of nodes in the tree being deleted. To mitigate this, we relax our requirements around the order in which onViewStateDeleted can be called and call it top-down instead of bottom up to maintain a smaller stack (see comments for more details).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D37619259
fbshipit-source-id: 8f7af0137a868606a72fdc7bdca13c5e89b69573
Summary:
After D37553813, there are no more TV apps in `fbsource`. Thus, we can begin the sequential teardown of all of the `APPLETVOS` variants in the codebase, which should migrating to `select()` and buck parse times a bit faster.
#nocancel
Reviewed By: natestedman
Differential Revision: D37594789
fbshipit-source-id: 830e40266654f948f39f5d10c32a080e970cf9d7
Summary:
Changelog: [RNTester][Internal] - Add the ability to filter PlatformTest results by test name substrings
In certain tests (such as the hoverable pointer attributes test) there are a super large number of results which can make it hard to focus on the ones you're actively trying to work on fixing. This diff adds the ability to filter those results with a simple substring filter on the test name of the results.
Reviewed By: lunaleaps
Differential Revision: D37558411
fbshipit-source-id: 8f4b19fed9bb9f1b08fd7470cd79d68b6c721c13
Summary:
If you don't list `Cxx` as a supported platform, we will use Android builds, even when using `buck run` for local execution.
Changelog: [Internal]
Reviewed By: derolf
Differential Revision: D37600464
fbshipit-source-id: 6ba8566cde4180524351c9d8c647ce1d4ac5279d
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.71.1 to 0.71.2.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.71.2
Changelog:
[General] Update direct Metro dependencies to 0.71.2
Reviewed By: jacdebug
Differential Revision: D37593257
fbshipit-source-id: f56db766a6c63b74ab9feab31a9d7a1f50c5af23
Summary:
Changelog: [Internal]
- Make the new architecture validation easier to understand by enabling validation with `RCTNewArchitectureSetMinValidationLevel(level)`.
- When `RCT_ONLY_NEW_ARCHITECTURE` flag is enabled:
- `RCTErrorNewArchitectureValidation` calls `RCTLogAssert` instead of `RCTLogError`.
- `RCTNewArchitectureValidationPlaceholder` calls `RCTLog`, instead of no-op.
Reviewed By: fkgozali
Differential Revision: D37555667
fbshipit-source-id: 2c725c287a2dec19e8946c7fe5d8fa111e4a17fa
Summary:
There is a very small volume of production errors caused by a View that is already in the hierarchy being added to the hierarchy again; this results in a crash on the Android platform layer.
We detect and attempt to silently recover from this case, while logging and collecting more diagnostics. This will still crash in debug mode.
It is unclear what layer this error is coming from: it could be an issue with the C++ differ (ordering, or something more tricky); that is unlikely but there are few other hypotheses at the moment.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37557663
fbshipit-source-id: ffe320ff646e314fa921a2c2cf8058254713505c
Summary:
The initial version of this would result in LayoutAnimations running potentially much faster than 60FPS (incorrectly). Resolve by calling tryDispatchMountItems directly instead of the frame callback runner.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37543693
fbshipit-source-id: 91dbd961ecc155221c84148cb6b252a4aac9ec91
Summary:
This PR adds a new method called **__apply_mac_catalyst_patches** to **scripts/react_native_pods.rb**. If it is enabled in the Podfile, it will apply three patches necessary for successful building not only for iOS and tvOS targets, but also for macOS using Apple's Mac Catalyst technology.
These 3 patches are:
- Fixing bundle signing issues by altering CODE_SIGN_IDENTITY
- Explicitly setting dead code stripping flag in project.pbxproj
- Modifying library search paths
The details were discussed here https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2754289
## Changelog
[iOS] [Added] - Add Mac Catalyst compatibility (can be enabled in Podfile)
Pull Request resolved: https://github.com/facebook/react-native/pull/34026
Test Plan:
1. Go to project settings in Xcode, to General tab. Enable "iPad" and "Mac Catalyst" checkboxes
2. Go to "Signing & Capabilities" tab, ensure that a correct bundle id and development team are set
3. Edit Podfile, uncomment **__apply_mac_catalyst_patches(installer)** line
4. Run `pod install` in ios directory
5. Get back to Xcode, select "My Mac (Mac Catalyst)" as a target device
6. Build & run
Reviewed By: cipolleschi
Differential Revision: D37362054
Pulled By: cortinico
fbshipit-source-id: 74636f716f112289ab40968bbc8e52406c1e9579
Summary:
```js
async () => {
let blobs = [];
for (let i = 0; i < 4; i++) {
const res = await fetch();
blobs = [...blobs, await res.blob()]
}
const blob = new Blob(blobs); // <<<<<<<<<<<<<<< a
return await new Promise((resolve, reject) => {
const fileReader = new FileReader();
fileReader.onload = async () => {
await RNFS.writeFile(destPath, (fileReader.result as string).split(',')[1], 'base64');
resolve(destPath);
};
fileReader.onabort = () => {
reject('');
};
fileReader.onerror = (event) => {
reject('');
};
fileReader.readAsDataURL(blob); // <<<<<<<<<<<<<<< b
});
}
```
Sometime `fileReader.readAsDataURL` is unable to get blob from the dictionary after `new Blob(blobs)` and then reject with `Unable to resolve data for blob: blobId` in iOS or `The specified blob is invalid` in android. Because line `a` and `b` can be run in different thread. `new Blob([])` is in progress and `fileReader.readAsDataURL` accesses the blob dictionary ahead of the blob creation.
The expected behaviour is it should finish new Blob([]) first and then readAsDataURL(blob)
To fix that, there should be a lock inside the method `createFromParts`. For iOS, It needs to be a recursive_mutex to allow same thread to acquire lock
## 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 the race condition when calling readAsDataURL after new Blob(blobs)
Pull Request resolved: https://github.com/facebook/react-native/pull/34096
Reviewed By: cipolleschi
Differential Revision: D37514981
Pulled By: javache
fbshipit-source-id: 4bf84ece99871276ecaa5aa1849b9145ff44dbf4
Summary:
LA needs to ignore the new RemoveDeleteTree mutation coming from the differ.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D37531217
fbshipit-source-id: c05b4106b6e955083e5e7e93619a13c4a2858404
Summary:
MSVC doesn't like Clang macros. Oops!
Constraints with this bit of code:
1. I'm trying to enforce constexpr in the most obvious, intuitive way possible. Macros are ugly but a "proper" solution would result in 10x as much code that is, totally subjectively, less readable to me.
2. This is evaluating at compile-time a hash of a string which is usually used in the `case` line of a switch statement.
For now I'm just hoping that MSVC will allow us to shadow `hash` which Xcode doesn't like. We might need to add a special pragma(s) for MSVC if it still doesn't like this.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D37529949
fbshipit-source-id: 9aa605a9786bf5d194819ef8dade778875ae744e
Summary:
Before
```
"If you want to override a property, don't addthe ReactProp annotation to the property in the subclass",
```
After
```
"If you want to override a property, don't add the ReactProp annotation to the property in the subclass",
```
Reviewed By: michaeltangelo
Differential Revision: D37526541
fbshipit-source-id: 850424a1b5a5aeb0abe64b6defcf6db96d2000cc
Summary:
Updating changelog for 0.69.1
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Update changelog for 0.69.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34097
Reviewed By: cortinico
Differential Revision: D37518312
Pulled By: cipolleschi
fbshipit-source-id: ba0784c371f0b771fc4f164a29aa24a1e7a46aa8
Summary:
Crashes can occur if we try to disassemble trees not managed by React Native - for example a native component tree, Litho hierarchies, etc.
As we disassemble the tree, ensure that children are managed before disassembling a subtree.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37493854
fbshipit-source-id: fee4d303133edcef663abfe8637bce6b24627724
Summary:
Due to the way we're dispatching queued MountItems on Android, we could be doing nothing on the UI thread for up to 15.99...ms before the start of the next frame, resulting in a delayed paint of up to 1 full (16ms) frame.
The delay is totally random and depends only on when the work is scheduled.
The tl;dr is that currently all MountItems are dispatched starting only at the /beginning/ of a UI frame. If we schedule work at FrameStart+0.000001ms, it will not be operated on until the start of the next frame, 16ms later. So the "wasted" time could be anywhere from 0 to ~16ms, but will result in at least 1 wasted frame regardless.
The fix is fairly trivial: start working on large buffered work as soon as we schedule it.
Changelog: [Android][Changed] Optimization to paint changes up to 1 frame earlier on Android/Fabric
Reviewed By: NickGerleman
Differential Revision: D37478885
fbshipit-source-id: 8af846736caf3a9d9f0d0c5e33328bebb87b1b32
Summary:
Instead of directly scheduling a Runnable on the UI thread, use a GuardedFrameCallback which (1) guards against exceptions thrown on the UI thread (in this case, errors in deferred remove/delete work really should not disrupt the UI at all or cause user-visible crashes) (2) allows us to split work across multiple frames if necessary (3) is more consistent with how we schedule other work on Android.
The only functionality change is that we might split work across multiple callbacks, in the case of tearing down a particularly large tree.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37470531
fbshipit-source-id: d9d1fc85c29e53addea886db975c0d914581e618
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34085
Hermes is now the default engine on iOS.
Apps can choose to continue using JSC by setting `hermes_enabled` to `false` in their Podfile.
The RNTester app now uses Hermes, as well. Use JSC in RNTester by setting `USE_HERMES=0` when running `pod install`.
Changelog:
[iOS][Changed] Hermes is now the default engine on iOS. This setting is controlled via `flags[:hermes_enabled]` in the Podfile.
Reviewed By: cortinico, cipolleschi
Differential Revision: D37361468
fbshipit-source-id: e6dda6a23eea4a824ad157d1a26f17e181db33cd
Summary:
This fix solves a problem very well evaluated [here](https://github.com/Expensify/App/issues/2727) as well as this [one](https://github.com/facebook/react-native/issues/29290).
The issue is that when the app goes to background, in landscape mode, the RCTDeviceInfo code triggers an orientation change event that did not physically happen. Due to that, we get swapped values returned when going back to the app.
I debugged the react-native code, and to me it seems that react native publishes the orientation change event one extra time when switching the state of the app to 'inactive'. Here is what is happening:
1. iPad is in landscape.
2. We move the app to inactive state.
3. Native Code queues portrait orientation change (no such change happened physically), and immediately after it triggers landscape change (same as we had in point 1).
4. We restore the app to active state.
5. The app receives two queued orientation change events, one after another.
6. The quick transition between portrait and landscape happens even though it never went back to portrait.
Fresh `react-native init` app repro case can be found here: https://github.com/lbaldy/issue-34014-repro
Video presenting the issue (recorded while working on: https://github.com/Expensify/App/issues/2727 ): https://www.youtube.com/watch?v=nFDOml9M8w4
## 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 the way the orientation events are published, to avoid false publish on orientation change when app changes state to inactive
Pull Request resolved: https://github.com/facebook/react-native/pull/34014
Test Plan:
### Test Preparation
1. Make sure you have a working version of E/App.
2. Open App/src/components/withWindowDimensions.js and update the constructor by changing this line:
`this.onDimensionChange = _.debounce(this.onDimensionChange.bind(this), 100);`
to
`this.onDimensionChange = this.onDimensionChange.bind(this);`
3. Open the NewExpensify.xcodeproj in xCode.
4. Open the RCTDeviceInfo.mm file and replace it's contents with the file from this PR.
5. Select your device of choice (I suggest starting with iPad mini) and run the app though xCode.
6. From this point you can move to the test scenarios described below.
### iPad Mini tests:
Reproduction + Fix test video (Test 1): https://youtu.be/jyzoNHLYHPo
Reproduction + Fix test video (Test 2): https://youtu.be/CLimE-Fba-g
**Test 1:**
1. Launch app in portrait, open chat - no sidebar visible.
7. Switch to landscape - sidebar shows.
8. Put app to background.
9. Put app back to foreground - make sure the side menu doesn't flicker.
**Test 2:**
1. Launch app in portrait, open chat - no sidebar visible.
2. Switch to landscape - sidebar shows.
3. Put app to background. Switch orientation back to portrait.
4. Put app back to foreground - make sure the side menu hides again as it should be in portrait.
### iPad Pro tests:
Reproduction + Fix test video (Test 3, Test 4): https://youtu.be/EJkUUQCiLRg
iPad mini test 1 applies.
Scenario 2 does not as the screen is too wide in both orientations and iPad pro shows sidebar always.
**Test 3:**
1. launch the app.
2. Make sure you're in landscape mode.
3. See split screen with some other app. Make sure the side bar is visible.
4. Play with the size of the view, resize it a bit. When the view shrinks it should hide the sidebar, when it grows it should show it.
10. Move the app to background and back to foreground, please observe there are no flickers.
**Test 4:**
1. Launch the app.
2. Make sure you're in landscape mode.
3. Make the multitasking view and make Expensify app a slide over app.
4. Move back to fullscreen/split screen. Make sure the menu is shown accordingly
5. Move the app to background and back to foreground, please observe there are no flickers.
### iPhone:
Non reg with and without the fix video: https://youtu.be/kuv9in8vtbk
Please perform standard smoke tests on transformation changes.
Reviewed By: cipolleschi
Differential Revision: D37239891
Pulled By: jacdebug
fbshipit-source-id: e6090153820e921dcfb0d823e0377abd25225bdf
Summary:
`InputAccessoryView` works fine on iOS, but crashes on Android - you can see that by using an Android device on the [Expo Snack from the official doc](https://reactnative.dev/docs/inputaccessoryview).
It forces the developer not to render the component on Android, which is usually good, but other components have implemented other, safer ways to deal with incompatibility issues.
I am of course open to discussion about this change, as well as other implementation ideas.
## Changelog
[Android] [Fixed] - Fix InputAccessoryView crash on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/33803
Test Plan:
`yarn test` gives out the following output:

Reviewed By: cipolleschi
Differential Revision: D37215394
Pulled By: cortinico
fbshipit-source-id: 66c4401f7c61b745ea893969d69c8dde3e5afb03
Summary:
I'm simplifying the `Android.mk` file inside the template as it was confusing. There are two ways to include the generated code from the codegen:
1. Importing the generated Android.mk file
2. Include the generate source files in the `_appmodules` source files.
Those two approaches are mutually exclusive (as doing both will lead to duplicate symbols). Our template comments were confusing and were suggesting a combination of both.
I'm simplifying the comments here by removing the one suggesting to go with option `1` instead.
## Changelog
[Android][Changed] - Simplify the Android.mk file in the App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34080
Test Plan: Nothing to test here as it's a comments only change
Reviewed By: cipolleschi
Differential Revision: D37463222
Pulled By: cortinico
fbshipit-source-id: 30ecc6fbbbcaf484272b4c724600cda588146506
Summary:
This is the companion PR of https://github.com/react-native-community/cli/pull/1630
It extends the `ReactNative-application.cmake` file with instructions to pickup the autolinked libraries.
## Changelog
[Internal] [Changed] - Extend the RN Application.cmake file to support Android autolinking
Pull Request resolved: https://github.com/facebook/react-native/pull/34082
Test Plan: Tested locally as we don't have a way to test autolinking on CI.
Reviewed By: cipolleschi
Differential Revision: D37463203
Pulled By: cortinico
fbshipit-source-id: 0b28e7f214c265ebfec4ccc59ae321f682299cf8
Summary:
setFocusable(int) was added in Android O, and setHyphenationFreqauency was added in M.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D37462117
fbshipit-source-id: e59d2de49dbdcddfdba25def6bb39695c65efe89
Summary:
We will use this error reporting pipeline for all js errors not only early js errors, so remove all "early" prefixes.
Changelog:
[General][Changed] - Remove "Early" in Js error reporting pipeline
Reviewed By: fkgozali
Differential Revision: D37379339
fbshipit-source-id: d44772818ead977a164c8632c081863851046be6
Summary:
Removes the `isTVOS` check, which just duplicated and returned the `isTV` check anyway.
## 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] [Removed] - Remove deprecated `isTVOS` constant.
Pull Request resolved: https://github.com/facebook/react-native/pull/34071
Test Plan: Run against CI, and apply changes as needed.
Reviewed By: cipolleschi
Differential Revision: D37434978
Pulled By: cortinico
fbshipit-source-id: 2b38253125251b0ce28cf10c88471d8f16704999
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34025
This diff moves the monkeypatch LocalPodspecPatch to a dedicated ruby file.
It also adds test for that
## Changelog
[iOS][Changed] - Move LocalPodspecPatch to dedicated file
Reviewed By: cortinico
Differential Revision: D37069361
fbshipit-source-id: 28fddb197484f45aa20ccac516c874e79448e999
Summary:
TL;DR: For applications using JS navigation, save 50-95% of CPU during mounting phase in N>2 navigations that replace ~most of screen.
During investigation of performance on the UI thread of React Native applications, I noticed that the /initial/ render of an screen for an application using JS navigation is /mostly/ consumed (on the UI thread) by tearing-down the previous View hierarchy. In one 185ms segment on the UI thread in production, 95% of the CPU time was Remove/Delete instructions and only 5% of CPU time was consumed by actually displaying the new hierarchy (this is specific to Android and also assumes that View Preallocation is being used, so post-commit work consists of Insert and UpdateLayout mutations primarily).
There are /some/ cases where the C++ differ knows that we are deleting an entire subtree and therefore we could communicate this to the mounting layer. All that matters is that these Views are removed from the View hierarchy immediately; and secondarily that their memory is cleaned up ASAP, but that doesn't need to happen immediately.
Some additional constraints and notes:
1) As noted in the comments, we cannot simply stop producing Remove and Delete instructions. We need to produce /both/ the new RemoveDeleteTree instruction, /and/ produce all the Remove/Delete instructions, primarily because LayoutAnimations relies heavily on these Remove/Delete instructions and certain things would break if we removed those instructions entirely. However, we can mark those Remove/Delete instructions as redundant, process them only in LayoutAnimations, and not send them to the Android mounting layer.
2) We want to make sure that View Recycling is not impacted. Since Android cannot take advantage of View Recycling until /after/ the second major render (preallocation of views will happen before any views are recycled), this doesn't impact View Recycling and we'll make sure Views are recycled whenever they are deleted.
Thus, we do two things:
1) Introduce a new RemoveDeleteTree operation that can delete an entire subtree recursively as part of one operation. This allows us to avoid serializing hundreds or thousands of instructions and prevents JNI traffic.
2) Besides removing the topmost View from the View hierarchy, and ensuring it's not drawn, the full teardown and recycling of the tree can happen /after/ the paint.
In some flows with JS navigation this saves us 95% of CPU during the mount phase. In the general case it is probably closer to 25-50% of CPU time that is saved and/or deferred.
Changelog: [Android][Changed] Significant perf optimization to Fabric Remove/Delete operations
Reviewed By: ryancat
Differential Revision: D37257864
fbshipit-source-id: a7d33fc74683939965cfb98be4db7890644110b2
Summary:
Changelog: [Internal] - Fix a bug in dispatch filtering that was too aggressively filtering out events to fire.
My flaw in logic was limiting the `isListening(view, bubble)` logic to `i==0` for relevant `ViewTargets`, when in reality, we need to be checking if every `ViewTarget` passed to `filterByShouldDispatch` is listening to a bubble event.
Further, as vincentriemer pointed out, `ancestorListening` should only be set true if a `ViewTarget` is listening to a capture event.
Reviewed By: vincentriemer
Differential Revision: D37423952
fbshipit-source-id: 2ed08038632677c24766bca6214dc00013fa2446
Summary:
Changelog: [iOS][Internal] - Emit move PointerEvents when hovering with an indirect pointer
This diff ensures that when a user is hovering an RN app w/ an indirect pointer (mouse/trackpad/ect.) that `pointermove` events are emitted. Previously `pointermove` was only fired on touch interactions on iOS.
Reviewed By: lunaleaps
Differential Revision: D37353158
fbshipit-source-id: 30366324ea10c91a38dbbc1be1032c021fd8a0e0
Summary:
Provides necessary changes for the autolinking to work in new architecture on Android. Depends on https://github.com/react-native-community/cli/pull/1603 and is subject to change.
Upgraded the RN CLI to v9.0.0-alpha.0 so that it's testable locally.
## 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
-->
[Android] [Change] - Adapt template to new architecture autolinking on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/33777
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D36478984
Pulled By: cortinico
fbshipit-source-id: 970fa7bcb77898d9defae18c20026a7783ba4108
Summary:
Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Details:
- Codemod script: `scripts/flow/tool add-comments --all --code missing-local-annot --comment "The type annotation(s) required by Flow's LTI update could not be added via codemod" .`
- Local Type Inference announcement: [post](https://fb.workplace.com/groups/flowlang/posts/788206301785035)
- Codemod announcement: [post](https://fb.workplace.com/groups/flowlang/posts/917522612186736)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
bypass-lint
drop-conflicts
Reviewed By: evanyeung
Differential Revision: D37403582
fbshipit-source-id: 2024542952042dd93e2c123ba047410e1feca749
Summary:
`getCurrentPriorityLevel` is a function which should return the priority level on invocation.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37314727
fbshipit-source-id: fe385af02af49d1ca444beb881a4893f7f0712f0
Summary:
`asHostObject` should throw a `JSINativeException` like the other `as*`
functions. This should be a safe change to make in most cases, since
this function already did not work when JSI was being provided by a
dynamic library. However, I defer to mhorowitz.
Changelog: [Fixed] Throw JSINativeException from asHostObject
Reviewed By: jpporto
Differential Revision: D36873355
fbshipit-source-id: 589ac50ebb4ecec4bacfd923d8b0795c0a6c0e34
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary:
The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration.
Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native.
So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files.
The code snippet in **ReactInstanceManager** for adding a new setter method:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
The code snippet for the new logic in **ReactInstanceManagerBuilder**:
1) Setting up the new logic:
Adding a new enum class :
```
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable.
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one:
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix**
```
builder = ReactInstanceManager.builder()
.setApplication(this)
.setJsEngineAsHermes(BuildConfig.HERMES_ENABLED)
.setBundleAssetName("index.android.bundle")
.setJSMainModulePath("index")
```
where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle:
`def enableHermes = project.ext.react.get("enableHermes", true)
`
and then
```
defaultConfig{
if(enableHermes) {
buildConfigField("boolean", "HERMES_ENABLED", "true")
}
else{
buildConfigField("boolean", "HERMES_ENABLED", "false")
}
}
```
Our app was facing a similar issue as listed in this list: **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button.
This change can possibly solve many of the issues listed in the list as it solved ours.
## Changelog
[GENERAL] [ADDED] - An enum JSInterpreter in com.facebook.react package:
```
/**
* An enum that specifies the JS Engine to be used in the app
* Old Logic uses the legacy code
* JSC/HERMES loads the respective engine using the revamped logic
*/
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
[GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder:
```
private JSInterpreter jsEngine = JSInterpreter.OLD_LOGIC;
```
[GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
[GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33952
Test Plan:
The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO
Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project.
It can be like:
```
packagingOptions {
if (enableHermes) {
exclude "**/libjsc*.so"
}
}
```
Reviewed By: lunaleaps
Differential Revision: D37191981
Pulled By: cortinico
fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e
Summary:
Changelog: [Internal] Fixing a recent optimization to prevent event dispatches for events that are not listened for. An incorrect hitpath was passed in for `leave` events.
Refactored the PointerEvent optimization such that `filterByShouldDispatch` determines what views should dispatch a PointerEvent, and `dispatchEventForViewTargets` to actually dispatch them. We are separating this because the order of dispatch differs between `enter` and `leave` events.
Reviewed By: vincentriemer
Differential Revision: D37348726
fbshipit-source-id: a09a04df3ae027cce95e0d93a4163c2015fe3fe3
Summary:
We need to check that the animated node exists prior to executing the animation. The native animated node lifecycle is not synced with Fabric and nodes are frequently destroyed and re-created on rerenders. Therefore, there is a possibility that the the animated node does not exist when the native event is dispatched, in particular with native call batching.
Changelog:
[Internal] - Make NativeAnimatedNodesManager.getNodeById public
Reviewed By: JoshuaGross
Differential Revision: D37323138
fbshipit-source-id: ed0567871b4189c454b6b3145b853ecdfe844840
Summary:
This improves errors significantly, which is especially helpful as the runtime scheduler only implements a subset of the JS API.
Example error: `Error: Exception in HostObject::get for prop 'unstable_next': undefined property`
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D37313924
fbshipit-source-id: b53bc67b9cc36dee34dba86c07fdcf2353338c72
Summary:
As we changed the deps for react-native/eslint-plugin-specs, let's release a new version of it.
Changelog:
[General] [Changed] - Bump react-native/eslint-plugin-specs to 0.0.4
Reviewed By: jacdebug
Differential Revision: D37353474
fbshipit-source-id: dc77c987ee06d72903d246544c63816a64ecd7f6
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: bradzacher
Differential Revision: D37363351
fbshipit-source-id: a9d3df7db6f9d094ac2ce81aae1f3ab4f62b243a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34049
This just flips the switch for having Hermes on by default
on new projects for React Native.
Changelog:
[Android] [Changed] - Make Hermes the default engine on Android
Reviewed By: neildhar, jpporto
Differential Revision: D37354079
fbshipit-source-id: cb0391eb3927d13432e7d4b9efef7b8812938a98
Summary:
This removes the `hermes-engine` NPM package from the RN package.json.
Users are not supposed to use this package anymore as we now ship Hermes
bundled with React Native.
More on this here: https://reactnative.dev/architecture/bundled-hermes
Changelog:
[General] [Changed] - Do not depend on hermes-engine NPM package anymore
Reviewed By: neildhar
Differential Revision: D37353977
fbshipit-source-id: b049d18e945a72c1f37c3e4b040af83b5e395774
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37360113
fbshipit-source-id: 870bcfe680542b3861fefbaf372db0ae8b32cbf3
Summary:
ThemedReactContext should be what is stored as the context on all RN views, but some legacy components use other things like an Activity.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37356865
fbshipit-source-id: bc914cd06a8846037506a50f254995a6e10c8a9c
Summary:
[`babel-eslint`](https://github.com/babel/babel-eslint) is deprecated now. We should use the new Babel parser.
## 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] - Use new Babel parser instead of deprecated one
Pull Request resolved: https://github.com/facebook/react-native/pull/34020
Test Plan: Ensure lint is working as expected.
Reviewed By: cortinico
Differential Revision: D37239826
Pulled By: jacdebug
fbshipit-source-id: f5fa5d7f829d6d3ae5cffd855ed6c8542c7d46de
Summary:
This PR is a follow up for the contributing content move on the website:
* https://github.com/facebook/react-native-website/pull/3120
It replaces most of the CONTRIBUTING file content with a reference to the contributing overview page on the website, which has been based off the content of this file.
Additionally I have searched thought the code for the wiki links and replaces theme with the correct website links. There was an instance where comment was referring to an old and removed a while ago wiki page, so I just get rid of this link.
## Changelog
[Internal] [Chore] - Update CONTRIBUTING.md, replace wiki links
Pull Request resolved: https://github.com/facebook/react-native/pull/34035
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D37318814
Pulled By: cortinico
fbshipit-source-id: d3f5e5c5bd477c0de5c4f0f1d5de81f464b9f5b4
Summary:
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Changelog for 0.69.0
Pull Request resolved: https://github.com/facebook/react-native/pull/33730
Reviewed By: lunaleaps
Differential Revision: D36007445
Pulled By: cortinico
fbshipit-source-id: adb9070a83b992f7138e93710a0508be59f07832
Summary:
Fix crashes that can occur on older versions of Android due to not-yet-implemented APIs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37321713
fbshipit-source-id: a27aaf4b28e19a86f4cb10808162102177b9f306
Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## 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][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
Original commit changeset: 78387999f94e
Original Phabricator Diff: D34392529 (https://github.com/facebook/react-native/commit/086c13dd5fba3f77acbc70c9bdedc9299118b526)
Backing this out because it breaks univeral hot reload support. We should probably find a way to support this *without* relying on swizzling. This was originally backed out it because it was blocking app store submission, but this is gated by `RN_DEV` so should never be included in a release build.
Changelog:
[General][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's
Reviewed By: cipolleschi
Differential Revision: D37311377
fbshipit-source-id: 18abb1b53a5be054098cd3717705ea5086c4f595
Summary:
# Context
ScrollView sticky headers rely on this bit of code to work:
```
AnimatedImplementation.attachNativeEvent(
this._scrollViewRef,
'onScroll',
[{nativeEvent: {contentOffset: {y: this._scrollAnimatedValue}}}],
);
```
What this code means:
When the ScrollView host component receives the "onScroll" event, assign event.nativeEvent.contentOffSet.y to the this._scrollAnimatedValue AnimatedValue.
How this subscription mechanism is set up:
NativeAnimatedTurboModule subscribes to events dispatched by RCTEventDispatcher sendEvent. Then, whenever RCTEventEmitter sendEvent executes, NativeAnimatedTurboModule also updates the AnimatedValue for that event.
# Problem
Previously, in bridgeless, we started dispatching RCTScrollView via the RCTEventDispatcher sendEvent to update the AnimatedValue for ScrollView. This meant that we started dispatching the onScroll event to JavaScript via RCTEventEmitter.receiveEvent JSModule, which isn't supported in the Fabric renderer.
With this diff, we dialed back that solution. Instead of (1) notifying NativeAnimatedTurboModule and (2) sending the onScroll event to JavaScript, we're only doing (1) (i.e: notifying NativeAnimatedTurboModule).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D37257719
fbshipit-source-id: 7dea3cf8b9ae78f6b0fd40414b8f224d43367a5a
Summary:
`use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things:
- use `header_mappings_dir` to keep `react/bridging` header structure
- because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary.
- forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec.
## Changelog
[iOS] [Fixed] - Fix use_frameworks! for 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/34011
Test Plan:
```sh
$ npx react-native init RN069 --version next
# add `use_frameworks!` to ios/Podsfile
# comment out use_flipper!() in ios/Podfile
# patch node_modules/react-native with these changes
$ yarn ios
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D37169699
Pulled By: dmitryrykun
fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0
Summary:
This PR is fixing the build errors on iOS when `use_frameworks!` and `:hermes_enabled` are both enabled. There are two errors:
- fmt/compile.h include not found: This PR adds fmt in header search paths.
- undefined symbols `_jump_fcontext` and `_make_fcontext` from boost. the two symbols are actually not be unused. because to generate the shared library in dynamic framework mode, LTO (Link-Time-Optimization) is not as powerful as generating a single executable.
## Changelog
[iOS] [Fixed] - Fix RCT-Folly build error when use_frameworks! and hermes are both enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34030
Test Plan:
- CI passed
-
```
$ npx react-native init RN069 --version next
# edit RN069/ios/Podfile to enable use_frameworks! and hermes_enabled
# patch node_modules/react-native from both https://github.com/facebook/react-native/issues/34011 and this prs' patch
$ pod install
$ yarn ios
```
Reviewed By: cortinico
Differential Revision: D37284084
Pulled By: dmitryrykun
fbshipit-source-id: 923fa03d7844d1d227880919c8b2c8614c848d59
Summary:
Rewrites `EventEmitter` as a simple, type-safe abstraction with a minimal interface.
The public interface of `EventEmitter` is unchanged. This rewrite was made possible only after deprecating and removing public methods that imposed restrictions on implementation details (e.g. deleting `removeListener`).
However, this includes a subtle breaking change that makes it behave the same as `EventEmitter` in Node.js and `EventTarget` in the DOM. The set of listeners being notified by `emit` will no longer be influenced by changes made during the course of notifying the existing listeners.
Changelog:
[General][Changed] - `EventEmitter#emit` now freezes the set of listeners before iterating over them, meaning listeners that are added or removed will not affect that iteration.
Reviewed By: javache
Differential Revision: D22153962
fbshipit-source-id: 81b87113590dee0296eff61374bf732171855453
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33990
This diff moves the setting of some CPP flags from the main React native pods file to a dedicated file.
It also introduces some tests and it improves the Test Mocks we have
## Changelog
[iOS][Changed] - Move the `modify_flags_for_new_architecture` method to separate ruby file
Reviewed By: cortinico
Differential Revision: D37040927
fbshipit-source-id: 037ddaf123d01f3a2fd622b8a0cd10535da70b92
Summary:
Currently `ListHeaderComponent` & `ListFooterComponent` allow to use React Componetn & Elemelen
```tsx
<FlatList
ListHeaderComponent={<View />} // valid
ListHeaderComponent={View} // valid
/>
```
But when you try to pass `ItemSeparatorComponent` as React Element it will throw an error
```tsx
<FlatList
ItemSeparatorComponent={View} // ok
ItemSeparatorComponent={<View />} /* not valid:
Error: Element type is invalid: expected a string (for built-in components) or a class/function
(for composite components) but got: object.
Check the render method of `CellRenderer`.
*/
/>
```
So, this PR adds this ability
## 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] - Add ability to pass `ItemSeparatorComponent` as React Element
Pull Request resolved: https://github.com/facebook/react-native/pull/32748
Test Plan: ...
Reviewed By: lyahdav
Differential Revision: D37227719
Pulled By: cortinico
fbshipit-source-id: 1c4943fa9d42bf5e61fbd999d1f5be46b51ecb14
Summary:
Fixes a trivial crash that occurs when running View Recycling on pre-Android P devices.
Changelog: [Internal]
Reviewed By: bvanderhoof
Differential Revision: D37242858
fbshipit-source-id: 74f3912d60799172c47c67a87f662b4ff8fb1e35
Summary:
LogBox was using AppRegistry to render on to the screen. Switch LogBox over to using SurfaceRegistry instead.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D37223641
fbshipit-source-id: 59001ad290c1e2c2f14828d38a96f48bd1ab39ca
Summary:
Original commit changeset: 4c0afc95abe8
Original Phabricator Diff: D37155957 (https://github.com/facebook/react-native/commit/d1321d88bdc80b209aeb781991d8143d6ce2f9a9)
See attached UBN task for more details, I am reverting the whole diff now while investigating the root cause.
Changelog:
[General][Changed] - Revert "React Native sync for revisions d300ceb...256aefb"
jest_e2e[run_all_tests]
=== update
klein did a bisect for S276290, it seems Original Phabricator Diff: D37155957 (https://github.com/facebook/react-native/commit/d1321d88bdc80b209aeb781991d8143d6ce2f9a9) is the blame diff.
jackworden also has verified backout can fix it for both ios and android.
Reviewed By: ahujap-fb, kacieb
Differential Revision: D37205394
fbshipit-source-id: 600e6593532da064631c016aace317932f290c67
Summary:
`hermes-eslint` is built by Meta to work with the latest Flow code.
It follows the latest ESLint standards and AST, and has a true scope analyser to ensure best compatibility with core ESLint rules.
Reviewed By: motiz88
Differential Revision: D37181192
fbshipit-source-id: 1f59e01f306792e67a4977435c5c77e0000d960a
Summary:
See commentary at top of stack.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37051020
fbshipit-source-id: 643e433c0d0590cfcd17bc7a43d105bed6ff12ef
Summary:
See commentary at top of stack.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050961
fbshipit-source-id: 170a09c08d7406b6aac51d7e78cf295a72fdcf91
Summary:
See commentary at top of stack.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050376
fbshipit-source-id: 2bea35a6d604704cf430bd3b2914988227d1abf8
Summary:
Perf numbers for this stack are given in terms of before-stack and after-stack, but the changes are split up for ease of review, and also to show that this migration CAN happen per-component and is 100% opt-in. Most existing C++ components do not /need/ to change at all.
# Problem Statement
During certain renders (select critical scenarios in specific products), UIManagerBinding::createNode time takes over 50% of JS thread CPU time. This could be higher or lower depending on the specific product and interaction, but overall createNode takes a lot of CPU time. The question is: can we improve this? What is the minimal overhead needed?
The vast, vast majority of time is taken up by prop parsing (specifically, converting JS values across the JSI into concrete values on the C++ props structs). Other methods like appendChild, etc, do not take up a significant amount of time; so we conclude that createNode is special, and the JSI itself, or calling into C++, is not the problem. Props parsing is the perf problem.
Can we improve it? (Spoiler: yes)
# How does props parsing work today?
Today, props parsing works as follows:
1. The ConcreteComponentDescriptor will construct a RawPropsParser (one per component /type/, per application: so one for View, one for Image, one for Text... etc)
2. Once per component type per application, ConcreteComponentDescriptor will call "prepare" on the RawPropsParser with an empty, default-constructed ConcreteProps struct. This ConcreteProps struct will cause RawProps.at(field) for every single field.
3. Based on the RawProps::at calls in part 2, RawPropsParser constructs a Map from props string names (width, height, position, etc) to a position within a "value index" array.
4. The above is what happens before any actual props are parsed; and the RawPropsParser is now ready to parse actual Props.
5. When props are actually being parsed from a JSI dictionary, we now have two phases:
1. The RawPropsParser `preparse`s the RawProps, by iterating over the JSI map and filling in two additional data structures: a linear list of RawValues, and a mapping from the ValueIndex array (`keyIndexToValueIndex_`; see step 3) to a value's position in the values list (`value_` in RawPropsParser/RawProps);
2. The ConcretePropT constructor is called, which is the same as in step 2/3, which calls `fieldValue = rawProps.at("fieldName")` repeatedly.
3. For each `at` call, the RawProps will look up a prop name in the Map constructed in step 3, and either return an empty value, or map the key name to the `keyIndexToValueIndex_` array, which maps to a value in `values_`, which is then returned and further parsed.
So, a few things that become clear with the current architecture:
1. Complexity is a property of the number of /possible/ props that /can/ be parsed, not what is actually used in product code. This violates the "only pay for what you use" principal. If you have `<View opacity={0.5} />`, the ViewProps constructor will request ~170 properties, not 1!
2. There's a lot of pre-parsing which isn't free
3. The levels of indirection aren't free, and make cache misses more likely and pipelining is more challenging
4. The levels of indirection also require more memory - minor, but not free
# How can we improve it?
The goal is to improve props parsing with minimal or zero impact on backwards-compability. We should be able to migrate over components when it's clear there's a performance issue, without requiring everything gets migrated over at once. This both (1) helps us prove out the new architecture, (2) derisks the project, (3) gives us time, internally and externally, to perfect the APIs and gradually migrate everything over before deleting the old infrastructure code entirely.
Thus, the goal is to do something that introduces a zero-cost abstraction. This isn't entirely possible in practice, and in fact this method slightly regresses components that do not use the new architecture /at all/, while dramatically improving migrated components and causing the impact of the /old/ architecture to be minimal.
# Solution
1. We still keep the existing system in place entirely.
2. After Props are constructed (see ConcreteComponentDescriptor changes) we iterate over all the /values/ set from JS, and call PropsT::setProp. Incidentally, this allows us to easily reuse the same prop for multiple values for "free", which was expensive in the old system.
3. It's worth noting that this makes a Props struct "less immutable" than it was before, and essentially now we have a "builder pattern" for Props. (If we really wanted to, we could still require a single constructor for Props, and then actually use an intermediate PropsBuilder to accumulate values - but I don't think this overhead would be worth for the conceptual "immutability" win, and instead a "Construct/Set/Seal" model works fine, and we still have all the same guarantees of immutability after the parsing phase)
# Implementation Details
# How to properly construct a single Prop value
Minor detail: parsing a single prop is a 3-step process. We imagine two scenarios: (1) Creating a new ShadowNode/Props A from nothing/void, so the previous Props value is just the default constructor. (2) Cloning a ShadowNode A->B and therefore Props A must be copied to Props B before parsing.
We will denote this as a clone from A->B, where A may or may not be a previous node or a default-constructed Props node; and imagine in particular that we're setting the "opacity" value for PropsB.
We must first (1) copy a value over from the previous version of the Props struct, so B.opacity = A.opacity; (2) Determine if opacity has been set from JS. If so, and there is a value, B.opacity = parse(JSValue). (3) If JS has passed in a value for the prop, BUT the value is `null`, it means that JS is resetting or deleting the prop, so we must set it BACK to the default. In this case we set PropsB.opacity = DefaultConstructedProps.opacity.
We must take care in general to ensure that the correct behavior is achieved here, which should help to explain some of the code below.
## String comparisons vs hash comparisons
In the previous system, a RawPropsKey is three `const char*` strings, concatenated together repeatedly /at runtime/. In practice, the ONLY reason we have the prefix, name, suffix Key structure is for the templated prop parsing in ViewProps and YogaStyableProps - that's it. It's not used anywhere else. Further, the key {"margin", "Left", "Width"} is identical to the key {"marginLeftWidth", null, null} and we don't do anything fancy with matching prefixes before comparing the whole string, or similar. Before comparison, keys are concatenated into a single string and then we use `strcmp`. The performance of this isn't terrible, but it's nonzero overhead.
I think we can do better and it's sufficient to compare hashed string values; even better, we can construct most of these /at compile time/ using constexpr, and using `switch` statements guarantee no hash collisions within a single Props struct (it's possible there's a collision between Props.cpp and ViewProps.cpp, for example, since they're different switch statements). We may eventually want to be more robust against has collisions; I personally don't find the risk to be too great, hash collisions with these keys are exceedingly unlikely (or maybe I just like to live dangerously). Thus, at runtime, each setProp requires computing a single hash for the value coming from JS, and then int comparisons with a bunch of pre-compiled values.
If we want to be really paranoid, we could be robust to hash collisions by doing `switch COMPILED_HASH("opacity"): if (strcmp(strFromJs, "opacity") == 0)`. I'm happy to do this if there's enough concern.
## Macros
Yuck! I'm using lots of C preprocessor macros. In general I found this way, way easier in reducing code and (essentially) doing codegen for me vs templated code for the switch cases and hashing prop names at compile-time. Maybe there's a better way.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050215
fbshipit-source-id: d2dcd351a93b9715cfeb5197eb0d6f9194ec6eb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34015
I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup.
Changelog: [Internal]
Reviewed By: IanChilds
Differential Revision: D37178005
fbshipit-source-id: cba51e168c5a2f2ee6468acb8c144db4ad352d95
Summary:
A huge set of props use YGValue directly, say something really basic like `margin`/`position`/`padding`/`border`.
All of these according to CSS spec actually support `number | "em" | "px" | %` units, but we are going to throw and hard crash on `em` and `px`, which are unsupported in React Native.
Using `tryTo` instead of `to` (noexcept vs throwing method) for conversion, and treating things like `margin: 50px` same way as we would treat `margin: false` which is not really supported.
Changelog:
[General][Fixed] - Fixed a crash on deserialization of props when using 'px'/'em' units.
Reviewed By: bvanderhoof
Differential Revision: D37163250
fbshipit-source-id: 59cbe65a821052f6c7e9588b6d4a0ac14e344684
Summary: Some files relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff is fixing missing imports
Reviewed By: rmaz
Differential Revision: D37140239
fbshipit-source-id: bc57921e0c8365e0e9a5a571d607ba40ff1b31f3
Summary:
Changelog: [Internal][Changed]
The diff I'm backing out accidentally made Hover events in Felios apps that use RN under the hood stopped working in headsets (Oculus, Arcata). So we can't test our apps properly without these events.
We, with the diff author Luna tried to fix that but it turned out to be not easy so we decided to revert the commit in order to unblock experiences teams.
Original commit changeset: d6b5c32ae50b
Original Phabricator Diff: D36601638 (https://github.com/facebook/react-native/commit/40769f2212dcd85cba2e54973179c7de445499a4)
(Note: this ignores all push blocking failures!)
Reviewed By: arhelmus
Differential Revision: D37135208
fbshipit-source-id: 4f7d5f168b795690e951ce7063ae3feec3338772
Summary:
Adds support for handling animations in response to events on the platform side, without needing a JS round trip. With this TM, NativeViewEvents will no longer affected by JS thread - hover events will not be delayed when JS thread is busy. This makes a significant difference for VR panel apps - see test plan for an example for the before and after in Store.
Changelog:
[Internal] - Make NativeAnimatedNodesManager public
Reviewed By: JoshuaGross
Differential Revision: D37082069
fbshipit-source-id: 330acd78c547587de5545b61895e0d821fb99552
Summary:
We currently wrap colors in an object to make it look similar to a `PlatformColor` object, but since this is a hot codepath, let's just optimize it to a simple array of strings. The next step is to apply a layer of caching here, but this should be a simple improvement.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D31057046
fbshipit-source-id: f68e17167ddd5bba3b545d039600c7c9b40808f5
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33982
This Diff moves another part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37006265
fbshipit-source-id: ffaac3270cb098fa30b73c97ce7cd350dfb8d7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33978
This Diff moves part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37004347
fbshipit-source-id: a5156f7c199d082d5d895a58af80948556c51c2a
Summary:
Reverts https://github.com/facebook/react-native/pull/29012
It is not really possible to properly validate if ENTRY_FILE exists since it is resolved by metro, and the server is not always running from the app root, like in a monorepo with multiple RN apps running on the same metro server.
In my case I run metro on the repo root and entry file will be something like `apps/app/index.js`. `-f "$ENTRY_FILE"` will fail since the script is run from the project folder (`PROJECT_ROOT`, in my case the `apps/app` folder, so it tries to resolve `apps/app/apps/app/index.js`).
I don't think this check is actually useful since metro will report the error if the entry file is invalid (fixed in https://github.com/facebook/react-native/pull/30150). The error is not as user friendly, but I think it is still fine. Maybe it could be improved in metro.
## Changelog
[iOS] [Fixed] - Don't validate ENTRY_FILE in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/32762
Test Plan:
Before
<img width="854" alt="image" src="https://user-images.githubusercontent.com/2677334/146100834-39310c9f-1767-496a-8698-1026726a1120.png">
After if file is actually missing
<img width="987" alt="image" src="https://user-images.githubusercontent.com/2677334/146100893-d01e2247-c787-4174-ac60-2f308c338c8f.png">
After if file exists, builds successfully.
Reviewed By: cortinico
Differential Revision: D37066073
Pulled By: cipolleschi
fbshipit-source-id: 8f6b149099a39d9179996bb965daa6cd9e06feac
Summary:
Please see this issue https://github.com/facebook/react-native/issues/33034 for details on the problem solved by this PR.
## 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
-->
[CATEGORY] [TYPE] - Message
[ios] [changed] - HTTP Response headers added to the error object passed to JS code.
Pull Request resolved: https://github.com/facebook/react-native/pull/33880
Test Plan:
Tested:
(All tests done on images in rn-tester app, which is a part of this repo)
1. onError method in case image has an HTTP Error
2. onError method in case of non http error (DNS error)
3. Successful image load
Reviewed By: cortinico
Differential Revision: D37066159
Pulled By: cipolleschi
fbshipit-source-id: 546f7678fa0321fe6c6fbef55288715cb6ddc2fd
Summary:
The idea behind this is to encapsulate as much build logic as possible inside a `.cmake` file which is contained inside React Native.
This reduces the API surface for the users, once we apply this change to the `template` project, and makes easier for us to evolve native library dependencies on Android, without having to worry about asking users to replicate those changes.
Currently the change is only on RN Tester, will replicate to the template afterwards
## Changelog
[Internal] [Changed] - Encapsulate all the CMake build logic inside a `ReactNative-application.cmake` file for RN Tester
Pull Request resolved: https://github.com/facebook/react-native/pull/33985
Test Plan: Circle CI
Reviewed By: cipolleschi
Differential Revision: D37039658
Pulled By: cortinico
fbshipit-source-id: 536593e3b7227158acba3f0fb6561efaaa9720a5
Summary:
Changelog:
[Internal][Fixed] - https://github.com/facebook/react-native/pull/33973 breaks the internal CI, as it depends on the outdated offline mirror for `Pods/Target Support Files`.
Reviewed By: cortinico
Differential Revision: D37038213
fbshipit-source-id: 1d27c9c32f2c3ddecd15a83935c520d1e1524b21
Summary:
It turned out the previous attempt to rely on the Event's UIManagerType wasn't sufficient, as not all Fabric touch event had a surfaceId set on them, e.g. Modal etc.
This brings back the UIManagerType detection based on reactTag, but do it only for non-rootView to keep handling touch via the right dispatcher for rootView as well.
Changelog: [Fixed][Android] Bring back non-rootview touch handling based on reactTag
Reviewed By: JoshuaGross, sshic
Differential Revision: D37063335
fbshipit-source-id: 76e2d7ae5f00006c5ecaf50c86920ea6e85155b7
Summary:
TurboCxxModule doesn't use the the default JSI getter that TurboModule offers, and has custom behaviour for `getConstants` which broke the I18nAssets module in the binding experiment.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37030917
fbshipit-source-id: 187f159abc76f792ad2c7045dc2852d216ea978d
Summary:
[A recent fix](https://github.com/facebook/react-native/pull/33076) to Android to set focusable to true when accessible is true, and this caused several components not to work correctly.
This JS change essentially reverts the default back to Text not being focusable unless it is explicitly set. Android's "auto" behavior is better than setting `accessible=true`, and it's also the behavior React Native has had since accessibility on Android was implemented.
# Wall of Text Explanation
Explanation From Brett's comment [here](https://www.internalfb.com/diff/D35908559?dst_version_fbid=700876567897063&transaction_fbid=477905564133412)
blavalla
Generally speaking, "accessible" in react native maps to "focusable" in Android views, and the default value for "focusabe" for a TextView (and actually all views) is "auto" not "false". The difference here is that "false" is telling the system to explicitly disallow focus on this element, where as "auto" is telling the system that it's up to whatever service is trying to focus to determine if it should or not.
In the case of text, Talkback generally does default to focusing on Text when it's set to "auto", though it also does try to combine this text together with other not-explicitly focusable siblings and roll the focus up to some common ancestor element.
In the case of TetraButton here, I would expect the default behavior would be that the text is "auto" focusable, so Talkback would combine the text here with the parent <TetraPressable> (which is explicitly focusable via accessible="true").
...
[This diff](https://github.com/facebook/react-native/pull/33076) was to fix the issue with "disabled" not properly announcing on text views, which was commonly occuring due to the description-combining feature described above. Basically, when Talkback decides to combine not-explicitly-focusable elements together, it ignores properties like "disabled", "selected", etc. so when combined only the text is transferred.
The "fix" here was to make sure that if disabled was set, that an element was always explicitly focusable so that it wouldn't be eligible to be combined with others. I think that as a general concept makes sense, but the fix actually surfaced an issue that is likely a much older bug.
This line in <Text>
```
accessible={accessible !== false}
```
Is basically always setting accessible="true" unless it's explicitly set to false, and has been in there for years. It was likely added to force text to be accessible by default for iOS. But until [this diff](https://github.com/facebook/react-native/pull/33076) this line was basically a no-op for Android, since setting accessible="true" on text would do nothing at all.
[This diff](https://github.com/facebook/react-native/pull/33076) changed this so that setting accessible="true" worked how you'd expect, by making the view explicitly focusable, which was necessary for the disabled behavior to work properly. But that means that now by default all text views are explicitly focusable on both iOS and Android, and this there is likely many components that were built that don't expect this to be the case.
It doesn't seem like the right fix here is to revert this behavior to its previous state, as it wasn't working how anyone would expect it to if they looked at the code, and it seems like we were relying on some fairly undocumented behavior of Talkback to get it to work how we wanted. If we truly only wanted accessible="true" to be set on all TextViews for iOS, we should be explicit about it and do a platform check before setting that property. If we didn't want this to be iOS-specific, then everything is now actually working as originally intended.
For reference, this is the diff that introduced the default-accessible text - https://www.internalfb.com/diff/D1561326, and the description makes it clear that this was only tested on iOS, and the behavior was explicitly trying to map to iOS norms such as not allowing nested accessible elements.
Changelog:
[Android][Fixed] Make Text not focusable by default
Reviewed By: ryancat
Differential Revision: D36991394
fbshipit-source-id: c45d2ada72bb2d6ffeee6947d676a07fb8899449
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33885
When building Hermes for React Native, point to the React Native JSI location to ensure both React Native and Hermes use the exact same version of JSI.
Changelog:
[iOS] [Changed] - When Hermes is enabled, it will use the same copy of JSI as React Native
Reviewed By: cortinico, cipolleschi
Differential Revision: D36567471
fbshipit-source-id: 97d954ef34007bd31f008fab451512194060d670
Summary:
Allow an arbitrary path to hermes-runtime-darwin-vX.Y.Z.tgz to be specified. This can be used in CI or in local e2e tests to test with Hermes enabled without having a matching GitHub release.
Usage:
```
HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes- runtime-darwin-v0.69.0.tar.gz \
USE_HERMES=1 \
pod install
```
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36985477
fbshipit-source-id: 853829c89e6f0ac3f63781c7f290cf3994b8e0cd
Summary:
Changelog: [iOS][Fixed] - `_scrollViewComponentView` is set to `RCTPullToRefreshViewComponentView's` superview:
```
_scrollViewComponentView = [RCTScrollViewComponentView findScrollViewComponentViewForView:self];
```
It should be safe to make it weak.
Reviewed By: javache
Differential Revision: D36998626
fbshipit-source-id: 2130b743d181e15986cb68636d60507a986968e1
Summary:
This fixes an issue in the C++ TurboModule codegen where optional return types would result in a compiler error because they were not being defaulted to `null` when converting to `jsi::Value`.
Changelog:
Internal
Reviewed By: javache
Differential Revision: D36989312
fbshipit-source-id: 525f9ce7a5638ba5a655fa69ba9647978030ab0b
Summary:
This diff adds an assertion to make sure the pending events are enqueued only when the event emitter is null. This is to avoid unexpected workflow when we queue events but we should just dispatch them.
Changelog:
[Android][Internal] - Make sure we only queue events when event emitter is null
Reviewed By: javache
Differential Revision: D36916482
fbshipit-source-id: fff305615b302ece26bc2482c826b74de4f70266
Summary:
`OTHER_CFLAGS` doesn't seem to work when the file is imported from Objc++. This causes flipper to not be included.
## Changelog
[iOS] [Fixed] - Use `GCC_PREPROCESSOR_DEFINITIONS` to set `FB_SONARKIT_ENABLED`
Pull Request resolved: https://github.com/facebook/react-native/pull/33972
Test Plan: Tested the change in an app. Used a breakpoint to see that flipper code is not executed before this change, and is after. Also made sure other `GCC_PREPROCESSOR_DEFINITIONS` set by cocoapods are still properly inherited.
Reviewed By: cipolleschi
Differential Revision: D37001624
Pulled By: dmitryrykun
fbshipit-source-id: 920f3fe368a9fbe2cde9aa1e6d5b3b883c42119d
Summary:
D36784563 (https://github.com/facebook/react-native/commit/ec307e0167deca7f17640cd3c5a60f6be5f47b62) caused some issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Changelog
[Android] [Fixed] - Revert PR 33924 because of issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Reviewed By: makovkastar
Differential Revision: D36994688
fbshipit-source-id: 89cd556ca1cf8fd89560aeb9ead129607b4c13c6
Summary:
D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) changed Animated to only use value of natively driven nodes on initial render.
However, there remained a case where we could end up with a race condition between Fabric prop update (via SurfaceMountingManager.updateProps) and Animated (via NativeAnimatedNodesManager.runUpdates), when an animation on a node that was created natively is triggered close to render (such as in componentDidUpdate). This happens as Animated and Fabric aren't synchronized, and at the platform level, they do not know each other's state.
Say we have two items, where opacity is used to indicate whether the item is selected. On initial render, A's opacity is set to 1, and animated sets opacity to 1; B's opacity is set to 0, and animated sets opacity to 0. When B is selected (and causes A and B to rerender), A's opacity is now set to null, and animated sets opacity to 0; B's opacity is also now set to null, and animated sets opacity to 1. A's props have changed, and thus the default opacity value of 1 is applied via Fabric, but Animated also sets the opacity to 0 - either may end up being the value visible to the user due to the nondeterministic order of Fabric update props and Animated. This is what is causing T122469354.
This diff addresses this edge case by using the initial prop values for native animated nodes, for subsequent renders, to ensure that values of native animated nodes do not impact rerenders.
This diff also fixes a bug in OCAnimation where translateX/Y values of 0 in transition will result in render props containing translateX/Y instead of transform, resulting in potentially incorrect pressability bounds.
Changelog:
[Internal][Fixed] - Only use initial value of natively driven nodes on render
Reviewed By: JoshuaGross, javache
Differential Revision: D36958882
fbshipit-source-id: 10be2ad91b645fa4b8a4a12808e9299da33aaf7d
Summary:
Changelog:
[Android][Fix] - When `onEndReachedThreshold` is set to 0 `onEndReached` function on `VirtualizedList` properly fires once the user scrolls to the bottom of the list.
Reviewed By: genkikondo
Differential Revision: D36488189
fbshipit-source-id: b95f3291f2957273280696d8840c1e000d669380
Summary:
This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See https://github.com/facebook/react-native/pull/33381.
The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers.
Tested in the YogaKitSample, and also in a react-native app.
Changelog:
[iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus
X-link: https://github.com/facebook/yoga/pull/1150
Reviewed By: dmitryrykun
Differential Revision: D36966687
Pulled By: cortinico
fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39
Summary:
https://github.com/facebook/react-native/commit/3337add547c60b84816ef5dad82f4ead2e8742ef made some changes to method signature but the template wasn't updated. This adds the missing changes.
## Changelog
[Internal] [Fixed] - Pass string by ref in TurboModule template
Pull Request resolved: https://github.com/facebook/react-native/pull/33970
Test Plan: Didn't test the template directly, but the change is trivial.
Reviewed By: cortinico
Differential Revision: D36964481
Pulled By: dmitryrykun
fbshipit-source-id: 561e32f218baf398b8d4d8c77381a2642e22ef42
Summary:
Seems like an obvious typo! Whoops!
Not causing any known issues, but... this should be fixed.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36940476
fbshipit-source-id: d534ca3763b1f91e41c56953bf3d665e86db9e2b
Summary:
This diff address an edge case when the pending events are enqueued when the surface is stopped. In this case we will reset map that holds view state to null, which will cause NPE.
Changelog:
[Android][Fixed] - Fix edge case when we enqueue a pending event to views on stopped surface
Reviewed By: javache, gorodscy
Differential Revision: D36912786
fbshipit-source-id: 3ae5a4b08a0a6bf55538d69ac80a101c2c3d899a
Summary:
When tapping on ReactRootView and having Fabric enabled, the touch logic mistakenly dispatch the event to JS via the legacy renderer. This is because the destination was computed based on reactTag (odd = legacy, even = Fabric), but root view tag happens to be always odd (always ends with 1). This change uses the right destination based on what the Event itself tells us, instead of deriving from the reactTag.
Changelog: [Android][Fixed] Fix Fabric touch event dispatching for root views
Reviewed By: JoshuaGross, sshic
Differential Revision: D36917300
fbshipit-source-id: 838b4e135d7df07c37040bd47d71370ff10df067
Summary:
Problem - Error when trying to publish to Apple Store in debug scheme
Error thread - https://github.com/facebook/react-native/issues/31507
## 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][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's
Pull Request resolved: https://github.com/facebook/react-native/pull/33153
Reviewed By: lunaleaps
Differential Revision: D34392529
Pulled By: sshic
fbshipit-source-id: 78387999f94e0db71f5d3dafff51e58d7d0c1847
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33937
This moves the build of RNTester from Unix Make to CMake
This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls.
In order to make this possible I had to:
* Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build.
* Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make
* Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make
Changelog:
[Internal] [Changed] - Build RN Tester with CMake
Reviewed By: cipolleschi
Differential Revision: D36760309
fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70
Summary:
This diff fixes the rendering of transparent borders in RN Android views
The fix clips the view ONLY when there is a border color that's non transparent
This change unifies the rendering of transparent and semitransparent borders for Views between RN Android, iOS and Web
Changelog: [Android][Fix] Fix rendering of transparent borders in RN Android
Reviewed By: JoshuaGross
Differential Revision: D36890856
fbshipit-source-id: 38fc2ae215f136160a73ca470e03fada8cb81ced
Summary:
Changelog:
[iOS][Fixed][Internal] - Protect handlers in RCTNetworking with mutex even if RCTNetworking has been deallocated
# The Logview
We get this error in LogView: `Unhandled JS Exception: Error: Exception in HostFunction: mutex lock failed: Invalid argument`, which is an C++ std::error. "This typically happens when .lock() is called on a mutex that is not yet constructed, or has already been destructed."
# Hypothesis of issue
The LogView says the line that throws this softerror is [RCTNetworking.ios.js](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.ios.js#L87).
Inside RCTNetworking, there's only [one mutex and only one line where is is being used](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.mm#L207-L215
), to protect the _handlers array.
My guess is that RCTNetworking was deallocated, which made `_handlersLock` nil, so it resulted in this error when we tried to lock it.
# This diff
* Add `std::lock_guard<std::mutex> lock(_handlersLock);` to `invalidate()`
* Move `_handlersLock` logic to its own method instead of using a lambda. If `self` is being deallocated, I would guess that this method (`[self prioritizedHandlers]`) would return nil.
Referencing this for correct ways to use lock_guard with mutex: https://devblogs.microsoft.com/oldnewthing/20210709-00/?p=105425
Reviewed By: fkgozali
Differential Revision: D36886233
fbshipit-source-id: 60246f4d9bbc1d834497e4fb8a61d9c0e9623510
Summary:
The current implementation of `throwJSError` places it in jsi.cpp, but
does not actually export it. This means that when JSI is being provided
by a dynamic library, `detail::throwJSError` will not be available.
To fix this, move the definition of `throwJSError` into jsi-inl.h,
similar to all of the other functions in the `detail` namespace. This
uses a roundabout implementation of `throwJSError` in order to avoid
directly using `throw`, which would fail to compile when exceptions are
turned off.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D36873154
fbshipit-source-id: bbea48e0d4d5fd65d67a029ba12e183128b96322
Summary:
D36612758 (https://github.com/facebook/react-native/commit/40f4c662bc7a66e5caea4909d74f435f5b72190c) attempted to remove the check that the animated node was native when fetching animated prop values for render, in order to fix an issue that arises when a node is converted to native before the initial call to render to mount the component, where the initial value is not applied.
However, this causes issues for cases where we call setValue on an animated node soon after render, such as on componentDidUpdate. setValue first updates the animated node value on JS side, then calls the native API setAnimatedNodeValue. The problem is that the next render will then use these updated values in the style props (because we removed the check for native in D36612758 (https://github.com/facebook/react-native/commit/40f4c662bc7a66e5caea4909d74f435f5b72190c)), resulting in a diff in props. Since Animated and Fabric aren't synchronized, there's a race condition between SurfaceMountingManager.updateProps and NativeAnimatedNodesManager.runUpdates
To allow proper rendering of initial values of native animated nodes, and mitigate the issue when calling setValue on an animated node soon after render, during initial render we use the initial values of both native and non-native driven nodes, and on subsequent renders we only use the initial values of non-native driven nodes.
An alternative considered was to add internal state to the nodes themselves (AnimatedProps, AnimatedStyle), but keeping it in sync with the component state is not easy/clean as AnimatedProps can be recreated and reattached at any time for a mounted component.
Changelog:
[Internal][Fixed] - Only use value of natively driven nodes on initial render
Reviewed By: JoshuaGross
Differential Revision: D36902220
fbshipit-source-id: c20f711aa97d18a2ed549b5f90c6296bf19bb327
Summary:
In the constructor we should get the default gravity params (as we did previously) and then never change these; thus, we can also make these fields final. These are used in `initView` during construction and upon recycling to reset vertical and horizontal alignment to their defaults.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36885646
fbshipit-source-id: 2f4d0b125b8645a380a08965e08db3ba1f12cae3
Summary:
See also D36889794. This is a very similar idea, except the core problem is that BaseTextProps is accessing the same props as ViewProps; and for ParagraphProps parsing, it first defers to ViewProps' parser and then BaseTextProps. RawPropsParser is optimized to access the same props in the same order, *exactly once*, so if we access a prop out-of-order, or for a second time, that access and the next access are deoptimized. Paragraph/Text, in particular, were quite bad because we did this several times, and each out-of-order access requires scanning /all/ props.
This fixes the issue, at least partially, by (1) pulling all the duplicate accesses to the beginning of BaseTextProps, and (2) accessing them all in the same order as ViewProps, relatively (some props are skipped, but that matters less).
Practically what this means is that now, all of Props' accesses have a cost of O(1) for lookup, or a total of O(n) for all of them; each access is at the n+1 position in the internal RawPropsParser array, so each access is cheap. BaseTextProps' duplicate accesses, even though there are only 4 of them: (1) the first one scans the entire array until we reach the prop in question; (2) the next accesses require scans, but not whole-array scans, since they're in order. (3) The BaseTextProps accesses /after/ the duplicate accesses are all O(1).
tl;dr is that before we had something like O(n*6) cost for BaseTextProps parsing and now it is O(n*2).
Similar to my summary in the last diff: we may want to revisit the RawPropsParser API... but I want to tread gently there, and this gets us a large improvement without major, risky changes.
Empirically, based on a couple of systraces, average time for a single UIManager::createNode called from JS thread, before this stack: 17us. After: 667ns (3% as long). On average, for every 60 createNode calls, we will save 1ms on the UI thread. The savings will be greater for certain screens that use many Views or Text nodes, and lesser for screens that use fewer of these components.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36890072
fbshipit-source-id: 5d24b986c391d7bb158ed2f43d130a71960837d1
Summary:
Without getting into the weeds too much, RawPropParser "requires" that props be accessed in the same order every time a Props struct is parsed in order to most optimally fetch the values in a linear-ish fashion, basically ensuring that each rawProps.at() call is an O(1) operation, and overall getting all props for a particular component is O(n) in the number of props for a given struct. If props are called out of order, this breaks and worst-case we can end up with an O(n^2) operation.
Unfortunately, calling .at(x) twice with the same prop name triggers the deoptimized behavior. So as much as possible, always fetch exactly once and in the same order every time. In this case, we move initialization of two fields into the constructor body so that we can call .at() a single time instead of twice.
In the debug props of ViewProps I'm also reordering the fields to fetch them in the same order the constructor fetches them in, which will make this (debug-only) method slightly faster.
What's the impact of this? If you dig into the Tracery samples, the average/median RawPropsParser::at takes 1us or less. However, in /every single/ call to createNode for View components, there is at least one RawPropsParser::at call that takes 250+us. This was a huge red flag when analyzing traces, after which it was trivial (for View) to find the offending out-of-order calls. Since this is happening for every View and every type of component that derives from View, that's 1ms lost per every 4 View-type ShadowNodes created by ReactJS. After just 100 views created, that's 25ms. Etc.
There are other out-of-order calls lurking in the codebase that can be addressed separately. Impact scales with the size of the screen, the number of Views they render, etc.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36889794
fbshipit-source-id: 91e0a7ca39ed10778e60a0f0339a4b4dc8b14436
Summary: Creates a base TurboModule for Catalyst.
Reviewed By: ann-ss
Differential Revision: D36707915
fbshipit-source-id: 9a246f238efdcdde45e0332f7b868478deadf50e
Summary:
I'm backporting PR https://github.com/facebook/react-native/pull/33945 to main
as it was merged on the release branch to unblock 0.69.
Those changes are necessary as Hermes was not being donwloaded at all during `pod install`
on .69 and the app was failing to build with a missing `hermes/hermes.h` import.
Changelog:
[iOS] [Fixed] - Fix Hermes not being properly downloaded during pod install
Reviewed By: hramos
Differential Revision: D36810787
fbshipit-source-id: f898e61b6536dfcfc81feeff740703fbd697b000
Summary:
Right now, when we change the keyboardType on android between between default and email, the value keyboard type stays as email (specially noticeable with the key next to the spacebar, that changes between the comma (`,`) to the at sign (`@`)).
This is because the mask we are using when updating the input is only taking into account the class, and not the flags nor the variations.
We don't apply all masks because it may interfere with flags assigned by other props, like multiline or secure text entry. Therefore, we have created our own mask, taking into account all the variations and flags that the keyboardType prop may set. This may be hard to maintain, since whenever we add any other keyboard type, we have to take these flags into mind.
The error I was trying to fix was in particular regarding going back and forward from email, but this fix may solve other similar issues with other keyboard styles.
## Changelog
[Android] [Fixed] - Fix a bug where the keyboard, once set as email, won't change back to default.
Pull Request resolved: https://github.com/facebook/react-native/pull/33924
Test Plan: In order to test this PR, any test code with a TextInput, and a way to change the value of the keyboardType should work. We should be able to see how the keyboard changes to the correct type without staying, for example, on the email state.
Reviewed By: lunaleaps
Differential Revision: D36784563
Pulled By: makovkastar
fbshipit-source-id: 74d7b61b3c07feea4e4050d7a07603a68b98e835
Summary:
I was reading source code, and I noticed the _subscriptions attribute (and the _clearSubscriptions method) of the FileReader is not used.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - Remove unused _subscriptions attribute in FileReader
Pull Request resolved: https://github.com/facebook/react-native/pull/33946
Test Plan: I checked that flow and jest are still green as I can't think about another way.
Reviewed By: lunaleaps
Differential Revision: D36807828
Pulled By: cortinico
fbshipit-source-id: 9bb599bbc7b79d2b4c010ba84cc8777e29b974ca
Summary:
tldr; `ReactEditText` and Android's emoji support in Android's AppCompat 1.4.0 / 1.4.x conflict in an odd way, causing NPEs.
`ReactEditText` defines an `InternalKeyListener`, `mKeyListener`, that it uses to make sure input from all keyboards works correctly. This listener is normally initialized at the end of the constructor.
Unfortunately, some versions of `AppCompatEditText`, most notably the version in the App Compat `1.4.0-alpha0x`, the [minimum version required for the Play Store's emoji compliance](https://developer.android.com/guide/topics/ui/look-and-feel/emoji2#appcompat) call `setInputType` from `AppCompatEditText`'s constructor. `ReactEditText` operates on the key listener inside of `setInputType` and since the `AppCompatEditText` constructor is called via call to `super` before the key listener is initialized, these versions of app compat can cause NPEs when used with React Native.
The fix is simple; check to see if `mKeyListener` is null, and initialize it if it is. This is necessary in both the constructor and inside of `setInputType`.
## 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
-->
https://github.com/facebook/react-native/wiki/Changelog
[Android] [Fixed] - NPE in `ReactEditText.setInputType` when React Native is used with some versions of a AppCompat 1.4.x. (and possibly others)
Pull Request resolved: https://github.com/facebook/react-native/pull/33920
Test Plan:
1. Build an app with both React Native and load it inside an app that is using AppCompat 1.4.x
2. Add a text field using React Native.
3. Open the screen of the app that contains the text field.
If you're working from this branch, you'll be fine. If you're working from main you'll get an NPE.
I can put together a test repo if needed.
Reviewed By: kacieb
Differential Revision: D36802622
Pulled By: cortinico
fbshipit-source-id: e7646da9a1ef0e0334152aecab0f972ca25092ec
Summary:
The sdks/.hermesversion file should be included inside the React Native NPM package.
While this file is available on the release branch, so it's effectively used during artifact preparation,
the file should also be included inside the react-native NPM package.
This commit addresses it.
Changelog:
[Internal] - Make sure sdks/.hermesversion is included inside the NPM package
Reviewed By: dmitryrykun
Differential Revision: D36785480
fbshipit-source-id: 1152de77818e92814b402a57ca5a05c235747eac
Summary:
Adding a flag to prepare for the phase 3 of the new architecture. This is still work in progress, not usable yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36767843
fbshipit-source-id: 338d775681f2890461608b403749c3a7f05f84ff
Summary:
Followups to View Recycling diffs to improve things / clean up things a bit. This also fixes memory warnings which were not hooked up before.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36707792
fbshipit-source-id: 410e70bf0eeec5569566138af547e1601394d0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33914
Add test coverage for the new hermesc functions in hermes-utils.js
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36361612
fbshipit-source-id: 270f30917245c8d81baf136d9f58da4d77f7ad55
Summary:
Turns on the ssa env mode in Flow, which supercedes constrained writes with additional fixes
to refinement invalidation.
Reviewed By: SamChou19815
Differential Revision: D36717890
fbshipit-source-id: 20ee963591e8b454458273ac5aa86798e94a8bbd
Summary:
This diff upgrades xplat to 0.178.1 and pre-suppresses errors from turning on constrained writes.
To generate this diff I:
* Modified every `env_mode=constrain_writes` to `env_mode=ssa` and made a commit (this is so our upgrade script will work)
* Ran scripts/flow/upgrade.sh 0.178.1 to upgrade all the flowconfigs to 178.1 and suppress new-env errors
* Modified arvr/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project arvr`
* Modified xplat/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project xplat`
* Unstacked from the commit in point 1
Reviewed By: SamChou19815
Differential Revision: D36676019
fbshipit-source-id: c3032f18ed838afc327f00de563e7f20713bdc26
Summary:
`pod install --project-directory=ios` silently fails to prep Hermes:
```
% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
[Hermes] Downloading Hermes source code for commit 515e112edc267ad58d3c70991b3d9a721cc66b19
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 9478k 0 9478k 0 0 3939k 0 --:--:-- 0:00:02 --:--:-- 5591k
[Hermes] Expanding Hermes tarball for commit 515e112edc267ad58d3c70991b3d9a721cc66b19
[Hermes] Using pre-built HermesC
[!] One or more resources were not found and will not be included in the project. If they are found later and you want to include them, run `pod install` again.
warn Multiple Podfiles were found: ios/Podfile,macos/Podfile. Choosing ios/Podfile automatically. If you would like to select a different one, you can configure it via "project.ios.sourceDir". You can learn more about it here: https://github.com/react-native-community/cli/blob/master/docs/configuration.md
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
[Codegen] Found FBReactNativeSpec
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec`
Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec`
[!] No podspec found for `hermes-engine` in `../node_modules/react-native/sdks/hermes/hermes-engine.podspec`
% ls -l node_modules/react-native/sdks
total 0
hermes-engine
hermesc
```
## Changelog
[iOS] [Fixed] - `pod install --project-directory=ios` fails when Hermes is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33909
Test Plan: Instead of running `pod install` inside `ios` folder, run `pod install --project-directory=ios`.
Reviewed By: cortinico
Differential Revision: D36693625
Pulled By: hramos
fbshipit-source-id: 8757a9c388348276b07c785c211979ec8f2e2f84
Summary:
This target is not a good idea for a number of reasons:
1. It groups up multiple targets which breaks the dependency graph
2. It does not handle dependency remapping correctly
3. It has no mirror into fbcode
We should warn people this is a bad idea
Reviewed By: alexmalyshev
Differential Revision: D36519357
fbshipit-source-id: d60ca3237c7710118732578fecd1b2fc8903321b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33897
Now the exception will display the class which caused the exception as well as helpful information as to why.
We've seen this happen a bunch due and have been very confused by the error message. It turns out that this processor runs before the classes listed are compiled. This means that if there's a compile error (or a missing import) the user will only see that this processor crashed, and not the compile error.
The additional information in the error is:
`java.lang.RuntimeException: Could not load classes set in ReactModuleList.nativeModules. Check that they exist and are imported correctly on class: com.meta.x.y.ReactPackage`
In this case, `com.meta.x.y.ReactPackage` is the class which needs to be fixed. Before, the error message made no mention of this class or the annotation.
Changelog: [Internal] This will change the way the annotation processor crashes. It will throw a RuntimeException instead of a ClassCastException.
Reviewed By: javache
Differential Revision: D36606279
fbshipit-source-id: aedf9682286fba49e23716b7eda16b2dd3b13422
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33915
We don't need to import shelljs as a dependency anymore,
plus we had a duplicated entry in the files array for package.json
Changelog:
[Internal] [Changed] - Remove shelljs dependency and duplicated scripts in files
Reviewed By: dmitryrykun
Differential Revision: D36698750
fbshipit-source-id: 94f449f2c3c5d73d0f9ffd29df6b26f5fd6ef129
Summary:
See previous diff for details on general approach and benchmarks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36676887
fbshipit-source-id: b177dcd19f1ea687bf7d2d4f2f637d2924723340
Summary:
Followup task for S271544.
There were no tests covering RTL on FlatLists, which would have prevented the above SEV. Adding an RNTester example for this.
Changelog:
[Internal] - Added RNTester example FlatList with RTL
Reviewed By: lunaleaps, javache
Differential Revision: D36601583
fbshipit-source-id: 054ac4eee876a514152f83ecc0522c62337cfea5
Summary:
When a JavaScript module is not registered as callable, the bridge will throw an error. Let's clean up the error message so that it's more helpful.
Now, it logs the number of registered callable JavaScript modules, as well as the list of callable JavaScript modules.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D36646936
fbshipit-source-id: 62d091cda35e296ef9e569b444cd5b6f09b8bc54
Summary:
Changelog: [Internal][Changed] - Make the same optimization on enter/leave/move pointer events being dispatched by a mouse input.
If any ancestor view is listening to enter/leave events (just capture) then we dispatch the enter/leave event.
Reviewed By: vincentriemer
Differential Revision: D36601638
fbshipit-source-id: d6b5c32ae50bcf000100bcb878ca2ca89bd5c02e
Summary:
Upgrade the version of Xcode used in Sandcastle to Xcode 13.3.1, and the version used on Circle CI to Xcode 13.3.1.
Added a reminder to the Circle CI config to ensure we keep these versions in sync in future updates.
Circle CI software manifest: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v7555/index.html
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D36671468
fbshipit-source-id: 8c028915d38738c92b5f759186b0fb95a9274211
Summary:
In AnimatedComponent.render, we get the initial values of any styles backed by AnimatedNode, but ONLY for non-native animations. Thus, if convert an animated node to native before the call to render to mount the component, we will end up not applying the initial value until after the component is mounted. This may result in a visible flicker as the expected value is applied some time after the component is mounted and visible.
- Without native driver: BaseViewManager.setTransform called during view preallocation (ViewManager.createViewInstance)
- With native driver: BaseViewManager.setTransform called during MountingManager.updateProps (called from PropsAnimatedNode.updateView)
This diff removes the isNative check in AnimatedStyle and AnimatedProps when traversing style props. This shouldn't be a problem:
- Created as non-native, animated with JS driver
- This diff does not affect this scenario
- Created as non-native, animated with native driver
- Initial value is applied correctly on render/mount. On subsequent renders, the outdated value from JS side will not apply on the platform view as it has not changed.
- Created as native, animated with native driver
- Initial value is applied correctly on render/mount. On subsequent renders, the outdated value from JS side will not apply on the platform view as it has not changed.
Changelog:
[Internal][Fixed] - Set correct initial value for AnimatedComponent for styles backed by native animated nodes
Reviewed By: JoshuaGross, javache
Differential Revision: D36612758
fbshipit-source-id: 922d6534c605b3eb0a1d9476753111b726f138f2
Summary:
RN-Tester is currently crashing at startup time due to an NPE.
This PR fixes it.
## Changelog
[Android] [Fixed] - Fix NPE on `ReactEditText` due to null mFabricViewStateManager
Pull Request resolved: https://github.com/facebook/react-native/pull/33910
Test Plan: Tested locally that RN Tester runs both in Debug and in Release
Reviewed By: cipolleschi
Differential Revision: D36666440
Pulled By: cortinico
fbshipit-source-id: f004ff228fb4f9ff339aac606858d47de3706426
Summary:
There are two methods in ReactRootView to handle touch events "onInterceptTouchEvent" and "onTouchEvent", for Venice we have ReactSurfaceView inherits ReactRootView but the implementation for above 2 touch handling methods still calls into it's super implementation which uses the bridge.
In this diff we make ReactSurfaceView inherits ReactRootView's "dispatchJSTouchEvent" and "dispatchJSPointerEvent". So that Venice has separate implementation for touch events handling.
Changelog:
[Android][Changed] - Revamp touch event dispatching methods
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D36629466
fbshipit-source-id: fb7c5950afe6249d22edd3fac3fa5d3b83b3af84
Summary:
This op code was incorrectly configured to take two args, while it only takes one.
Changelog: [Internal]
Differential Revision: D36664590
fbshipit-source-id: 6e1fdb9f64bbd32fbe05bbd174f94ae57292bcf9
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
There's no need for this to be a setter/getter, as there are no side-effects, and it means we can use the same helper method to read it as other feature flags.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36595602
fbshipit-source-id: d27c01bd39d03606a6f8c17ba181a8cd0bf58dbb
Summary:
Enables two new experiments (and the current behaviour as default) to speed up access to TurboModule methods from JS.
1) HostObject - Current behaviour
2) Prototype - Connect the TM HostObject via `__proto__`, and cache any methods accessed on the wrapper object.
3) Eager - Eagerly store all methods on the wrapper object, do not expose the HostObject to JS at all (TurboModules no longer need to be HostObjects in this scenario)
Changelog: [Internal]
Reviewed By: JoshuaGross, rubennorte, mdvacca
Differential Revision: D36590018
fbshipit-source-id: c9565eb239eb6aeee0f06b581ff8cd72a92073fc
Summary:
* Make constructor private, all access is through install()
* Use nullability of longLivedObjectCollection_ instead of separate bool disableGlobalLongLivedObjectCollection_
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36592492
fbshipit-source-id: d65e779e1ac9fbe121937c5a20763aefcd589795
Summary:
In D36345402 (https://github.com/facebook/react-native/commit/56e9aa369f5c13af38cf80ba47e9eb29d835ec89) I changed the behaviour for mount items to be skipped if they were just setting zero values. AndroidTextInput is the only component that I'm aware of that has non-zero padding by default, and we account for this when creating the native shadow node. This optimization broken TextInput use-cases that explicitly request zero-padding, since we end up ignoring it.
To keep this optimization, explicitly init ReactTextInput's padding to 0, but only in Fabric. `updateState` was the closest thing I could find to a Fabric-only callback, once it's fully rolled out, we can also move this to the constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545775
fbshipit-source-id: 07bb96032c69d7e350980b0b975e637b66c307ed
Summary:
Update `hermes-engine.podspec` to use pre-built Hermes artifacts from the corresponding React Native GitHub Release when targeting a specific React Native release.
Otherwise, fallback to building Hermes from source.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36609257
fbshipit-source-id: 6179c9e255558c7eaf1417ff46a2e7db120295f0
Summary:
Due to invalid utf-8 data NSString may return nil during initialisation and this leads to crash when nil goes to NSDictionary or NSArray
Changelog: [Internal]
Differential Revision: D36623628
fbshipit-source-id: 23efad87cc9fe4a23c5e90dad63e0d74036b62fa
Summary:
This fixes an issue where nullability was lost on readonly types in TurboModules specs. The "outside" nullability would be ignored in favor of only respecting the "inside" nullability (i.e. `?$ReadOnly<{}>` vs `$ReadOnly<?{}>`). It now ensure either is propagated correctly.
Changelog:
[General][Fixed] Fix nullability lost on readonly types in TurboModule specs
Reviewed By: RSNara
Differential Revision: D36615346
fbshipit-source-id: 42408d9298703f4c382657f573480d2574d6c973
Summary:
There are cases where we want to pass arbitrary types to a TurboModule, which may then handle the values appropriately, but we haven't supported this use case. Since C++ TurboModules can accept any `jsi::Value` (unlike Java/ObjC) and we have real-world need for this (otherwise we must require JSON serialization), this now allows `mixed` (`unknown` in TypeScript) for C++-only TurboModules.
Changelog:
[General][Added] C++ TurboModule methods can now use mixed types
Reviewed By: RSNara
Differential Revision: D36611299
fbshipit-source-id: bbf29dfcc6aed67e213bb3eab06537c18c7db1fe
Summary:
The new Hermes scripts need to be included in the `react-native` npm.
The `shelljs` dependency that was used by the Hermes scripts is a dev dependency, so instead of adding to the `react-native` npm size, we refactored its use out of hermes-utils.js.
Changelog:
[General][Added] - Add Hermes scripts to package
Reviewed By: cortinico
Differential Revision: D36387135
fbshipit-source-id: 12d0bc29d365c4cb18d33a0d390e6e7d34864b7a
Summary:
`test_android` is now red because I had to specify a root for RN tester.
The job is now failing as it fails to find the correct platforms for the bundler command.
This PR fixes it.
## Changelog
[Internal] - Attempt to fix test_android by moving react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/33901
Test Plan: Tested locally + will wait for a CI result
Reviewed By: cipolleschi
Differential Revision: D36625857
Pulled By: cortinico
fbshipit-source-id: 01852cc966e611c6724ba528ea351a17011d62e2
Summary:
This PR tries to simplify the `use_flipper` logic:
- makes `use_flipper` a configuration inside `use_react_native`'s options
- uses the already present `production` flag in the `use_react_native`'s options to decide if add or not the Flipper pods
- Simplifies the logic to download the flipper dependencies
This PR also adds a workaround for https://github.com/facebook/react-native/issues/33764
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Move `use_flipper` logic inside `use_react_native` and simplify the Flipper dependencies logic
Pull Request resolved: https://github.com/facebook/react-native/pull/33882
Test Plan: Executed a pod install with and without flipper and with isProduction true
Reviewed By: cipolleschi
Differential Revision: D36592338
Pulled By: f-meloni
fbshipit-source-id: 3c3f773151513e27e251f18865986e942a96ffd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33893
The previous diff was breaking the external CI tests on Windows because of the file separators.
The fix was to use UNIX separator but to apply `path.normalize` to make sure that the path is platform agnostic.
## Changelog
[General][Fixed] - Make tests pass for windows
Reviewed By: cortinico
Differential Revision: D36597593
fbshipit-source-id: 47731f34a08c778268a6cc9674257403985d4599
Summary:
I have never seen these asserts fire in production. They're pretty cheap but the cost is not zero. We will use annotations and test carefully in debug if we need to ensure that something runs on a particular thread - which we do anyway.
Motivation: this method is called /extremely frequently/, everywhere in the mounting layer. And 99.99% of the time it's completely useless and results in absolutely no signal. In many cases, it will be called hundreds or thousands of times during a single operation (for example, when executing the IntMountBuffer items, each sub-item will call this many times).
Wall-clock time is usually low according to systrace (sometimes there are odd spikes), but over time these do add up and it seems good to save a few ms here and there.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36539399
fbshipit-source-id: 3e023be64b8c9f0e6c3c8347c077ce9fa38f74a4
Summary:
It's useful to have more systrace markers that are all the same, so that they can all be aggregated and work underneath them aggregated across an entire trace. As it is, this marker gets treated as unique nearly every time which makes analysis harder.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36533075
fbshipit-source-id: 925afa7db152eca1166891b41e7c6f6a511840af
Summary:
setImmediate will result in these debounced/queued operations being sent to native immediately at the end of a ReactJS render loop instead of in the next tick, which could result in more fluid animations.
I verified with logs that batching still occurs.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36521717
fbshipit-source-id: 4f94e26503d4e6e40f52a4120ae407044af0c451
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
We don't want to include tests as they're not valuable for our users + the might break users build if they try to run `./gradlew build`.
Changelog:
[Internal] [Changed] - Do not publish Android tests inside the NPM package
Reviewed By: cipolleschi
Differential Revision: D36600831
fbshipit-source-id: b88ee4dc93f276cd0729a2193346f5fcde34323c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33876
WIP. Published so we can export and test on CI.
These two jobs can likely be merged onto the existing build_hermesc_macos job.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36538847
fbshipit-source-id: e52c39ccfe652e70c54fd4892513c0060c3f021d
Summary:
For published RN releases, use a published hermes-engine pod that corresponds to the current React Native version.
For unpublished RN versions, continue consuming the local hermes-engine pod which requires building Hermes from source.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36533683
fbshipit-source-id: 963a0f0e24baaf73a87c9bae4bc20d83757bbfde
Summary:
Introduces option to use pre-built Hermes binaries.
Requires a `hermes-engine` pod release to have been published in the following manner:
```
env hermes-artifact-url='https://github.com/facebook/react-native/releases/download/vX.Y.Z/hermes-runtime-darwin-vX.Y.Z.tar.gz' pod trunk push hermes-engine.podspec
```
...where "vX.Y.Z" corresponds to a published React Native release on GitHub where the `hermes-runtime-darwin-vX.Y.Z.tar.gz` binary was generated and/or uploaded as part of the release process.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36532561
fbshipit-source-id: 73bc107158387ff2db359e1b6a973db6ee85995c
Summary:
I've accidentally broke the external CI.
The reason is that root is defaulted to `$rootProject/..`.
The Gradle Plugin assumes there is a package.json there, which is always the case for RN projects, given that root is configured properly.
This was green on internal CIs as it was actually hitting the file on `xplat/js/package.json`. Externally, there is no such file, therefore is failing.
The fix is to specify the root path and don't use the default for ReactAndroid
Changelog:
[Internal] [Fixed] - Set root to be `..` for ReactAndroid
Reviewed By: cipolleschi
Differential Revision: D36597308
fbshipit-source-id: 66638ee1014ef35c81195526e0b325f5cc008b82
Summary:
It seems that using `:` inside the `name` field of our Issue Template broke the parsing of them. I'm fixing it here.
## Changelog
[Internal] - Fix broken `ISSUE_TEMPLATE` due to extra `:`
Pull Request resolved: https://github.com/facebook/react-native/pull/33892
Test Plan:
Tested on:
https://github.com/cortinico/react-native/issues/new/choose
Reviewed By: f-meloni, cipolleschi
Differential Revision: D36596469
Pulled By: cortinico
fbshipit-source-id: 8009a88efc800622bad493a170b054972bb2147c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33891
This diff adds a function to clean up folders and empty files (if any) after the codegen runs in the OSS.
To align how iOS and Android behave in the codegen, we now have to preemptively create folders that we may not need later.
Thanks to this function, we recursively the folders in the codegen and we delete them if they are empty.
## Changelog
[iOS][Added] - Add function to cleanup codegen folders
Reviewed By: cortinico
Differential Revision: D36594999
fbshipit-source-id: 904aa2442c0d9621b7ec77c31f7be9daa4e7b7e1
Summary:
This extends the Gradle plugin to allow configuration for `codegenConfig` from the
`package.json` that lives in one of the root folder.
There are a couple of points open for discussion. The most important one
is that now we're moving from absolute paths to relative paths, from the
package.json location. I'm not entirely sure this will work correctly
for users in monorepos, so we might consider this carefully.
Moreover, I've moved the `codegenJavaPackageName` to be `android.javaPackageName`.
Happy to discuss this further.
Changelog:
[Android] [Added] - Extend the React Native Gradle plugin to accept a config from package.json
Reviewed By: cipolleschi
Differential Revision: D36374475
fbshipit-source-id: fe669ebd5bc92abbbe57677c1995d0e01f2400d7
Summary:
Call `setWaitingForIdentifier` before we do any `setValue` calls to make sure we execute them together (and only call start/finish batch once). Only calll `updateAnimatedNodeConfig` conditionally when we changed nativeColor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36517302
fbshipit-source-id: ecbae2d1df69e4456620c58a922275406e22a2f8
Summary:
Splitting these changes of from D36482630, which is a minor improvement to the singleOp experiment. Since we call start/finish already on the native side, we don't need to repeat it from JS.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36541700
fbshipit-source-id: 7d61669710faca3153be557fb2d214011eda87c5
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.71.0](https://github.com/facebook/metro/releases/tag/v0.71.0).
Changelog:
[General] Update direct Metro dependencies to 0.71.0
Reviewed By: motiz88
Differential Revision: D36592469
fbshipit-source-id: 4d95608545a5dff59049f1f48e18b08d4856961f
Summary:
* Make inner classes static where possible
* Make member variables final when set from constructor
* Remove Nullable on `mFabricViewStateManager` and associated checks
* Remove `createInternalEditText` which has moved to the ShadowNode (paper-only)
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36545807
fbshipit-source-id: 85517511d1734f0e55de5caa012e32feb40e8492
Summary:
ViewManager does a null-check already, and so inside the `updateState` method, we can safely assume this parameter is no longer nullable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545806
fbshipit-source-id: 92eefa518f11c17b91aa3da2e14066d36fa4f4c2
Summary:
`test_android` is currently broken as it tries to build with `source = "7"` (the default).
This is a best guess fix to try to fix this issue.
## Changelog
[Internal] - Attempt to fix test_android by specifying source 8
Pull Request resolved: https://github.com/facebook/react-native/pull/33890
Test Plan: Will rely on CI
Reviewed By: cipolleschi
Differential Revision: D36589814
Pulled By: cortinico
fbshipit-source-id: 8ef50f8531b9d4367d2f2c75a312e8fdaf38fd85
Summary:
Run Danger on all the PRs, not just on the forks, use fail or warning where is needed and make CircleCI fail if danger fails
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Run Danger on all the PRs and use fail or warning where is needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/33872
Test Plan: Run the change on CirlceCI
Reviewed By: cortinico
Differential Revision: D36516847
Pulled By: f-meloni
fbshipit-source-id: 2c956295a56cc8aa47df4c64f8ca0a211796c73c
Summary:
Changelog:
[iOS][Fixed] - When in an RTL locale on iOS, e.nativeEvent.zoomScale is -1. This seems to cause erratic blank spaces that don't recover as you scroll. Set the value to 1 instead when negative.
Differential Revision: D36499121
fbshipit-source-id: f82812ca00ae4162fbff617df8c716a4964b3a8f
Summary:
As the title says, let's make this field mandatory so we don't have to ask for
a repro over and over again.
Changelog:
[Internal] [Changed] - Make the reproducer mandatory in the issue template
Reviewed By: cipolleschi
Differential Revision: D36552021
fbshipit-source-id: ac6aa0c3b1583afe38b3fcf78c385e5bdfb5f6e2
Summary: Changelog: [Internal] - Make it easier to specify what events to listen to on each `EventfulView`. This is helpful for testing future optimizations to event dispatch filtering. Also removed the switches for triggering events -- the idea being that we're using these examples with Metro and we can just remove the relevant props when we want to not fire any events.
Reviewed By: kacieb
Differential Revision: D36530066
fbshipit-source-id: 3ff45c263bdcacedde8d2720e156ab8156424c53
Summary:
There are use cases of needing to setValue multiple times per second (for example, using PanResponder to update a slider component).
This requires the use of the native driver for perf reasons as using the JS driver will cause a rerender. Currently, the only way to make an animated node native is via setting useNativeDriver: true on an animation config. For example:
```
Animated.timing(animatedValue,
{
toValue: newValue,
duration: 0,
useNativeDriver: true
}).start();
```
To avoid needing to call the above, add a useNativeDriver param to the constructor. When set to true, the node will be made native immediately.
```
const animatedValue = new Animated.Value(0, useNativeDriver);
...
animatedValue.setValue(newValue);
```
Note that, like with useNativeDriver in the animation config, once a node is made native, it cannot be reverted to JS-only.
---
As an aside, PanResponder uses JS-side events, and thus we cannot use Animated.event with native driver; we instead need to setValue on a native AnimatedValue. A much more thorough explanation is in D34564598.
---
Changelog:
[General][Added] - [Animated] Add useNativeDriver as a param for setValue
Reviewed By: JoshuaGross
Differential Revision: D36459457
fbshipit-source-id: 284148a6d16537429efeab8b07184019990909cd
Summary:
When releasing the latest RC, we have noticed `pod install` is broken since the downloaded `react-native` package is missing hermes scripts and `shelljs` dependency (needed by `hermes-utils.js`).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Fix compiling hermes in the release version.
Pull Request resolved: https://github.com/facebook/react-native/pull/33881
Test Plan: - Run `test-manual-e2e.sh` with template and Hermes on iOS
Reviewed By: GijsWeterings
Differential Revision: D36546116
Pulled By: cortinico
fbshipit-source-id: 70fe70de7d63193df888b8ece935c4fa97b4dfc8
Summary:
Improve the types of `queueOperation` so flow can assert that the parameters match.
Also in the case of `singleOpBatching == false`, nativeOps is just an alias of NativeModule so there's no overhead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36482617
fbshipit-source-id: e000d11b04166cd7a069af024b9c2cc226efa701
Summary:
This will fix a crash on Motorola devices on Android 7, where WebView fails to load due to initialisation issues in the WebViewChromiumFactoryProvider (Caused by org.chromium.base.library_loader.ProcessInitException).
## Changelog
[Android][Fix] - Exception with `Cannot load WebView` message will initialising WebView (along with existing checks)
Pull Request resolved: https://github.com/facebook/react-native/pull/33867
Test Plan: <img width="1368" alt="Screenshot 2022-05-19 at 02 21 57" src="https://user-images.githubusercontent.com/933314/169154293-c442a54f-96f5-4309-a6ce-c8f9c4beeb17.png">
Reviewed By: javache
Differential Revision: D36517673
Pulled By: cortinico
fbshipit-source-id: 4fa5b903529eb04d01ed8fa540cbd883224e8e62
Summary:
With the new architecture, this module should be using the implementation from ReactFabric instead. However, given the ReactNative module had side effects (like registering `RCTEventEmitter`), let's import from ReactFabric only in the latest "new architecture" mode.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D36535626
fbshipit-source-id: 6758b671df9a47607d8caf4a021ac73410f4c6e9
Summary:
I'm finding it useful to keep track of a few additional numbers when doing perf analysis in Fabric.
Also making it easier to enable just these perf logs without all of the other verbose Fabric logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36500518
fbshipit-source-id: e57e1e75131c5d59da876d1decb96d4da386f025
Summary:
We were calling the wrong operation from the MegaOp which caused indices to become offset. Trivial fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36482822
fbshipit-source-id: 83ebc37a8773f0277db4caff9d3e7c9c91931ddb
Summary:
Currently this [section](https://reactnative.dev/docs/next/new-architecture-app-intro#ios-enable-c17-language-feature-support) of the Playbook tells us to set CLANG_CXX_LANGUAGE_STANDARD = "c++17" in the main app target for the new architecture to work.
Would be nice to be able to automate that instead
## 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] [Added] - Cocoapods function to add the `CLANG_CXX_LANGUAGE_STANDARD` to all the targets if needed
Pull Request resolved: https://github.com/facebook/react-native/pull/33863
Test Plan:
I've created some unit tests for the newly added function.
I've executed pod install and the ruby tests locally.
Reviewed By: cipolleschi
Differential Revision: D36484366
Pulled By: f-meloni
fbshipit-source-id: 553b092e747bef11d82195619ae1058985fdc325
Summary:
Noticed we were copying ShadowView, where a reference should suffice.
Changelog: [Internal]
Reviewed By: appden
Differential Revision: D36455200
fbshipit-source-id: 2cd3cf66b9e5ec05bce9ce1d739fbed66f3a6d89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33864
This Diff aligns the way in which iOS and Android codegen the modules and components.
Android takes all the JS in the project root folder and creates components starting from there.
iOS used to required to specify a specific path for each component, within a JSON field called `libraries`. This Diff let iOS work in the same way as android does
**Backward compatibility:** This diff still support the old way for iOS, but we are deprecating it.
## Changelog
[iOS][Added] - Support codegen from a single folder
Reviewed By: cortinico
Differential Revision: D36473005
fbshipit-source-id: 1e8cf0f9764f529c02e948984c74d1982a84030b
Summary:
Which idiot wrote this? Oh yeah, I did.
This was introduced in D36109810 (https://github.com/facebook/react-native/commit/bf405d70837e1319cfa83e4c5cbb7c9a69abd820) so hasn't been around too long luckily.
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings
Differential Revision: D36480272
fbshipit-source-id: b0fbb6b820185185359c6c75f77f2921dc892b02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33870
I'm fixing a broken CI on master for `test_windows` as `metro-memory-fs` doesn't
automatically recognize the platform but needs to have it passed in input.
It was currently failing to parse a `C:\...` path. This fixes it.
Changelog:
[Internal] [Changed] - Fix `test_windows` by passing the correct platform to the Metro Virtual FS
Reviewed By: cipolleschi
Differential Revision: D36507564
fbshipit-source-id: 39dfd7e9ce492d126fbb513a70ec5a60965c61fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33869
When I disabled the Javadoc pubblication as it was failing on CI,
I forgot to turn off the verification that the -javadoc artifact is included
inside the NPM package. This caused `build_npm_package-1` to fail on main.
I'm fixing it here.
Changelog:
[Internal] [Fixed] - Do not fail if -javadoc.jar are missing in the final NPM package
Reviewed By: cipolleschi
Differential Revision: D36507320
fbshipit-source-id: 3836de5212de91bb44e0e586564b46114ca346b4
Summary:
I'm disabling the publishing of Javadoc as it's currently failing on CI.
The failure is happening due to a concurrency problem during the Kotlin
documentation generation.
As we don't have much Javadoc to export, I'm removing this for now.
Changelog:
[Internal] [Fixed] - Disable Javadoc publishing as it's currently failing on CI
Reviewed By: cipolleschi
Differential Revision: D36481215
fbshipit-source-id: 6f875932013f80779151f75e20d25ba3b71de074
Summary:
Codegen a static field for every caller of `invokeJavaMethod` to cache the jmethodID that should be used for the method, which saves us a string-based name lookup at invocation time.
Changelog: [internal]
Reviewed By: genkikondo
Differential Revision: D36376056
fbshipit-source-id: 298430746a8f25a5337aba05b56876ba789e2344
Summary:
Simplify argument and result conversion by using existing fbjni helpers (which will cache class and method ID lookups already)
Changelog: [internal]
Reviewed By: RSNara
Differential Revision: D36312751
fbshipit-source-id: 16713642b2c5fb4c2b6447c30652d91ddbd88224
Summary: Changelog: [Android][Fixed] Scroll views would still receive scroll events when nested in a view with `pointer-events: "none"`
Differential Revision: D36423921
fbshipit-source-id: 87b8a236e15dda7b648b6fc649187e95a9a2cc42
Summary:
Noticed that we emit a large amount of (admittedly cheap) mountitems as part of node creation for values that are all zero (e.g. padding, overflowinset), which we can assume to be already initialised with these values on the native side.
There's a further opportunity to do this for State as well, as ReactImageComponentState exports just empty maps to Java.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36345402
fbshipit-source-id: 8d776ca124bdb9e1cd4de57a04e2785a9a0f918c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33818
This Diff moves the fabric setup from the `react_native_pods` script to its own `fabric` file.
It also introduces tests for the file and some test utilities.
## Changelog
[iOS][Changed] - Move fabric setup to its own file
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36344911
fbshipit-source-id: 586186684be2c0080f247390f26145f2defa9e97
Summary:
Changelog:
[iOS][Fixed] - When in an RTL locale on iOS, e.nativeEvent.zoomScale is -1. This seems to cause erratic blank spaces that don't recover as you scroll. Taking Math.abs of the value fixes it. Blame: D36169686 (https://github.com/facebook/react-native/commit/13a72e0ccceb2db6aeacd03b4f429d200392c17b)
Differential Revision: D36468390
fbshipit-source-id: f18244f1421fc1ccbb0d1035df8a7c6de10ccf62
Summary:
We introduce a few optimizations:
(1) Previous diff: We defer calling any NativeAnimatedModule methods by waiting 1ms before flushing the queue, and debouncing until no flush is requested. Practically, this just means that we'll call NativeAnimatedModule methods N times at once, at the end of a render loop, instead of N times smeared throughout the render loop.
(2) Additionally, instead of calling N methods, we create multi-operation argument buffer and call a single NativeAnimatedModule API, which should essentially throttle NativeAnimatedModule API calls to once-ish per frame. On the native side, this also reduces a lot of overhead associated with scheduling work on the UI thread (we schedule 1 function to run on the UI thread and perform N operations, as opposed to scheduling N functions to run on the UI thread).
TODO:
- implement stubs for iOS
- write gating code so this can be properly tested in VR and in fb4a
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338606
fbshipit-source-id: 29ac949b53b874683128a76525586c22def3143b
Summary:
Because of the disconnect between the ReactJS render loop and Animated nodes, we don't know when a render loop begins or ends. Historically we haven't cared about that much,
but now for perf reasons we're attempting to batch them. Scheduling a function to execute at the end of the runloop and canceling until nothing interrupts it achieves that.
Impact seems fairly minimal and this should work everywhere (android, ios, etc) but we may want to gate the behavior as it *could* change things in surprising ways.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338621
fbshipit-source-id: 48e52a1b2e2bcfb3ef13d3abd38d735967356de7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33852
Similarly to buildAll and cleanAll, I'm creating a downloadlAll task
which is aligning the behavior of the download task we're doing on CIs.
I've also updated the Offline Cache as we're now storing a bigger set of dependencies.
Changelog:
[Internal] [Changed] - Setup a toplevel downloadAll task
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D36441728
fbshipit-source-id: f847b5e665c64e0b4b93d984bbc1b64c00a3b4f7
Summary:
I'm adding a readme inside the ./Libraries/Renderer folder
to explain how React and React Native are aligned.
Changelog:
[Internal] [Changed] - Add a note about React/React-Native versioning
Reviewed By: cipolleschi
Differential Revision: D36445819
fbshipit-source-id: cf1b071b9996bcc8222deab2e9458f014766f2a9
Summary:
build_ios is a subset of test_ios.
The Hermes cache takes 20-30 minutes to be downloaded and unarchived, that is the slowest part of both the jobs and that was duplicated.
This means that if we remove build_ios we save a lot of time, and the CI is still covering the build and the testing of the code.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Remove build_ios and use only test_ios
Pull Request resolved: https://github.com/facebook/react-native/pull/33837
Test Plan: Checked on CircleCI
Reviewed By: cipolleschi
Differential Revision: D36437775
Pulled By: f-meloni
fbshipit-source-id: 53adf77e3511963d2dbfadf26122fd70b0de1113
Summary:
The bump of AGP to 7.2 caused the tests inside `AndroidConfigurationTest.kt` to fail.
As we're now running `buildAll` both on Sandcastle and on CircleCI, this is now failing
on both CIs. The issue is that AGP 7.2 change the way to introspect resValues and
requires now to specify a type when querying for a value. I'm updating the tests here.
Changelog:
[Internal] [Fixed] - Fix broken AndroidConfigurationTest.kt on main
Reviewed By: cipolleschi
Differential Revision: D36437875
fbshipit-source-id: 58f457a78eae861e86808e58c23f5d04fb196d45
Summary:
We try to remove the use test_ownership_2020 oncall, which was created to enforce oncall field in test module. This diff stack tries its best to guess who the right oncall is for these "unowned" tests.
If you don't think this belongs to you, please
1. Either re-assign to another team to your best knowledge
2. Or delete the test
Every test should have an owner!
Differential Revision: D36404812
fbshipit-source-id: daf57e860d3700928ae4518897d87247a672eae4
Summary:
Noticed that (LockFree)EventDispatcherImpl had NativeAnimatedNodesManager as a listener 100+ times, as listener registration can happen multiple times from Animated node creation. Since listener management on event dispatcher is thread-safe, we can avoid the thread hop for this.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36316102
fbshipit-source-id: f2f417b69885def87f88460d8b1e0b35b66726cb
Summary:
elementsThatOverlapOffsets was quite inefficient as it was doing a linear scan over all items without an early out for each input offset.
The number of items can be large, so we'd want to use binary search here.
Before: O(MN), where M is the # offsets and N is the # items
After: O(MlogN)
As a utility method, elementsThatOverlapOffsets should not be responsible for checking that the offsets are in increasing order
'binary-search' dep added via https://www.internalfb.com/intern/wiki/React_Native/Building_Product_Experiences/Third_Party_Packages_(npm)/
Changelog:
[Internal] - Modify VirtualizeUtils.elementsThatOverlapOffsets to use binary search
Reviewed By: javache
Differential Revision: D36292326
fbshipit-source-id: 5f22eb5533b69e2ebe5c1cb34e4f82605838f0a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33838
The idea behind this diff is to set a top level `buildAll` task that will be responsible
of invoking all the tasks we want to verify both in the internal and in the external CI.
This should ideally remove the breakages of the External CI happening from internal changes.
Changelog:
[Internal] [Changed] - Setup a top level buildAll Gradle task
Reviewed By: cipolleschi
Differential Revision: D36376384
fbshipit-source-id: d810b59577340628bb49562bfedf28440bd0f792
Summary:
I'm adding a new Issue Template for New Architecture issues + I've added a contact entry for the Working Group.
## Changelog
[Internal] - Add issue templates for New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/33832
Test Plan:
Tested this here
https://github.com/cortinico/react-native/issues/new/choose
Reviewed By: hramos
Differential Revision: D36376737
Pulled By: cortinico
fbshipit-source-id: b8561a7faf0bb99c033686a92bb2d88e443333c2
Summary:
This diff fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
When a cached image is loaded, we will dispatch the event to JS immediately. This is could happen after the view is created during pre-allocation phase, when the event emitter is not instantiated yet. In that case, we will see [an error](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/fabric/FabricUIManager.java#L927) and the event will effectively be ignored.
To fix that we introduced a queue in this diff for those events. They will be dispatched in order when the view is mounted and the event emitter is non-null.
Changelog:
[Android][Fixed] - Fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
Reviewed By: mullender
Differential Revision: D36331914
fbshipit-source-id: cd065b0b36978cb5f0aac793d8d16f07a48f0881
Summary:
Use pre-built hermesc if available by generating a ImportHermesc.cmake file that points to the hermesc binary. Recent `react-native` releases should have hermesc available in sdks/hermesc.
Hermes build scripts have been updated to support a `HERMES_OVERRIDE_HERMESC_PATH` envvar which can point to this generated ImportHermesc.cmake file.
Pull Request resolved: https://github.com/facebook/react-native/pull/33827
Changelog:
[iOS] [Changed] - Use pre-built HermesC if available in current React Native release
Reviewed By: cortinico
Differential Revision: D36024615
fbshipit-source-id: 476569f73309f9bd142f28cb02d1f7d57b6cbc6a
Summary:
This patches a loophole in the logic that caused some operations to execute immediately and some to be deferred, even within the same render loop. This caused the non-queued operations to be executed out of order. Instead, if an operation is created and a queued exists, we just push the operation to the end of the queue so ordering is preserved.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36379125
fbshipit-source-id: d9f63f4d47d8453d51add61763b7b9c74ffe9d88
Summary:
Avoid re-building Hermes if a cache hit is found for the required Hermes version.
Cache sdks/hermes and sdks/hermesc in Circle CI iOS jobs: `test_ios_rntester`, `build_ios`, and `test_ios`.
`test_ios_rntester` "Install CocoaPod Dependencies" step reduced from 37m40s to 3m35s.
`test_ios` "Generate RNTesterPods workspace" step reduced from 36m54s to 1m34s.
Pull Request resolved: https://github.com/facebook/react-native/pull/33828
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36365596
fbshipit-source-id: b5b6fe639f18b1724f80ab61c2262659c4987ff6
Summary:
Currently on Android, React Native can only accept font resource IDs which it internally converts into Typeface objects. This change allows ReactFontManager to be passed a Typeface at runtime to enable e.g. downloading fonts on demand.
Changelog:
[Android][Added] - Ability to pass a Typeface object to ReactFontManager in addition to a font resource ID
Reviewed By: makovkastar
Differential Revision: D36138123
fbshipit-source-id: b314e8c7fc28174b5caa017076b6eb3d4f6dbaa8
Summary:
We are currently seeing warning `Native Component 'X' that calls codegenNativeComponent was not code generated at build time. Please check its definition.` even though we have not opted into Fabric. This warning is not actionable and is just noisy.
See also discussion: https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2657180
## Changelog
[General] [Fixed] - Remove unactionable warning about `codegenNativeComponent` when on 'Paper'
Pull Request resolved: https://github.com/facebook/react-native/pull/33830
Test Plan: n/a
Reviewed By: dmitryrykun
Differential Revision: D36377844
Pulled By: cortinico
fbshipit-source-id: 23c9f9dbf0ce1cea60c5dc8caa02d0dc53bd635d
Summary:
The machines have on their env `HOMEBREW_NO_AUTO_UPDATE=1`, hence I believe that `with_brew_cache_span` is not needed anymore.
If this works it should save the cache downloading and unarchiving time
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Remove with_brew_cache_span from Circle's config
Pull Request resolved: https://github.com/facebook/react-native/pull/33831
Reviewed By: cortinico
Differential Revision: D36374646
Pulled By: f-meloni
fbshipit-source-id: 0e6a35bb2c2dfe44e340e95a1b5e158389a3dfe9
Summary:
Instead of wait for Circle to delete the simulators, we can do it in background and save 40 seconds
Changelog:
[Internal] - Delete iOS simulators in background
Pull Request resolved: https://github.com/facebook/react-native/pull/33822
Reviewed By: cortinico
Differential Revision: D36348573
Pulled By: f-meloni
fbshipit-source-id: 89d9e7caddb44e085734e74f417687ee031dd67b
Summary:
This way we can avoid unnecessary ArrayList copies.
Changelog: [Android][Changed] Generalized the return type of ViewManagerOnDemandReactPackage.getViewManagerNames
Reviewed By: nlutsenko
Differential Revision: D36131516
fbshipit-source-id: 6a42c76cadbcce4c3720875d80062e1ee237bc2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33811
Use `scripts/hermes/prepare-hermes-for-build.js` in Circle CI, eliminating redundant steps in the `prepare_hermes_workspace` Circle CI job.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36335122
fbshipit-source-id: b7e8c7aeb2aac5afaf37677cd3ac949ac3f96de1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33825
Updates the CocoaPods build scripts to consume the prepare-hermes-for-build script, replacing the now redundant set of Ruby code that would previously set the filesystem up.
Changelog:
[iOS] [Changed] - When building Hermes from source, the filesystem will now be prepared using the new hermes-utils.js scripts, outside of CocoaPods
Reviewed By: cortinico
Differential Revision: D36336633
fbshipit-source-id: a4506db80c039529b14b0290d2f0b54fae78dcf2
Summary:
Adds a script that uses the new hermes-utils.js functions to prepare the local filesystem for Hermes to be built from source (e.g. download the Hermes source code tarball and extract it into its final location).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36334624
fbshipit-source-id: 012f758ecda07931bdb0ab1728b87733bf5af16a
Summary:
Currently, the tasks for downloading, expanding, and preparing Hermes to be built for Apple targets are split across the Circle CI and CocoaPods configs.
This diff sets out to consolidate these tasks into a single hermes-utils.js script that can be reused across CI and build systems.
The release script that is used to assign the Hermes tag for a given React Native version has been moved into `scripts/hermes`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36329356
fbshipit-source-id: 0222070adf201fa533b607a183471396d45c6caf
Summary:
Unify the different cache keys in one unique place to avoid duplication, and possible issues with typos.
## Changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/33821
Test Plan: Check Circle CI jobs to verify that caches are working correctly
Reviewed By: cortinico
Differential Revision: D36347758
Pulled By: f-meloni
fbshipit-source-id: 2a02855e938c7cb27eaa5ebee221f5861f72aee9
Summary:
Small win: if the queue is empty we shouldn't start/stop the batch.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36298399
fbshipit-source-id: b43c07994ba28b4c890fe52af4e81c265a3b8ac7
Summary:
Changelog:
[Internal][Changed] - Remove babel plugins from jest preprocessor which are part of preset metro-react-native-babel-preset
Transformer metro-react-native-babel-transformer has preset metro-react-native-babel-preset which has necessary plugins to transpile the source. So we don’t need to pass it again in the preprocessor.
As part of the change, updated one test to use strict mode since metro-react-native-babel-preset has strictMode is set to false.
Reviewed By: motiz88
Differential Revision: D34868961
fbshipit-source-id: 71678f1ee6f1b5ebf9a0c6fd2d6444a61d7583ac
Summary:
Patch release bumps that just change arm64 slice packaging
See https://github.com/facebook/flipper/issues/3117#issuecomment-1123759397
These pods were just released by lblasa and this PR integrates them - I personally confirm success on an arm64 doing a macCatalyst build for the first time since react-native 0.64, and users report intel works fine as well - no regression
## Changelog
[Catalyst][Fix] - use pods with arm64 macCatalyst slices
Pull Request resolved: https://github.com/facebook/react-native/pull/33809
Test Plan:
Run a macCatalyst build on intel machine and m1 machine, I use this harness as part of release-testers facebook group, and it exercises macCatalyst build if you pass in a valid development team (for signing) https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh
(the test harness is locally modified to no longer exclude M1 builds and with a patch-package that implements this PR, pending this merge+release...)
Reviewed By: cortinico
Differential Revision: D36339335
Pulled By: cipolleschi
fbshipit-source-id: d4574fc960e6ff345b31a83ff4629e22edfcf2f7
Summary:
Sometimes this._scrollMetrics.offset is 0 even after initial scroll is triggered, because the offset is updated only upon _onScroll, which may not have been called in time for the next computation of the render limits. Thus, there is a window of time where computeWindowedRenderLimits calculates undesired render limits as it uses the offset. This results in 2 extra rerenders of the VirtualizedList if an initial scroll offset is applied, as the render limits shifts from the expected bounds (calculated using initialScrollIndex), to the 0 offset bounds (calculated using computeWindowedRenderLimits due to offset = 0), back to the expected bounds (onScroll triggers recalculation of render limits via _updateCellsToRender).
This issue was introduced in https://www.internalfb.com/diff/D35503114 (https://github.com/facebook/react-native/commit/c5c17985dae402725abb8a3a94ccedc515428711)
We cannot rely on this._hasDoneInitialScroll to indicate that scrolling *actually* finished (specifically, that _onScroll was called). Instead, we want to recalculate the windowed render limits if any of the following hold:
- initialScrollIndex is undefined or is 0
- initialScrollIndex > 0 AND scrolling is complete
- initialScrollIndex > 0 AND the end of the list is visible (this handles the case where the list is shorter than the visible area) <- this is the case that https://www.internalfb.com/diff/D35503114 (https://github.com/facebook/react-native/commit/c5c17985dae402725abb8a3a94ccedc515428711) attempted to address
Changelog:
[Internal][Fixed] - Fix issue where VirtualizedList rerenders multiple times and flickers when initialScrollIndex is set
Reviewed By: JoshuaGross
Differential Revision: D36328891
fbshipit-source-id: aba26aa06b24f6976657dd1e9f95bb666f60d9a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33805
When we synced react to 18, we haven't updated repo-config and rn-tester
to also use version 18. I'm updating them here as this is creating confusion
and duplicated entries in the yarn.lock file.
Changelog:
[Internal] [Changed] - Bump React to 18.0.0 inside repo-config
Reviewed By: robhogan
Differential Revision: D36249888
fbshipit-source-id: a89ba1b5592f46987c5a70b707fe9ec57c4fe0ff
Summary:
The `utils/build-apple-framework.sh` script uses the ruby runtime to load `hermes-engine.podspec`, and in the process it will load the Core CocoaPods gem to parse the podspec file.
Since the podspec file uses Pod::UI to print logs, and the CoreUI gem is not loaded when `build-apple-framework.sh` accesses `hermes-engine.podspec`, we would get a warning due to Pod::UI not being defined.
This change will only use Pod::UI when it is defined, therefore limiting it to only executing when `hermes-engine.podspec` is loaded as part of the normal `pod install` build process.
Changelog: [Internal]
Reviewed By: cortinico, neildhar
Differential Revision: D36297856
fbshipit-source-id: ac1ab021f74f9dcaa7be2a2358482c73b827b756
Summary:
Hermes' build scripts use the Ninja build utility if available, otherwise they default to Unix Makefiles. When Unix Makefiles were used, builds would take far too long due to the use of a single core.
To reduce the surface area of issues that may arise as we switch to building Hermes from source, we will now focus on a single build system using Unix Makefiles. We will also ensure all available cores are used when building on macOS.
Changelog: [Internal]
Reviewed By: cortinico, neildhar
Differential Revision: D36296838
fbshipit-source-id: 4be23739fb022e3ae8e974ad3c2c70e7011abb5a
Summary:
Copy Hermes build scripts to React Native repository for greater control over the build pipeline when used in RN.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D36295406
fbshipit-source-id: 54bf4173b6c75db35de828378e6f5782a248ed2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33802
We use to have a couple of tests for the script phases script that were not running during the CI.
This diff connect them with the two CI, so that they run together with the other ruby tests.
## Changelog
[iOS][Added] - Run script phases tests in CI
Reviewed By: fkgozali
Differential Revision: D36283211
fbshipit-source-id: 01b257cdc99b0bc196d60d49ac76cf044d61a7e9
Summary:
Fixes https://github.com/facebook/react-native/issues/30708.
When given the `--port` option to the `npx react-native run-ios` command, [the React Native CLI passes the `RCT_METRO_PORT` variable when calling `xcodebuild`](https://github.com/react-native-community/cli/blob/ada951606e52ad98346cd72beeb15b56ceda8b7c/packages/platform-ios/src/commands/runIOS/index.ts#L552).
This used to adjust the port used when building on iOS, but this appears to have stopped working when the xcodeproj configuration was removed in favor of CocoaPods ([link, load the diff for React.xcodeproj](https://github.com/facebook/react-native/commit/79a7828b91b405de7399cd8cdc1aaaf610ce9d75#diff-43a2b2682727878049c3283b9361d9ad94964b63105fda6a834ba23baa5b471bL5199-L5205)).
This change re-adds the preprocessor definition that was used to pull the environment variable in, and now the `--port` flag works again.
## Changelog
[iOS] [Fixed] - Fixed the ability to pass the port to use for Metro when running `react-native run-ios --port <port>`.
Pull Request resolved: https://github.com/facebook/react-native/pull/33726
Test Plan:
1. Using an example project generated from the 0.68.1 template, I modified `node_modules/react-native/React-Core.podspec` to have the same changes.
2. Deleted my project's `ios/Pods` folder and re-ran `bundle exec pod install`
3. Ran `yarn ios --port=9900` and verified that the app is connected to Metro, and check again with a refresh of the app.
4. Verified that I saw traffic on port 9900 when refreshing the app with `sudo lsof -i :9900`
5. Stopped the app and tested `yarn ios` without a port, and used `lsof` again to ensure it was using the default port `8081` again
I also ran the iOS tests locally and they passed.
Reviewed By: dmitryrykun
Differential Revision: D36097840
Pulled By: cipolleschi
fbshipit-source-id: c3f31789e15f6cd3386350e917cfa715b2d7fd58
Summary:
An issue that popped up working on:
D36140890
There is already behavior implemented to set the TextInput caret/cursor color independently from the selection box color in Android.
However this handy prop, was not documented or added as one of the available props for the TextInput component.
Associated behavior can be found here:
https://www.internalfb.com/code/fbsource/[f116d651b2e8]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java?lines=512
## **Changelog**
[Android] - Add android-only prop documentation at the TextInput js level.
Reviewed By: genkikondo
Differential Revision: D36208656
fbshipit-source-id: a54a2646351d897e0d598d5e1979f2a0c443e9d6
Summary: [RN][iOS] Changelog: [Internal][Fix] Minor fix: Don't display a legacy surface from Logbox if Bridge is invalid
Reviewed By: RSNara
Differential Revision: D36268234
fbshipit-source-id: 227f465fb1fc2953b5d6813485ed6750b1d3dea3
Summary:
During debugging of undesired behavior using VirtualizedList with initialScrollIndex, it was found that zoomScale was sometimes undefined, which resulted in elementsThatOverlapOffsets returning not being able to find the frame at the given offsets.
This does not cause any unexpected behavior when scrolling from the top, as the first item index in VirtualizedList is always calculated to be 0; however, when we set initialScrollIndex, the frame calculations are incorrect, resulting in wasteful re-renders of the VirtualizedList as it renders every frame (row) from the top.
Changelog:
[Internal][Fixed] - Default zoomScale to 1 for computeWindowedRenderLimits and elementsThatOverlapOffsets in order to fix render limit calculation.
Differential Revision: D36294426
fbshipit-source-id: 1e1abec1c95f58a1913bafa2c9680e51e2dc26fa
Summary: Changelog: [iOS][Internal] - Only fire pointerEnter/Leave events if a view in the event path is listening to that event
Reviewed By: yungsters
Differential Revision: D35911045
fbshipit-source-id: 8b3021619622c3e83c15acea46c23bfe3e0f9284
Summary:
Based on Google Play crash logs, crashes due to the assertions in `dispatchViewManagerCommand` is our top source of crashes:
```
com.facebook.react.uimanager.IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand: blur on view with tag: 17549, since the view does not exists
at com.facebook.react.uimanager.UIImplementation.assertViewExists(UIImplementation.java:830)
at com.facebook.react.uimanager.UIImplementation.dispatchViewManagerCommand(UIImplementation.java:713)
at com.facebook.react.uimanager.UIManagerModule.dispatchCommand(UIManagerModule.java:739)
at com.facebook.react.uimanager.UIManagerModule.dispatchViewManagerCommand(UIManagerModule.java:726)
at com.facebook.react.uimanager.ReanimatedUIManager.dispatchViewManagerCommand(ReanimatedUIManager.java:233)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java:-2)
```
There are many other places in UIImplementation that instead of throwing a fatal exception, just log a message and continues execution.
Logging a message and discarding the command should be safe for commands like "blur this view". We keep the previous behavior in debug mode, but just log and discard commands in production.
## 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
-->
[Android] [Fixed] - Avoid crash by handling missing views in dispatchViewManagerCommand
Pull Request resolved: https://github.com/facebook/react-native/pull/33795
Test Plan: We had a tough time reproducing specific crashes, but we ran with this binary in the latest release of our app and it has eliminated this class of crashes from Google Play and Bugsnag instrumentation.
Reviewed By: cortinico
Differential Revision: D36285603
Pulled By: JoshuaGross
fbshipit-source-id: db0be74926c4cb83f07686398579236da8e586bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33791
This flag is used as a duplication for the `RCT_NEW_ARCH_ENABLED` flag. There is a [spot](https://github.com/facebook/react-native/blob/d96806bbc67f9a9e42791b319d1dddaf8a3cd34f/scripts/react_native_pods.rb#L31) in the code where, if `RCT_NEW_ARCH_ENABLED`, then the `USE_CODEGEN_DISCOVERY` is set to true as well.
Maintain two different flags for similar reasons is cumbersome and error-prone. This diff removes the `USE_CODEGEN_DISCOVERY` in favor of the `RCT_NEW_ARCH_ENABLED` flag.
## CHANGELOG
[iOS][Removed] - Remove USE_CODEGEN_DISCOVERY flag
Reviewed By: cortinico
Differential Revision: D36244618
fbshipit-source-id: 8e8979268b7aa25b895236b0c3a86fb57c6f2ea6
Summary:
This diff adds a CompositeReactPackageTurboModuleManagerDelegate which can be used to combine 1 or more TurboModuleManagerDelegates into a single one.
This is useful when both the app and one or multiple of its libraries provides a TurboModuleManagerDelegate
Changelog:
[Internal] [Changed] - Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: mdvacca
Differential Revision: D36187694
fbshipit-source-id: 88f1d689342345b4cb7e67186791ad5bd1a6f21b
Summary:
ScrollView's contentOffset prop was assumed to be iOS only, but in reality it is supported on Android as well: https://fburl.com/code/nuxpjpth
Changelog:
[General] - Move ScrollView's contentOffset to common props
Reviewed By: yungsters
Differential Revision: D36219604
fbshipit-source-id: f41679fd2ce7971a30129e0d91ae9f32b9cf756e
Summary:
This Change fixes a possible null exception as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The exception may happen as `mFabricViewStateManager` is accessed during
the constructor of the superclass, and is not yet initialized.
- For reference, commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
Possible null exception as `mFabricViewStateManager` is accessed during
the constructor of the superclass, white it is not yet initialized.
This commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening, accessing of mFabricViewStateManager before initialization, and left another one of the call of the same nature.
## 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
-->
Fix: accessing `mFabricViewStateManager` before initialization.
[JavaScript] [Fixed] - accessing `mFabricViewStateManager` before initialization.
Pull Request resolved: https://github.com/facebook/react-native/pull/33769
Test Plan: no external tool was used.
Reviewed By: javache
Differential Revision: D36205441
Pulled By: cortinico
fbshipit-source-id: f3fca69224c7794757514f026a5293b213986186
Summary:
I'm updating the versioning schema of `react-native-codegen` to use minor instead of patch versions.
Historically we used to use a version as `0.0.15` and incrementally bump it.
Today, we had to do released a patched version of `react-native-codegen` for React Native 0.68.
Therefore, we're moving to use a versioning scheme as `0.<RN-VERSION>.x` which gives more flexibility and allows us to follow-up on specific version of the codegen for every RN version, should we need to.
`react-native-codegen` 0.70 is essentially a re-publishing of 0.0.16 from `main`
Changelog:
[General] [Changed] - Bump React Native Codegen to 0.70.0
Reviewed By: motiz88
Differential Revision: D36244307
fbshipit-source-id: 475615e5dbc4e6bc850f64110c060a1c87544292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33792
This Diff exports the `flipper.rb` file in the `package.json` to fix the OSS CI
## Changelog
[iOS][Changed] - Export `flipper.rb` script file
Reviewed By: cortinico
Differential Revision: D36244721
fbshipit-source-id: d8c57ce6525bce6f0acbe722064b79eda0d0a7a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33776
The implementations of these modules is pretty much identical, and we're already shipping the fbjni version of this anyway.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D36200330
fbshipit-source-id: 135ee621e1e4c5eb9616ce7f442fc6d4b946f865
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
This Diff moves all the Flipper.rb related setup in the cocoapods scripts to a dedicated script.
It also removes the not needed dummy files and add tests for flipper.
## Changelog
[iOS][Internal] - Extract Flipper setup in a separate file and add tests
Reviewed By: cortinico
Differential Revision: D36129808
fbshipit-source-id: 5446203a69b527146c893aa9611e98688e20b778
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33780
Currently this just has a default ThreadPool name, which can be confusing in systraces and crash reports.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D36200090
fbshipit-source-id: 22918993e7c822ed721ccaf79cdcd9d2a972193d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33761
Changelog:
[General][Fixed] - Add 'mkdirp' as a direct dependency to 'react-native' instead of assuming it being a transitive dependency of some other module.
Reviewed By: cortinico, cipolleschi
Differential Revision: D36138320
fbshipit-source-id: b2421aa6b22fca0b813bbb5bb0c7213540ca578d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33779
This diff adds a `store_artifacts` to CircleCI so the Hermes debug symbols are retained and can be used to symbolicate native crashes for Hermes.
Changelog:
[Internal] [Changed] - Store Hermes Debug Symbols inside CircleCI
Reviewed By: cipolleschi
Differential Revision: D36201978
fbshipit-source-id: ef9a71e2953180aef5caea9f5eb0047190ed6198
Summary:
This comment on how to enable/disable Hermes went out of sync with the release of the New Architecture. Got reported on the website here: https://github.com/facebook/react-native-website/issues/3105
I'm fixing it.
Changelog:
[Internal] [Changed] - Fix comments on how to enable/disable Hermes on iOS
Reviewed By: cipolleschi
Differential Revision: D36204189
fbshipit-source-id: 5831a9500477115ebe5fa5cb62176ceefc722839
Summary:
Customize the Hermes version exposed to CocoaPods with one that refers to the facebook/hermes commit sha from which Hermes was built.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36145140
fbshipit-source-id: 4ff7546d2335ea6642dd9b10f4b7a9aba260d550
Summary:
Use Circle CI caching to avoid re-building Hermes. The cache key will be determined by the Hermes tag specified in sdks/.hermesversion; if the file does not exist (as is the case in builds from main), the commit sha for the latest Hermes commit from facebook/hermes will be used.
This should significantly speed up builds across all workflows: builds from main (commitlies), nightlies, and release builds.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36158296
fbshipit-source-id: b80457fdefad0d63e62feeb4d509265e2762f253
Summary:
Updates `yarn.lock` to resolve mixed/mismatched Metro versions between direct dependencies on `0.70.3` and indirect dependencies on `^0.70.1`, so that everything resolves to `0.70.3`.
Changelog: [Internal]
Reviewed By: jacdebug, cortinico
Differential Revision: D36131458
fbshipit-source-id: d1ad72432b664b7191b2431d3c3b95b70f3a81d7
Summary:
Changelog:
[Breaking][General] Remove jest/preprocessor from the react-native package
Using `react-native/jest/preprocessor` outside of the React Native repo has been deprecated since D34820086 (https://github.com/facebook/react-native/commit/c1e9aa9a272aed3cba60c4aeff783eeb8bffce68). Here, we make this file private and stop publishing it to npm.
The supported method of using Jest in React Native projects is using the [Jest preset](https://jestjs.io/docs/tutorial-react-native) shipped as part of the `react-native` package.
NOTE: We could probably make some of the other files under `jest/` private as well, but we should go through a separate deprecation cycle with those, in case they are also being used externally by some projects. I'm leaving that for future followup at the moment.
Reviewed By: GijsWeterings
Differential Revision: D36132939
fbshipit-source-id: 300ffa6cf16232573cd3a79a34c14daaafd7aa43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33773
I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D36164350
fbshipit-source-id: 5290587010fe6021b758bda98bf01995fdf14acd
Summary:
Noticed in D36098912 (https://github.com/facebook/react-native/commit/5de0f145eca36d3263cb8a9928add278cdfffa2b) that the definition of NativeAnimatedModule's OperationQueue.isEmpty was incorrect as it didn't account for `mPeekedOperation`, while `drainQueueIntoList` did.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36109810
fbshipit-source-id: afd7059975ce6e5c65d1975d168a03f0881bd7c1
Summary:
Adjust logs during `pod install` to warn user about longer install times due to Hermes compilation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36143766
fbshipit-source-id: 0facb2e295543438dfbc46d11db1c4dc163acff9
Summary:
The ReactAndroid cmake build assumes that the build directory is ReactAndroid/build, but this is not always the case if gradle is configured with a different build location. Instead of assuming the build location in cmake, pass it from gradle.
## Changelog
[Android] [Fixed] - Pass react build dir to cmake
Pull Request resolved: https://github.com/facebook/react-native/pull/33736
Test Plan:
Tested in an app with a custom build dir that RN now builds properly after this change.
In build.gradle add:
```groovy
allprojects {
buildDir = "${System.getProperty("user.home")}/.gradle/builds/${rootProject.name}/${project.name}"
}
```
Reviewed By: christophpurrer
Differential Revision: D36128556
Pulled By: cortinico
fbshipit-source-id: cdb8283c93ea7c384ec94cd3e24012220965b6dc
Summary:
This change caused some internal regression in release builds, hence reverting it
Changelog:
[Internal] [Changed] - Back out > Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: alsun2001
Differential Revision: D36182014
fbshipit-source-id: e49fc897f3b1a2e9d33fcb7687244be74020c5be
Summary:
Changelog:
[General][Breaking] - Remove nonstandard Promise.prototype.done
`Promise.prototype.done` has been deprecated since D34222667 (https://github.com/facebook/react-native/commit/35800962c16a33eb8e9ff1adfd428cf00bb670d3). Here we remove it from React Native's default Promise polyfill. Users should switch to using standard Promise features like `.then()`, or install their own custom polyfills for advanced use cases.
Reviewed By: kodafb
Differential Revision: D36001688
fbshipit-source-id: 37f452000c16279280ef6a50b2ce616776377c4e
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Some manual fixes, in particular to React Native code, which is used and can be synced to other repos (e.g. WWW).
With these changes, error diff in Xplat is down to ~1990 errors
Note that after I roll out `exact_empty_objects`, I'll codemod all the `{...null}` (the only way to get an exact empty object currently) back to `{}`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D36142838
fbshipit-source-id: 054caf370db230f42a4c5f5706c88979ef246537
Summary:
Assertion failure would lead to a crash, in real world not being able to start an activity shouldn't crash - usually a navigation won't happen as expected, user could try again.
Changelog:
[Android][Changed] - Don't assert on current activity when call startActivityForResult
Reviewed By: cortinico
Differential Revision: D35746652
fbshipit-source-id: 0b77ca5a69b2f3f3b0b969d84980ed8290ac9b1f
Summary:
Remove old deprecated modules that cause annoying warnings. This can be a breaking change for some third-party modules.
## Changelog
[General] [Removed] - Remove deprecated removeListener methods
Pull Request resolved: https://github.com/facebook/react-native/pull/33580
Test Plan: See `flow-check` and `build-arvr-js-flow` succeed in Sandcastle.
Reviewed By: cortinico
Differential Revision: D35549719
Pulled By: yungsters
fbshipit-source-id: 0495e36de19db434362d5de56463d9c1ad6edd73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33758
This fails to compile in our CircleCI builds
```
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/CompositeReactPackageTurboModuleManagerDelegate.java:52: error: incompatible types: java.util.List<java.lang.Object> cannot be converted to java.util.List<com.facebook.react.ReactPackage>
delegates.add(delegatesBuilder.build(context, Collections.emptyList()));
```
Make the empty collection generic should solve the issue
Changelog:
[Internal] [Changed] - Fix Circle CI for CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36130573
fbshipit-source-id: 9615311798fbbd7c000838dfbc043f450c2d9e2e
Summary:
Using Fabric with a Swift native module is currently broken. There are currently two issues.
If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries),
you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`.
Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name.
## 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 using Swift in a native module with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33743
Test Plan:
1. Clone [this](https://github.com/fortmarek/react-native) repo
2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app)
3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR
6. Both pod install and the subsequent build should succeed.
I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main`
Reviewed By: dmitryrykun
Differential Revision: D36097852
Pulled By: cipolleschi
fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33749
Yet another bump of the Codegen to ship new features for RN 0.69
Changelog:
[Internal] [Changed] - Bump React Native Codegen to 0.0.16
Reviewed By: cipolleschi
Differential Revision: D36096803
fbshipit-source-id: 46e118f633eff2abf636737e69718e8fcb3608ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33729
This PR addresses [this comment](https://www.internalfb.com/diff/D35820848?dst_version_fbid=496290878846487&transaction_fbid=355967423221044).
It makes the CodeGen to the `outputDir` as base directory for the codegen.
Finally, it updates the unit tests accordingly.
## Changelog
[iOS][Changed] - use `outputDir` as base directory for the codegen and remove the possibility to customize the intermediate path. The generated code requires specific paths in the `#include` directive.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35935282
fbshipit-source-id: a9ad4e296efb042cf34b20db5eebb59614beb5f6
Summary:
This Diff splits the `generate-specs-cli.js` script into:
* `generate-specs-cli-executor.js`: which contains the logic to generate the code for iOS.
* `generate-specs-cli.js`: which contains the argument parsing logic and invokes the executor.
Finally it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35892576
fbshipit-source-id: 6a3205af049bf55aa4ecaf64544ebc4eb7b13f73
Summary:
This Diff splits the `generate-artifacts.js` script into:
* `generate-artifacts-executor.js`: which contains the logic to generate the code for iOS.
* `generate-artifacts.js`: which contains the argument parsing logic and invokes the executor.
Finally, it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35846674
fbshipit-source-id: 14873c3fe762606e9004a29e4a6b986bf6a8f055
Summary:
This Diff introduces some changes in the CodeGen to properly generate the types in the right folder.
## Issue
The codegen on iOS defines the output folder once, before creating the generated code.
When the code we have to generate is just a TurboModule (TM) or a Fabric Component (FC), this mechanism works properly.
However, if a library has to generate both TM and FC, actually using the library type `all`, all the code is generated using the TurboModules' output folder.
(**Note:** Android only works in this way)
This generates invalid code because all the FC's `#import` directives assumes that the code is generated in the FC output path which, in this case, is not.
## Solution
The adopted solution moves the responsibility to decide where the files has to be generated to the CodeGen step instead of in the preparatory phases.
The two paths are precomputed in the `generate-artifacts.js` script (the entry point for the CodeGen) and they are passed to all the scripts that requires them.
Once they reach the `RNCodegen.js` file, the generators creates the files and save them in the proper paths.
## Changelog
[iOS][Changed] - CodeGen now supports the `"all"` library type.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35820848
fbshipit-source-id: ce7f5393936e2ae17f8b2c970f6a011d27f641f2
Summary:
This diff adds a CompositeReactPackageTurboModuleManagerDelegate which can be used to combine 1 or more TurboModuleManagerDelegates into a single one.
This is useful when both the app and one or multiple of its libraries provides a TurboModuleManagerDelegate
Changelog:
[Internal] [Changed] - Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: cortinico
Differential Revision: D36057036
fbshipit-source-id: bf131fa7315941b3353c0522e4d77d909b82914b
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Making this change exposes a variety of errors. We can prevent these errors by annotating what we want the type of the empty object to be.
Reduces Xplat error diff to 2.3k
- Announcement: [post](https://fb.workplace.com/groups/flowlang/posts/903386663600331)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
Format:
```
arc f
```
Sort imports
```
hg l -n | xargs js1 lint --fix --rule 'fb-tools/sort-requires'
```
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D36086696
fbshipit-source-id: 90447279f2e6e38f44189b74ec0297719f7adf58
Summary:
With the new architecture, this diagnostic utility will be helpful to ensure stronger validation of various corner cases at runtime, like handling an early JavaScript exception when loading React Native.
If `global.RN$DiagnosticFlags` is set to a string of comma-separated flags, the util functions will be able to perform additional diagnostics. For now, the accepted flags are:
- `early_js_errors`
- `all`
This is still experimental and may change frequently.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36088407
fbshipit-source-id: 9059d2d081b0f41d049310fb09650416b333ff57
Summary: There's no need to use private feature flag for overflowInset feature. This makes future refactor on feature flags easier.
Reviewed By: javache
Differential Revision: D35866302
fbshipit-source-id: a3fde212ff40cd6d4c68832bb39b34de5a17a8d4
Summary:
Changelog:
[Internal]
Cleans up unnecessary type casts / suppressions throughout the codebase following D35869725.
Reviewed By: javache
Differential Revision: D35870027
fbshipit-source-id: eefcb544b19ba93587011cdfd4046d18dddb246e
Summary:
Changelog:
[General][Fixed] - Improved Flow type inference in Animated `.interpolate()`
Improves the ergonomics of `.interpolate()` by allowing Flow to infer the correct type for `outputRange`. This is achieved by adding a new type parameter `OutputT` to `interpolate()` (and `Animated.Interpolation` and `InterpolationConfigType`), which Flow infers as either `number` or `string` based on usage.
Admittedly, at the call site, this is not that much safer compared to something like `outputRange: $ReadOnlyArray<number | string>`, but it does document the intent of the API a bit better and provide some downstream type safety. For example, we can now express `Animated.Number` (D35869375) more precisely by excluding string-valued interpolation nodes.
Reviewed By: javache
Differential Revision: D35869725
fbshipit-source-id: e03ec22e9b3368ee196b392af011062ac99d8bb9
Summary:
Changelog: [General][Added] - Add `Animated.Numeric` Flow type
Adds a Flow type to represent the various Animated node types that evaluate to numeric values and can be `interpolate()`d.
I'm including `AnimatedInterpolation` as "numeric" here even though it can technically evaluate either to a number or to a string, depending on its config. Note that calling `interpolate()` on a string-valued `AnimatedInterpolation` is a runtime error.
In a future diff, I'm planning to add a type argument to `AnimatedInterpolation` (and its config type), at which point we can refine `Animated.Numeric` to correctly include only `AnimatedInterpolation<number>`.
Reviewed By: javache
Differential Revision: D35869375
fbshipit-source-id: 2ff6754f1a5abc68c9da2c6836872c2022b25676
Summary:
I wrote a test for a vibration feature in a react native app by importing the `Vibration` module and using `jest.spyOn(Vibration, 'vibrate')`.
I had the following error:
```
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'Vibration' could not be found. Verify that a module by this name is registered in the native binary.
```
That lead me to look for (and not find) a mock for the `Vibration` module in the code.
## 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] - Add Jest mock for Vibration module
Pull Request resolved: https://github.com/facebook/react-native/pull/30643
Test Plan:
I would be glad to provide a test plan for this, but as it is part of testing I don't really know how to do so.
Any suggestion or help is welcome!
Reviewed By: yungsters
Differential Revision: D36097003
Pulled By: cortinico
fbshipit-source-id: 58683120da34f40e142a44c4bef8a5fced04bac2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33747
This Diff connects the ruby tests setup with CircleCI, making sure that we are executing the same script in Sandcastle and CircleCI.
At the moment, the scripts runs somedummy tests to make sure that everything works.
## Changelog
[iOS][Changed] - Add ruby tests to circleci
Reviewed By: dmitryrykun
Differential Revision: D36091716
fbshipit-source-id: c432e5f8b5269754db2b7ec278b159dcedf3b3b9
Summary:
This PR adds a step in the iOS legocastle script to run the ruby tests in the cocoapods folder.
These tests are executed before the pod installation step: this because we would like to fail as fast as possible in case of issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36006781
fbshipit-source-id: 8afbc1ccc751d2dc736bdc23ec382ebd7b5c7f4f
Summary:
This Diff prepares a set of dummy tests to make sure that our infra supports tests in ruby.
It also adds a scripts in the `__tests__` folder which can be invoked to run all the tests. The script performs a discovery of all the tests in the cocoapods folder.
Next steps will configure Sandcastles and CircleCI.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35968556
fbshipit-source-id: b8bf23d30dc5358ab603e396cce1c6639dd0f567
Summary:
Changelog: [Internal][iOS] Fix AppState in Bridgeless mode by removing guard for bridge, since it doesn't use bridge
AppState doesn't use bridge because RCTAppState subclasses RCTEventEmitter, which calls `_callableJSModules invokeModule` in both Bridge and Bridgeless mode to send events to JS.
Reviewed By: fkgozali
Differential Revision: D35988515
fbshipit-source-id: fb19f0f2df5b270f0ef57637930f94686e39a9a1
Summary:
This PR reestablish the WebSocketTest in CI which is making the `test_ios_unit` fail.
**Note:** the test_ios_unit is actually running integration tests...
## Changelog
[iOS] [Changed] - Fix the test_ios_unit test
Pull Request resolved: https://github.com/facebook/react-native/pull/33721
Test Plan: The CI of this PR is green. 😬
Reviewed By: cortinico
Differential Revision: D36002823
Pulled By: cipolleschi
fbshipit-source-id: 20eeb08bfd02658ad6579085241f81654f74c1af
Summary:
During the release of .69, we (fortmarek and me) discovered a couple of bits that needed
some intervention.
- `sdks/.hermesversion` was gitignored, so we could not commit that.
- `scripts/bump-hermes-version.js` was not executable, so we had to chmod +x to
make it runnable.
Here I'm fixing it.
Changelog:
[Internal] [Changed] - Fix release infrastructure failures discovered during .69 release
Reviewed By: cipolleschi
Differential Revision: D36003808
fbshipit-source-id: c4d82ed5e2c63988699035ac84b0e87ed8894540
Summary:
For RN 0.69, we want to ship all the changes we have on master
for React Native Codegen.
Changelog:
[Internal] [Changed] - Bump React Native Codegen to 0.0.15
Reviewed By: cipolleschi
Differential Revision: D35964934
fbshipit-source-id: d6b6c36a9a077cb53113907ea59da3148e18e5cd
Summary:
I'm removing the Java generation as we're not using it for now, and we're not maintaining it.
Moreover is not feature complete, and still needs `react-native-codegen` to generate the Makefile/CMake/C++ code.
We can still resort it if we decide to switch to AST based generation.
Changelog:
[Internal] [Changed] - Remove the unused JavaGenerator from the React Native Gradle Plugin
Reviewed By: cipolleschi
Differential Revision: D35930746
fbshipit-source-id: 624c411cdc678b270a647efc3cc8236b50018bef
Summary:
Build Hermes on Circle CI, and pull in the osx-bin, win64-bin, linux64-bin directories into sdks/hermesc when react-native is packaged for npm.
Pull Request resolved: https://github.com/facebook/react-native/pull/33679
Changelog:
[General][Added] - Hermes Compiler binaries will be provided in react-native/sdks/hermesc
Reviewed By: cortinico
Differential Revision: D35793916
fbshipit-source-id: b9322abec29dd90b8bad6b803b1b1dff87d62669
Summary:
In order to release RN 0.69, we need to Bump React Native Gradle plugin to
the latest stable.
Changelog:
[Internal] [Changed] - Bump React Native Gradle plugin to 0.0.7
Reviewed By: cipolleschi
Differential Revision: D35964705
fbshipit-source-id: 0893fe092cfddffd5e79b70fc069f7c59ce33845
Summary:
Currently, we build Hermes by specifying the Cmake flag `-B ./hermes`. That means
that the output out the build is going to be placed along side the source code.
This is fine, as long as the user doesn't use the `REACT_NATIVE_OVERRIDE_HERMES_DIR`,
which is used inside the Hermes CI. In that case, the source location of Hermes can be
changed, leading to scenarios where `hermesc` can't be found.
Here I'm changing the flag to be `-B $buildDir/hermes`. Therefore the build output
will always be located within the `./ReactAndroid/hermes-engine/build` folder.
This is a more robust solution as the build output will be encapsulated within the
`build/` folder.
Changelog:i
[Internal] [Changed] - Update the hermesc output to be inside the $buildDir
Reviewed By: cipolleschi
Differential Revision: D35964402
fbshipit-source-id: aa7e0775b282897d5a99c1c46265884d19c5f289
Summary:
Upgrades the React Native CLI to v8 alpha.4. Includes `--generate-static-view-configs` metro flag for `bundle` command cc dmitryrykun kelset cortinico
## Changelog
[General] [Changed] - Upgrade RN CLI to v8 alpha.4
Pull Request resolved: https://github.com/facebook/react-native/pull/33718
Test Plan: CI green.
Reviewed By: cipolleschi
Differential Revision: D35961818
Pulled By: cortinico
fbshipit-source-id: 54137cd32d4a5d546dbee17983a2c04321b9a3fc
Summary:
This diff breaks the RNTester app at runtime and it prevents us from cutting RN 0.69.
Original commit changeset: a879787d8683
Original Phabricator Diff: D35435562 (https://github.com/facebook/react-native/commit/f4c4f446e4365c6cf7adf5db21d3d746b38aa3e2)
## Changelog
[General][Fixed] - Revert change which breaks RNTester
Reviewed By: cortinico, kacieb
Differential Revision: D35936298
fbshipit-source-id: c4ec92002fde9c1de691bcda17ebc5d0747914f6
Summary:
Ideally, the application should always be able to create the TurboModule object given an ObjC class. This debugging information will help track down these classes of issues, when they surface.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D35945399
fbshipit-source-id: 1621a4a64bc8fb0411123fb1470bbb52ccf0edcf
Summary:
During the TurboModule init path, the TurboModuleManager asks the application to create the TurboModule object, given its class.
If the application is unable to create the TurboModule object, what should we do?
0. **What we do now:** Continue executing TurboModule init path.
1. Silently return nil early.
2. Silently return nil early, and RCTLogError.
If we Continue executing the TurobModule init path, we'll run into a segfault, because we'll call objc_setAssociatedObject(nil, ...).
This diff prevents that segfault, by doing a silent return of nil.
Changelog: [iOS][Fixed] - Prevent Nullptr segfault in TurboModule init path
Reviewed By: fkgozali
Differential Revision: D35942323
fbshipit-source-id: 7755800379c4bc733502314f3af3f401e9b04872
Summary:
The `notifyNativeGestureEnded` API is added to notify user gesture ended, so that any optimization we had during handling the gesture can be restored.
It's possible that when the gesture finishes, the RootView is already unmounted from the native side. This might happen when user starts a gesture that caused leave of the RN screen, or close the app.
Changelog:
[Android][Internal] - Avoid NPE for gesture notifier
Reviewed By: javache
Differential Revision: D35902523
fbshipit-source-id: 9bb5819a53dd053290031eebaae1b8f0318ae534
Summary:
# First issue - incorrect ref
In this example, `AccessibilityInfo.setAccessibilityFocus_unstable` is being called on the Button ref. This fails because Button is not a HostComponent and does not accept a forwarded ref.
Since the button needs to be focused in order to click on it, I don't think the intention of this example actually makes sense. Since even if it worked, it would just reset the focus in the same place.
Instead, I alter this to set accessibility focus on the preceding Text element, which makes it more clear that setAccessibilityFocus is working.
# Second Issue - focus after closing Alert doesn't work
I am not sure why this is the case, but removing the alert causes focus to work correctly. i'm guessing the set focus command is conflicting with Alert's default resetting focus behavior.
# Minor Fix
I also quickly cleaned this up to be a function component because class components make refs more confusing (to me).
Changelog:
[Genera] Fix sendAccessibilityEvent_unstable Example in RNTester
Reviewed By: p-sun
Differential Revision: D35725018
fbshipit-source-id: f5a1dbbcf2635f038c41db9ef2a0b31389d2c745
Summary:
This commit moves the resolution of the hermesc inside the TaskAction block of the
HermesBinaryTask. Therefore the hermesc path will be investigated only during the
execution of the task, and not when the task is created.
Changelog:
[Internal] [Changed] - Lazily resolve the hermesc path rather than eagerly
Reviewed By: motiz88
Differential Revision: D35930548
fbshipit-source-id: a517dda0fa9b10f53c25cd256ceb68d37d533d3b
Summary:
This diff updates the CMake command used for configuring the Hermes build
from `cmake` from $PATH to the `cmake` bundled with the Android SDK.
If not found, fallsback to the previous behavior.
This relaxes the requirement of having to ask our users to install CMake
in their CLIs.
Changelog:
[Internal] [Changed] - Use Android SDK version of CMake rather than an external one
Reviewed By: neildhar
Differential Revision: D35931306
fbshipit-source-id: 8d6c554e5e9040e3bd4fed5f72fbdb0eb61d745a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33688
These methods used to be public in the legacy implementation, and hiding them significantly reduces amount of customization available to other clients outside Fabric core.
Changelog: [Internal] Allow external callers to call UIManager methods
Reviewed By: cipolleschi
Differential Revision: D35818114
fbshipit-source-id: 4dc4177c82b5db9ae3d136a1a83f5ec3123b971f
Summary:
Minimal set of changes to intercept events in external modules. Current intended use-case is for Reanimated to handle events for the Animated properties.
Changelog: [Added] Add listeners to allow intercepting events in C++ core.
Reviewed By: cipolleschi
Differential Revision: D35312534
fbshipit-source-id: ec924b57fd0c0dabf7be7b886dbef23bf3170d6c
Summary:
When a FlatList is nested inside another FlatList, it may be re-rendered whenever the outer FlatList renders. Apply the same optimization we already had in `VirtualizedListContextProvider` to avoid changing the context object if no values have changed.
Changelog: [General][Changed] - Optimized VirtualizedList context when used with nested lists
Reviewed By: genkikondo
Differential Revision: D35905952
fbshipit-source-id: 695253c85db2043d22e208ad94ecc7daa1455055
Summary:
Refactor of TouchTargetHelper.findTargetPathAndCoordinatesForTouch to avoid unnecessary lookup of views during the dispatching of Hover Events
changelog: [internal] internal
Reviewed By: lunaleaps, mdvacca
Differential Revision: D32296003
fbshipit-source-id: 93834c37331ad5d75645a5665a1c8c3d965765fb
Summary:
When searching for the `hermesc` path, we should also honor the `REACT_NATIVE_OVERRIDE_HERMES_DIR` variable.
Changelog:
[Internal] [Changed] - Honor the REACT_NATIVE_OVERRIDE_HERMES_DIR variable when searching for `hermesc`
Reviewed By: neildhar
Differential Revision: D35903601
fbshipit-source-id: 31e1255a558eece8cd84669861328db72e9ed17b
Summary:
This would fix test errors caused by including <string> in non-C++ compatible files.
Changelog:
[General][Changed] - Remove usage of std::string in EarlyJsErrorHandler.
Reviewed By: RSNara
Differential Revision: D35645334
fbshipit-source-id: 7f04d2c66d53dc1eef63367de1a64ed9273898f5
Summary:
Ensures that transaction telemetry modified by transaction controller is the same as sent in the view callbacks.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D35827347
fbshipit-source-id: 123ae01d4a7fe1a9c97ebccae3ae248f7f2cf654
Summary:
Changelog:
[iOS][Fixed] - Expose the extraData dict attached to JavaScript errors to the native ExceptionManager on iOS, similar to Android
Attaching the `extraData` dict to JavaScript crash reports is something that was done for Android only in 2019 (D16133080 (https://github.com/facebook/react-native/commit/3a825c036065783aae6fb734028f986dbead80d7)), and somehow we never really got around to adding it in iOS. This diff finally adds the capability to iOS as well. `extraData` can be used to attach various bits of data to a crash report for better debugging and categorization. As with the Android implementation, `extraData` is not attached if the `reportException` API is not used.
Reviewed By: dmitryrykun
Differential Revision: D35743658
fbshipit-source-id: de4060cb6e514db1d85907441a8962f98e9b8392
Summary:
Apple suggested to this new API on iOS 10+.
> // Any new bitmap drawing code is encouraged to use UIGraphicsImageRenderer in lieu of this API.
WWDC18 Reference: https://developer.apple.com/videos/play/wwdc2018/219/
> Use UIGraphicsImageRenderer to create and draw to an image buffer
Supports Wide Color, unlike UIGraphicsBeginImageContext()
Combine with UIImageView for efficient offscreen rendering
Per https://nshipster.com/image-resizing/#performance-benchmarks, the new API runs even faster than the C version, probably due to more smart context reuses/management.
Changelog:
[iOS][Changed] - Adopt UIGraphicsImageRenderer API
Reviewed By: philIip
Differential Revision: D35699584
fbshipit-source-id: 7a1e2109d5e121fb396c1014f4ed0a892211b0cc
Summary:
WHen porting TurboModules or adding new TurboModules, ReactModuleSpecProcessor may fail during buck build, and when the failure is caused by typeElement.getAnnotation, no useful information gets collected, making it difficult to debug.
So here I am adding a try & catch so we can get useful debugging info.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D35767207
fbshipit-source-id: 7e1f9dfbfd31339ab37af19c51d85085e100955a
Summary:
We're adding a native module that returns a Nullable type. This makes the Java spec and the implementation to be the same.
Changelog:
[Android][Added] - Generate `Nullable` for optional objects and arrays in module codegen.
Reviewed By: yungsters
Differential Revision: D35651333
fbshipit-source-id: d73c87340e33cf79831915ce6892e457ef369175
Summary:
This diff allows to customize the Hermes version exposed by the VM with
a version provided by React Native. This will make clearer that a specific
version of Hermes was built at a specific point of the RN release process.
Changelog:
[Internal] [Changed] - Customize the Hermes version using the RN one
Reviewed By: neildhar
Differential Revision: D35820268
fbshipit-source-id: 3e76db921c12a599743fb9312f52edd06d223bad
Summary:
If Hermes is enabled, it will be built from source instead of using the CocoaPods hermes-engine pod.
Changelog:
[iOS] [Changed] Build Hermes from source when Hermes is used
Reviewed By: cortinico
Differential Revision: D35693945
fbshipit-source-id: eadc638106180b183fd6d1e2a272dc3df66fa8b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33547
Now that Hermes is being built from source, Circle CI iOS unit tests can be re-enabled.
Changelog: [Internal]
Reviewed By: cortinico, neildhar
Differential Revision: D35328103
fbshipit-source-id: ea99d8f1fa02997e9c4f55048012b4b55c0bb2b3
Summary:
This diff extends the Gradle algo used to search for `hermesc`.
Currently we look into `node_modules/hermes-engine/%OS-BIN%/hermesc`
With this change the algo will look into:
- A user provided path to hermesc
- Built from source version of hermesc (for users of New Architecture)
- Bundled version of hermesc inside react-native
- hermesc from the hermes-engine NPM package
I've added tests for the new algo. I also realized our tests were broken
(since they stopped running on CI), I fixed them as well.
Changelog:
[Android] [Changed] - Gradle: extend the algoritm to find hermesc paths
Reviewed By: ShikaSD
Differential Revision: D35649911
fbshipit-source-id: d4bcbe06a6bfa8d98b91c1612fc28b300de91661
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33671
With React 18, we now need to allow users on Fabric to opt-in for Concurrent Root.
This commit adds a new method that can be customized in the AppDelegate to turn the feature on and off.
The flag is passed as an initialProps to the rootView.
## Changelog:
[iOS][Added] - Prepare a method in the AppDelegate to control the concurrentRoot.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35757833
fbshipit-source-id: 192cf74c796554cba39366aa90c53c191f960c20
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33672
This pr adds a parameter to the `create-artifacts.js` script to accept the path to a node executable, falling back to `node` in case the parameter has not been passed.
Then, it passes the NODE_BINARY to the script in the `script_phases.sh` script.
This PR decouples the `node` environment from the system one and fixes a build issue in the new architecture when the environment has no `node`
## Changelog
[iOS][Changed] - Update CodeGen scripts to accept custom node executable
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35748497
fbshipit-source-id: 41b102de6427d6ef0ba1f8725f4b939d3b8c63db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33674
## Issue
In D35317070 (https://github.com/facebook/react-native/commit/0480f56c5b5478b6ebe5ad88e347cad2810bfb17) we introduced a way to configuring the Xcode environment via he `.xcode.env`, falling back to the old `find-node-for-xcode.sh` behavior in case of a misconfiguration.
Unfortunately, there were an issue with the new architecture for which the pods were not able to locate the `find-node-for-xcode.sh`, crashing while building the new architecture.
## Solution
This Diff solves the issue in two steps:
1. it exposes to the project the REACT_NATIVE_PATH like Android does here: D35451821 (https://github.com/facebook/react-native/commit/f8d7e0a968ea12606fd8cce03470fd374f732aad)
2. it leverages this new variables to reach the script
## Changelog
[iOS][Changed] - Fixed the fallback behavior when the `.xcode.env` file is missing, actually using the old `find-node-for-xcode.sh` script
Reviewed By: dmitryrykun
Differential Revision: D35779165
fbshipit-source-id: 393ef9a0b98d32d9cf226f7d109fdefd772e5120
Summary:
This PR updates `RCTMountingTransactionObserving` protocol to accept full `MountingTransaction` object as an argument to its methods as opposed to just `MountingTransactionMetdata` which contained only some subset of information.
This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.
One of the use cases for `RCTMountingTransactionObserving` protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.
Before this change, we'd use `mountingTransactionDidMountWithMetadata` to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.
In this PR we're updating `RCTMountingTransactionObserving` protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept `MountingTransaction` as the only argument instead of `MountingTransactionMetadata` object. With this change we are also deleting `MountingTransactionMetadata` altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in `RCTScrollViewComponentView` and `RCTModalHostViewComponentView`.
## Changelog
[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects
Pull Request resolved: https://github.com/facebook/react-native/pull/33510
Test Plan:
As there are not that many uses of `RCTMountingTransactionObserving` protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in `RCTScrollViewComponentView` with the following steps:
1. Build for iOS
2. Put a breakpoint in mountingTransactionDidMount method in `RCTScrollViewComponentView.mm`
3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)
Outside of that we verified the transactions can be processed in `mountingTransactionDidMount` after the changes from this PR are applied in FabricExample app in [react-native-screens](https://github.com/software-mansion/react-native-screens/tree/main/FabricExample) repo.
Reviewed By: cipolleschi
Differential Revision: D35214478
Pulled By: ShikaSD
fbshipit-source-id: f40afc512f2c8cfa6262d2fb82fb1ccb05aa734c
Summary:
`hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Changelog:
[iOS][Added] - `hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Reviewed By: arhelmus
Differential Revision: D35777883
fbshipit-source-id: a7435358701bedb54e33198724180eb1c27248b8
Summary:
Changelog: [Internal] Bump react-native-community/eslint-plugin
It looks like we `*` version on the package.json so no updates needed, published 1.2.0: https://www.npmjs.com/package/react-native-community/eslint-plugin
Reviewed By: cortinico, neildhar
Differential Revision: D35590075
fbshipit-source-id: 11402cedea3067018c03e7b59202a48dc3a6b084
Summary:
This PR re-enables bundling of the precompiled `hermesc` binary inside the react-native NPM package. To handle this I've stripped over all the unnecessary files and kept only the relevant binary. It now follows the same structure as the `hermes-engine` NPM package.
## Changelog
[Internal] - Re-enable bundling of hermesc inside the react-native NPM package
Pull Request resolved: https://github.com/facebook/react-native/pull/33677
Test Plan:
Will wait for a successful CI job to produce a commitlies of RN.
https://app.circleci.com/pipelines/github/facebook/react-native/13020/workflows/9b59c6e0-4e90-4008-be73-aaa3155cefc9/jobs/248841
Here the output of the RN commitlies with the file correctly placed:
```
tar -tvf ~/Downloads/react-native-1000.0.0-1520d36ba.tgz | grep hermesc
-rwxr-xr-x 0 0 0 3516952 Oct 26 1985 package/sdks/hermesc/linux64-bin/hermesc
-rwxr-xr-x 0 0 0 2618232 Oct 26 1985 package/sdks/hermesc/osx-bin/hermesc
-rwxr-xr-x 0 0 0 1613312 Oct 26 1985 package/sdks/hermesc/win64-bin/hermesc.exe
```
Reviewed By: neildhar
Differential Revision: D35784619
Pulled By: cortinico
fbshipit-source-id: 334ed03c40f6838ae8365a1f1c6e86e38a8dbc59
Summary:
Fixes https://github.com/facebook/react-native/issues/33529 (note that I reproduced the bug on iOS too).
The bug comes from the fact that we were using `this._scrollMetrics.offset` to determine if the initial scroll was done. But sometimes it equals 0 even after the initial scroll is done, for example when the content does not fill the list. So I replaced it with `this._hasDoneInitialScroll`.
I believe that `this._hasDoneInitialScroll` was not used in the first place because it was introduced later (3 years ago vs 5 years ago for the original code).
The replacement correctly fixes the broken test case and the example given in the issue.
Then I had to update two test cases (rename the first and remove the second), that shows explicitly the broken behavior:
we have to simulate the initial scroll for the content to be adjusted, so when the content does not fill the view and the scroll cannot be executed, the content is not adjusted.
## Changelog
[General] [Fix] - Fix VirtualizedList with initialScrollIndex not rendering all elements when data is updated
Pull Request resolved: https://github.com/facebook/react-native/pull/33558
Test Plan:
- I added a broken test case based on the issue
- I tested with the RNTesterApp using the code example given in the issue
Reviewed By: ryancat
Differential Revision: D35503114
Pulled By: yungsters
fbshipit-source-id: 67bb75d7cf1ebac0d59127d0d45afbaa3167dcf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33673
This PR solves a TODO in a script that required a link to the documentation on the website.
## Changelog
[iOS][Changed] - Adding a link in a message for the users.
Reviewed By: cortinico
Differential Revision: D35742810
fbshipit-source-id: b7416a5bead5fa525ca69f05391b307195f5c987
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33645
With React 18, we now need to allow users on Fabric to opt-in for Concurrent Root.
This commit adds a new method that can be called on the ReactActivityDelegate
that can be used to set the `concurrentRoot` flag on the `initialProps` on the Render.
Changelog:
[Android] [Added] - Expose an API to enable Concurrent Root on Android
Reviewed By: mdvacca
Differential Revision: D35614879
fbshipit-source-id: 2de83e8115d3748c0346cdec6f31b2ab1f899478
Summary:
A couple of semver-minor/patch dependency bumps to reduce the number of distinct requirements across the repo.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D35748473
fbshipit-source-id: 270c9a1b828aba20e03ac27600eb3a6e4ce2f0ec
Summary:
Changelog:
[**General**][**Removed**] - Removed AsyncStorage usage from RNTester
As part of the "Lean Core" efforts (see https://github.com/react-native-community/discussions-and-proposals/issues/6) to remove outdated and/or unused components (status: https://gist.github.com/Simek/88a9f1a014a47c37f4fce3738864d2e1), this diff removes usage of the deprecated AsyncStorage API from RNTester.
RNTester is intended as a reference to showcase various components and APIs. The implications of the replacement of AsyncStorage in RNTester with in-memory management of state is a tradeoff of persistance to a lighter weight implementation and user predictable behavior.
1. Removed AsyncStorage from rn-tester
- removed Navigation and bookmark persisting from reducer
- moved JS Stalls and tracking to application state with context and reducer
2. Fixed InternalSettings Example bugs
Reviewed By: lunaleaps
Differential Revision: D35435562
fbshipit-source-id: a879787d8683a1c452e5b6b75a9e01f3ceadfe5d
Summary:
We've seen a couple of `EXC_BAD_ACCESS` crashes in [`RCTParagraphComponentAccessibilityProvider.mm:L125`](https://github.com/facebook/react-native/blob/52d8a797e7a6be3fa472f323ceca4814a28ef596/React/Fabric/Mounting/ComponentViews/Text/RCTParagraphComponentAccessibilityProvider.mm#L125), most likely explained by [RCTLocalizationProvider RCTLocalizedString] returning nil, which will happen in the case that a language pack has no entry for the input string.
This is a small defensive change to fall back to the input if there's no better alternative.
Changelog:
[iOS][Fixed] - `RCTLocalizationProvider` Fall back to input when no localization is available
Reviewed By: luluonet
Differential Revision: D35583786
fbshipit-source-id: e8ae6ff61518e105301e7e51f5d8f43290fb20bf
Summary:
Changelog: [Internal][iOS] Add validation log to the only static method in RCTUIManager, JSResponder
When all surfaces of an app has been fully migrated to Fabric, we don't expect `[RCTUIManager JSResponder]` to be called, so I'm expecting this API to be broken on Fabric and Bridgeless.
Reviewed By: RSNara
Differential Revision: D35723794
fbshipit-source-id: ec786946a33fca98c89e8cad0e0467bf45dc1735
Summary:
The current JSI implementation is converting a Symbol to String when creating a jsi Value.
Changelog: [General][Fixed]
Reviewed By: neildhar
Differential Revision: D35705825
fbshipit-source-id: 3bee0a02bb77643c6a33031b4d98ac9a7e126303
Summary:
This fixes an oversight where focusing fails if a C++ TurboModule is in the build graph. See line 391 in `rn_codegen_components` that does the same thing.
Changelog:
Internal
Reviewed By: mdvacca
Differential Revision: D35663755
fbshipit-source-id: d7d2e0109fd536586292d333b7d53b7b2e948d86
Summary:
Flow v0.176.1 has a bug when run in a non-lazy mode.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D35665720
fbshipit-source-id: a5fa691adf9ab5f5f4a67188fb3b52b4c69ee325
Summary:
Changelog: [Internal][SVC][JS] Refactor the JS base SVC StaticViewConfig to be easier to understand
This diff is a refactor that doesn't change any logic.
# Context
NativeViewConfigs are generated from RCTViewManager in iOS and ViewManager in Android.
StaticViewConfigs are partially generated from JS, and partially handwritten in JS.
We've noticed in at least 2 instances that engineers who add new props to NativeViewConfigs sometimes don't put props in the correct place for StaticViewConfigs, and thus they accidentally break the landblocking jest e2e test that validates the StaticViewConfigs matches the NativeViewConfigs.
The human error is mostly because PlatformBaseViewConfig.js was too nested to be easily understood. This diff refactors PlatformBaseViewConfig.js and adds clarifying comments.
Reviewed By: RSNara
Differential Revision: D35623775
fbshipit-source-id: 498a3daa812fa314821a2e7cb7d6f809900dbe3a
Summary:
Changelog: [Internal][Fixed] Fix StaticViewConfigs for Android, by removing iOS-only accessibilityLanguage prop
The accessibilityLanguage was a prop added to RCTViewManager, that is iOS-only, so it shouldn't exist in the SVCs for Android.
Reviewed By: RSNara
Differential Revision: D35630945
fbshipit-source-id: 7ed7f2619f73bb88babfbb207793d5415addaee6
Summary:
Changelog: [internal]
we have an issue where the moduleRegistry that the TM uses is released, adding this log to check if it's bc the bridge was released
Reviewed By: RSNara
Differential Revision: D35420922
fbshipit-source-id: 93c206b5afefeac3121df148940d9658736cb9d2
Summary:
Problem:
Current creation of ModuleConfig does a full copy of folly::dynamic object, which for large objects can cause 1000's of memory allocations, and thus increasing app's memory footprint and speed.
Fix:
Use std::move semantics to avoid copy of folly::dynamic, thus avoiding memory allocations.
## Changelog
[General] [Fixed] - Avoid full copy of large folly::dynamic objects by switching to std::move semantics
Pull Request resolved: https://github.com/facebook/react-native/pull/33621
Test Plan:
Compiled React Native for Windows
Consumed into Microsoft Excel App
Tested functionality through Microsoft Office Excel App
Viewed Memory Allocations in Debugger
Reviewed By: cortinico
Differential Revision: D35599759
Pulled By: RSNara
fbshipit-source-id: 095a961422cca4655590d2283f6955472f1f0410
Summary:
D34687371 (https://github.com/facebook/react-native/commit/7b5b114d578142d18bf4a7a5279b179a9ac8d958) unfortunately caused a regression with UIAutomator, where it would no longer be able to see any Views that have the ReactAccessibilityDelegate attached to them. This was because the delegate was changed to extend ExploreByTouchHelper which implements its own default AccessibilityNodeProvider, which does nothing in the case of a view without any virtual children.
This diff simply *only* uses the node provider if the view in question has virtual children, otherwise defaulting to the standard behavior from the View class.
Changelog:
[Android][Fixed] - Fixed issue where any node with an AccessibilityDelegate set (which was any node with any accessibility propoerty), was using ExploreByTouchHelper's built in AccessibilityNodeProvider, and not properly populating their AccessibilityNodeInfo's, leading to focus issues and issues with automated test services like UIAutomator.
Reviewed By: kacieb
Differential Revision: D35601320
fbshipit-source-id: 92e009c6e8b4ddcab860e2c91e6bd1a8f95359f0
Summary:
Update changelog for 0.68.1
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] - Update changelog for 0.68.1
Pull Request resolved: https://github.com/facebook/react-native/pull/33630
Reviewed By: dmitryrykun
Differential Revision: D35611623
Pulled By: cortinico
fbshipit-source-id: 2b5801810fc1c7416ad17859bf62c591b0be8c2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33611
Bumping the NDK to 23 to prevent build failures due to the NDK
using longer paths.
Changelog:
[Android] [Fixed] - Use NDK 23 only for Windows users.
Reviewed By: motiz88
Differential Revision: D35547459
fbshipit-source-id: 4e44c0b5fd8d1c559b04fb43eb4eeadc13943394
Summary:
Changelog:
[Android][Fixed] - Fix Extras usage in Android implementation of Linking.sendIntent()
The implementation of sendIntent() has a bug in a way it uses extras map.
From JS layer the API sends and array of map, where each map contains exactly 2 entries: {"key" -> "name_of_extra_to_use", "value" -> value_of_extra_to_use}
However Java parsing was just picking a random pair out of this map and was sending it as extra.
Most frequently the result was "value" -> value_of_extra_to_use in Intent instead of name_of_extra_to_use -> value_of_extra_to_use
This diff fixes the problem
Reviewed By: lunaleaps
Differential Revision: D35516496
fbshipit-source-id: 7da0a1cb3b8aa30463004dbb47008c83d8e95bd1
Summary:
This diff fixes a NullPointerException when disaptching events while the SurfaceMountingManager is being destroyed
changelog: [android] android
Reviewed By: cortinico
Differential Revision: D35559550
fbshipit-source-id: c07f74493384fb1b306338ec1bc8b96f1b6f1f41
Summary:
I guess it's the same since we're working on a `bool` but... this causes some compilation error.
Changelog:
[General][iOS] - Fix compilation warning in yoga
Reviewed By: Andrey-Mishanin
Differential Revision: D35438992
fbshipit-source-id: 22bb848dfee435ede66af0a740605d4618585e18
Summary:
This bumps ruby to the latest 2.7.x versions which includes bug fixes and 3 CVEs (https://www.ruby-lang.org/en/news/2021/11/24/ruby-2-7-5-released/)
## Changelog
[iOS] [Changed] - Bump ruby to 2.7.5
Pull Request resolved: https://github.com/facebook/react-native/pull/33485
Test Plan: no test plan, should just pass tests.
Reviewed By: cortinico
Differential Revision: D35116757
Pulled By: GijsWeterings
fbshipit-source-id: a8e96bfcc6086b70dac21aee24bae46fe6b072bb
Summary:
There is a simple typo - a missing space in to string concatenation in a deprecation message, the message pops up in a newly initialized RN68 project so seems worth fixing
## 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
-->
[Android] [Fixed] - Fix typo in gradle plugin deprecation message
Pull Request resolved: https://github.com/facebook/react-native/pull/33619
Test Plan:
Fixed via visual inspection (adding a single space character is luckily easy like that, yes that's perhaps over-confident but if you see the diff you will probably agree?)
cortinico
Reviewed By: cortinico
Differential Revision: D35577039
Pulled By: GijsWeterings
fbshipit-source-id: 84dc28ca0d0dcce89e1ca0c39ab0357b59396073
Summary:
Upgrades the React Native CLI to v8 alpha. This version removes manual linking configuration and a few other things, hence changes to the project configuration.
cc kelset fortmarek
## Changelog
[General] [Changed] - Upgrade RN CLI to v8 alpha
Pull Request resolved: https://github.com/facebook/react-native/pull/33610
Test Plan: CI green.
Reviewed By: rubennorte
Differential Revision: D35547624
Pulled By: cortinico
fbshipit-source-id: 4de9f280f9d1949c94057c32568b3fdfa4ee6a73
Summary: Changelog: [Internal] - Fix pointer event dispatch to also fire enter/leave for ancestors in the hit path. Compared the event order with web on the RNTester W3C pointer example
Reviewed By: appden
Differential Revision: D35403076
fbshipit-source-id: 726e45e49a901b1d97ad3e20f5898701fd1f763b
Summary:
The `override` keyword was used for some overriden methods and was not
used for others. This caused the `-Winconsistent-missing-destructor-override`
warning to show up, and since in some cases we build with `-Werror`, this broke
the build.
This diff adds the missing `override` keyword in a few places.
Changelog:
[Internal][Fixed] - Build issues
Reviewed By: kodafb
Differential Revision: D35513149
fbshipit-source-id: 92bca699f1be163189487d50c1050402df2ff038
Summary:
Changelog: [Internal][Bridgeless] Fix sticky headers for scrollviews by sending onScroll event to legacy RCTEventDispatcher
## Extra Context
FYI. <ScrollView> is the only Fabric component view that needs to send events via the legacy RCTEventDispatcher. Ideally, all component views should only use `ViewEventEmitter` to send events to JS and not use RCTEventDispatcher. This ScrollView does use ScrollViewEventEmitter, a subclass of ViewEventEmitter:
```
std::static_pointer_cast<ScrollViewEventEmitter const>(_eventEmitter)->onScroll([self _scrollViewMetrics]);
```
However, it also needs RCTEventDispatcher for animations using `Animated.event` for `useNativeDriver: true`. See [ScrollView.js](https://github.com/facebook/react-native/blob/370c65b94379a72e74f5dfd5b6202f282841a950/Libraries/Components/ScrollView/ScrollView.js#L1124-L1129).
Reviewed By: RSNara
Differential Revision: D35540277
fbshipit-source-id: a28535ed10cac8e003523ecda6080574fbb89b85
Summary:
This drastically improves `Animated.interpolate` performance when `inputRange` has a considerable amount of elements (~100 in my tests).
For instance in `ActivityIndicator` inside `react-native-paper`, the input has 144 elements https://github.com/callstack/react-native-paper/blob/main/src/components/ActivityIndicator.tsx#L170. `react-native-elements` has 9k stars, so I'm assuming this is widely used.
### Cause
The reason for the performance drop is that if we assume `n` to be the size of the range, calculating `'inputRange must be monotonically non-decreasing ' + arr` essentially calculates `arr.toString()` which has O(n) complexity.
Since it is recalculated in a for loop, we end up with `checkValidInputRange` having a O(n²) complexity. Which means ~10k operations if the array has a size close to 100.
## Changelog
[General] [Fixed] - Fix performance issue on Animated.interpolate with big input range
Pull Request resolved: https://github.com/facebook/react-native/pull/33598
Test Plan:
[Here's a repo](https://github.com/Almouro/AnimatedInterpolationRepro) reproducing the issue.
The branch `fix` includes the fix.
Clicking `Interpolate` runs:
```js
new Animated.Value(0).interpolate({
inputRange: Array(144)
.fill()
.map((_, i) => 1 / (i + 1))
.reverse(),
outputRange: Array(144)
.fill()
.map((_, i) => 1 / (i + 1))
```
Here's a comparison of JS thread perf before the fix and after the fix:
- on a Samsung J3 2017 (lower end)
- using Flipper and https://github.com/bamlab/react-native-performance)
- ` __DEV__` mode deactivated
- clicking the button and waiting 15s
| Before | After |
|----------|:-------------:|
|  | |
The error still throws if `inputRange` is incorrect:
<img width="517" alt="image" src="https://user-images.githubusercontent.com/4534323/162439219-6ce120ae-98e5-496b-899a-492978689d6d.png">
However if `__DEV__` mode is deactivated, no error is thrown
Reviewed By: yungsters
Differential Revision: D35507441
Pulled By: javache
fbshipit-source-id: 36ac49422f7a42d247130c42d12248b2be1232c6
Summary:
there are build errors happened when in [`generate_multiple_pod_projects`](https://blog.cocoapods.org/CocoaPods-1.7.0-beta/#multiple-xcodeproj-generation) mode and fabric is on. since we have multiple pod projects, there are something breaks.
### `-DRCT_NEW_ARCH_ENABLED=1` does not pass to `RCTAppSetupUtils.mm`
because `installer.pods_project` is targeting `Pods.xcodeproj` but not `React-Core.xcodeproj`. we should use ` installer.target_installation_results.pod_target_installation_results` to deal with `generate_multiple_pod_projects` mode.
### fatal error: 'CompactValue.h' file not found
```
In file included from /path/to/react-native/packages/rn-tester/build/generated/ios/react/renderer/components/rncore/Props.cpp:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Codegen/react/renderer/components/rncore/Props.h:13:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/ViewProps.h:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/YogaStylableProps.h:10:
/path/to/react-native/packages/rn-tester/Pods/Headers/Public/Yoga/yoga/YGStyle.h:16:10: fatal error: 'CompactValue.h' file not found
#include "CompactValue.h"
^~~~~~~~~~~~~~~~
1 error generated.
```
`Props.cpp` -> `YogaStylableProps.h` -> `YGStyle.h` -> `CompactValue.h`
[`CompactValue.h` is internal private header for Yoga pod](https://github.com/facebook/react-native/blob/4eef075a583224ec9da6bbc4b42bc52508eb31be/ReactCommon/yoga/Yoga.podspec#L54-L56) where `React-Codegen` project cannot access to.
~there are some solutions toward this problem. one way is to make other yoga headers as public headers. i am not sure whether this solution would introduce any side effects. so i only make necessary projects to search yoga private headers.~
Update: a solution is to expose all yoga headers publicly. however, CocoaPods will put all public headers to module umbrella header. this will break YogaKit (swift) integration because swift module doesn't support c++. my pr is trying to expose all yoga headers to `$PODS_ROOT/Headers/Public/Yoga/yoga`, but use custom `module_map` to control which headers should be exposed to the swift module. CocoaPods's custom module_map has some limitation where cannot well support for both `use_frameworks!` mode and non use_frameworks! mode. there's a workaround to use `script_phase` copying the umbrella header to right place.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `generate_multiple_pod_projects=true` and Fabric is on
Pull Request resolved: https://github.com/facebook/react-native/pull/33381
Test Plan:
verify with rn-tester
1. add `generate_multiple_pod_projects`
```diff
--- a/packages/rn-tester/Podfile
+++ b/packages/rn-tester/Podfile
@@ -5,7 +5,7 @@ platform :ios, '11.0'
# Temporary solution to suppress duplicated GUID error.
# Can be removed once we move to generate files outside pod install.
-install! 'cocoapods', :deterministic_uuids => false
+install! 'cocoapods', :generate_multiple_pod_projects => true, :deterministic_uuids => false
USE_FRAMEWORKS = ENV['USE_FRAMEWORKS'] == '1'
```
2. pod install and build rn-tester from xcode
Reviewed By: cortinico
Differential Revision: D34844041
Pulled By: dmitryrykun
fbshipit-source-id: 93311b56d8e44491307a911ad58442f267c979eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33546
This Diff does 2 things:
1. Removes all the remnant of the `find-node.sh` script. This allows React Native to stay agnostic from any other node manager
2. Introduces a way for the developers to specify which `node` executable they want to use, through a simple `.env` file.
## Changelog
[iOS][Changed] - This PR removes the `find-node.sh` scripts and replaces it with an `.xcode.env` file that is sourced by the script phases that needs it. The `.xcode.env` file is versioned: to customize a local environment, an unversioned `.xcode.local.env` can be used.
Reviewed By: cortinico
Differential Revision: D35317070
fbshipit-source-id: 4b400ba56aa2d574db563fa67b2008e1ddde1c59
Summary:
Allow modifying iOS image cache limits. Currently the image cache imposes some strict limits:
[NSCache.totalCostLimit](https://developer.apple.com/documentation/foundation/nscache/1407672-totalcostlimit?language=objc) of 20MB.
Single Image Size Limit of 2MB (bitmap size).
This may not be enough for applications that make heavy use of images. With this commit it is possible to fine tune them to the applications need.
This can be set for example in the App Delegate with:
```objc
RCTSetImageCacheLimits(4*1024*1024, 200*1024*1024);
```
This would increase the single image size limit to 4 MB and the total cost limit to 200 MB.
## Changelog
[iOS] [Added] - Allow modifying iOS image cache limits
Pull Request resolved: https://github.com/facebook/react-native/pull/33554
Test Plan: There is no easy way to test this except adding the above snippet and checking via break points that the new limits are used.
Reviewed By: cipolleschi
Differential Revision: D35485914
Pulled By: cortinico
fbshipit-source-id: 646cf7cab5ea5258d0d0d0bce6383317e27e4445
Summary:
This PR updates the GitHub actions uses in the repository workflows.
## Changelog
N/A
Pull Request resolved: https://github.com/facebook/react-native/pull/33595
Test Plan: Run the workflows.
Reviewed By: rickhanlonii
Differential Revision: D35495697
Pulled By: cortinico
fbshipit-source-id: a41a83dc61f199f9acbc0ce28d6a23fafc94a99c
Summary:
As we introduced KGP inside `ReactAndroid` (cc ShikaSD), we now need to specify a version for it (as users will consume that build on Android New Architecture.
Currently, the version is loaded in the RN `rootProject` which is not available on user's project. I'm cleaning this up.
## Changelog
[Internal] - Do not specify a Kotlin version in the RN rootProject
Pull Request resolved: https://github.com/facebook/react-native/pull/33589
Test Plan:
Tested on a nightly version with
```
npx react-native init RNNightly --version nightly
```
Reviewed By: mdvacca
Differential Revision: D35476777
Pulled By: cortinico
fbshipit-source-id: 5a819ef5fa9a6886d7b7b683f31d59cb05a49f29
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.70.1](https://github.com/facebook/metro/releases/tag/v0.70.1).
Changelog:
[General] Update direct Metro dependencies to 0.70.1
Reviewed By: robhogan
Differential Revision: D35462164
fbshipit-source-id: 5daeb28e60f1babb78c5029e673926c76de65491
Summary:
This is a follow up to my previous diff. It applies the same customization for M1 users to the :ReactAndroid:hermes-engine build.
The two diffs are split so the first one can be cherry-picked into 0.68.1 if needed.
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468658
fbshipit-source-id: c07822f6708f872456971378f44257f6c1e967ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33588
Currently users on M1 machine can't use the New Architecture correctly as they will get build failures when building the native code.
This Diff fixes it by automatically recognizing the host architecture and switching to NDK 24 if user is runnign on `aarch64`
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468252
fbshipit-source-id: b73f5262b9408f04f3ae4fd26458a4d17c1ec29a
Summary:
Jest 28 will error if only a string is returned from a transfomer, it needs to be an object of `{code: string, map?: object}`. Returning an object has been supported since https://github.com/facebook/jest/pull/2290, released in Jest v20.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Return object from Jest preprocessor
Pull Request resolved: https://github.com/facebook/react-native/pull/33576
Test Plan: Green CI?
Reviewed By: motiz88
Differential Revision: D35426748
Pulled By: robhogan
fbshipit-source-id: 3edb79b62b2d34274be192061817d3fcd8a7ba17
Summary:
This diff adds more folders to the cleanAll gradle task,
a utility task that gets invoked when cleaning the whole project.
Just realized that after the Hermes integration project, we never
added those folders that now need to be cleaned up as well.
Changelog:
[Internal] [Changed] - Add further folders to the cleanAll Gradle task
Reviewed By: sshic
Differential Revision: D35444265
fbshipit-source-id: ee4ded9a4ee9554b5e3f0f8cb85f60a4797e9010
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33581
We currently have some code on the RN Gradle Plugin that we need to ship.
There are both bugfixes needed for RN 0.68.1 and for the current nightly
(therefore needed for RN 0.69).
I've verified that this works on a fresh RN 0.68.0 install with `npm pack`
and triggering a build on a fresh setup from app template, with newArchEnabled set to true.
Changelog:
[Android] [Changed] - Bump React Native Gradle plugin to 0.0.6
Reviewed By: rubennorte
Differential Revision: D35439444
fbshipit-source-id: 662b2211c44b261e3e3c9cddc946107cfb495c79
Summary:
While testing with the RN Nightly versions, I realized we pushed two changes
recently that are not working fine with the gradle setup of our users.
That's becuase we're referencing the `rootProject` directly.
`rootProject` should never be used directly as it resolves to:
- The root of the git repo of `react-native` when building the RN project (so
`./ReactCommon` exists there).
- The /android folder of users' project when building an app that uses RN (so
`./ReactCommon` does not exists there).
Changelog:
[Android] [Fixed] - Do not use `rootProject` directly in Gradle scripts
Reviewed By: sshic
Differential Revision: D35444967
fbshipit-source-id: be0508480a08224302168804b6feb52fd604d8db
Summary:
I'm just adding a macro passing the NODE_MODULES_DIR to the NDK build.
This will make easier to import external libraries for our users.
Changelog:
[Internal] [Changed] - Specify a NODE_MODULES_DIR inside the NDK config for the Android template
Reviewed By: cipolleschi
Differential Revision: D35451821
fbshipit-source-id: 5d79359a1610f2de4ec2d50a78b4c930458185d8
Summary:
Changelog: [Fabric][iOS] Fix: Make RCTSurfacePresenter weakly retain its observers
There is retain cycle because RCTSurfacePresenter is keeping an array of RCTSurfacePresenterObserver, which is strongly retaining the class that owns this RCTSurfacePresenter.
This diff makes RCTSurfacePresenter weakly retain observers instead.
Reviewed By: RSNara
Differential Revision: D35439589
fbshipit-source-id: ddc7813976b543de12af6173b2f1b31c69b043a8
Summary:
Changelog:
[iOS][Changed] - Update `PushNotificationIOS.checkPermissions` to include iOS 10+ notification settings.
`PushNotificationIOS.checkPermissions` is currently limited to only return:
* alert :boolean
* badge :boolean
* sound :boolean
That's has been a number of new properties since iOS 10 that we should support to improve pushability signal. This diff updates the logic to support 4 new available settings:
* critical :boolean,
* lockScreen :boolean,
* notificationCenter :boolean,
* autorizationStatus: number,
Reviewed By: philIip
Differential Revision: D35386762
fbshipit-source-id: 07c87de024756bc95a2c822ac35437ec76b3c903
Summary:
Annotations inside of destructuring (e.g. `const [foo: number] = ...`) are invalid Flow syntax. We currently ignore them, and in the future will error on them (D35304565).
Remove them using the codemod from D35390352
Locally changed WWW_ROOT, FLOW_ROOTS, and excluded paths in scripts/typedjs/flow/runner.config.js (e.g. P492224584) - and then
```
scripts/typedjs/flow/runner codemod removeAnnotationsInDestructuring ~/fbsource/xplat/js
```
formatting files didn't work, so do it manually
Changelog: [Internal]
drop-conflicts
Reviewed By: fred2028
Differential Revision: D35419146
fbshipit-source-id: e4c05506ceec11afcc8e92f13f732510ebabdbc3
Summary:
changelog: [internal]
this never fired, so it's not the cause of the nil moduleRegistry issue
Reviewed By: christophpurrer
Differential Revision: D35419873
fbshipit-source-id: 45693d3aa97d9efed2fe5085c281b57f1629764d
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33539
As we now provide `hermes-executor-debug` OR `hermes-executor-release` based on which version of RN we're building, we need to provide a variant aware AAR.
Changelog:
[Internal] [Changed] - Setup multi-variant publishing for React Native Android
Reviewed By: ShikaSD
Differential Revision: D35289444
fbshipit-source-id: ffccd2089dc2eb50ea8c08ed10d8fd9816f9efb7
Summary:
This adds the option for a TurboModule spec to use a "Cxx" suffix to unblock additional capabilities. This extends the pattern where TurboModules can have an "Android" or "IOS" suffix to exclude codegen for the other platform. When in `cxxOnly` mode, the parser will allow function return types (and additional features will be added over time).
Changelog:
[General][Added] C++ TurboModule methods can return functions
Reviewed By: christophpurrer
Differential Revision: D35364346
fbshipit-source-id: 768eb0ec2a1cbe3e458466064247d7e7f01135ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33560
X-link: https://github.com/facebook/hermes/pull/720
Turn on ICF for the build whenever it is available. This requires us to
link with LLD, which is only the default starting in NDK r23, so
manually specify LLD for the Android build.
Also turn on LTO for the CircleCI build, so we generate highly
optimised binaries for distribution.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D35344254
fbshipit-source-id: 64b37e6a7817a7b7826cc7480468367b95d63c61
Summary:
We currently enable the debugger by default on all platforms except
Android. On Android, we then manually enable the debugger in debug
builds. Instead, change it so the debugger is manually disabled in
release builds, to simplify the setup.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D35347444
fbshipit-source-id: a97bba0c65c61c211cf9e361e7091343a2c6416f
Summary:
Changelog: [Internal]
Working towards removing configure.py, switch to invoking CMake directly.
Note that with this change, ninja is no longer a requirement, since it will use the default build system on the host.
Reviewed By: cortinico, jpporto
Differential Revision: D35342731
fbshipit-source-id: f04a367bda9fb22642f17e7c2c5cf493e44013d3
Summary:
It is not necessary to call node via yarn. Instead with this commit node is called directly (windows aware). This enables builds on systems that don't have yarn installed.
Fixes https://github.com/facebook/react-native/issues/33525
## Changelog
[Android] [Fixed] - Don't require yarn for codegen tasks
Pull Request resolved: https://github.com/facebook/react-native/pull/33530
Test Plan:
1. react-native init test
2. cd test
3. enable newArchEnabled=true (gradle.properties)
4. enable enableHermes: true (build.gradle)
5. react-native run-android (when the yarn is not installed on the system)
(I have not tested or verified if this works on windows build machines)
Reviewed By: sshic
Differential Revision: D35279376
Pulled By: cortinico
fbshipit-source-id: 430e4a7bcdec7d5377efac747f6b935d634451cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33538
This Diff is a revert of this other diff: D34352049 (https://github.com/facebook/react-native/commit/802b3f778b4d2ecd22882b371a84293421558b8a).
Following a discussion with the Open Source Community, the removal of `find-node.sh` script will break some configurations that leverages different node managers.
The landed diff will block the release of version 0.69, that's the reason why we are reverting it.
However, we still want to abstract RN from knowing which node manager the user is going to use. After discussing with the community, we will deprecate the usage of this script and we will move toward a configurable `.xcode.env` file that developers can configure on their own. The task for this is tracked here: T115868521.
## Changelog
[Internal][Removed] - Reintroduce the old `find-node.sh` script to prevent broken builds for some users
Reviewed By: cortinico
Differential Revision: D35280778
fbshipit-source-id: 7a0b269af207e13998fd85c0c4839e75028cda65
Summary:
Other jobs in the React Native Circle config use underscores as the delimiter, so let's standardize on that.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35301098
fbshipit-source-id: 4c720db44faa8c42dece9dccc592b53330d42cc4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33549
When building Hermes from source, use arbitrary hermes-engine.podspec to ensure correct Hermes tag is used by CocoaPods.
Without this change, CocoaPods will check out the `v0.11.0` git tag from the `facebook/hermes` git repository.
Ideally, this change should be done in the original `hermes-engine.podspec` in `facebook/hermes`. For now, use the arbitrary copy until the canonical Pod has been updated.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35300595
fbshipit-source-id: be4b1225eb2c2a88958cd9e5e98cb8efed343bad
Summary:
When Hermes is used, and if it is built from source on Circle CI, the macos executors can run out of storage space.
Earlier, we solved this issue in the iOS unit test jobs by splitting them into build/test pairs. In the case of test_ios_rntester, there is no convenient way to split the job.
Since test_ios_rntester does not require the use of the iOS simulator, we can go ahead and delete it from the image at run time in order to free up some space and allow the job to finish when Hermes is built from source.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35297994
fbshipit-source-id: a0cddba2fc2900813fecc63eaf23d53e5b8f6e92
Summary:
Split test_ios job into build_ios and test_ios_unit. This allows us to build Hermes from source in `build_ios`, and to subsequently run unit tests in `test_ios_unit` in a fresh macOS machine. Otherwise, the Circle CI machine may run out of space when building the RNTester app.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35295708
fbshipit-source-id: 16833dfec517f6237d125f3e06ec1efa3f967b08
Summary:
Print logs during `pod install` to clarify when Hermes is being used with RNTester and/or iOS React Native apps.
This changeset should not result in any change to the behavior of `pod install`, other than adding logs to CocoaPods' stdout.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294993
fbshipit-source-id: 55b6115d9f49c311c34ad3cb07346b2f97adcbf9
Summary:
In preparation for the upcoming migration towards using Hermes by default, Circle CI jobs will only test using Hermes. With this, we no longer have a matrix where test_ios runs once with JSC and once with Hermes. Instead, there is a single `test_ios_unit` job that runs with Hermes.
This change is necessary in order to avoid unnecessary complex Circle CI config files in the JSC->Hermes transition.
The CocoaPods cache key needs to be updated to avoid using a stale cache. Keys v4-pods and v5-pods were used during tests and may already be present in the Circle CI cache for the next two weeks, so we must skip ahead to v6-pods-*
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35299690
fbshipit-source-id: 96c146c8b114c3874c64a8d7b6721c90acac0c33
Summary:
ModuleDataCleaner.cleanDataFromModules(**ReactContext**) is just like ModuleDataCleaner.cleanDataFromModules(**CatalystInstance**). However, one key difference is that this new method is bridgeless mode compatible. CatalystInstance doesn't exist in bridgeless mode.
Changelog: [Android][Added] Introduce ModuleDataCleaner.cleanDataFromModules(ReactContext)
Reviewed By: sshic
Differential Revision: D35286939
fbshipit-source-id: 1c09a3b34add88f848eab43b42b39ab624f0818b
Summary:
## Rationale
The CatalystInstance exposes a public API that returns a list of all instantiated NativeModules: [CatalystInstance.getNativeModules()](https://www.internalfb.com/code/fbsource/[d9cd2e5dd41fc3e3022bfb777c8b31c92af8c537]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/bridge/CatalystInstance.java?lines=73).
This enables a use-case: process all NativeModules that conform to a particular interface, to, for example, remove sensitive data before logging out.
## Changes
This diff moves that CatalystInstance.getNativeModules() API into the ReactContext. This allows us to migrate NativeModules leveraging this use-case off of ReactContext.getCatalystInstance(), which makes them bridgeless-mode compatible.
Changelog: [Android][Added] Introduce ReactContext.getNativeModules()
Reviewed By: sshic
Differential Revision: D35286940
fbshipit-source-id: 1b64351aa3f65ee59e6438a7a95974e219ccc69c
Summary:
Update C++ TurboModule codegen to wrap nullable types in `std::optional` whereas before the conversion would cause a crash.
Changelog:
Internal
Reviewed By: mdvacca, nlutsenko
Differential Revision: D35299708
fbshipit-source-id: 7daa50fe8b16879c5b3a55a633aa3f724dc5be30
Summary:
Use Circle CI's new generation macOS resource class in all iOS and macOS jobs. This resource provides additional resources and should reduce execution time in our iOS and macOS jobs by about 40-50%.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294738
fbshipit-source-id: 817a8f80e774a11d23d9466d938064ac41625256
Summary:
Use Circle CI's "xlarge" resource class in all Android jobs. This resource provides additional resources and should reduce execution time in our Android jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294718
fbshipit-source-id: 53a0df2926011b5ac75b2671733a1b1f881150fd
Summary:
Use Circle CI's "xlarge" resource class in all Node jobs. This resource provides additional resources and should reduce execution time in our Node jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294648
fbshipit-source-id: cfc175b4b327ca02d7094688f870cfea757915e6
Summary:
When downloading Hermes from source on Circle CI, the process will fail because Circle CI macOS machines do not have wget installed.
Since curl can serve the same purpose and it is already part of the installed software on macOS machines, we can use curl in place of wget.
This change ensures Hermes can be built from source on Circle CI jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294868
fbshipit-source-id: bb099b603ef64205d45b833882852b2f4d6060ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33535
Hack to support Kotlin functions in Buck compilation: adds Kotlin stdlib as a dependency to make sure upstream targets include Kotlin jvm internal classes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35284430
fbshipit-source-id: 0d29ad30386514c8df5376d0a6809d3105f0cd0f
Summary:
This are the two package upgrade required for this package to run with ESLint 8
## Changelog
[JavaScript] [Changed] `react-native-community/eslint-config` to work with ESLInt 8
Pull Request resolved: https://github.com/facebook/react-native/pull/33448
Test Plan: Try the package with ESLint 8
Reviewed By: yungsters
Differential Revision: D35012075
Pulled By: GijsWeterings
fbshipit-source-id: 7de68c770fb31fe8ec06c805afea9b5f3a7a7294
Summary:
Restore `nightly` jobs to green by removing `hermesc` from `react-native` package.
As a result, when building Hermes from source on developer's machines, the Hermes compiler will need to be built as well.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35289425
fbshipit-source-id: 2a058f714d670fbb4d0486e7280cab7dd923fc63
Summary:
As users can toggle `enableSeparateBuildPerCPUArchitecture` to create a split APK, once that is off, the `-PreactNativeArchitecture` is not correctly considered when building the local module.
This will make sure that, if users have `enableSeparateBuildPerCPUArchitecture` set to `false`, their
app is building the local `app_modules` only for the requested architectures.
Practically, users invoking with `--active-arch-only` might experience a build failure if they have a fully clean environment (would be forced to do a full build before using `--active-arch-only`). This addresses this scenario.
Changelog:
[Android] [Fixed] - Template: Specify abiFilters if enableSeparateBuildPerCPUArchitecture is not set.
Reviewed By: ShikaSD
Differential Revision: D35250700
fbshipit-source-id: 4e555888636cf182495fab2b4a562d93a70b9e66
Summary:
The getAll() method of the [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData) interface returns all the values associated with a given key from within a FormData object.
## Changelog
[General] [Added] - Add getAll function to FormData class for getting all parts containing that key. This is also available in web API.
Pull Request resolved: https://github.com/facebook/react-native/pull/32444
Test Plan: New test added in FormData-test.js
Reviewed By: lunaleaps
Differential Revision: D31798633
Pulled By: cortinico
fbshipit-source-id: ef29bb54e930532a671adbe707be8d1a64ff0d82
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.69.1 to 0.70.0.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.70.0
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D35258405
fbshipit-source-id: f46f28c177f9f7fdaf2e680ab5c6c350cee4308d
Summary:
This adds an unnecessary dependency between two NPM package which can be avoided. See https://github.com/reactwg/react-native-releases/discussions/17#discussioncomment-2452813
for context.
Changelog:
[Internal] [Changed] - react-native-gradle-plugin should not depend on react-native-codegen NPM package
Reviewed By: dmitryrykun
Differential Revision: D35279729
fbshipit-source-id: f18f79809f115f28203ac0a843fafead63528904
Summary:
Aligns naming with `JWritableMapBuffer` and other fbjni classes to indicate that it is a JNI binding.
Changelog: [Internal] - Rename C++ part of ReadableMapBuffer to JReadableMapBuffer
Reviewed By: mdvacca
Differential Revision: D35219323
fbshipit-source-id: a7eb644a700a35dc94fa18e4fb3cc68f2cfa3e99
Summary:
Updates `ReadableMapBuffer` to conform to `MapBuffer` interface, to allow interchangeable use of `Readable/WritableMapBuffer` in the code.
Notable changes:
- MapBuffer.Entry getters are now represented as Kotlin properties and appended `Value` suffix (e.g. `entry.getInt()` becomes `entry.getIntValue()` in Java, or `entry.intValue` in Kotlin)
- `ByteBuffer` is imported in constructor instead of on demand. This method doesn't copy the data as the bytes are read directly from native heap, and benchmarking a 500-byte `MapBuffer` shows no difference in import speed.
- Internal logic of `ReadableMapBuffer` uses `UShort` kotlin type for key retrieval, for more correct representation of values.
- Explicit exception throws are replaced with `require` and `check` methods for `IllegalArgumentException` and `IllegalStateException` (default FB conversion).
The change also updates `ReadableMapBuffer` usages to `MapBuffer` interface where possible (virtually everywhere except JNI methods).
Changelog: [Android][Changed] - Adopt `MapBuffer` interface for `ReadableMapBuffer`
Reviewed By: mdvacca
Differential Revision: D35218633
fbshipit-source-id: 515dd974c27b2978ade325b2e1750ab8f068a20a
Summary:
Creates a `WritableMapBuffer` abstraction to pass data from JVM to C++, similarly to `ReadableMapBuffer`. This part also defines a Kotlin interface for both `Readable/WritableMapBuffer` to allow to use them interchangeably on Java side.
`WritableMapBuffer` is using Android's `SparseArray` which has almost identical structure to `MapBuffer`, with `log(N)` random access and instant sequential access.
To avoid paying the cost of JNI transfer, the data is only transferred when requested by native `JWritableMapBuffer::getMapBuffer`. `WritableMapBuffer` also owns it data, meaning it cannot be "consumed" as `WritableNativeMap`, with C++ usually receiving copy of the data on conversion. This allows to use `WritableMapBuffer` as JVM-only implementation of `MapBuffer` interface as well, e.g. for testing (although Robolectric will still be required due to `SparseArray` used as storage)
Changelog: [Android][Added] - MapBuffer implementation for JVM -> C++ communication
Reviewed By: mdvacca
Differential Revision: D35014011
fbshipit-source-id: 8430212bf6152b966cde8e6f483b4f2dab369e4e
Summary: Changelog: [Internal] Add another example for testing out the pointer events spec
Reviewed By: vincentriemer
Differential Revision: D35116565
fbshipit-source-id: 5f0cfeb871ae55071549c2289782401807f55515
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33518
Changelog: [Internal]
When building with buck2, `setup_env_vars.sh` cannot be found. exporting setup_env_vars.sh and adding it as a dep to `write_to_json` fixes it.
Reviewed By: d16r
Differential Revision: D35188154
fbshipit-source-id: e1e1be4c83a57e443a181efaf1af3e6c8e6452f9
Summary:
These `constexpr` template variables make it really easy to test for bridging conversion to/from the specified types. The unit tests for this actually uncovered a bug with incompatible casts from lvalue references that was fixed in this diff as well.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D35105398
fbshipit-source-id: 6e5f16e44ba99b296284970bf32c1f2f47201391
Summary:
I've noticed that some builds are sporadically failing as `configureCMake*` is runnign before
`preBuild`. When this happens, some 3rd party library folder won't exist yet and the build will
essentially fail. This is introducing flakyiness that this commit is essentially reducing
Changelog:
[Internal] [Changed] - Reintroduce missing dependency between configureCMakeDebug and preBuild
Reviewed By: ShikaSD
Differential Revision: D35213932
fbshipit-source-id: bfb4173843349ca4c1699d584bf0c915ab7b35cf
Summary:
Changelog: [iOS][Internal] Add api to disable New validation reporting
Previously `RCTNewArchitectureValidationSetEnabled` was not set to false once it was set to true when a use is in app-wide Bridgeless mode.
This resulted it being in an incorrect state if a user:
1) Opens RN while in app-wide Bridgeless enabled
2) Logout
3) Re-login as another user without killing the app.
The fix is to set `RCTNewArchitectureValidationSetEnabled(RCTNotAllowedValidationDisabled)` in FBReactModule initialization.
Reviewed By: RSNara
Differential Revision: D35233335
fbshipit-source-id: 82a2c2ed030df5d68267a40b14322e652eb29e96
Summary:
Changelog: [iOS][Internal] Refactor: Migrate Logbox surface initialization to Fabric when available, in Bridge and Bridgeless modes
# Why
This diff main purpose is to add `RCTErrorNewArchitectureValidation(RCTNotAllowedInAppWideFabric)` in `RCTSurface`, to ensure Paper surfaces are never created in FBiOS.
# The Situation
Before this diff, in Bridged Fabric, `[RCTLogbox show]` initializes a Paper `RCTSurface`, [using `[RCTLogBoxView initWithWindow]`](https://github.com/facebook/react-native/blob/main/React/CoreModules/RCTLogBoxView.mm#L46))
In this diff, in Bridged and Bridgeless Fabric, `[RCTLogbox show]` initializes a Fabric `RCTFabricSurface`.
Before this diff, in Bridgeless Fabric, RCTLogBox posts a "CreateLogBoxSurface" notification to RCTInstance.
In this diff, the notification hack is replaced by the same `RCTFabricSurface` initialization above.
Behavior is the same.
Reviewed By: RSNara
Differential Revision: D35177311
fbshipit-source-id: 6de418af8a01f914c9a806bb8d74915015f9087a
Summary:
Changelog: [iOS][Internal] Remove RCTNotAllowedInBridgeless validation for RCTRegisterModule
In the TurboModule system, `RCTRegisterModule` gets called for all `RCTBridgeModules` that calls `RCT_EXPORT_MODULE()` and it works fine in Bridgeless mode.
Reviewed By: RSNara
Differential Revision: D35203039
fbshipit-source-id: 8ae2be4487fe21653a7f1628fa92606a7d36d467
Summary:
In short, if an RCTEventDispatcher observer sends an event on the same thread that the observer was initially on, there will be a deadlock due to `sendEvent` already having the lock active on the `_observers` NSHashTable. An example where this occurred was when we had react-native-gesture-handler trigger an animated event, which then triggered an event on the underlying component being animated as a result of it being an observer on the animation event. Since this all occurred on the main thread, we ended up with a deadlock and the app froze.
To prevent this scenario, I used a `NSRecursiveLock` for _observersLock to be able to dispatch events on the same thread from observers.
joebernard
## 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] [Fix] - Prevent deadlock when dispatching events from observers on the same thread.
Pull Request resolved: https://github.com/facebook/react-native/pull/33490
Test Plan:
Not sure if there are any tests present for sending events with RCTEventDispatcher already in place, but In regular app usage this solution has proved to be a viable and stable option so far and has prevented the deadlock from occurring.
This would still be thread-safe since we are now allowing the event to be sent through observers on the same thread the initial event was dispatched on. The only issue I could see here is the behavior of sending an event could be changed.
Reviewed By: RSNara
Differential Revision: D35118752
Pulled By: charlesbdudley
fbshipit-source-id: 7e93a8d49841e001b235a437ccca1e072dcc7ab1
Summary:
Changelog: [Fabric][iOS] Allow CKComponents to embed Fabric surfaces too.
Previously RCTSurfaceHostingComponent, a CKComponent, could only initialize the legacy RCTSurface. Now it can initialize RCTFabricSurface too, when a RCTSurfacePresenter is passed in.
Reviewed By: RSNara
Differential Revision: D35163595
fbshipit-source-id: e11a9334b0282e0728a38cc1c96de48a694e9e3d
Summary:
Changelog: [iOS][Internal] Refactor: Make ComponentKit hosting ReactNative use RCTSurfaceProtocol instead of Paper's RCTSurface
Replace RCTSurface with id<RCTSurfaceProtocol>, because both RCTFabricSurface and RCTSurface conforms to RCTSurfaceProtocol.
Reviewed By: RSNara
Differential Revision: D35163498
fbshipit-source-id: ba54c9bf5949313cd501bd185975fe96d4770961
Summary:
Changelog:
Before diff, we always hit assert the `'self.component' must be called on the main thread` assertion whenever we open a surface with a RCTSurfaceHostingComponent (React Native surface inside a CKComponent).
Reviewed By: RSNara
Differential Revision: D35152263
fbshipit-source-id: 1b06ca9d2ae7ca211120b71504e2eeaabaaf3bfd
Summary:
Changelog: [iOS][Internal] Rename RCTNotAllowedInFabric to RCTNotAllowedInAppWideFabric
Clarify that methods marked with `RCTNotAllowedInAppWideFabric` are only NOT available when Fabric is app-wide (which is necessary for app-wide Bridgeless mode). These methods may still be called in apps with legacy pre-Fabric surfaces.
Reviewed By: RSNara
Differential Revision: D35194789
fbshipit-source-id: e16fa54d22ea67be995e93f6ff60567a117398be
Summary:
Adding more context for event dispatching process in systrace.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D35208257
fbshipit-source-id: 4a70e15a0074d4a53a895066e6fa1e60a6ebda0d
Summary:
The Array appended to FormData must be transmitted in the form of a string.
However, it is treated as a file object and transmitted, because `typeof Array` is `'object'` too
In network
```js
form.append('array_name', ['a', 'b', 'c'])
// Browser
// Content-Disposition: form-data; name='array_name';
// a,b,c
// ReactNative
// Content-Disposition: form-data; name='array_name';
//
```
## Changelog
[General] [Fixed] - The Array appended to FormData is transmitted as a string
Pull Request resolved: https://github.com/facebook/react-native/pull/32815
Test Plan: Added test case
Reviewed By: lunaleaps
Differential Revision: D33369594
Pulled By: charlesbdudley
fbshipit-source-id: 0b5219a2c9f73cf16665dc417cceb4481428ad4e
Summary:
As per commit: https://github.com/facebook/react-native/commit/4f3b17412018a10f9293247c802598d2b94a844b which states that "React Native requires that the RootView id be managed entirely by React Native, and will crash in addRootView/startSurface if the native View id isn't set to NO_ID."
This behaviour can not be guaranteed in **hybrid** apps that have a native android layer over which ReactRootViews are added and the native views need to have ids on them in order to work. **The control of views can jump back and forth between native android and react-native (fabric). As the ReactRootView is added to ViewGroups (or layouts) in Android Fragments and Activities, they contain ids on their views which might get passed down to the reactRootView by features like DataBinding**
Hence this can cause unnecessary crashes at runtime for hybrid apps even when they are not changing the id of the reactRootView object they are adding to their ViewGroups.
Our app is a hybrid app that uses both native android and react-native on different screens and on one such screen that has a Fragment adding a ReactRootView to its FrameLayout to render native android views to render in ReactNative, this crash occurs on pressing the back button as well as on unlocking the screen while staying on the same screen.
The app was running fine on more than a 100 million devices on React Native 0.63.4 but after updating to 0.67.2, that features this commit, it crashes on the very first device it was tested on.
Refer to the issue: https://github.com/facebook/react-native/issues/33121 for more information on the crash
The fragment in which this issues arises is like this:
```binding.frameLayout.addView(getReactRootView())```
where getReactRootView() is like this:
```
private var mReactRootView: ReactRootView? = null
private var mReactInstanceManager: ReactInstanceManager? = null
mReactRootView = ReactRootView(context)
if (activity != null) {
val application = activity?.application
if (application is MainApplication) {
mReactInstanceManager = application.reactInstanceManager
}
}
fun getReactRootView():View?{
return mReactRootView
}
```
So converting this to a soft exception such that pure react-native devs can still see the error while hybrid apps continue to run without crashes.
### Snippet of the change:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
## Changelog
[GENERAL] [ADDED] - A ReactSoftException log instead of a direct exception being thrown:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
[GENERAL] [REMOVED]- Directly throwing an exception even when the code is not responsible for this issue:
```
if (getId() != View.NO_ID) {
throw new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID.");
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33133
Test Plan:
This crash is hard to reproduce but when it occurs, this is the only way to fix it.
If any app used to crash with this exact error, it will no longer crash but show an error log in Logcat for developers to be informed about the issue.
Reviewed By: ShikaSD
Differential Revision: D34304212
Pulled By: cortinico
fbshipit-source-id: f0eaeef2e905a6e0587df088b43cc49cabda397a
Summary:
Add cached yarn deps
Seeing the message below during development, packages are outdated
```
=============
WARNING: You are currently running a version of TypeScript which is not officially supported by typescript-eslint/typescript-estree.
You may find that it works just fine, or you may not.
SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.1.0
YOUR TYPESCRIPT VERSION: 4.5.4
Please only submit bug reports when using the officially supported version.
=============
```
Update packages below to "5.8.0" should fix this
- typescript-eslint/eslint-plugin
- typescript-eslint/parser
## 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] - Bump dependencies version for eslint-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/32800
Test Plan: `yarn lint` with no error
Reviewed By: cortinico, yungsters
Differential Revision: D33331050
Pulled By: charlesbdudley
fbshipit-source-id: 27bf9b9b0536545ebfe4614ed210255df65aa2cd
Summary:
This PR fixes RTTI (run-time type information) for ShadowNodeWrapper and ShadowNodeListWrapper classes, i.e., calls to dynamic_cast and dynamic_pointer_cast that are called via JSI's getHostObject calls.
The fix is simply to add a so-called "key function" in a form of virtual destructor. Key functions needs to be a virtual non-pure and non-inlined functions that points the compiler as to which library contains the vtable/type information for a given class (see https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable and https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries)
Without the "key function", calls to dynamic_cast for ShadowNodeWrapper instances won't work across library boundaries because the class will have separate definitions in each separate library, therefore objects created in one of those libraries won't be recognized as the same type by the other library. This has been a problem in reanimated and gesture-handler libraries where we call `object.getHostObject<ShadowNodeWrapper>(rt)` (this is a method from JSI) in order to access ShadowNode instance from a handle we have in JS. I think, this issue is going to be relevant to more libraries that cope with view instances. In this scenario, we have a separate library, say "libreanimated.so" that calls to `getHostObject` which is an inline function that calls `dynamic_cast` for the `ShadowNodeWrapper` class. On the other hand, the instances of `ShadowNodeWrapper` are created by the code from `libreact_render_uimanager.so`. Because of that `dynamic_cast` fails even though it is called on instance of `ShadowNodeWrapper` because the class has separate vtable/type info: one in `libreanimated.so` and one in `libreact_render_uimanager.so` (by "fails" I mean that it actually returns `nullptr`).
This problem has been documented here: https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries where the solution is for the class to have a so-called "key function". The key function makes it so that compiler sees that one of the implementation for a given class is missing and therefore can safely assume that a vtable/type info for a given class is embedded into some library we link to.
This change adds a virtual destructor that is declared in the header file but defined in file that gets compiled as a part of `libreact_render_uimanager`. As a result, the compiler only creates one vtable/type info and calls to dynamic_cast works as expected in all libraries for `ShadowNodeWrapper` and `ShadowNodeListWrapper` classes.
This issue would only surface on Android, because on iOS all libraries by default are bundled together via Pods, whereas on Android each library is loaded separately using dynamic loading.
## Changelog
[Fabric][Android specific] - Fix dynamic_cast (RTTI) for ShadowNodeWrapper and similar classes when accessed by third-party libraries.
Pull Request resolved: https://github.com/facebook/react-native/pull/33500
Test Plan:
1. In order to test this you need to add a library that'd include `<react/renderer/uimanager/primitives.h>` (i.e. use this branch of reanimated library: https://github.com/software-mansion/react-native-reanimated/tree/fabric)
2. After compiling the app inspect libreact_render_uimanager.so and libreanimated.so artifacts with `nm` tool
3. Notice that symbols like `vtable for facebook::react::ShadowNodeWrapper` and `typeinfo for facebook::react::ShadowNodeWrapper` are only present in the former and not in the latter library (before this change you'd see them both)
Reviewed By: ShikaSD
Differential Revision: D35143600
Pulled By: javache
fbshipit-source-id: 5fb25a02365b99a515edc81e5485a77017c56eb8
Summary:
If an RN app is embedded in a Mac Catalyst app that uses the UIWindowScene API to manage multiple windows, LogBox would fail to render because it didn't know which UIWindowScene to render to. This diff fixes that situation by ensuring that the LogBox window gets rendered in the key window's scene.
Changelog:
[iOS][Fixed] - Update iOS LogBox to render its UIWindow with the key window's UIWindowScene
Reviewed By: appden
Differential Revision: D35027831
fbshipit-source-id: e0df5865f95323b03d08d6b1fb3ec912aa9a9167
Summary:
In https://github.com/facebook/react-native/blob/main/scripts/update-ruby.sh#L61
```bash
bundle lock
```
is called which creates a Gemfile.lock in the rn root. This file should be in the git add files list along with the other files that get updated by that script.
## Changelog
[Internal] [Fixed] - Added Gemfile.lock to git add files when calling update-ruby.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/33484
Test Plan: Call update-ruby.sh with or without this patch. Without this patch, the Gemfile.lock will not be staged, with this patch, the Gemfile.lock will be staged.
Reviewed By: GijsWeterings
Differential Revision: D35118250
Pulled By: cortinico
fbshipit-source-id: 80f2c7fad6fbc3f09697988dcc20f7ac94a21473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33499
This DIFF turns on the `FB_SONARKIT_ENABLED` flag when installing Flipper ina RN app. The flag is enabled only in Debug config, given that Flipper is installed only in this configuration.
This PR also fixes this issue: https://github.com/facebook/react-native/issues/33497
This PR is required because release 0.67 has the Flag in the app, while release 0.68 moved it in the React-Core pod.
We can't enable the flag at the `React-Core.podspec` level because we should not make assumptions on whether users want flipper or not.
## Changelog
[iOS][Changed] - Enable SonarKit in React-Core when the configuration is `'Debug'`
Reviewed By: cortinico
Differential Revision: D35141506
fbshipit-source-id: 171b7fa8ea7727c633ef963408e86b332c32e9fa
Summary:
I noticed the `AppState.removeEventListener` was in fact calling `addListener` instead of `removeListener` when type is blur or focus.
I know this method is deprecated but it can't hurt to fix it.
## Changelog
[General] [Fixed] - AppState.removeEventListener correctly removes listener for blur and focus events
Pull Request resolved: https://github.com/facebook/react-native/pull/33491
Test Plan: I've thought about adding a unit test, but it isn't that easy since AppState is mocked and the method is deprecated so I don't think it is worth investing too much for it.
Reviewed By: cortinico
Differential Revision: D35139808
Pulled By: GijsWeterings
fbshipit-source-id: 9d8ba157db3a62ea53759e1246f483182faf12f1
Summary:
Undoing the recent change that enabled Hermes to be built from source by default.
Building Hermes from source now requires the use of the BUILD_HERMES_SOURCE envvar, again.
To be re-enabled shortly.
Pull Request resolved: https://github.com/facebook/react-native/pull/33478
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35100459
fbshipit-source-id: ec83fcdf2432c689b0c02f86fbabcc8625975d51
Summary:
Problem:
All CellRenderers rerender every time the containing VirtualizedList is rerendered. This is due to the following:
- Lambda is created for each CellRenderer's onLayout prop on every VirtualizedList render (fixed in D35061321 (https://github.com/facebook/react-native/commit/19cf70266eb8ca151aa0cc46ac4c09cb987b2ceb))
- CellRenderer's parentProps prop changes on every VirtualizedList render (fixed in D35062323 (https://github.com/facebook/react-native/commit/adb2962fee968d7ae20ec32a55dc69e4ebb3ce12))
- FlatList recreates renderItem/ListItemComponent in FlatList._renderer (addressed in this diff)
Changelog:
[Internal] - VirtualizedList optimization - memoize FlatList._renderer
Reviewed By: ryancat
Differential Revision: D35067472
fbshipit-source-id: 124629d94821f35b8943730839fbe72f547e80fd
Summary:
Problem:
All CellRenderers rerender every time the containing VirtualizedList is rerendered. This is due to the following:
- Lambda is created for each CellRenderer's onLayout prop on every VirtualizedList render (fixed in D35061321 (https://github.com/facebook/react-native/commit/19cf70266eb8ca151aa0cc46ac4c09cb987b2ceb))
- CellRenderer's parentProps prop changes on every VirtualizedList render (addressed in this diff)
- FlatList recreates renderItem/ListItemComponent in FlatList._renderer
Changelog:
[Internal] - VirtualizedList optimization - refactor CellRenderer props to eliminate parentProps
Reviewed By: javache
Differential Revision: D35062323
fbshipit-source-id: 705c2f7c6c482b7813efdfdac7019a94594de590
Summary:
Problem:
All CellRenderers rerender every time the containing VirtualizedList is rerendered. This is due to the following:
- Lambda is created for each CellRenderer's onLayout prop on every VirtualizedList render (fixed in this diff)
- CellRenderer's parentProps prop changes on every VirtualizedList render
Changelog:
[Internal] - VirtualizedList optimization - avoid lambda creation in CellRenderer onLayout prop
Reviewed By: javache
Differential Revision: D35061321
fbshipit-source-id: ab16bda8418b692f1edb4bce87e25c34f6252b56
Summary:
With CMake we're accidentally bundling the .cxx folder inside the NPM package. This is making the package explode and is letting the publishing of nightly fail
Changelog:
[Internal] [Changed] - Do not bundle ReactAndroid/.cxx inside the npm package
Reviewed By: ShikaSD
Differential Revision: D35110743
fbshipit-source-id: fb51f0c4948479e2fcf96f5ac8df6362d5875421
Summary: This diff adds flag to `ReactRootView` to control if the touch event is to be dispatched to the JS side. This is needed for subclass of `ReactRootView` to control if the dispatch is needed.
Reviewed By: javache
Differential Revision: D35033684
fbshipit-source-id: febab6988cc3e4259e726d03d797dd0ffc978d24
Summary:
Remove BUILD_HERMES_SOURCE gate and default to building Hermes from source on iOS when Hermes is enabled.
Changelog:
[iOS][Changed] - When Hermes is enabled, the Hermes Engine will be built from source instead of using the pre-built `hermes-engine` CocoaPod.
Reviewed By: cortinico
Differential Revision: D34911987
fbshipit-source-id: 9d6d49498a23f6dae0b97c9f80c689b654db11bd
Summary:
Extend the hermesc build jobs to cover nightlies, commitlies, and stable releases.
The Hermes Compiler will be packaged alongside react-native releases in order to save on build time.
# Changelog:
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/33398
Reviewed By: cortinico
Differential Revision: D34727676
fbshipit-source-id: cc147b4d015abc8b5c798e8e3b5497a5de653b69
Summary:
GitHub's tarball endpoint does not provide a last-modified header, which keeps us from using wget's `--timestamping` flag to avoid re-downloading Hermes unnecessarily.
To work around this, we use the commit sha for the requested Hermes version - whether that is Hermes from trunk (`main` branch) or Hermes from a tagged commit - as the filename for the hermes tarball. Then it's as simple as performing a filesystem check to determine if we need to re-download the Hermes tarball. This should work as expected because any changes will result in a different commit SHA.
Additionally, a symbolic link to the pre-compiled HermesCompiler is created after the Hermes tarball is extracted. The result of this is that hermesc won't be recompiled when the `hermes-engine` Pod is built.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D34834139
fbshipit-source-id: 4c49bc11f3551ec8d6cca58fcceccad48ad4a10f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33472
Changes native build of ReactAndroid to CMake instead of ndk-build. Removes a few workarounds around AGP issues with ndk-build which seems to be working with CMake by default.
Changelog: [Changed][Android] - Use CMake to build ReactAndroid module
Reviewed By: cortinico
Differential Revision: D35018803
fbshipit-source-id: af477937ed70a5ddfafef4e6260a397ee9911580
Summary:
For the same reason we don't keep a yarn.lock or Podfile.lock, we shouldn't be keeping a Gemfile.lock in the template. The user will generate this on his own pulling in the current dependencies with the constraints in Gemfile. No need to lock to a specific version.
cc barbieri (author of https://github.com/facebook/react-native/pull/32303)
cc ravirajn22 (for raising the issue)
## Changelog
[iOS] [Fixed] - Remove Gemfile.lock from template
Pull Request resolved: https://github.com/facebook/react-native/pull/33469
Test Plan: no test plan
Reviewed By: javache
Differential Revision: D35074105
Pulled By: cortinico
fbshipit-source-id: 47d1b92329f1d55d4a0adbacbc7e5e45f9d957e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33467
We can now change the `hermes-engine` dependency to be consumed by the `react-native` NPM package
and not anymore from the standalone `hermes-engine`. This will allow for a better stability
as the `hermes-engine` and the `react-native` were built from source at the same instant in time.
Changelog:
[Android] [Changed] - Update template/android and RN Tester to use `hermes-engine` from the `react-native` NPM package.
Reviewed By: hramos
Differential Revision: D34213795
fbshipit-source-id: 29e54b37db0103f72e9983976ef9147fe69116e7
Summary:
Changelog: [Internal][iOS] Add validation reporting APIs for unexpected uses of Paper when Fabric is enabled
## RCTNotAllowedInBridgeless
Previously, we only had violation reporting APIs for when **Bridge APIs** are used in **Bridgeless mode**, which was only enabled in Bridgeless mode.
## RCTNotAllowedInFabric
This diff adds violation reporting APIs to use when **pre-Fabric Bridge APIs** are used in **Bridge or Bridgeless mode**. This allows us to add RCTAssert/RCTError/RCTLog to more APIs in Bridge mode. The main purpose is to distinguish between Bridge APIs that still work in Fabric, versus Bridge APIs that are no longer used in Fabric, so that the latter can be removed.
Reviewed By: philIip
Differential Revision: D35015758
fbshipit-source-id: 35366bc5143a59ee9a16d75da4de546ebfe250e6
Summary:
In the previous template, configure depends was placed after the globbing expression, causing CMake warning.
Changelog: [Internal] - Correct globbing for CMake config in the codegen
Reviewed By: cortinico
Differential Revision: D35044874
fbshipit-source-id: 4f022bfaaec3a84141f4be7de96c56a545639e56
Summary:
When using Android Studio, an active ABI gets selected which is resulting in failing to open the project as some of the tasks can't be found. I'm fixing this.
Changelog:
[Internal] [Changed] - Use `findByName` instead of `named` when applying Gradle task dependencies
Reviewed By: ShikaSD
Differential Revision: D35044870
fbshipit-source-id: 44bfaee320bce84c992610325c13daf71934a38b
Summary:
Test Docker Android is failing with `No space left on device`
I've fixed it by freeing up some space on the runner.
I'm looking into potentially removing this job entirely as I believe it's not
really helpful at the moment.
Changelog:
[Internal] [Changed] - Fix broken Test Docker Android
Reviewed By: ShikaSD
Differential Revision: D35013831
fbshipit-source-id: 594e65fa05c7dfc8b5acfde88658b341d26aa586
Summary:
Changelog for 0.67.4
## Changelog
[Internal][Added] - Changes for 0.67.4
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/33447
Test Plan: 👀
Reviewed By: ShikaSD
Differential Revision: D35008687
Pulled By: cortinico
fbshipit-source-id: 11a59a01b3935b72c4030907cbcf570fe61acf98
Summary:
Aligns two codepaths for measure, making sure we can use both MapBuffer and ReadableMap for measuring components.
Changelog: [Internal] - Align measure interface for MapBuffer experiment
Reviewed By: javache, mdvacca
Differential Revision: D34960317
fbshipit-source-id: a39eb84a0abb4414717463f2f1741e470be3531f
Summary:
This is a follow up to
https://github.com/facebook/react-native/commit/21dd646ecaf4f17cc62f18a4abf2f9cb88a72881
The ABI specific tasks were not involved in this patch, and they're still
failing. I'm fixing them.
Changelog:
[Internal] [Changed] - Reduce flakyness of `configureNdkBuild*` tasks by setting an
explicit dependency on prefab - part 2
Reviewed By: ShikaSD
Differential Revision: D34960946
fbshipit-source-id: 3e4feb93aa59cbe47142dece1d0246117381179d
Summary:
Changes in https://github.com/facebook/react-native/compare/7cece3423...189c2c895 broke build for Windows because of a conversion from size_t to int. Adds a static cast to int to fix the error and restore windows build
Error Message
```
##[error]node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): Error C2220: the following warning is treated as an error
3>D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): error C2220: the following warning is treated as an error [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
##[warning]node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): **Warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data**
3>D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
```
## Changelog
[General] [Fixed] - Restore Windows build with RawPropsParser.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/33432
Test Plan: Tested locally and changes pass in the react-native-windows pipeline, change is being merged into the main branch of react-native-windows.
Reviewed By: philIip
Differential Revision: D34907928
Pulled By: javache
fbshipit-source-id: 8b76cbef0b637f2d607a8aefd2998322c3245713
Summary:
When upgrading `react-native`, the version `RCT-Folly` defined [here](https://github.com/facebook/react-native/blob/main/third-party-podspecs/RCT-Folly.podspec) can change. If that happens, if you run `pod install` after `yarn install`, you will get a similar error to this:
```
[!] CocoaPods could not find compatible versions for pod "RCT-Folly":
In snapshot (Podfile.lock):
RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)
In Podfile:
RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)
React-RCTNetwork (from `../node_modules/react-native/Libraries/Network`) was resolved to 0.66.3, which depends on
RCT-Folly (= 2021.06.28.00-v2)
```
This error occurs because `Cocoapods` does not update pods that point to a local podspec. Locally, you could resolve this issue by running `pod update RCT-Folly --no-repo-update`. On the CI, you have to do a clean checkout (in case you cache the `Pods` folder which we do). All of this makes upgrading `react-native` painful - for the whole community and for us shopify
There are other users who have struggled with this, such as [here](https://github.com/facebook/react-native/issues/32423). The suggestion there is to delete `Podfile.lock` which is unnecessary - but it shows that users are confused what to do with this error and is something worth fixing.
To mitigate these issues, `react_native_pods.rb` automatically marks `RCT-Folly` as changed in the [detect_changes_with_podfile method](https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/lockfile.rb#L289) from `Pod::Lockfile` if the version in `node_modules/react-native/third-party-podspecs/RCT-Folly.podspec` and `Pods/Local Podspecs/RCT-Folly.podspec.json` mismatch.
Instead of automatically updating the local podspec (in `Pods/Local Podspecs` directory) we could also:
a) integrate `RCT-Folly` as a local pod (such as `React-Core` and others)
b) integrate `RCT-Folly` as an external dependency (going through Cocoapods' centralized repository)
I don't have enough context on why `RCT-Folly` is bundled the way it is, so I am open to suggestions here.
## 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 `pod install` when `RCT-Folly` version has been updated.
Pull Request resolved: https://github.com/facebook/react-native/pull/32659
Test Plan:
I have created a [repository](https://github.com/fortmarek/react-native-upgrade-reproduction) where you can reproduce the issue. You can simply:
1) clone the repo (`git clone https://github.com/fortmarek/react-native-upgrade-reproduction`)
2) Run `yarn install && cd ios && pod install`
3) Change `react-native` version in `package.json` to `0.66.3`
4) Run again `yarn install && pod install`
5) Observe error
To test the fix, you can then:
1) copy-paste the `react_native_pods.rb` file from this branch to `react-native-upgrade-reproduction/node_modules/scripts/react_native_pods.rb`
2) run `pod install` again
This time, the `pod install` command should succeed.
Reviewed By: sota000
Differential Revision: D32720758
Pulled By: cortinico
fbshipit-source-id: 940db9c9f0530f896e47b676dec46bc93cea0085
Summary:
Changelog: [Internal]
this doesn't really make any sense, first of all CGFloat is a primitive data type so comparing it against nil only will return true if it's 0. but that won't catch cases where CGFloat is uninitialized bc it will be holding junk in memory.
the error checking of the value is already handled in the accessibility manager, so just remove it here.
Reviewed By: p-sun
Differential Revision: D34909365
fbshipit-source-id: 483f9c100433f8533edd784622523c5469c616c2
Summary:
Changelog: [Internal]
for the last 6 months or so, we've been getting this task where the moduleRegistry in RCTDeviceInfo is nil. in this change, i add some logs to see what might be setting this to nil.
in all honestly, i don't really think this is happening, but it would be good to verify.
Reviewed By: sshic
Differential Revision: D34908902
fbshipit-source-id: d375285467a87453605ba0fecfc124bc3bff6e63
Summary:
The context could be null or is finishing when we create the redbox surface content view. This diff adds the null check and delegate the message in log when context is not available.
Changelog:
[Android][Fixed] - Adding null check for context in redbox surface delegate
Differential Revision: D34930595
fbshipit-source-id: 91508ded7821033abcd893f70bcfe3cc9ee5b5c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33439
This allows us to toggle the publishing of prefab if the `REACT_NATIVE_HERMES_SKIP_PREFAB`
env variable is set. With this we can control how big is the .aar of hermes-engine, reducing
the size from ~200Mb right now to 8Mb.
Changelog:
[Internal] [Changed] - Disable prefab publishing if REACT_NATIVE_HERMES_SKIP_PREFAB is set
Reviewed By: ShikaSD
Differential Revision: D34929265
fbshipit-source-id: eb710b72ee4e17ac04c2924ffdac7a542928e9f8
Summary:
sSpannableCache is a significant user of Java heap memory - up to 0.22MB is retained by sSpannableCache.
It turns out sSpannableCache was never hitting as hashCode is different for the same attributedString contents. attributedString.getInt("hash") provides the expected hash code.
This indicates removing spannableCache will not affect perf. Will gate just in case though.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D34900414
fbshipit-source-id: 7563cde6ba9dc153072e7aebede99389ce3153e7
Summary:
This re-applies Consider relative to pwd installation root when looking for files in rn module via cocoapods by danilobuerger
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33427
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: cortinico
Differential Revision: D34890926
Pulled By: dmitryrykun
fbshipit-source-id: f7adc6196874822d5ff38f275414f529d385f2ea
Summary:
There is a typo in the hermes-engine resulting in hermes-engine not picking up the Intl
Java source code. I'm fixing it.
Changelog:
[Internal] [Changed] - Fix a typo in the hermes-engine srcSet folder
Reviewed By: motiz88
Differential Revision: D34922477
fbshipit-source-id: a144f7a2f75702bc8ddea73fa8b48c71d8fcd499
Summary:
We have a lot of stale issues that are receiving essentially no traffic. Previously we used to use `stalebot` which had an interval of 90 days but was somehow unreliable. Now we moved to the state GH actions but with an interval of 365 days which I believe is potentially too high.
Changelog:
[Internal] [Changed] - Reduce stale range from 365 days to 180 days
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: GijsWeterings
Differential Revision: D34831199
fbshipit-source-id: 70f3f6cc97ac4add625061577e53cc80da987c7a
Summary:
Adds CMake files to configure hermes-executor build, with the same setup as we have in Android.mk
Changelog: [Internal] - CMake build config for hermes executor
Reviewed By: cortinico
Differential Revision: D34811909
fbshipit-source-id: 2df6dbaf46131db87a25e26c83b38ba44f29d1d3
Summary:
Generates `CMakeLists.txt` for the codegen the same way as we generate Android.mk
Changelog: [Internal] - CMakeLists.txt for codegen targets
Reviewed By: cortinico
Differential Revision: D34821864
fbshipit-source-id: 0cbe7a450a4a064e2285890253ae152fb03267c2
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.69.0 to 0.69.1.
Changelog:
[Internal]
Reviewed By: arushikesarwani94
Differential Revision: D34898033
fbshipit-source-id: 267821ec6cb926f371c4029bd6f09984c6f7334b
Summary:
Existing RNTester examples for text did not contain a case where text with color was nested inside of another with text at both ends. This would have caught T113767991
Changelog:
[Internal] - Add RNTester example for nested text
Reviewed By: mdvacca
Differential Revision: D34874080
fbshipit-source-id: cda91cde9c7449abb677ae9fa936a61e396ffbd3
Summary:
Sticky headers (via OCScrollTrackerStickyHeader) did not work with RN because overscroll does not trigger onScroll events.
This diff adds a listener to overscroll, which then emits scroll events.
Changelog:
[Internal][Changed] - Changed ScrollEvent's scrollX and scrollY to float
---
# Context
GamingActivity headers are part of the FlatList; on overscroll (when you scroll up when you're already at the top of the FlatList), the header is translated via Animated's native event. The problem on RN is that onScroll is not fired during overscroll (due to how overscroll-decor works - it merely applies a translation on the scroll view itself).
Scroll events propagate to the native animated events as follows:
- ReactScrollView.onScrollChanged -> ReactScrollViewHelper.updateStateOnScrollChanged -> ReactScrollViewHelper.emitScrollEvent -> EventDispatcher.dispatchEvent -> NativeAnimatedNodesManager.onEventDispatch
# Approaches
Two approaches were considered to fix sticky headers:
- [Implemented in this diff] Attach a listener on OverScrollDecor and fire onScroll events. I ran into 2 main issues with this:
- The header clips as the scroll view is translated down. This is fixed via setting clipChildren.
- Move headers out of FlatList, and translate the header only for positive scroll offsets.
- Requires product-side code changes
- Hover outline is cut off by the header
- Click-drag to scroll does not work on the header
Reviewed By: javache
Differential Revision: D34696042
fbshipit-source-id: 15450f31a7042ce67cdffc74614f4f7b9684d0ca
Summary:
Avoid breaking tools relying on absolute path for `cliPath`
## Changelog
[Android] [Fixed] - Enable cliPath to have an absolute path value
Pull Request resolved: https://github.com/facebook/react-native/pull/32983
Test Plan:
declare `cliPath` from `expo`:
```groovy
cliPath: new File(["node", "--print", "require.resolve('react-native/package.json')"].execute(null, rootDir).text.trim()).getParentFile().getAbsolutePath() + "/cli.js",
```
and run an android build
Reviewed By: ShikaSD
Differential Revision: D33843275
Pulled By: cortinico
fbshipit-source-id: 65f55a5e07a4ec0a6205d5f06f150377708c30cc
Summary:
This Diff re-applies some of the changes that landed on main
to the CMake files we currently landed so far.
Changelog:
[Internal] [Changed] - Re-apply main changes to CMake files
Reviewed By: ShikaSD
Differential Revision: D34859685
fbshipit-source-id: 772a3aed05f56b6fbb2942bf9d1a5bd4581b48d5
Summary:
This pull request simplifies and makes it easy to debug the `rn-tester` project and switch configurations within the project.
- `yarn start` : Start packager
- `yarn install-android-jsc` : Build with `installJscDebug`.
- `yarn install-android-hermes` : Build with `installHermesDebug`.
- `yarn clean-android` : Clean up the Android build files.
- `yarn setup-ios-jsc` : Install dependencies to use JSC.
- `yarn setup-ios-hermes` : Install dependencies to use Hermes.
- `yarn clean-ios` : Clean up the build files and Pods.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Add scripts to debug `rn-tester` easier
Pull Request resolved: https://github.com/facebook/react-native/pull/33386
Test Plan:
<details><summary>Log</summary>
<p>
```sh
// packages/rn-tester
$ yarn setup-ios-jsc
yarn run v1.22.17
$ yarn install && bundle install && bundle exec pod install
[1/5] 🔍 Validating package.json...
[2/5] 🔍 Resolving packages...
success Already up-to-date.
Using rexml 3.2.5
Using CFPropertyList 3.0.5
Using concurrent-ruby 1.1.9
Using i18n 1.9.1
Using minitest 5.15.0
Using tzinfo 2.0.4
Using zeitwerk 2.5.4
Using activesupport 6.1.4.4
Using public_suffix 4.0.6
Using addressable 2.8.0
Using httpclient 2.8.3
Using json 2.6.1
Using algoliasearch 1.27.5
Using atomos 0.1.3
Using bundler 2.1.4
Using claide 1.1.0
Using fuzzy_match 2.0.4
Using nap 1.1.0
Using netrc 0.11.0
Using ffi 1.15.5
Using ethon 0.15.0
Using typhoeus 1.4.0
Using cocoapods-core 1.11.2
Using cocoapods-deintegrate 1.0.5
Using cocoapods-downloader 1.5.1
Using cocoapods-plugins 1.0.0
Using cocoapods-search 1.0.1
Using cocoapods-trunk 1.6.0
Using cocoapods-try 1.2.0
Using colored2 3.1.2
Using escape 0.0.4
Using fourflusher 2.3.1
Using gh_inspector 1.1.3
Using molinillo 0.8.0
Using ruby-macho 2.5.1
Using nanaimo 0.3.0
Using xcodeproj 1.21.0
Using cocoapods 1.11.2
Bundle complete! 2 Gemfile dependencies, 38 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Building RNTester with Fabric enabled.
[Codegen] Generating ./build/generated/ios/React-Codegen.podspec.json
[Codegen] generating an empty RCTThirdPartyFabricComponentsProvider
Building RNTester with Fabric enabled.
[Codegen] Skipping React-Codegen podspec generation.
[Codegen] generating an empty RCTThirdPartyFabricComponentsProvider
Building RNTester with Fabric enabled.
[Codegen] Skipping React-Codegen podspec generation.
[Codegen] generating an empty RCTThirdPartyFabricComponentsProvider
Analyzing dependencies
[Codegen] Found FBReactNativeSpec
[Codegen] Found rncore
[Codegen] Found ScreenshotmanagerSpec
Downloading dependencies
Installing FBLazyVector 1000.0.0
Installing FBReactNativeSpec 1000.0.0
Installing RCTRequired 1000.0.0
Installing RCTTypeSafety 1000.0.0
Installing React 1000.0.0
Installing React-Core 1000.0.0
Installing React-CoreModules 1000.0.0
Installing React-Fabric 1000.0.0
Installing React-RCTActionSheet 1000.0.0
Installing React-RCTAnimation 1000.0.0
Installing React-RCTBlob 1000.0.0
Installing React-RCTFabric 1000.0.0
Installing React-RCTImage 1000.0.0
Installing React-RCTLinking 1000.0.0
Installing React-RCTNetwork 1000.0.0
Installing React-RCTPushNotification 1000.0.0
Installing React-RCTSettings 1000.0.0
Installing React-RCTTest 1000.0.0
Installing React-RCTText 1000.0.0
Installing React-RCTVibration 1000.0.0
Installing React-callinvoker 1000.0.0
Installing React-cxxreact 1000.0.0
Installing React-graphics 1000.0.0
Installing React-jsi 1000.0.0
Installing React-jsiexecutor 1000.0.0
Installing React-jsinspector 1000.0.0
Installing React-logger 1000.0.0
Installing React-perflogger 1000.0.0
Installing React-rncore 1000.0.0
Installing React-runtimeexecutor 1000.0.0
Installing ReactCommon 1000.0.0
Installing Yoga 1.14.0
Generating Pods project
[DEDUCTED]/react-native/packages/rn-tester/Pods/Target Support Files/Pods-RNTester/Pods-RNTester.release.xcconfig
[DEDUCTED]/react-native/packages/rn-tester/Pods/Target Support Files/Pods-RNTester/Pods-RNTester.debug.xcconfig
[DEDUCTED]/react-native/packages/rn-tester/Pods/Target Support Files/Pods-RNTesterUnitTests/Pods-RNTesterUnitTests.release.xcconfig
[DEDUCTED]/react-native/packages/rn-tester/Pods/Target Support Files/Pods-RNTesterUnitTests/Pods-RNTesterUnitTests.debug.xcconfig
[DEDUCTED]/react-native/packages/rn-tester/Pods/Target Support Files/Pods-RNTesterIntegrationTests/Pods-RNTesterIntegrationTests.release.xcconfig
[DEDUCTED]/react-native/packages/rn-tester/Pods/Target Support Files/Pods-RNTesterIntegrationTests/Pods-RNTesterIntegrationTests.debug.xcconfig
React-Core
Integrating client project
Pod installation complete! There are 65 dependencies from the Podfile and 53 total pods installed.
✨ Done in 8.68s.
```
</p>
</details>
Reviewed By: ShikaSD
Differential Revision: D34835086
Pulled By: cortinico
fbshipit-source-id: 83649f42e8ac77efd8617601e18f15bfcf8f1f61
Summary:
I've noticed that `test_android` and the Test Android Docker image jobs fails sometime with a missing
`libhermes.so` file. That is happening because the `configureNdkBuild*` tasks are executing
before the prefab for Hermes is ready. I'm adding an explicit dependency here that will prevent this
kind of situations from happening.
Changelog:
[Internal] [Changed] - Reduce flakyness of `configureNdkBuild*` tasks by setting an explicit dependency on prefab.
Reviewed By: ShikaSD
Differential Revision: D34859961
fbshipit-source-id: e4dc4b22c808359018ec952287b2d8a7094f0698
Summary:
This commit allows to specify a custom location for Hermes sources with the
`REACT_NATIVE_OVERRIDE_HERMES_DIR` environment variable.
This can be useful during local development if you wish to build against a local
clone of facebook/hermes.
Changelog:
[Internal] [Changed] - Allow to override Hermes source location with REACT_NATIVE_OVERRIDE_HERMES_DIR
Reviewed By: ShikaSD
Differential Revision: D34858893
fbshipit-source-id: 4fad3d1c8e99f1f1880b5633e596b67f5dfcc264
Summary:
We were opening the file multiple times just to read the same couple of bytes.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D34835972
fbshipit-source-id: 9de899f37a9193db4ab72e69e02e8d41e5515da0
Summary:
## Summary
Hermes added support for generators in 0.2.0, and JSC is ES6 feature complete since r202125.
NOTE: This is a combined Metro + React Native commit. For React Native, the only change here is adding `babel/plugin-transform-regenerator` to `repo-config` ( = `devDependencies`), so the tests no longer implicitly consume it via Metro.
Changelog: [Internal]
X-link: https://github.com/facebook/metro/pull/789
Reviewed By: rh389
Differential Revision: D34819044
Pulled By: motiz88
fbshipit-source-id: fe27b2c2af0281d5309d4c16f95762d4d4935eba
Summary:
This Diff moves from specifying a list of files to use file(GLOB) with
CONFIGURE_DEPENDS on several CMakefiles.
I've updates those where we use globbing also inside buck.
Changelog:
[Internal] [Changed] - Setup Globbing with CONFIGURE_DEPENDS inside CMake files
Reviewed By: ShikaSD
Differential Revision: D34826311
fbshipit-source-id: 8fc654626c897cdc4cdd79c699ce19f1e5e1212f
Summary:
When the `snapToOffsets` prop is empty array, the scroll view would crash unexpectly. This diff fixed that by treating empty array prop as null value for `snapToOffsets`.
Changelog:
[Android][Fixed] - Fix crash on empty snapToOffsets array
Reviewed By: makovkastar
Differential Revision: D34802022
fbshipit-source-id: af330512e444081b0cb02b65288ec5cd2bd14205
Summary:
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33399
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: ShikaSD
Differential Revision: D34784966
Pulled By: dmitryrykun
fbshipit-source-id: d6d5e71bc2fcd32f2cd60a498f39e6f772fc9005
Summary:
Changelog:
[General][Deprecated] Deprecate the use of `react-native/jest/preprocessor.js` by external projects
The supported method of using Jest in React Native projects is using the [Jest preset](https://jestjs.io/docs/tutorial-react-native) shipped as part of the `react-native` package. Some projects are directly using `preprocessor.js` which is part of the testing setup for the React Native repo itself.
In a future release of React Native, we will stop publishing this file to npm and require projects to switch to the supported preset (or a custom Jest config if necessary).
Reviewed By: GijsWeterings
Differential Revision: D34820086
fbshipit-source-id: 197c33726639e66c6916a244117252e6af11f2f6
Summary:
We're replacing console.disableYellowBox (untyped, global hack, only warnings) with LogBox.ignoreAllLogs() (typed, local method, handles errors and warnings). rickhanlonii made the initial deprecation of this >2 years ago in https://github.com/facebook/react-native/commit/87f1e22434210ad22f526422bbda0413f59786ce . This diff finally removes the support of `console.disableYellowBox`. Users of LogBox should be using `LogBox.ignoreAllLogs`. This removal also allows us to move LogBox to strict mode flow.
Changelog: [BREAKING] [Removed] Removed console.disableYellowBox in favor of LogBox.ignoreAllLogs.
Reviewed By: rickhanlonii, yungsters
Differential Revision: D34689343
fbshipit-source-id: 3b2865a4918de703e47cd722e3f396475254c65a
Summary:
Rearranges folly_futures configuration into a static library only required for `hermes-inspector` + `folly_runtime` which merges `folly_json` and mutex-related implementations `folly_futures` was used for. As `hermes-executor-debug` is removed by `vmCleanup` configurations later, it allows to shave additional 300KB from the release APK size.
Changelog: [Internal] - Rearrange folly build to reduce APK size
Reviewed By: cortinico
Differential Revision: D34342514
fbshipit-source-id: b646680343e6b9a7674019506b87b96f6007caf2
Summary:
`MapBuffer` is not used in RN utils for anything shared for now, so we can remove it from the build config by reordering methods, shaving 20KB in APK size for each architecture.
Also applies clang-tidy rules to `MapBuffer`/`folly::dynamic` configurations.
Changelog: [Internal] - Remove `mapbuffer` dependency from `Android.mk` of reactutilsjni
Reviewed By: javache, cortinico
Differential Revision: D34620455
fbshipit-source-id: ad3717448f5c20fd071f71d436bb9dd00efe7eb0
Summary:
When starting the surface, _propagateStageChange is called. This checks the delegate to call surface:didChangeStage: on it.
When initWithSurface:sizeMeasureMode: is called after start, then the delegate will be nil and thus not be called.
This turns it around so a delegate is present for the surface to propagate its state to.
This fixes RCTContentDidAppearNotification not getting posted otherwise.
## Changelog
[iOS] [Fixed] - Post RCTContentDidAppearNotification with new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33402
Test Plan:
I found it best to set a breakpoint in XCode to where RCTContentDidAppearNotification is being posted.
Prior to the patch that breakpoint will not be called. After applying the patch, it will be called.
Reviewed By: philIip
Differential Revision: D34753329
Pulled By: ShikaSD
fbshipit-source-id: cc44a4c3a787d49e22e9d0c3a82c0f11ed281a0a
Summary:
It is possible that `init` is null when using the following code.
```js
export var a;
```
The typescript compiler actually generates something like this for enums so a lot of third party libraries triggered this issue.
For example in expo-apple-authentication/build/AppleAuthentication.types.js
```js
export var AppleAuthenticationScope;
(function (AppleAuthenticationScope) {
AppleAuthenticationScope[AppleAuthenticationScope["FULL_NAME"] = 0] = "FULL_NAME";
AppleAuthenticationScope[AppleAuthenticationScope["EMAIL"] = 1] = "EMAIL";
})(AppleAuthenticationScope || (AppleAuthenticationScope = {}));
```
This simply adds a null check.
## Changelog
[General] [Fixed] - Fix babel-plugin-codegen crash when export init is null
Pull Request resolved: https://github.com/facebook/react-native/pull/33387
Test Plan: Tested that this fixed the crash in an app.
Reviewed By: javache
Differential Revision: D34687271
Pulled By: philIip
fbshipit-source-id: 7a7e0fe1bb6a7a21a5b442af26b221a263d4173d
Summary:
This PR adds a `dismissActionSheet` method to `ActionSheetIOS` in order to allow dismissing an ActionSheet programmatically. This is especially useful in apps where a user has the ability to open an ActionSheet and then open a push notification that will redirect them to another screen which usually leads to scenarios where the presented ActionSheet has no relation with the current screen.
#### TODO
- [ ] Submit react-native-website PR updating ActionSheetIOS documentation.
## Changelog
[iOS] [Added] - Add dismissActionSheet method to ActionSheetIOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33189
Test Plan:
1. Open the RNTester app and navigate to the ActionSheetIOS page
2. Test `dismissActionSheet` through the `Show Action Sheet and automatically dismiss it` example
https://user-images.githubusercontent.com/11707729/155867546-c6770a49-9b09-45e3-a6b1-4f7645d67dbf.mov
Reviewed By: lunaleaps
Differential Revision: D34518952
Pulled By: cortinico
fbshipit-source-id: 912a9b83ee078f791b42efddf5abb7e1cd09d520
Summary:
URL params are not encoded which could cause a security risk, for more details pls see https://fb.workplace.com/groups/react.technologies.discussions/permalink/3184249088473474/
Changelog:
[General][Security] - Encode URL params in URLSearchParams.toString()
Reviewed By: yungsters
Differential Revision: D34415119
fbshipit-source-id: 83c29df9427ad0adc9b6a2b4d0ff5494247aa5cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33396
This commit fully unplugs the `ReactAndroid` from using hermes from the NPM package and plugs the usage of Hermes via the `packages/hermes-engine` Gradle build.
I've used prefab to share the .so between the two builds, so we don't need any extra machinery to make this possible.
Moreover, I've added a `buildHermesFromSource` property, which defaults to false when RN is imported, but is set to true when RN is opened for local development. This should allow us to distribute the `react-native` NPM package and users could potentially toggle which source to use (but see below).
Changelog:
[Android] [Changed] - Build Hermes from Source
Reviewed By: hramos
Differential Revision: D34389875
fbshipit-source-id: 107cbe3686daf7607a1f0f75202f24cd80ce64bb
Summary:
Changelog:
[Android][Fixed] - Fix StatusBar not updating to use translucent values when set to the same value across different activities
With native nav we open routes in a new activity. Each activity has its own StatusBar configured so we need to ensure it is configured properly.
Currently since the statusBar RN component avoids changing the StatusBar if the value hasn't changed it never gets updated and doesn't become translucent this results in all our padding being off since we add padding to account for the status bar
Reviewed By: yungsters
Differential Revision: D34810143
fbshipit-source-id: 5e382026fb89542fe0c8f6ab396f2fbeedee7a05
Summary:
This adds the *option* for C++ TurboModules to use a `*CxxSpec<T>` base class that extends the existing (and unchanged) corresponding `*CxxSpecJSI` base class with code-generated methods that use `bridging::calFromJs` to safely convert types between JSI and C++. If a type conversion cannot be made, then it will fail to compile.
Changelog:
[General][Added] - Automatic type conversions for C++ TurboModules
Reviewed By: christophpurrer
Differential Revision: D34780512
fbshipit-source-id: 58b34533c40652db8e3aea43804ceb73bcbe97a5
Summary:
This adds `bridging::callFromJs` that can call class instance methods with JSI arguments and will automagically convert types to the types expected by the method, or otherwise will fail to compile. The same type conversion back to JSI applies as well for the return value, if there is one.
This will allow C++ TurboModules to more easily define their interface in terms of C++ types instead of having to interact with JSI directly for everything, though it remains possibles for JSI values to pass through if that's what a given method wants.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34780511
fbshipit-source-id: 1f9caadeefa6d4023f679e95f3decc64d156b3f0
Summary:
This adds `bridging::toJs` and `bridging::fromJs` functions that will safely cast to and from JSI values and C++ types. This is extensible by specializing `Bridging<T>` with `toJs` and/or `fromJs` static methods. There are specializations for most common C++ and JSI types along with tests for those.
C++ functions and lambdas will effortlessly bridge into JS, and bridging JS functions back into C++ require you to choose `SyncCallback<R(Args...)>` or `AsyncCallback<Args...>` types. The sync version allows for having a return value and is strictly not movable to prevent accidentally moving onto another thread. The async version will move its args onto the JS thread and safely call the callback there, but hence always has a `void` return value.
For promises, you can construct a `AsyncPromise<T>` that has `resolve` and `reject` methods that can be called from any thread, and will bridge into JS as a regular `Promise`.
Changelog:
[General][Added] - New bridging API for JSI <-> C++
Reviewed By: christophpurrer
Differential Revision: D34607143
fbshipit-source-id: d832ac24cf84b4c1672a7b544d82e324d5fca3ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33413
This moves `CallbackWrapper` and `LongLivedObject` into a new "bridging" library. This library is mostly intended for use by the native module system, but can also be used separately to "bridge" native and JS interfaces through higher-level (and safer) abstractions than relying JSI alone.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34723341
fbshipit-source-id: 7ca8fa815537152f8163920513b90313540477e3
Summary:
This is the first round of CMake files to support the React Native build on Android.
They're supposed to eventually replace the various Android.mk files we have around in the codebase.
So far we're not actively using them. This is the first step towards migrating our
setup to use CMake
Changelog:
[Internal] [Changed] - First Round of CMake files for React Android
Reviewed By: ShikaSD
Differential Revision: D34762524
fbshipit-source-id: 6671e203a2c83b8874cefe796aa55aa987902a3b
Summary:
Proguard seems to keep Fabric methods a bit differently from Redex, with method signature lookup with `MountItem` and `StateWrapperImpl` failing in release RNTester builds because of mangled names. Adding these annotations should keep the classes, ensuring lookup from native is correct.
Changelog: [Internal] - Add DoNotStrip annotations to Fabric related classes
Reviewed By: ryancat
Differential Revision: D34726510
fbshipit-source-id: 0c1d8e1fabec75511942943b533ddd8b637a5e19
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
using namespace in header file is a bad practice due to many reasons as well as discouraged by `-Wheader-hygiene` compiler flag which is default for many apps
https://stackoverflow.com/questions/5849457/using-namespace-in-c-headers
Changelog:
[General][Fixed] - Fixed compilation warning due to `using namespace` being used as part of header
Reviewed By: nlutsenko
Differential Revision: D34788523
fbshipit-source-id: 2a50fbf2ac3371ff5670c600c7f5ad9055060ad2
Summary:
Flipper-DoubleConversion and Flipper-Glog iOS pods received a build optimization
a few versions back that pre-compiled the pods and references the xcframework slices
Unfortunately, the pre-compile did not include macCatalyst slices, so this disabled support
for flipper on macOS for react-native >0.65
lblasa has re-compiled the pods with the macCatalyst slices added
See https://github.com/facebook/flipper/issues/3117
## 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] - update Flipper pods to support re-enable macCatalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/33406
Test Plan:
- [ ] The Flipper repo has a react-native test that appeared to work with these versions, CI should work here
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on arm64
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on x86_64 mac
- [ ] Prove there is no regression, a flipper-enabled build test should work for real device iOS target
- [ ] To prove the issue is resolved, a build should be attempted for a macCatalyst target, and it should work.
Reviewed By: cortinico
Differential Revision: D34789654
Pulled By: lblasa
fbshipit-source-id: 466803dd07b5820220512b7d7d760b94b8aa65f7
Summary:
Downloads a tarball of the Hermes source code when `pod install` is run.
If the current release is pinned to a Hermes tag, it will use that specific tag, otherwise the latest Hermes commit will be used.
# Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D34629595
fbshipit-source-id: 5f36af4a43bc2d137dfd702082558ab9d0191140
Summary:
Hoop up EarlyJsErrorHandler so we could pass js error data to object-c to report.
Changelog:
[iOS][Chagned] - Add function to report early js errors
Reviewed By: RSNara
Differential Revision: D34096343
fbshipit-source-id: fdbc6ea5d1f3cc6ab55fcd22b48bbe8fb1f1ca8f
Summary:
Changelog: [Internal] This diff add support of relative paths in `app_path` argument of `use_react_native` function.
Ruby's `relative_path_from` function requires both paths to be either relative or absolute. I added `realpath()` call that converts any path to absolute.
Reviewed By: ShikaSD
Differential Revision: D33311728
fbshipit-source-id: 393a7b4f0eb26831f4d9f4cec8ec180b41cad580
Summary:
Blocks on queue write/drain for Animated module under a feature flag to test whether it resolves race conditions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D34752947
fbshipit-source-id: a1b1a286772d29a7a27b5e9c3f743cac84cc2bab
Summary:
In iOS, the native LogBox that gets rendered for JS errors/warnings is statically sized once and bases that size off of the entire screen's size. This causes issues when being run in a Mac Catalyst app since 1) the sizing is not static since we can resize the window and 2) the size of the LogBox's root should fill the *window* and not the screen. This diff fixes both of these issues.
Changelog:
[iOS][Fixed] - Ensure LogBoxView is sized relative to the key window instead of the full screen
Reviewed By: appden
Differential Revision: D34697076
fbshipit-source-id: 9665fd51bc86ed29837672cec882bac97904b0c8
Summary:
changelog: [internal]
For embedded React Native screens, we need to calculate the intrinsic size. To do that, we need to pass Yoga value `YGUndefined`. However, if available size was `CGFLOAT_MAX` (which is not inifinity), we would pass it to Yoga and it would calculate layout with available height/width `CGFLOAT_MAX`.
To fix this, we convert `CGFLOAT_MAX` to infinity. Which in YogaLayoutableShadowNode gets converted to YGUndefined.
Reviewed By: ShikaSD
Differential Revision: D34719047
fbshipit-source-id: e6fd40724f81abfba164e67efc9ca8fc74e9b235
Summary:
This diff fixed an issue that caused regression in fb4a and React Native panel apps regarding scrolling behavior. When scrolling in either horizontal or vertical scroll view, if the consecutive touch interrupted the previous fling (post touch scrolling), the scroll view would block touch event from dispatching to the content view. Thus, the items in scroll view are not responding to touch events anymore.
The diff that caused this issue is D34627330 (https://github.com/facebook/react-native/commit/0368081858193d7c2537acd9080d11bb701ee98b). In that diff, I added code to cancel the scheduled post touch runnable when touch down is received in scroll view. That is expected as the post touch runnable is to handle snapping scroll case, where [an extra fling](https://fburl.com/code/7qza1ece) is triggered to make sure scroll view stops at the right position. When user touch the screen before the previous scroll fling finishes, this post processing is no longer needed -- the new touch should take full control of scroll view.
However, in D34627330 (https://github.com/facebook/react-native/commit/0368081858193d7c2537acd9080d11bb701ee98b), I failed to reset the runnable instance `mPostTouchRunnable` to null when cancelling it. This caused the future post touch handle logic [stops to run](https://fburl.com/code/lh8pi7l0), as it thinks the runnable is non-null and has been scheduled. This prevents fabric from receiving proper scroll state updates from android side, thus causing a state corruption and affects logic to decide where the scroll offset is and where the child item is after that.
This diff fixed the issue by resetting the runnable instance, as well as making sure if the runnable is already running and the extra fling starts, we are canceling that fling animation properly.
Changelog:
[Android][Fixed] - Fixed regression on content in scroll view not responding to touch when fling got interrupted
Reviewed By: ShikaSD
Differential Revision: D34734129
fbshipit-source-id: 7d7689d203ce76c59cd44e16e31582317bb409bd
Summary:
When packaging a react app as an android library with the enableVmCleanup flag not set to false, an error occurs since the "package${targetName}" task can not be found. This PR adds a simple null check, similar to what is being done for the sTask and mTask just below it to prevent the error.
## 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
-->
[Android] [Fixed] - Fixes android build error when compiling as library
Pull Request resolved: https://github.com/facebook/react-native/pull/33179
Test Plan:
Compile project as library (com.android.library), and should not trigger and error with these changes.
Would also like to have this fix cherry-pick'd to release 0.67 after merging.
Reviewed By: ShikaSD
Differential Revision: D34475934
Pulled By: cortinico
fbshipit-source-id: ce6ce43960c4b388c4b1da49a9a6e21fd3bf8e16
Summary:
This is only defined on Windows, and thus code that compiles on all platforms
may successfully build on Linux/macOS, but not on Windows, making it
potentially harder to detect and debug. Let's unify all platforms to solve
this.
Changelog: [Internal]
Reviewed By: chadaustin
Differential Revision: D34648154
fbshipit-source-id: b2549bb3eb120e6207cab8baaafced8b1b18e6a7
Summary:
Fix a few issues with msggen:
1. run_msggen: fully-qualified path to clang-format
1. Updated the license for autogenerated files
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D34114718
fbshipit-source-id: 831d4b20bfdc39cfa1226e2a32dcb445c8086ff3
Summary:
Changelog: [internal]
To avoid unnecessary string copy in event pipeline, use move semantics.
Event pipeline has ownership of event type. Passing it by reference ends up in a copy when `RawEvent` object is constructed. To avoid this, pass string by value through each layer and use move semantics to avoid extra copies.
Reviewed By: javache
Differential Revision: D34392608
fbshipit-source-id: c11d221be345665e165d9edbc360ba5a057e3890
Summary:
Since the generated functions move JSI arguments as rvalues into these methods, using const lvaue references doesn't provide any benefit, and in fact hinders our ability to *move* arguments somewhere else and instead requires having to confusingly copy them instead (which JSI makes more difficult).
Changelog:
Internal
Reviewed By: nlutsenko
Differential Revision: D34704455
fbshipit-source-id: 520a358d8a7adeb848e7d7eb204f7154f8f4b58d
Summary:
This moves the `indent` function into a `Utils` module so it can be also used to properly indent the abstract methods declarations in a C++ TurboModule spec.
Changelog:
Internal
Reviewed By: nlutsenko
Differential Revision: D34704456
fbshipit-source-id: 88a3a672e4860927b5dd1f5107f40da7b5a83e51
Summary:
Typically, ReactTextView#setText is called via ReactTextViewManager#updateExtraData, but natively animated color changes bypass render and layout pass via direct call to SurfaceMountingManager#updateProps from UIManager#synchronouslyUpdateViewOnUIThread.
Thus, for animated color changes to get applied, we need to handle the color prop in ReactTextAnchorViewManager.
In addition, native driver updates are not synchronized with Fabric's mounting; if the native driver update happens before mount, the update is done in updateState.
Changelog:
[Android][Added] - Support animating text color with native driver
Reviewed By: mdvacca
Differential Revision: D34630294
fbshipit-source-id: c0f1e19c801c0e909e84387d623a6556ce6f2d67
Summary:
Silence some warnings in xcode 13.3 by explicitly defining some copy constructors in JSI and adding a compiler flag in Hermes.
Changelog:
[Internal][Fixed] - Build issues
Reviewed By: jpporto
Differential Revision: D34526541
fbshipit-source-id: 7029e3d20b9209007cf7e9f4c935338513ee1dd0
Summary:
I accidentally broke CircleCI. This PR attempts to fix it by setting the requested CMake version to `3.18.1`.
We might have to bump the Docker image to fix this instead.
## Changelog
[Internal] - Attempt to fix CircleCI by bumping CMake to 3.18.1
Pull Request resolved: https://github.com/facebook/react-native/pull/33382
Test Plan: Will rely on Green CircleCI
Reviewed By: motiz88
Differential Revision: D34679269
Pulled By: cortinico
fbshipit-source-id: 2addb0914d900c5e712e905cf14a54d6028cf417
Summary:
Not having this disallows including turbo module and extending in places where RTTI is enabled.
There is no additional includes or implementation changes - it merely allows for things to nicely link with other libraries.
Changelog: [General][Fixed] - Allow including TurboModule.h in mixed rtti/no-rtti environment, even if TurboModule.h/cpp is compiled without RTTI.
Reviewed By: appden
Differential Revision: D34637168
fbshipit-source-id: 2e5d9e546bdc5652f06436fec3b12f1aa9daab05
Summary:
The issue to be fixed here is an edge case when in nested scroll view, for example vertical scroll wraps horizontal scroll, when user scrolls horizontally then move the joystick downwards, the horizontal scroll would bounce back. This is shown in the demo:
https://pxl.cl/209f8
The root cause of the issue is due to two workflows fight to set the scroll position and confusing the scroll change dispatcher to calculate fling velocity direction, which caused a wrong fling behavior. Check this log and description to get more details:
{F706620839}
To fix the issue, in this diff we overridden the `onInterceptTouchEvent` method in panel app scroll views, and make it return true when the previous scroll is still running. This effectively skips the drag slop in the default scroll view behavior, as we know the touch event should've been handled by the scroll view if it's still scrolling.
This way, the vertical scroll part on the vertical scroll view will not be dispatched to the horizontal scroll at all. This allows the nested scroll view to work separately.
Changelog:
[Android][Internal] - Share the post intercept touch event logic in scroll views
Reviewed By: javache
Differential Revision: D34627329
fbshipit-source-id: d500ec3bfbe349a45ef5c1360b5c8807c168f682
Summary:
This diff aims to fix an issue I found while working on T113264056. It's to address the [comment](https://www.internalfb.com/diff/D3207608 (https://github.com/facebook/react-native/commit/a3146e41a259175f0c79e3c213523a0fb21613d7)?dst_version_fbid=507451319451602&transaction_fbid=1615731455398227) in an old diff D3207608 (https://github.com/facebook/react-native/commit/a3146e41a259175f0c79e3c213523a0fb21613d7). That issue begins to surface after I made the change in the next diff, which is discussed in detail in the task description (T113385381).
The fix here is to cancel the post touch processing when a new touch down is received. This should've cancel any previous post touch processing as the new touch should take full control of scrolling.
Changelog:
[Android][Fixed] - Cancel post touch process when new touch is received
Reviewed By: javache
Differential Revision: D34627330
fbshipit-source-id: 1fb8cfc1a4d94349b5290915a0a9f190186f2af3
Summary:
Why Lacrima?
- Throw a JavascriptException in native won't get the js error reported to backend, we need to use reporter APIs
- Lacrima is a new error reporting framework to report crashes and app deaths in android applications at Facebook, and it has APIs for reporting js exceptions.
- ```FbErrorReporterImpl.java``` uses ```Acra``` API to report, and ```Lacrima``` is a rewrite of ```Acra``` https://fb.workplace.com/groups/323014308578038/
- We've been receiving js errors reported via Lacrima https://fburl.com/logview/y1vhc8u8
In this diff all js errors are treated as soft errors during reporting because they don't usually crash the app, crashes will be reported with a different category.
Changelog:
[Android][Chagned] - Change static string to public
Reviewed By: fkgozali
Differential Revision: D34095100
fbshipit-source-id: 73d89647134a197baf5d228d620732781b6bd723
Summary:
The `get*` methods will assert and thus crash if JS passes a value by the wrong type. Although we have type checking, we should strive to never crash the app if an incorrect value slips by. The `as*` variants will throw an error back into JS instead.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34630900
fbshipit-source-id: 5ec55ca08ca7a1f43b2d9bfbb1d4e6fa89146e12
Summary:
This sets up the publishing of the `hermes-engine` to end up in the Maven Local repository
we have set up inside the ./android folder of the NPM package of `react-native`.
Artifacts from there will be picked up similarly to what it's happening for React Android
Changelog:
[Internal] [Changed] - Setup publishing for the `ReactAndroid/hermes-engine` to the top level `/android` folder.
Reviewed By: hramos
Differential Revision: D34213638
fbshipit-source-id: adbc0d1559ee815f9d7a711c9c77489ec92b76ff
Summary:
This commits sets up an Android library by applying the plugin
and configuring all the necessary flags.
Flags have been adapted from:
https://github.com/facebook/hermes/blob/main/android/hermes/build.gradle
Removing the unnecesary ones and adapting the build to conform
to the React Native build system.
Changelog:
[Internal] [Changed] - Setup an android library project inside `ReactAndroid/hermes-engine`
Reviewed By: hramos
Differential Revision: D34213534
fbshipit-source-id: c2e7b810bf4c4b1831a764a6f76cb73722da2125
Summary:
As the title says, we need to invoke:
```
./utils/build/configure.py ./ninja_build
cmake --build ./ninja_build --target hermesc
```
In order to build the Hermes compiler, otherwise the CMake build
will fail with a missing Cmake file.
Changelog:
[Internal] [Changed] - Create a Gradle task to setup the Hermes Ninja build
Reviewed By: hramos
Differential Revision: D34213468
fbshipit-source-id: 83f70bdb068f99ce17a44207b4282fde2d7420ca
Summary:
This Diff sets up a small Gradle build inside `ReactAndroid/hermes-engine`
The idea is to kickoff a small project where we can download Hermes sources and start a compilation of
the Hermes sources from there.
Specifically the used paths are:
- `/sdk/hermes` for the unzipping
- `/sdk/download/hermes.tar.gz` for the tarball location
- `/sdk/hermes/.hermesversion` for the hermes version.
allow-large-files
Changelog:
[Internal] [Changed] - Setup a Gradle build inside `hermes-engine` to download Hermes sources
Reviewed By: hramos
Differential Revision: D34210236
fbshipit-source-id: 97034f5608dfb3fcd1d74e9851944f7a60e52ea1
Summary:
Original commit changeset: f1c831a45f96
Original Phabricator Diff: D34552175 (https://github.com/facebook/react-native/commit/6a4e905e3a4cccb7c134e8504a1c6674e23b1b70)
Changelog:
[Android][Fixed] - Revert back a previous change that could cause null pointer exception on UI manager
----
Context:
We were flagged a spiking crash on BizApp v348 (T113279390). We were able to repro the issue on multiple UI components on BizApp so we suspect it's caused by some kind of RN infra issue.
Unfortunately the issue can't be always reproed so we can't do a biset.
Based on mdvacca's initial assessment, the original diff D34552175 (https://github.com/facebook/react-native/commit/6a4e905e3a4cccb7c134e8504a1c6674e23b1b70) was landed right before version 348.0.0.0.114 was created which aligns with the timeline of the crash (see attached task).
We've also tried to backout the diff locally and tested for multiple Pages and seems the crash disappears - so we decided to give it a shot and see if this could mitigate the crash on RC.
Reviewed By: mdvacca
Differential Revision: D34632014
fbshipit-source-id: ce589d6e7d2293befc3615ecb87a9fc09f6a33f4
Summary:
We're seeing a red box that `Component 'RCTModalHostView' re-registered bubbling event 'topDismiss' as a direct event moduleConstantsForComponent` in some downstream react-native-macOS builds.
Looking at other usage of this object, we treat it as a direct event block everywhere else, just this one spot it's a bubbling event block. It was added with [this PR](https://github.com/facebook/react-native/commit/7bf78eae5e2d53438bc333d3b9995b218f74c84b) which doesn't explicitly address the desire for the prop to bubble up through the view hierarchy or not, so I'm guessing it was just mislabeled and should be direct like the other usages.
## Changelog
[iOS] [Bug] - Fix modal redbox for onDismiss
Pull Request resolved: https://github.com/facebook/react-native/pull/33222
Test Plan: We don't redbox downstream anymore
Reviewed By: p-sun, RSNara
Differential Revision: D34628759
Pulled By: philIip
fbshipit-source-id: bb3cc78fa43d20808579c614e25716880d002d88
Summary:
changelog: [internal]
I'm looking into JS exceptions in React 18 on Android and I've noticed we use [std::unordered_set::contains]((https://en.cppreference.com/w/cpp/container/unordered_set/contains) that is only supported in C++20. I don't think this causes the exceptions but I would like to eliminate this option.
Reviewed By: javache
Differential Revision: D34547741
fbshipit-source-id: 6cffcff3366e7579a2c0e19bc01ffcb355b9ddb6
Summary:
changelog: [internal]
ViewState is sometimes deleted but not created again because of race condition in C++ pre-allocation and how it checks for revision to determine if createView mount item should be dispatched.
In this diff, we add an option to delay deletion of ViewState until the next commit.
Reviewed By: ShikaSD
Differential Revision: D34553174
fbshipit-source-id: e5213f1d39137fb56fc745321a7c1b28d417ea27
Summary:
changelog: [internal]
Make all feature flags `const` and initialise them as ivars. Also makes the class final and removes virtualised destructor since it is not needed.
Reviewed By: ShikaSD
Differential Revision: D34549013
fbshipit-source-id: 2b326bc5b6c1dd6d89c2fb9c671bda6da669fa76
Summary:
Changelog: [iOS] Add `_viewRegistry_DEPRECATED addUIBlock` to replace `uiManager addUIBlock` for Fabric migration
Allow people to directly replace `uiManager addUIBlock` with `_viewRegistry_DEPRECATED addUIBlock` when they migrate the method in RCTViewManagers.
Currently we add an if check in the RCTViewManager, which makes migration a bit harder for OSS.
```
if (self.bridge) {
[self.bridge.uiManager addUIBlock:^(__unused RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
work();
}];
} else {
RCTExecuteOnMainQueue(work);
}
```
Reviewed By: sammy-SC
Differential Revision: D34532609
fbshipit-source-id: 19647fea03be8fd71d8f46dfe216275894d8165c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33209
Downloads Kotlin compiler JARs with Buck before starting docker build. This solution is slower than checking in JARs directly, but it allows to keep lighter size of the repo for people who want a complete checkout.
Changelog: [Internal] - Update CI build to download Kotlin jars for buck
Reviewed By: cortinico
Differential Revision: D34582932
fbshipit-source-id: 290398579ce2a4d57c7af318c66526689db6073c
Summary:
In preparation for upcoming changes, it is useful / necessary to have a CustomEvent and Event polyfill for React Native.
In browser environments, both of those are expected to be accessible in the global scope, so we do the same here.
Changelog: [Added][JS] Event and CustomEvent W3C-compatible polyfills
Reviewed By: necolas
Differential Revision: D34462447
fbshipit-source-id: 5efdad6f24c268a6d248d4e3351fc96715ee3fdf
Summary:
Due to a bug with AGP, the configureNdkBuild* tasks are not depending on
preBuild tasks. We need to manually fix this otherwise the build will fail the
first time the NDK is invoked.
More on this here: https://issuetracker.google.com/issues/207403732
Changelog:
[Android] [Fixed] - Make sure configureNdkBuild* tasks are depending on
preBuild in the Android template.
Reviewed By: passy
Differential Revision: D34578860
fbshipit-source-id: 5d4caa7d2b7a976b1c9caa6dce8e186c1486cafa
Summary:
Per Android docs (https://developer.android.com/reference/android/graphics/Paint#FILTER_BITMAP_FLAG):
> This should generally be on when drawing bitmaps, unless performance-bound (rendering to software canvas) or preferring pixelation artifacts to blurriness when scaling significantly.
Changelog:
[Android][Fixed] - Improve rendering of images when resampled and corner radius applied
Reviewed By: genkikondo
Differential Revision: D34551184
fbshipit-source-id: 649da53af816be829e5b7f8e2a100f07a8b412b7
Summary:
Changelog:
[iOS][Changed] - Removed methodName parameter that was used only for a warning message and moved the warning parameter to be calculated inline.
Reviewed By: fkgozali
Differential Revision: D34551444
fbshipit-source-id: 6ceba425b64df37b0dca7e222072f1836f151d83
Summary:
Disables preallocation for cloned nodes, switching to create during commit for those cases instead.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34555621
fbshipit-source-id: 21fc834cea318ca299aa37a9aab28a2f2a9675b5
Summary:
The props generator assumes that Props are used only on iOS. (i.e: the generator doesn't generate the props code if the iOS platform is excluded). However, Props are also used on Android. So, this diff makes us generate Props for all platforms.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34559900
fbshipit-source-id: 0c25835dd57aa55a094152c147a9f952b9bc6850
Summary:
This should fix the SVC === NVC check for ScrollView and AndroidHorizontalScrollView.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34542873
fbshipit-source-id: 7e25d3a6c1417877b64501981652d767ba2eda48
Summary:
The static ViewConfig codegen generates the static ViewConfig inside the JavaScript module [under an exported constant](https://github.com/facebook/react-native/blob/a0a2958cdac767f50084c2d5bee6cf224ffb9db3/packages/react-native-codegen/src/generators/components/GenerateViewConfigJs.js#L127-L129):
```
export const __INTERNAL_VIEW_CONFIG = VIEW_CONFIG;
export default NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
```
This exported constant allows us to build a test page that requires all components, and compares their static ViewConfigs with their native ViewConfig.
This diff makes components with hand-written static ViewConfigs also export this __INTERNAL_VIEW_CONFIG const.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34541868
fbshipit-source-id: f55dd3f1b161038baaf84cbbf75c1f4041c34647
Summary:
remove duplicate code in FabricUIManager
The removed line is already called few lines above
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D34553849
fbshipit-source-id: 2e0102a77e7464c9803fb1175385fdafbb88f1fa
Summary:
This diff fixes overflowInset calculation when a shadow node has transform matrix from a transfrom prop in JS. Specifically, this fixed the use case when transform directly used on a view component. When using Animated.View, it will create an invisible wrapper which will behave correctly with existing logic. This diff bring both use cases to work properly.
When a shadow node has transform on it, it will affect the overflowInset values for its parent nodes, but won't affect its own or any of its child nodes overflowInset values. This is obvious for translateX/Y case, but not for scale case. Take a look at the following case:
```
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│Original Layout │ │ Translate AB │ │ Scale AB │
└────────────────┘ └────────────────┘ └────────────────┘
─────▶ ◀───── ─────▶
┌ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ┐ ┌ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ─ ┐
│ A │ │ A │ │ A │
│ │ │ │ │ │ │ │ ├ ─ ─ ─ ─ ─ ┼ ─ ─┌─────┤─ ─ ─ ─ ─ ┤
─ ─ ─ ─│─ ─ ─┌───┐┼ ─ ─ ─ ─ │ │ ◀─ ─ ─ │ │AB │ ─ ─ ─▶
│ │ │AB ││ │ │ ┌ ─ ─ ┼ ─ ─ ─ ┬──┴┬ ─ ─ ─ ─ ┤ │ │ │ │ │
└─────┤ ├┘ └───────┤AB │ └────┤ │
│ │┌──┴─────────┤ │ │ │ │ │ │ │ │ ┌───┴──────────┤
││ABC │ │┌──┴─────────┐ │ │ABC │
│ │└──┬─────────┤ │ │ │ ││ABC │ │ │ │ │ │ │
┌───ABD───────┴─┐ │ │ │└──┬─────────┘ │ ▼ │ └───┬──────────┘
├─────────────┬─┘ │ │ │ │ ├───ABD───────┴─┐ │ │ │ ├────────────────┴──┐ │ │
─ ─ ─ ─ ─ ─ ─└───┘─ ─ ─ ─ ─ ▼ └─────────────┬─┘ │ ▼ │ ABD │ │
└ ┴ ─ ─ ─ ─ ─ ─ ┴───┴ ─ ─ ─ ─ ┘ ├────────────────┬──┘ │ │
─ ─ ─ ─ ─ ─ ─ ─ ┴─────┴ ─ ─ ─ ─ ─
```
For the translate case, only view A has change on the overflowInset values for `right` and `bottom`. Note that the `left` and `top` are not changed as we union before and after transform is applied.
For the scale case, similar things are happening for view A, and both `left`, `right`, and `bottom` values are increased. However, for View AB or any of its children, they only *appear* to be increased, but that is purely cosmetic as it's caused by transform. The actual values are not changed, which will later be converted during render phase to actual pixels on screen.
In summary, overflowInset is affected from child nodes transform matrix to the current node (bottom up), but not from transform matrix on the current node to child nodes (top down). So the correct way to apply transform is to make it only affect calculating `contentFrame` during layout, which collects child nodes layout information and their transforms. The `contentFrame` is then used to decide the overflowInset values for the parent node. The current transform matrix on parent node is never used as it's not affecting overflowInset for the current node or its child nodes.
This diff reflects the context above with added unit test to cover the scale and translate transform matrix.
Changelog:
[Android/IOS][Fixed] - Fixed how we calculate overflowInset with transform matrix
Reviewed By: sammy-SC
Differential Revision: D34433404
fbshipit-source-id: 0e48e4af4cfd5a6dd32a30e7667686e8ef1a7004
Summary:
## Problem
the partialLoadHandler is nil on line 338 of RCTImageLoader, therefore, if there is a cached image, it would crash on line 495.
## Change
Check if partialLoadHandler is nil on line 495 to prevent the crash
Changelog: [iOS][Changed] - fix the crash caused by nil partialLoadHandler
Reviewed By: appden
Differential Revision: D34544090
fbshipit-source-id: f9965700e529c5add1e25867a3772c053447d99a
Summary:
Annotate use of `ConcurrentRoot` in React in performance logger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34453147
fbshipit-source-id: 813a58ae964e5ae4ddf806a30597ee39d315e800
Summary:
This adjusts the previously unused (but fully working!) `rn_codegen_cxx_modules` rule to be consistent with the other codegen rules and calls it from the `rn_codegen` with the "JSI" suffix to not conflict with the other rules, and to match the convention established by hand-written C++ TurboModules.
Changelog:
Internal
Reviewed By: RSNara
Differential Revision: D34451208
fbshipit-source-id: 4d779b068dfa4f7fd73fd3bca354fffe86d01f73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33196
Fixes compilation of Android template and renames the field according to Java guidelines.
Changelog: [Android][Changed] - Rename field with default values for ReactConfig to DEFAULT_CONFIG
Reviewed By: cortinico
Differential Revision: D34523356
fbshipit-source-id: 46ed703e7ca8ab5e05879dd93e8e4d2d816c2d03
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.69.0](https://github.com/facebook/metro/releases/tag/v0.69.0).
Changelog:
[General] Update direct Metro dependencies to 0.69.0
Reviewed By: motiz88
Differential Revision: D34520074
fbshipit-source-id: 93b9f5fa8ccc65132c9c96b23080edb5a339d5ce
Summary:
This PR adds comments explaining the reason why the `NativeDatePickerAndroid.js` file was kept when removing `DatePickerAndroid`(https://github.com/facebook/react-native/commit/7a770526c626e6659a12939f8c61057a688aa623 ) in order to prevent people from trying to delete it, as this file has no references in the Github repo
## Changelog
[Internal] [Added] - Add comments explaining the existence of NativeDatePickerAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/33159
Test Plan: Ensure builds are still working correctly, although this just adds a comment
Reviewed By: cortinico
Differential Revision: D34487638
Pulled By: lunaleaps
fbshipit-source-id: 42cb7331e98d69ff2f69f19bfbb2e65c063120f7
Summary:
See the main spec preserve_paths, they are all also included as source_files. Without this, the folly fabric header files won't be available for other pods.
## Changelog
[iOS] [Fixed] - Include folly fabric headers in source files
Pull Request resolved: https://github.com/facebook/react-native/pull/33188
Test Plan:
Include react-native-safe-area-context 4.0.1 with new architecture active. It will result in a xcode build error:
<img width="466" alt="Screenshot 2022-02-26 at 19 33 35" src="https://user-images.githubusercontent.com/996231/155855017-8ea5f473-42a0-4e56-8108-472e6224ae7e.png">
Reviewed By: cortinico
Differential Revision: D34518841
Pulled By: motiz88
fbshipit-source-id: 1053fe204331a314427c793f28b2458e7b78e6c5
Summary:
See https://docs.fastlane.tools/best-practices/source-control/
This commit reflects the best practices as outlined by fastlane.
## Changelog
[iOS] [Fixed] - Improved template fastlane gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/33186
Test Plan: no test plan
Reviewed By: cortinico
Differential Revision: D34518831
Pulled By: motiz88
fbshipit-source-id: eee1d332f24caa37bc48fd058bf0eb0e73f6bc1b
Summary:
TextMeasurement destructor is not necessary, we are deleting it
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D34246015
fbshipit-source-id: 6ca4803fafc8b195828d546ba8fb45353257f383
Summary:
TextLayoutManger should be not copyable / not movable
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D34246013
fbshipit-source-id: dc20db2ad9e2709ddca5bef5218356bd2b292c2d
Summary:
Introduce DefaultValuesReactNativeConfig constant that represents a ReactNativeConfig that always return default values
I also use this constant in all the apps using fbaric that don't have a custom Mobile Config
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D34160478
fbshipit-source-id: 5730054fd4cc87e1fe5dc8247cc237194bf48981
Summary:
## Problem
Previously the RN Image render the cached images asynchronously (line 555 and 594 prior to the change), which caused the images to render at least a frame later than the adjacent components.
## Change
In this change, we call partialLoadHandler with the cached image synchronously on the main thread.
Changelog: [iOS][Changed] - Synchronously render cached images
Reviewed By: p-sun
Differential Revision: D34487673
fbshipit-source-id: 0600c2fa5f7a1eca71b8582bbe968694cf211468
Summary:
Changelog: [iOS][Internal] Use synthesize viewRegistry_DEPRECATED for Keyframes to remove RCTWeakViewHolder
Remove the `RCTWeakViewHolder` hack, since it can be replaced with `viewRegistry_DEPRECATED viewForReactTag`.
Reviewed By: RSNara
Differential Revision: D34468082
fbshipit-source-id: be41ed2df6ee195409724f6069fd99a793dca01a
Summary:
React Native releases that bundle the Hermes source code will have a `sdks/.hermesversion` file which indicates the specific git tag used when pulling the Hermes source code.
This script provides a method for release coordinators to specify which Hermes tag will be used in a given release. The Hermes tag should already exist on the `facebook/hermes` repository on GitHub, although this script makes no determination as to its validity.
# Changelog
[Internal] Added new script for release coordinators
Reviewed By: cortinico
Differential Revision: D34460693
fbshipit-source-id: b2f882ba66d925034c3803aafe81de5204d9e33f
Summary:
Changing fbjni's mapException interface to use `std::exception_ptr`, this enables us to use `std::rethrow_exception` and `catch` statements to check for specific exception types, rather than using dynamic_casts and having an explicit dependency on RTTI.
While generally, we should always be enabling RTTI and exception support simultaneously, we have a number of targets where we don't, or where avoiding RTTI provides significant binary size gains.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D34379950
fbshipit-source-id: 446d105f9fb50ada3526f242f98e163215abd0ab
Summary:
Changelog: [iOS][Internal] 4/5 Attach synthesize ivars to RCTViewManagers using RCTBridgeModuleDecorator in Bridgeless mode
- In RCTInstance, insert RCTBridgeModuleDecorator into RCTInstance into contextContainer
- In LegacyViewManagerInteropComponentDescriptor.mm, unwrap RCTBridgeModuleDecorator from contextContainer
- Then pass RCTBridgeModuleDecorator from LegacyViewManagerInteropComponentDescriptor to RCTLegacyViewManagerInteropCoordinator
- In RCTLegacyViewManagerInteropCoordinator, call `RCTBridgeModuleDecorator attachInteropAPIsToModule` to attach synthesize ivars to all RCTViewManagers.
This does not affect Bridge mode.
Reviewed By: RSNara
Differential Revision: D34439950
fbshipit-source-id: d814c56a52f226e3a2c96fea01efb51afc571721
Summary:
Changelog: 2/n Refactor RCTModuleData to use RCTBridgeModuleDecorator, to attach synthesize ivars to non-TurboModule RCTBridgeModules in Bridge mode
I decided to not include the `RCT_PROFILE_BEGIN_EVENT`s in [RCTBridgeModuleDecorator attachInteropAPIsToModule] because people don't override the set methods for the 4 synthesize ivars, so setting each ivar should be instant.
Reviewed By: RSNara
Differential Revision: D34438180
fbshipit-source-id: 871ac4cadd7a36821dac1274f0645c19d63943fc
Summary:
Changelog: [iOS][Internal] Refactor CxxBridge: Introduce RCTBridgeModuleDecorator to attach synthesize ivars to RCTTurboModules, in Bridge mode
This doesn't change any logic. RCTBridgeModuleDecorator was created to consolidate several nearly identical implementations of the `attachInteropAPIsToModule` method to one place.
Most importantly, it allows us to attach interop APIs in RCTBridgeModuleDecorator to RCTViewManagers in diff 4/4, using `attachInteropAPIsToModule`. Before this stack, these four synthesize ivars in RCTViewManagers are nil in Bridgeless mode, and point to instances in Bridge mode.
# Context
These are used in RCTBridgeModules to access APIs for view managers. These APIs are necessary and compatible with Bridgeless mode.
* synthesize viewRegistry_DEPRECATED
* synthesize bundleManager
* synthesize callableJSModules
* synthesize moduleRegistry
Reviewed By: RSNara
Differential Revision: D34437802
fbshipit-source-id: b773d511cf877d4896436fabf4893c978e5f8dd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33182
This information can be checked by the type system + `DynamicColorIOS` supports other properties now.
Changelog: [Removed][iOS] - Removed lint restricting `DynamicColorIOS` to only two properties
Reviewed By: cortinico
Differential Revision: D34475985
fbshipit-source-id: c4190adad05e68b0a38a6ec89862372d9af55894
Summary:
`size_` will always match `keys_.size()` so we don't have to keep track of it.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34391445
fbshipit-source-id: f6c9316c989137425abfb7b3d72b571d08240f34
Summary:
Added a null check to native.value in Switch to fix regression from RN 66 -> stuck operation in mViewCommandOperations list in Android Release on initial layout of a screen with Switch component. If approved, please incorporate this fix into an RN 66 release.
## Changelog
[Android][Fixed] - Added a null check to native.value in Switch to fix https://github.com/facebook/react-native/issues/32594
Pull Request resolved: https://github.com/facebook/react-native/pull/32602
Test Plan: To reproduce, put a log in UIViewOperationQueue in dispatchViewUpdates you can see that the RetryableMountingException is no longer thrown for a screen with the Switch component on Android Release. As a result, mViewCommandOperations no longer has a stuck operation on initial layout.
Reviewed By: charlesbdudley
Differential Revision: D34397788
Pulled By: lunaleaps
fbshipit-source-id: 1cee3516fb987942dfa50ad1f2d11c965a947f05
Summary:
If Hermes is enabled on a project and the envvar `BUILD_HERMES_SOURCE` is truthy, a React Native project will build Hermes from source when running `pod install`:
```
cd ios/
BUILD_HERMES_SOURCE=1 pod install
```
* Requires `cmake` and `ninja` to be installed: `brew install cmake ninja`.
* Requires a `react-native` release with Hermes source code bundled in (`scripts/publish-npm.js --include-hermes && npm pack`).
# Changelog
[Internal]
Reviewed By: cortinico
Differential Revision: D34313581
fbshipit-source-id: 4ba5f82aa6c7027fd37f1982127fc5f63d931ded
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33168
Buck Kotlin setup requires jars to be available locally before the build, so we are checking them in.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D34419817
fbshipit-source-id: 5e75f0f3818fb76b640349c003bd258bc12aa53d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33166
`pure_kotlin` kwarg doesn't exist in the OSS Buck definition, so we should remove it
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D34417682
fbshipit-source-id: 24a0d1adb15dc244d37be7ded12e244619cc803c
Summary:
Doing this patch level bump to ensure that all packages consuming `react-native` will get `7.0.3` and not lower 7.x versions.
This is because this new patch contains this fix: https://github.com/react-native-community/cli/pull/1560
(thanks NickGerleman & thymikee for your work!)
We'll have to cherry-pick this into the 0.68 branch.
While at it, I've also done a cheeky `npx yarn-deduplicate` to clean up the `yarn.lock` a bit.
## 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] - Bump RN CLI to v7.0.3 to address web debugging issue
Pull Request resolved: https://github.com/facebook/react-native/pull/33156
Test Plan:
CI + some local testing via `test-manual-e2e`:
<img width="1779" alt="Screenshot 2022-02-21 at 11 40 54" src="https://user-images.githubusercontent.com/16104054/154948695-8c40bb56-87eb-4326-a740-49930994c08b.png">
Reviewed By: cortinico
Differential Revision: D34385503
Pulled By: motiz88
fbshipit-source-id: f0d8c4e0e92f83c0d819eeaa0fbec27820145968
Summary:
With the `MapBuffer`-based props calculated from C++ props, there's no need to keep `rawProps` around for Android views.
This change makes sure that the `rawProps` field is only initialized under the feature flag that is responsible for enabling `MapBuffer` for prop diffing, potentially decreasing memory footprint and speeding up node initialization as JS props don't have to be converted to `folly::dynamic` anymore.
For layout animations, props rely on C++ values, so there's no need to update `rawProps` values either.
Changelog: [Internal][Android] - Do not init `rawProps` when mapbuffer serialization is used for ViewProps.
Reviewed By: mdvacca
Differential Revision: D33793044
fbshipit-source-id: 35873b10d3ca8b152b25344ef2c27aff9641846f
Summary:
If `--include-hermes` flag is set, the Hermes source code will be downloaded and included in the `react-native` npm package as part of the release.
Hermes will be available at `node_modules/react-native/third-party-podspecs/hermes`.
# Changelog
[Internal] Update build scripts to provide option to bundle Hermes source code
Reviewed By: cortinico
Differential Revision: D34255926
fbshipit-source-id: 76c1e9811a05a4a827ceba13e572d0ea756ac724
Summary:
Provides an alternative way of diffing props on Android side. Instead of passing dynamic JSON values from JS, the new approach diff C++ props and serializes difference into a `MapBuffer`. Current implementation does this only for `RCTView` component to test performance, correctness and memory impact (as MapBuffers are supposed to be more compact and performant).
This way of passing props allows for additional alignment between platforms, as C++ props are now source of truth for the view state, similar to iOS. At the same time, changing serialization method requires reimplementing `ViewManager` codegen (done manually for now) to account for `MapBuffer`s.
Changelog: [Added][Android] - Added an experimental prop serialization path based on MapBuffer
Reviewed By: mdvacca
Differential Revision: D33735245
fbshipit-source-id: 1515b5fe92f6557ae55abe215ce48277c83974a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33160
Enables Kotlin build in RNAndroid, while adjusting the package structure to help with path/package inconsistency.
Moves `react/uimanager/interfaces` files into `react/uimanager` to make sure package name matches with file location and updates Buck configuration to still include it as a separate target.
Changelog: [Android][Changed] - Moved `com/react/facebook/uimanager/interfaces` files into `com/react/facebook/uimanager` to enable Kotlin build
Reviewed By: cortinico
Differential Revision: D34381179
fbshipit-source-id: 252588d9c7f62b8019bdfcce66197628d63e63a1
Summary:
Creates a mapbuffer from two ViewProp objects. This MapBuffer is used later instead of bag of props from JS to set the properties with platform ViewManager.
Changelog: [Internal] - Added MapBuffer diffing for ViewProps
Reviewed By: mdvacca
Differential Revision: D33735246
fbshipit-source-id: 10ad46251ea71aa844586624c888f5223fa44e57
Summary:
Parses a set of props previously missing from C++ representation (they weren't required for iOS and core processing before).
Changelog: [Internal] - Added missing fields for Android to C++ view props
Reviewed By: sammy-SC
Differential Revision: D33797489
fbshipit-source-id: 1625baa0c1a592fcef409a5f206496dff0368912
Summary:
Small performance improvement since we don't need to copy the char * into a string just for the sake of comparison.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34351387
fbshipit-source-id: 10163164f6e95ab0737e8f865c37d8f0c3500662
Summary:
Changes `peek`->`poll` on Animated node queues to a single `poll`, accounting for race conditions. In case the queue batch is split at some point, previously polled operation is kept as a "carry-over" inside the queue abstraction.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34377737
fbshipit-source-id: 78e5ca60c4777576fbf009c3d3ffa53629221910
Summary:
This Diff updates the RNTester README to support Mac M1 laptops.
## Changelog
[General][Changed] - Updated `rn-tester/README.md` to include instructions for Mac M1 users
Reviewed By: cortinico
Differential Revision: D34376951
fbshipit-source-id: 7195bddefb6e202261fef9b5f5225484c506fd9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33140
Pull Request resolved: https://github.com/facebook/metro/pull/776
This Diff moves the `SegmentedComponentIOS` away from the core of React Native to move forward with the Lean Core effort
## Changelog
[General][Removed] - This diff removes the `SegmentedControlIOS` export from React Native. Internally, we are requiring `SegmentedControlIOS` directly now and externally people will have to use the community maintained module (https://github.com/react-native-segmented-control).
Reviewed By: cortinico
Differential Revision: D34304255
fbshipit-source-id: d4e2b0bda56708769603be6f164e6bf89997fd93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33146
Pull Request resolved: https://github.com/facebook/react-native/pull/33145
It removes the find node script that introduced complexity in the system.
## Changelog
[Internal][Removed] - Removed the old `find-node.sh` script which was only adding complexity without doing nothing really useful.
Reviewed By: cortinico
Differential Revision: D34352049
fbshipit-source-id: 9ba4275c3863a1ae4bc2b4e2f1694a7ac994cdc8
Summary:
The concurrent queue seems to leak values on some Android 12 devices when interleaving instruction polling and execution. To help with that, we can drain the queue before executing operations, reducing the window when `add` and `poll` happen concurrently.
Changelog: [Internal] - Drain the Animated queue before execution
Reviewed By: JoshuaGross
Differential Revision: D34370056
fbshipit-source-id: 781631dbf1a10e3f1ba9564db985403bd77a2c06
Summary:
This diff refactors LayoutAnimation to use ReactNativeFeatureFlags.ENABLE_LAYOUT_ANIMATION to enable / disable this feature
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D34349648
fbshipit-source-id: 90d1db6560867e44eeffbf03e5a84edadcdd55f9
Summary:
introduce ReactNativeFeatureFlags file to control FeatureFlags in React Native
changelog: [JS][Added] Create new API to configure FeatureFlags in ReactNative
Reviewed By: JoshuaGross
Differential Revision: D34349458
fbshipit-source-id: 73bb3704fc47e950ee1fcefcfaec1a85dfbcef59
Summary:
Time to release a new version of the Gradle plugin and bump it to 0.0.5
This version includes a deprecation of `reactRoot` and a warning message
to migrate to `root`/`reactNativeDir`.
Changelog:
[Android] [Changed] - Release react-native-gradle-plugin 0.0.5
Reviewed By: ShikaSD
Differential Revision: D34339272
fbshipit-source-id: c03495bda7c4185d674761e58a94fde8612f2941
Summary:
I was seeing a SoftException in our apps due to this method being called as part of ReactInstanceManager's init. It seems inconsistent that we would call this from a background thread when all other `onHost*` methods are marked as confined to the UI thread.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D34340210
fbshipit-source-id: 0104eda66b2ca6bb315e64e806e9a30409d0d45c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33142
The `reactRoot` property was confusing as we were using it for both the root of the project
and the react-native NPM Package root. I'm deprecating it and splitting it in two.
I've added several warning in the codebase to tell the people how to migrate away from it.
Moreover this is specifying default values that are more user-friendly. Users won't have to
configure anything unless they are in a monorepo.
Changelog:
[Android] [Changed] - Gradle: Deprecate `reactRoot` in favor of `root` and `reactNativeDir`
Reviewed By: ShikaSD
Differential Revision: D34277050
fbshipit-source-id: fc7f45017452b086726516a9586cacd9a661c287
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33134
When a user is enabling New Architecture, we should make sure they don't accidentally mix
imports of React Native from source vs prebuilts.
With this resolution strategy, we'll make sure all the import of `com.facebook.react:react-native:+`
will be resolved to the correct dependency.
Changelog:
[Android] [Fixed] - Set a resolution strategy for com.facebook.react:react-native when on New Architecture
Reviewed By: ShikaSD
Differential Revision: D34303267
fbshipit-source-id: 492fec59175c5887571e1b09ca8e233584b45dd1
Summary:
`prettier` should not be declared in dependencies in the ESLint config because it can trigger issues when a different version is installed on the client app.
`prettier` is already declared as `peerDependencies` and in the [README](https://github.com/facebook/react-native/blob/main/packages/eslint-config-react-native-community/README.md), it's explicitly asked to install it:
```
yarn add --dev eslint prettier react-native-community/eslint-config
```
## 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] - Remove prettier from dependencies in eslint-config
Pull Request resolved: https://github.com/facebook/react-native/pull/33125
Test Plan: - Install the package `react-native-community/eslint-config` and ensure everything works the same as before
Reviewed By: yungsters
Differential Revision: D34305118
Pulled By: ShikaSD
fbshipit-source-id: 65a3a79008cd5e28cc6aa93ef4a5032990b4e9f8
Summary:
Deprecates the nonstandard `Promise.prototype.done` method. This also removes one call site within React Native itself that relied on this method.
As part of this we are also removing React Native's custom Flow definition for `Promise` in favour of the standard one built into Flow. This will flag uses of `done` as type errors for anyone using the default app template's `.flowconfig`.
In a future release of React Native, we will remove the `done` method from the built-in `Promise` polyfill.
Changelog:
[General][Deprecated] - Deprecate the Promise.prototype.done method and log a warning when it's called in development.
Reviewed By: yungsters
Differential Revision: D34222667
fbshipit-source-id: 4b9708ac20c45b3966fdb93e883ab7f8d80017c1
Summary:
I'm disabling the integration test step for `test_ios_unit_hermes` as they're currently failign wiht a
`SIGSEGV` introduced by 9010bfe457
The change is legit, but is introducing an ABI incompatibility that is making the app crash at runtime.
We can re-enable them as soon as Hermes 0.12.0 is released.
## Changelog
[Internal] - Unblock CI by disabling integration testing for `test_ios_unit_hermes`
Pull Request resolved: https://github.com/facebook/react-native/pull/33128
Test Plan: Will wait for a Circle CI green before merging
Reviewed By: neildhar
Differential Revision: D34285751
Pulled By: cortinico
fbshipit-source-id: 40f8e3d1b41fc4d5f0459003dcd19d651aefbeb7
Summary:
Changelog: [Internal]
In the new architecture, when an interop component is being called, log instead of warn/error, since at the moment we expect this to happen often.
Reviewed By: fkgozali
Differential Revision: D34252666
fbshipit-source-id: 971156a1cd9ef9b788f677c49fa2c55bd86ad4fa
Summary:
This diff allows to setup a Gradle Enterprise instance
either locally or on CI via an external Gradle script.
I've create a `.sample` script that users can copy to
start setting up their GE instance, should they have one.
Moreover, it applies the `com.gradle.enterprise` Gradle
plugin by default. This has the positive side effect of
not invalidating build cache for the included build if
you happen to pass the `--scan` flag in OSS (as the
classpath isn't changed).
Changelog:
[Android] [Added] - Allow to setup a Gradle Enterprise instance via an external script
Reviewed By: mdvacca
Differential Revision: D33582388
fbshipit-source-id: 0c2f073cf7a8e39963b0adfc3b339b14c1e7759b
Summary:
iOS will sometimes invoke the UIAlertAction handler for the cancel button more than once on iPad. This can be reproduced relatively easily by having a button that opens an action sheet and spam tapping outside the action sheet while it is opening. Since native module callbacks can only be invoked once this causes the app to crash here https://github.com/facebook/react-native/blob/main/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm#L206.
## Changelog
[iOS] [Fixed] - Fix action sheet callback invoked more than once on iPad
Pull Request resolved: https://github.com/facebook/react-native/pull/33099
Test Plan: Tested on iPad simulator to reproduce the crash and verified that this fixes it.
Reviewed By: philIip
Differential Revision: D34215327
Pulled By: ShikaSD
fbshipit-source-id: 6f406e4df737a57e6dd702dd54260aa72eab31d6
Summary: Upgrades `repo-config/package.json` to `coveralls@^3.1.1`, which removes the security vulnerability in `json-schema<0.4.0`.
Reviewed By: GijsWeterings
Differential Revision: D33961117
fbshipit-source-id: 375bd641686533d52f42adb9155dd642ae4c7cef
Summary:
Updates all dependencies in `bots/`, which also removes a security vulnerability with `websocket-extensions@<0.1.4`.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D33960461
fbshipit-source-id: 2d32ceba5ab09dc1bed5d6edc26a5134042dd29f
Summary:
This is a refactor of the logging of Fabric commit statistics to simplify the way we track performance points.
we'll later refactor and iterate on the API to integrate fabric perf point into developer tools
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D34006700
fbshipit-source-id: 93a01accd90dfacc8b44edd158033b442a843284
Summary:
Was trying out some behaviour when using the MapBuffer experiment and fixed some small issues.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34108859
fbshipit-source-id: 550ca0847419006ec17472cc4b70d38fc8d05396
Summary:
Brings the same fix https://www.internalfb.com/diff/D34015853 (https://github.com/facebook/react-native/commit/be260b9f479a3b55ee43d2959d2c49fd3c1eb4ac) for ReactScrollView to ReactHorizontalScrollView
When setting ScrollView's contentOffset, if the ScrollView hasn't been laid out yet when ReactHorizontalScrollViewManager.setContentOffset is called, then scroll position is never set properly. This is because the actual scroll offset (0, 0) was being passed into setPendingContentOffsets, instead of the desired scroll offset. Thus, when ReactHorizontalScrollView.onLayout gets called, ReactHorizontalScrollView.scrollTo gets called with (0, 0).
Changelog:
[Android][Fixed] - Fix ReactHorizontalScrollView contentOffset
Reviewed By: bvanderhoof
Differential Revision: D34246489
fbshipit-source-id: d923f7c9f136f7275d64bd658ffd5c2cc049d392
Summary:
Found that after backgrounding `mShouldStop` would always remain true, which prevents events from being dispatched / scheduled.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34247567
fbshipit-source-id: 63876986dc0cee5e2a73cb4f8a35d90379d9f8ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33108
The codegen config is optional and can be removed from the default package.json configuration in the template to simplify 0.68 upgrade for people who are not opted-in to the new arch.
Changelog: [Internal] - Remove optional codegenConfig field from template
Reviewed By: cortinico
Differential Revision: D34216988
fbshipit-source-id: 5c448472eed99bc112aef204c4025454171a83c5
Summary:
The check implemented in PR https://github.com/facebook/react-native/issues/29089 is flawed as the exception class name and message depends on the OS version as well as the OEM. In OxygenOS running android 11, it comes out as RuntimeException and the check fails and hence the crash occurs again. But on observing closely, its clear that the exception message is consistent across OEMs with similar strings appearing in them that have been included in the if check.
Hence there is a simple fix to this issue, by checking the message instead of the exception class.
Here is the snippet:
```
private Nullable CookieManager getCookieManager() {
if (mCookieManager == null) {
possiblyWorkaroundSyncManager(mContext);
try {
mCookieManager = CookieManager.getInstance();
} catch (IllegalArgumentException ex) {
// https://bugs.chromium.org/p/chromium/issues/detail?id=559720
return null;
} catch (Exception exception) {
String message = exception.getMessage();
// We cannot catch MissingWebViewPackageException as it is in a private / system API
// class. This validates the exception's message to ensure we are only handling this
// specific exception.
// The exception class doesn't always contain the correct name as it depends on the OEM
// and OS version. It is better to check the message for clues regarding the exception
// as that is somewhat consistent across OEMs.
// For instance, the Exception thrown on OxygenOS 11 is a RuntimeException but the message contains the required strings.
// https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/WebViewFactory.java#348
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException") ||
(message!=null && (message.contains("WebView provider") ||
message.contains("No WebView installed")))){
return null;
} else {
throw exception;
}
}
}
return mCookieManager;
}
```
## Changelog
[General] [Added] - A fail proof check to catch any crash involving webview:
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException") || (message!=null && (message.contains("WebView provider") || message.contains("No WebView installed"))))
[General] [Removed] - Flawed check to catch WebViewProvider crash:
if (message != null && exception.getClass().getCanonicalName().contains("MissingWebViewPackageException"))
Pull Request resolved: https://github.com/facebook/react-native/pull/33088
Test Plan:
This code has been tested rigorously on OnePlus Nord CE 5G (Oxygen OS 11.0) and Realme X (Realme UI 2.0) both running on Android 11 and reproducing the crash on a hybrid (Native android + ReactNative) app that showed this crash in production being dependent on WebViews. I have implemented an entire patched fork of 0.67.2 to fix this issue in our app.
How to test:
Launch any app that has a webview.
Go to settings->apps->Android System Webview -> disable.
Resume/Restart the app.
In this fix:
Open a webview and notice that the app will not crash.
In current version:
App crashes on startup as the exception escapes the catch block.
Even if it survives startup (did on Realme X), it will crash once you try to open a webview.
Reviewed By: rh389
Differential Revision: D34240097
Pulled By: cortinico
fbshipit-source-id: 0f1f9a3b078c0ad3074c7841392892cb70b427eb
Summary:
Changelog: [Internal]
# Diff Changes
- Set `RCTEnableNewArchitectureViolationReporting` to YES in app-wide Bridgeless mode.
- Rename `RCTWarnNotAllowedForNewArchitecture` to `RCTErrorNotAllowedForNewArchitecture`, and use `RCTLogError` instead of `RCTLogWarn` so the error goes to Logview.
Reviewed By: RSNara
Differential Revision: D34202682
fbshipit-source-id: 471486c65f7a42f8f11140e61ff60592dc826f61
Summary:
Changelog: [Internal]
After the diff Bridgeless and Bridge behaves the same for `RCTLogError` and `RCTLogWarn`.
Reviewed By: RSNara
Differential Revision: D34197703
fbshipit-source-id: 0645857aad609fa911df6681de9c0c251cf72a36
Summary:
Changelog: [Internal]
* Rename DummyUIManager to BridgelessUIManager
* Cleanup `RCTVirtualText` & `RCTShimmeringView` since the native changes from T107747313 are already in production, so these two will components always return a viewConfig in prod.
- `console.error` when deprecated Bridge UIManager method are being accessed.
- Make sure new BridgelessUIManager.js has the same method definition as [NativeUIManager.js](https://www.internalfb.com/code/fbsource/[e80c98b816183dcdfde1e81de01ba99aa6e30ed2]/xplat/js/react-native-github/Libraries/ReactNative/NativeUIManager.js?lines=15)
Reviewed By: RSNara
Differential Revision: D34203081
fbshipit-source-id: 99aafc2372b118d0c8cc41f7376e136dabae9bd5
Summary:
This diff integrates DeviceConfig into ReactNativeConfig used by ReactNativePanelApps. The goal is to be able to control Fabric MCs using GKs and QEs in RN VR apps
I did an audit of the MCs that were used by RNPanelApps:
```
"react_fabric:enabled_android_fabric_logs": -> will get data from GK (disabled by default)
"react_fabric:disable_virtual_node_preallocation": -> does not exist in code anymore
"react_fabric:enable_early_event_emitter_update": -> will get data from MC (disabled using static value)
"react_fabric:enable_background_executor_android": -> does not exist in code anymore
"react_fabric:enable_props_forwarding_android": -> does not exist in code anymore
"react_fabric:remove_outstanding_surfaces_on_destruction_android": -> will get data from MC static value (ENABLED using static value)
"react_fabric:enable_large_text_measure_cache_android": -> will get data from MC default value (ENABLED by default)
```
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33898210
fbshipit-source-id: 0ea1e0e2fc15929bec328f7dcc9410efa9925b34
Summary:
Before, when we called setValue with a PlatformColor, we unnecessarily called setValue on all component AnimatedValues before updateAnimatedNodeConfig.
This diff also fixes a bug where if we set a PlatformColor as the initial color, calling setValue with a non-PlatformColor would not have any effect. The fix is to reset AnimatedColor.nativeColor to null upon calling setValue.
Changelog:
[Internal] Optimize AnimatedColor when setting platform color
Reviewed By: javache
Differential Revision: D34187540
fbshipit-source-id: a0005d13f392a858d2eade912f2353f67eec1fd9
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.68.0](https://github.com/facebook/metro/releases/tag/v0.68.0).
Changelog:
[General] Update direct Metro dependencies to 0.68.0
Reviewed By: motiz88
Differential Revision: D34108380
fbshipit-source-id: 06bddfcc16e0f715d6d120e48b37c64fda300c38
Summary:
Changes an internal call site that assumes image assets are `number`s to use the more general `ImageSource` type.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D34076216
fbshipit-source-id: dc0dc0c39982c87c21385828bb3357f9654d029f
Summary:
Adds `number` to the `ColorValue` union type.
Per our docs, React Native supports specifying colours as RGBA values packed into ints: https://reactnative.dev/docs/colors#color-ints. It looks like this case was missed in D6226807 (https://github.com/facebook/react-native/commit/da047966e4c2064a48e02ff74830c99808d8194b) when we started typing the `StyleSheet` API with Flow.
Changelog: [General][Fixed] - Support numeric color values in StyleSheet's Flow types
Reviewed By: yungsters
Differential Revision: D34140748
fbshipit-source-id: 5bfe2995a473260926fa3c8b6926bb841615d393
Summary:
React Native has an *implicit* dev dependency on this transform via `metro-react-native-babel-transformer`. The transform replaces `Object.assign` with `babelHelpers.extend`, but `Object.assign` has been available natively since node 4.
We intend remove it from metro (https://github.com/facebook/metro/pull/745) as it's no longer needed by any supported runtime - removing RN's small dependency in advance so RN's tests won't break when we do.
Changelog:
[Internal][Changed] - Remove `babel/plugin-transform-object-assign` from jest preprocessor
Reviewed By: motiz88
Differential Revision: D34110208
fbshipit-source-id: 064f8241461fb338de1cd8b53077e8660301aa77
Summary:
Changelog:
[Internal] - Add an example to demo Animated colors with both JS and native drivers
Reviewed By: mdvacca
Differential Revision: D34153047
fbshipit-source-id: 9b61fd4e5f597b0440bed7ff1a33716e50ec34e5
Summary:
Now that animating color styles using native driver is supported on both Android and iOS, add color styles to the allowlist in NativeAnimatedHelper.
Changelog:
[General][Added] - Allow color styles to be animated using native driver
Reviewed By: mdvacca
Differential Revision: D34148038
fbshipit-source-id: c20dc149b805ec691a3936a77ab130fb4477a4c3
Summary:
Certain events (practically always touch events probably?) will not be correctly emitted to JS in Fabric if there is no View underneath the touch - if there is no touch target besides the ReactRootView.
We can just rely on the UIManagerType annotation on the Event, which is correct and reliable.
Instead, what we do today is derive UIManagerType from ViewTag, which is correct UNLESS the viewtag is the same as the SurfaceId, in which case we may incorrectly detect that the touch is on a non-Fabric View when in fact it is on a Fabric ReactRootView.
ViewTag is not a reliable way to detect Fabric vs non-Fabric /when looking at the RootView/, where ViewTag is the same as SurfaceId. Ironically, only Fabric RootViews have a SurfaceId at all.
Practically, this won't change anything since events emitted to ReactRootView don't go anywhere (they don't have EventEmitters). So this is a pretty low-stakes fix, but is still technically correct.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D34149878
fbshipit-source-id: f01da556865eb597a50cd49e9787316a0ed56f70
Summary:
Adds support for Animated.Color with native driver for iOS. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into a SharedColor.
Followup changes will include support for platform colors.
Ran update_pods: https://www.internalfb.com/intern/wiki/React_Native/Preparing_to_Ship/Open_Source_Pods/
Changelog:
[iOS][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: sammy-SC
Differential Revision: D33860583
fbshipit-source-id: 990ad0f754a21e3939f2cb233bcfa793ef12eb14
Summary:
Currently we are using Appcompat in version 1.0.2 which is almost 4 years old now, this PR updates it to version 1.4.1.
Using Appcompat 1.0.2 was also causing a crash on RNTester due to an error where FontFamily's method was not found (Related to https://github.com/facebook/react-native/issues/33065)
Closes https://github.com/facebook/react-native/issues/31620
## Changelog
[Android] [Changed] - Bump android Appcompat to 1.4.1
Pull Request resolved: https://github.com/facebook/react-native/pull/33072
Test Plan: Use `./scripts/test-manual-e2e.sh` to test both RNTester and a new app
Reviewed By: cortinico
Differential Revision: D34107105
Pulled By: ShikaSD
fbshipit-source-id: 966e4687b09ae50a88ee518622f073d72e8c6550
Summary:
That's a really nit change, but when we moved the Makefile deps to be on separate
lines, we havent' done the same for the codegen. Here I'm doing it.
Changelog:
[Internal] [Changed] - Place Android.mk dependencies on separate lines for codegen
Reviewed By: ShikaSD
Differential Revision: D34144715
fbshipit-source-id: be9d5fb75b6b93c0b2bb479145053ae6f201e1fc
Summary:
This comment was out of date.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D34113966
fbshipit-source-id: 0768baa9238736aea26e354792096fea6bb7fcdb
Summary:
The views with touch event props are currently flattened by Fabric core, as we don't take event listeners into account when calculating whether the view should be flattened. This results in a confusing situation when components with touch event listeners (e.g. `<View onTouchStart={() => {}} /> `) or ones using `PanResponder` are either ignored (iOS) or cause a crash (Android).
This change passes touch event props to C++ layer and uses them to calculate whether the view node should be flattened or not. It also refactors events to be kept as a singular bitset with 32 bit (~`uint32_t`).
Changelog: [Changed][General] Avoid flattening nodes with event props
Reviewed By: sammy-SC
Differential Revision: D34005536
fbshipit-source-id: 96255b389a7bfff4aa208a96fd0c173d9edf1512
Summary:
In https://github.com/facebook/react-native/issues/32975 I implemented the new `insetsController#setSystemBarsAppearance` interface, but I found that on Android 11 (API 30) it doesn't appear to work which I missed in earlier testing. It works correctly on Android 12 and the deprecated `systemUiVisibility` interface still works fine on Android 11, so I'm having Android 11 use the deprecated mechanism.
## 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
-->
[Android] [Fixed] - Fix StatusBar on Android API 30
Pull Request resolved: https://github.com/facebook/react-native/pull/33058
Test Plan: Tested in `rn-tester` on simulators using Android 9, 10, 11, 12, and on an Android 9 device.
Reviewed By: lunaleaps
Differential Revision: D34050025
Pulled By: ShikaSD
fbshipit-source-id: ad80fae1446aca368b09df810785a1cc38383450
Summary:
This is pre-work for adding the v8 stack trace API support.
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D34048366
fbshipit-source-id: 9d2b469767f7669cb428c61b215f193894892c03
Summary:
Changelog: [Internal]
Fixes `normalizeColor` to always return the normalized color. Previously, when normalization was delegated to `normalizeColorObject`, we would return the *original* color object, which is a bug.
Reviewed By: javache
Differential Revision: D34048595
fbshipit-source-id: 083cbe36be2311ea9cffe8ef61e6a986840aec71
Summary:
This diff adds `RedBoxSurfaceDelegate` to replace existing logic in `DevSupportManagerBase` to abstract how we show/hide the RedBox surface. The delegate will wrap a RedBoxDialog instance, which is used to show/hide the dialog for default behavior (when there is no surface delegate for redbox got provided).
I also updated the interface for delegate to accomodate new use cases:
- Add `isShowing` for the `SurfaceDelegate`
- Add a list of getters for `DevSupportManager` for data access in the delegate
- (Update 2/7) Separate Dialog from `RedBoxDialog`, and re-named it to `RedBoxContentView`. This is to make it clear that the delegate is responsible to provide actual surface implementation (Dialog). The content view is meant to be shared.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D33987835
fbshipit-source-id: 57c20648e7f2ec8238963feca27ccd5518e7931d
Summary:
Not setting locale for language/country neutral operation may cause bug depending on the default locale.
See https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#ROOT
Note: I am just searching for toLowerCase() and toUppercase() in my project's dependencies and send the same PR, in order to just be considered. Although I've seen the lack of explicit locale has caused issues for us, I am not sure if react-native is actually affected. I haven't checked for `String.format()` yet.
Example related issue: joltup/rn-fetch-blob#573
## Changelog
[Android] [Fixed] - Use root locale when converting string case.
Pull Request resolved: https://github.com/facebook/react-native/pull/33028
Reviewed By: ShikaSD
Differential Revision: D33943446
Pulled By: cortinico
fbshipit-source-id: d5be9392ea7c21a33436acac5b5e8c50b7c7e31e
Summary:
Changes to MapBuffer code in https://github.com/facebook/react-native/compare/aaff15c...d287598 broke build for Windows. Errors included incompatible type conversions, the use of `__attribute__(__packed__)` which is only supported by GCC and Clang, and the usage of designated initializers which are only supported on C++20.
Changes here restore build on Windows.
## 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] - Fix build break on Windows with ReactCommon
Pull Request resolved: https://github.com/facebook/react-native/pull/33047
Test Plan: React Native project built on Windows and passes react-native-windows repository pipeline. These edits are currently merged into the main branch of react-native-windows.
Reviewed By: ShikaSD
Differential Revision: D34101367
Pulled By: philIip
fbshipit-source-id: 1596365c2e92f377c6375805b33de5e1c7b78e66
Summary:
This is necessary otherwise when building from source on JVM < 11, the `compileJava`
task of the Gradle Plugin will fail with `invalid source: 11`.
Essentially the Gradle build will not even start because of this. Instead we delegate
to a better formatted warning from either AGP or from our plugin.
Changelog:
[Internal] [Changed] - Set Java source/target compatibility for react-native-gradle-plugin to 8
Reviewed By: ShikaSD
Differential Revision: D34111799
fbshipit-source-id: 57ab11fe6c4532576776b586f75e8fcb5c71adcd
Summary:
Removes duplicated code in SharedColor conversions. The original copy was done for the MapBuffer experiment, as the method was returning `folly::dynamic` instead of integer. Nothing prevents us from returning integer here directly, so we can keep one implementation.
Changelog: [Internal] - Removed duplicated SharedColor conversion for Android
Reviewed By: javache
Differential Revision: D33797490
fbshipit-source-id: 196657f0616e6cb7e987225b76328fe77fd6c28a
Summary:
you can see discussion here: https://github.com/reactwg/react-native-releases/discussions/13#discussioncomment-2069527
we were getting this error message when we build Gradle with other than 11 JVM
```
> Task :react-native-gradle-plugin:compileJava FAILED
2 actionable tasks: 2 executed
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':react-native-gradle-plugin:compileJava'.
> invalid source release: 11
```
this solution is suggested by mikehardy
after this PR, now the error is like this
```
**************************************************************************************************************
ERROR: requires JDK11 or higher.
Incompatible major version detected: '8'
**************************************************************************************************************
```
## 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
-->
[Android] [Fixed] - jvm 11 error message
Pull Request resolved: https://github.com/facebook/react-native/pull/33048
Test Plan: install other than 11 java version and just run `./scripts/test-manual-e2e.sh` this command at the root of RN repo than this error will appair `invalid source release: 11`
Reviewed By: ShikaSD
Differential Revision: D34110990
Pulled By: cortinico
fbshipit-source-id: c142a363c7cec0db65d5ab9da858fd25866c7c49
Summary:
I'm updating the `test_android_template` CI step to use the result of `build_npm_package` instead of sed-ing the RN version to `file:..`.
This should be more robust and will allow to install transitive deps automatically, without having to deal with separate installation steps.
This also fixes the broken CI for Android
Changelog:
[Internal] [Changed] - Update `test_android_template` to use `build_npm_package`
Pull Request resolved: https://github.com/facebook/react-native/pull/33068
Reviewed By: ShikaSD
Differential Revision: D34083047
Pulled By: cortinico
fbshipit-source-id: de34472d5737db445cfc0d4b1c6feaf1e746bb61
Summary:
This function is only used by the RNHostComponentList route. Let's move it into the route, so that we could keep the StaticViewConfigValidator slim.
This will also allow us to more heavily customize this function for the route.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34026073
fbshipit-source-id: c3b3a93aed6007fadda2993afa52c28c028f6327
Summary:
In order to support AnimatedColor.setValue for platform colors, we need to pass the platform color object to the native animated node which will then resolve and apply the color.
Thus, the approach is:
- Add a new API updateAnimatedNodeConfig to NativeAnimatedModule
- [JS] On AnimatedColor.setValue, if the value is a platform color, then we call updateAnimatedNodeConfig
- [Android] We introduce AnimatedNodeWithUpdateableConfig interface with a method updateConfig. On ColorAnimatedNode.java, we use updateConfig to resolve and apply the color
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color
Reviewed By: javache, mdvacca
Differential Revision: D34025193
fbshipit-source-id: 8b368f6b7cb2cf7cebe8b66461cd4185cbadd44c
Summary:
There are cases where the activity may not exist (such as for VRShell panel apps). In this case we will search for a view associated with a PropsAnimatedNode to get the context.
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color if activity doesn't exist
Reviewed By: javache
Differential Revision: D34022882
fbshipit-source-id: c316935af1034ea770f3ef9334f77d6dc783fb27
Summary:
We should now be able to remove the explicit `react-native-gradle-plugin` dependency
from the `template/package.json` file.
Changelog:
[Android] [Changed] - Remove `react-native-gradle-plugin` as a dependency from template's package.json
Reviewed By: motiz88
Differential Revision: D34050589
fbshipit-source-id: c8d4e4fba481af6b56723906b71411132d60aded
Summary:
Similarly to what we did for react-native-codegen, I'm introducing
a dependency between RN and the Gradle plugin, to be processed upon OSS bumps.
Changelog:
[General] [Added] - Make react-native depend on react-native-gradle-plugin
Reviewed By: motiz88
Differential Revision: D31334773
fbshipit-source-id: 978da4946b7864d891553e6a7dcb67783399e76f
Summary:
Updates early return in the CREATE command codepath that checks if the view already exists before allocating it. Normally the view state is expected to be created only if the view is preallocated, but empty view state is also created for the flattened nodes when they create an event emitter.
By checking the view existence, we can ensure that view was indeed preallocated before, and skip for optimization purposes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34050884
fbshipit-source-id: 489fc1052fec9f71712ea729121ac8ef3e3f3d4e
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Notifications
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34055503
fbshipit-source-id: 8c2dd1066ba2b68e395226f15954d303894d0365
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Responses
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34052619
fbshipit-source-id: d213ed41335b64bf3168a43ce043f2c57f05fc52
Summary:
This event listener does nothing by default and will do nothing if (developer) users don't explicitly create some telemetry system for their own app.
This EventEmitter makes that easier but isn't necessarily tied to telemetry, especially since it does nothing at all by default.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D34060116
fbshipit-source-id: 9345a52f502e0225358fdaa1431c052a70fa54ce
Summary:
This will be used from the React JS renderer in a followup PR.
Changelog: [Added][JS] New event telemetry mechanism exposed from JS to supercede the Pressability-specific telemetry mechanism
Reviewed By: ryancat
Differential Revision: D33986916
fbshipit-source-id: 912d0b351869348f0ca6e5f6a882fc0501c2c7f0
Summary:
This diff separates the content view creation logic from existing `RedBoxDialog` logic. After the change, `RedBoxDialog` is no longer a subclass of `Dialog`, but behaves like a dialog with forwarding pattern to delegate dialog API to internal member. This will keep the APIs consistent with dependent components.
The motivation of the change is to make the content view reusable. This is important in VR surface where we don't have activities and necessary implementations for Dialog to show.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D34016503
fbshipit-source-id: 261594bda9f6fb2d83764a1e5ec2e9e60d8d39a3
Summary:
We put the `:interfaces` target on the dependencies list for `:devsupport` target in the [BUCK file](https://fburl.com/code/lrr1c0pn). In the following diffs I will need to put the interface [`/devsupport/RedBoxHandler`](https://fburl.com/code/v53euvps) on to [`/devsupport/interfaces/DevSupportManager`](https://fburl.com/code/k8gwxa0f). This violates the dependency rule.
Since `RedBoxHandler` is an interface, I moved it to the interfaces list in this diff to unblock.
Changelog:
[Android][Internal]
Reviewed By: yungsters
Differential Revision: D33987834
fbshipit-source-id: 77a1ee14bd10c6bbaac2ee465ae7050e99ed0399
Summary:
Probably my smallest PR yet, this just fixes a comment in the template's Java files.
## 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
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33050
Reviewed By: christophpurrer
Differential Revision: D34045805
Pulled By: cortinico
fbshipit-source-id: a7355b4dbae84b79ee9d68e2524393d03cda67fc
Summary:
https://github.com/facebook/react-native/commit/c974cbff04a8d90ac0f856dbada3fc5a75c75b49 changed the border colors to be of UIColor instead of CGColor. This allowed working with dark mode to switch the border colors automatically. However, in certain situation the system can't resolve the current trait collection (see https://stackoverflow.com/a/57177411/2525941). This commit resolves the colors with the current trait collection to ensure the right colors are selected. This matches with the behavior of how the background color is resolved (also in displayLayer:).
## Changelog
[iOS] [Fixed] - Resolve border platform color based on current trait collection
Pull Request resolved: https://github.com/facebook/react-native/pull/32492
Test Plan: Same test plan as https://github.com/facebook/react-native/pull/29728
Reviewed By: sammy-SC
Differential Revision: D33819225
Pulled By: cortinico
fbshipit-source-id: 2f8024be7ee7b32d1852373b47fa1437cc569391
Summary:
changelog: [internal]
In order to call `RuntimeScheduler::callExpiredTasks`, we need to pass it to `Scheduler` through context container.
Reviewed By: javache
Differential Revision: D34042293
fbshipit-source-id: 62d18507fb107c5be2ac9d003f63735aab6a09ac
Summary:
changelog: [internal]
Rename method so it does not collide with immediates that already exist in React Native.
Reviewed By: javache
Differential Revision: D34041418
fbshipit-source-id: 0ae75b683983c3be50320b195a7068d7178b0ed8
Summary:
I was trying to add an object property to my ViewManager and got a really opaque error (and I almost thought Objects weren't supported by the codegen) until I realized it expected the object to wrapped in a $ReadOnly type.
Changelog: [Internal] Improved error in codegen
Reviewed By: mdvacca
Differential Revision: D34006557
fbshipit-source-id: b3ab15a40cb66fdcd377f4e68df92060498e8e7f
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Messages
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34042008
fbshipit-source-id: 3a074e9840706ca977ff86d050e67b0dcea5c7ef
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: this is to break any unique dependencies this module is bringing in from the original module it was in.
Reviewed By: sammy-SC
Differential Revision: D33935581
fbshipit-source-id: 2ccf5b4a9d1dca1e6059cafb888091e450f6f980
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:
When setting ScrollView's contentOffset, if the ScrollView hasn't been laid out yet when ReactScrollViewManager.setContentOffset is called, then scroll position is never set properly. This is because the actual scroll offset (0, 0) was being passed into setPendingContentOffsets, instead of the desired scroll offset. Thus,
when ReactScrollView.onLayout gets called, ReactScrollView.scrollTo gets called with (0, 0).
Also updates out of date comments,
Changelog:
[Android][Fixed] - Fix ScrollView contentOffset
Reviewed By: ryancat
Differential Revision: D34015853
fbshipit-source-id: 84141a663fdb0ace2be7cef61f14944cb08125d1
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:
Update javadoc of ReactRoot.getState() since the task was fixed and the API remained the same
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D33981298
fbshipit-source-id: 0136a640b884a787b0a20162781735630c1fa1c7
Summary:
Optimize Android RNTester build workflow to run in a single job instead of running two separate Gradle invocations as Nicola suggested here https://github.com/facebook/react-native/pull/33033#discussion_r799066446
## Changelog
[General] [Changed] - Optimize CicleCI Android RNTester build job to run a single gradle invocation
Pull Request resolved: https://github.com/facebook/react-native/pull/33042
Test Plan: Make sure builds are working as expected and CI is green
Reviewed By: ShikaSD
Differential Revision: D34001440
Pulled By: cortinico
fbshipit-source-id: 90845482b69e5c2839d570db359223ee614ebf1b
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: Attempt to fix a crash during app termination on iOS in the new renderer
We need to stop all surfaces before it is terminated to prevent app from crashing.
The crash happens on background thread.
The app crashes because it is probably accessing static variable that has been deallocated by the main thread. How can main thread deallocate things when background thread is still running? Because main thread is attached to our app's process, background thread is provided by the system and continues to live.
Reviewed By: ShikaSD
Differential Revision: D33977161
fbshipit-source-id: 87546d7b70d1aa465e63f0d37b70bae1fffa2304
Summary:
Add 4 new jobs to CI in order to test RNTester builds on both Android and iOS using Hermes and JSC
Closes https://github.com/facebook/react-native/issues/32676
## Changelog
[General] [Added] - Add build tests for RNTester to CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/33033
Test Plan: Make sure builds are working as expected and CI is green
Reviewed By: lunaleaps
Differential Revision: D33982864
Pulled By: philIip
fbshipit-source-id: 00b2116be1b6484324e8162cc691b1d0863d282d
Summary:
changelog: [internal]
With multiple requests to the runtime, we need to make sure they are all granted before React continues with rendering. A boolean is not enough to track this. The first lambda that has VM will set it to false and subsequent requests will have to wait for React to finish rendering.
To prevent this, we can count how many lambdas are pending access to the runtime.
Reviewed By: ShikaSD
Differential Revision: D33792734
fbshipit-source-id: f785fae3575470179dd69acc6a466211b79b633b
Summary:
Running `test-manual-e2e.sh` from any folder other than the repo root results in errors regarding files not existing, that's because we're not taking into consideration the path from where the script is invoked. This PR updates it so that we get the absolute path of the script and then use it to get the parent directory and `cd` to the repo root folder.
Closes https://github.com/facebook/react-native/issues/32999
## Changelog
[Internal] [Fixed] - fix access to relative paths when invoking `test-manual-e2e.sh` from folders other than the repo root
Pull Request resolved: https://github.com/facebook/react-native/pull/33000
Test Plan:
1. Clone this repo
2. Navigate to the rn-tester folder `cd packages/rn-tester/`
3. Run `../../scripts/test-manual-e2e.sh`
4. Select RNTester, Android and Hermes
https://user-images.githubusercontent.com/11707729/151730441-18bc37de-0224-4f5e-a2fe-408e3ace5c1f.mov
Reviewed By: ShikaSD
Differential Revision: D33915561
Pulled By: cortinico
fbshipit-source-id: 66f2d1ebee50bba3fe884d6346ea08ffced47a96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33038
While rolling out RN 0.68.x we noticed that `libhermes.so` and `libjsc.so` were included
inside the final .aar we publish to NPM. This forced users (on both old or new arch) to
specify a `pickFirst` directive inside their packaging option (which is unpractical and
risky as the two .so might not be compatible each other if they're coming from
different Hermes/JSC versions).
Changelog:
[Android] [Fixed] - Do not bundle libhermes.so or libjsc.so inside the React Native Android AAR
Reviewed By: ShikaSD
Differential Revision: D33979107
fbshipit-source-id: 0b71d59f210b8bc9903cd0f30ed6e2120aab99e0
Summary:
changelog: [internal]
pass raw ShadowNode instead of shared_ptr. Ownership is not transferred, shared_ptr is misleading.
Reviewed By: javache
Differential Revision: D33917010
fbshipit-source-id: 4d9fdd4b4e0376149f1719ad160b957de4afdce3
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:
Updates maximum heap size for the gradle build to account for building RN from source when new architecture is enabled.
Changelog: [Changed][Android] - Use 2g as a default heap size for gradle builds
Reviewed By: cortinico
Differential Revision: D33947090
fbshipit-source-id: 2f551e688f2d92c3092e053086f6933779cd6f63
Summary:
This change makes automatic sample profiling registration opt in. This is in preparation for an upcoming change where hermes
will enforce that the sampling profiler must be destroyed on
the same thread it was created.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D33826992
fbshipit-source-id: 89843b5fc5b936f674a8d0a470e92af0cd8f6125
Summary:
Venice uses `SurfaceHandler` abstraction which start/stops surfaces independently from `Binding.cpp`, so previous `onSurfaceStart/Stop` callback would not be triggered.
On Android, each surface is used exactly once at the time of writing, so we can use `register/unregister` callbacks to create/clear remembered views for the surface.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33845685
fbshipit-source-id: 8de4204c7498176fdbe8d44fbc5f2e4079212a1c
Summary:
Danger 7 -> 11
## Changelog
[Internal] [Changed] - Updates Danger used in PR checking from v7 to v11
Pull Request resolved: https://github.com/facebook/react-native/pull/33027
Test Plan:
Works when testing locally
```
> DANGER_GITHUB_API_TOKEN=XXYYZZ yarn danger pr https://github.com/facebook/react-native/pull/32955
yarn run v1.22.15
$ node ./node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/32955
Starting Danger PR on facebook/react-native#32955
--- Accurate Error due to not being able to write to labels ---
## Failures
`node` failed.
## Messages
📋 Missing Summary - <i>Can you add a Summary? To do so, add a "## Summary" section to your PR description. This is a good place to explain the motivation for making this change.</i>
-
📋 Missing Test Plan - <i>Can you add a Test Plan? To do so, add a "## Test Plan" section to your PR description. A Test Plan lets us know how these changes were tested.</i>
-
📋 Missing Changelog - <i>Can you add a Changelog? To do so, add a "## Changelog" section to your PR description. A changelog entry has the following format: `[CATEGORY] [TYPE] - Message`.
<details>CATEGORY may be:
- General
- iOS
- Android
- JavaScript
- Internal (for changes that do not need to be called out in the release notes)
TYPE may be:
- Added, for new features.
- Changed, for changes in existing functionality.
- Deprecated, for soon-to-be removed features.
- Removed, for now removed features.
- Fixed, for any bug fixes.
- Security, in case of vulnerabilities.
MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.</details></i>
## Markdowns
Danger: ⅹ Failing the build, there is 1 fail.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
Reviewed By: GijsWeterings
Differential Revision: D33941271
Pulled By: cortinico
fbshipit-source-id: 359c0076a160a8eeac897a2e1556d3e4d3db5e04
Summary:
[Hermes][Inspector] Implement the CDP API for calling a function on an object.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D33722301
fbshipit-source-id: da26e865cf29920be77c5c602dde1b443b4c64da
Summary:
Removes the `deprecated-react-native-props` dependency from `react-native`.
This is now possible because all of the deprecated call sites have been removed:
- `Image.propTypes`
- `Text.propTypes`
- `TextInput.propTypes`
- `ColorPropType`
- `EdgeInsetsPropType`
- `PointPropType`
- `ViewPropTypes`
Changelog:
[General][Removed] - Removed `deprecated-react-native-props` as a package dependency.
Reviewed By: kacieb
Differential Revision: D33750413
fbshipit-source-id: 003fb275d1ce766cbce2b44708dd254243abb33b
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:
D33740360 (https://github.com/facebook/react-native/commit/16ed62a850dd81bd9cc7f77ab3e77f42ed64b177) broke Explore VR on React Native. The app would go into a loop on boot and not finish mounting. This is probably a product code issue, but it's not a trivial issue to solve. Unlanding to unblock the RN migration.
Changelog:
[internal] internal
Reviewed By: mdvacca
Differential Revision: D33918026
fbshipit-source-id: cc77c70ece9994d82c91f7ae8783e959629e9cfb
Summary:
Running `yarn audit` shows a vulnerability in the `shelljs` version we're currently using

This PR upgrades `shelljs` from 0.8.4 to 0.8.5 in order to mitigate this vulnerability
More info on https://github.com/advisories/GHSA-4rq4-32rv-6wp6
## Changelog
[Internal] [Security] - Upgrade shelljs to v0.8.5 in order to fix Improper Privilege Management vulnerability
Pull Request resolved: https://github.com/facebook/react-native/pull/33001
Test Plan: There are no API changes between versions 0.8.4 and 0.8.5, so just testing the scripts that use this lib should be enough.
Reviewed By: cortinico
Differential Revision: D33897436
Pulled By: lunaleaps
fbshipit-source-id: f32b118ff47c6135845ac4de425feb8ebea220a8
Summary:
Removes `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, and `ViewPropTypes` from the React Native Public API.
Accessing these will now cause an error to be thrown with a message to use the `deprecated-react-native-prop-types` package.
These were deprecated in React Native v0.66.
Changelog:
[General][Removed] - Removed `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, and `ViewPropTypes`.
Reviewed By: kacieb
Differential Revision: D33746966
fbshipit-source-id: 61d264d133f42008c7ff252e6ebbb8b47747939c
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:
Fixes a potential crash was introduced by https://github.com/facebook/react-native/issues/30919 that aimed to get the keyboard height on devices with a Notch. The problem is that it considers that any ReactRootView will have an insets available.
When using [react-native-navigation](https://github.com/wix/react-native-navigation) and assigning a Navigation button to the TopBar as a component, the component gets registered as a RootView but won't have any insets attach to the view.
[getRootWindowInsets()](https://developer.android.com/reference/android/view/View#getRootWindowInsets()) in fact return a `WindowInset` only available if the view is attached, so when executing `checkForKeyboardEvents` method from ReactRootView, is trying to access the `DisplayCutout` of a null object, leading to a crash.
## Changelog
[Android] [Fixed] - Fix potential crash if ReactRootView does not have insets attached.
Pull Request resolved: https://github.com/facebook/react-native/pull/32989
Test Plan:
Without the code change: Notice how the second screen being push contains a React Component on the top right of the navigation bar, and when component is unmounted (going back) the app crashes.
https://user-images.githubusercontent.com/6757047/151558235-39b9a8b5-be73-4c31-8053-02ce188637b8.mp4
crash log
```
2022-01-28 10:27:52.902 15600-15600/com.mattermost.rnbeta E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.mattermost.rnbeta, PID: 15600
java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.DisplayCutout android.view.WindowInsets.getDisplayCutout()' on a null object reference
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:778)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:769)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3214)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2143)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8665)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1037)
at android.view.Choreographer.doCallbacks(Choreographer.java:845)
at android.view.Choreographer.doFrame(Choreographer.java:780)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7839)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
After applying the patch which is only a null check validation and does not change any previous behavior
https://user-images.githubusercontent.com/6757047/151558429-9ff1a608-abb6-4168-8db9-df0c3c71d79e.mp4
Reviewed By: cortinico
Differential Revision: D33844955
Pulled By: ShikaSD
fbshipit-source-id: ed5579ad3afeed009c61cc1851eee45c70087cf5
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:
Changelog: [Internal]
Since DummyUIManager.getViewManagerConfig() & hasViewManagerConfig() are the same, it's safe to ship this before the native changes in this stack lands.
Reviewed By: RSNara
Differential Revision: D33832926
fbshipit-source-id: c0f0a169d02397e0f9125bb45d95d395c8bbc492
Summary:
Changelog: [Internal]
Remove all the MCs that enable SVCs in Fabric, because we'll only test SVCs in Bridgeless mode to simplify rollout. There were complications with enabling SVCs in Fabric at a previous rollout.
Reviewed By: RSNara
Differential Revision: D33861243
fbshipit-source-id: fdbfedce77f8bd1bab2a807237017787ae8bf7c1
Summary:
changelog: [internal]
React on web uses microtasks to schedule a synchronous update for discrete event. Microtasks are not yet available in React Native and as a fallback, React uses native scheduler and task with immediate priority. Until Microtasks are in place, React Native needs to make sure all immediate tasks are executed after it dispatches each event.
I tried to stay as close to [microtask standard](https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask) as I reasonably could.
Once microtasks on RN are shipped, this code can be removed.
Reviewed By: mdvacca
Differential Revision: D33742583
fbshipit-source-id: eddebb1bd5131ee056252faad48327a70de78a4a
Summary:
Calls to Inspector::evaluate() and Inspector::executeIfEnabled()
take a user-provided callback which are not try-guarded. This
means that, should the user code throw, the inspector's process
will likely die due to the unhandled exception. This change
makes sure that, if the user provided callback throws, then
the promise attached to those methods will be fulfilled by
an exception.
Change: [internal]
Reviewed By: avp
Differential Revision: D33852073
fbshipit-source-id: 7fbb6662b28d393a5d5b494c004aa9521e23ebb6
Summary:
The fix in this diff seems simple, but it took some time to understand why this change fixed the issue that views animated use native driver out from their parent's layout are not getting touch events.
We introduced `overflowInset` to RN Android a while back to give each shadow node extra information to cover all its children's layout. These values (left, top, right, bottom extensions from the view's own layout) help us improve hit-testing algorithm used in touch events. We could ignore all subtrees that the touch point not in their parent's overflowInset box.
However, this was not working for native animation. When `userNativeDriver` is on, all animation happens without Fabric knows anything about them. The overflowInset is out of date with the final animated layout, which caused the issue that we ignored the animated view as we thought it's not under the pointer.
Here is a playground demo (P476407654) for the issue:
https://pxl.cl/1XfPL
We've tried to fix this by passing the final animated values via `passthroughAnimatedPropExplicitValues` added in D32539976. This is a prop that will get merged into `style` prop for [animation component](https://fburl.com/code/jybzfgu5). The transform values were already applied when measuring layout in [Pressability](https://fburl.com/code/5mect2k3), which uses [LayoutableShadowNode](https://fburl.com/code/qh8fufrw). However, this is not the case for overflowInset calculation. Hence, the fix here is to apply the transform matrix in Yoga before calculating the overflowInset.
Changelog:
[Android][Fixed] - Fix overflowInset calculation by using transform values
Reviewed By: ShikaSD
Differential Revision: D33806030
fbshipit-source-id: e438618e3d6e5b0333cff9ff9919b841d73b2e9d
Summary:
This was a bug, we are fixing it.
Move pointerEvents from formsStacking -> formsView and we are also removing "onLayout" from formsStackingContext
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D33846660
fbshipit-source-id: 6b65a9a7815972e34dafbc48b3d732d9b02d5e9f
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.67.0](https://github.com/facebook/metro/releases/tag/v0.67.0).
Changelog:
[General] Update direct Metro dependencies to 0.67.0
Reviewed By: GijsWeterings
Differential Revision: D33828217
fbshipit-source-id: e4e9ba4cf43a8588f8db43885f67d4dc606198f5
Summary:
Creates a new package called `fb-tools-support/yarn` and moves the `getWorkspacesFromYarn` function (currently duplicated almost verbatim in two places) into that shared location.
Also, gets `yarn postinstall` to work again and runs it in `xplat/js` - this materialises some new BUCK files that weren't added when their respective Yarn workspaces were created.
Reviewed By: rh389
Differential Revision: D33826945
fbshipit-source-id: 02e2db8b210303ed4f6d24a777a2e0094022bd5d
Summary:
Before https://github.com/facebook/react-native/commit/f951da912dd8b4dc2b0d674f8f37f9d982a03c48 finding a system font used to return early. In order to allow variants, the referenced patch removed the early return so that variants could be applied later. However, there is no need to find the closest font as we already selected the proper system font. This also fixes a bug with setting a custom font handler via RCTSetDefaultFontHandler whos return could get overwritten by the closest font search.
## 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] - Respect RCTSetDefaultFontHandler chosen font
Pull Request resolved: https://github.com/facebook/react-native/pull/32482
Reviewed By: ShikaSD
Differential Revision: D33844138
Pulled By: cortinico
fbshipit-source-id: 05c01fc358cd19f8be342218cdba944b303073ed
Summary:
when migrated to `maven-publish` in https://github.com/facebook/react-native/issues/31611, the sources jar is not included by default from `maven-publish`. so react-native 0.66 / 0.67 doesn't include sources jar in npm published artifacts. it's not ideal for debug or tracing code.
this pr added the sources jar into the published artifact.
## Changelog
[Android] [Fixed] - Add missing sources jar into published android artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/32982
Test Plan:
make sure sources jar is included in artifact.
```
$ ./gradlew :ReactAndroid:installArchives
$ find android -name '*sources.jar*'
```
Reviewed By: ShikaSD
Differential Revision: D33842979
Pulled By: cortinico
fbshipit-source-id: f99ad46ce0cca0cfc2ab1d5c5a4fcb40a02683e7
Summary:
This PR bumps the `actions-apply-version-label` version to 0.0.3 in order to fix an issue where we were throwing an error when the identified label does not exist, instead we should just report a warning. This also updates `apply-version-label-issue.yml` to use `actions-apply-version-label` from `react-native-community` as it has been recently transferred to the community
## Changelog
[Internal] [Fixed] - Fix `actions-apply-version-label` error when version label is missing
Pull Request resolved: https://github.com/facebook/react-native/pull/32979
Test Plan:
Open an issue with a missing version label and ran the new action version
https://github.com/gabrieldonadel/actions-apply-version-label/actions/runs/1756805059
Reviewed By: ShikaSD
Differential Revision: D33819052
Pulled By: cortinico
fbshipit-source-id: 49c719e729e3085e78b1c43143c2d41a03e797e4
Summary:
The current JSLoader implementation (on Android) will copy the buffer into a JSBigBufferString during startup. This duplicates work Android is already doing (it allocates creates a copy of the bundle in memory while decompressing the asset from the APK) or worse, if the APK is mmap'ed this will unnecessarily create dirty memory.
The risk with this approach is that the bundle loaded from disk is no longer \0 terminated, but that's also the case for the bundles we load with `JSBigFileString` and is not an issue as far as I can tell.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D33792735
fbshipit-source-id: 61fc089a223f3602d3575340d79a8de2ec92d8a0
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:
This diff deletes the flag ReactFeatureFlags.enableReactContextCleanupFix, the flag was disabled for many months, I just disable it.
changelog: [internal] internal
Reviewed By: genkikondo, makovkastar
Differential Revision: D33781628
fbshipit-source-id: 4b5e22adf9d30da5b85bbbde8bdc98d98f5e8891
Summary:
This diff deletes the ReactFeatureFlag enableFabricInLogBox, from now on Logbox will be rendered in Fabric when Fabric is enabled
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D33781626
fbshipit-source-id: 3187a22fec80125afd27860995637564640dab8d
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:
Fixes https://github.com/facebook/react-native/issues/32939
It appears there is circular dependencies on the Modal component that causes the modalMock function to be an empty object. Removing the import fixes the issue.
I don't know yet why this is not happening when executing the test suite inside `Modal-test.js` but I will investigate this later.
## 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] - Fix error "mockModal is not a function"
Pull Request resolved: https://github.com/facebook/react-native/pull/32964
Test Plan:
On a newly initiated project using react-native 0.67.1 I created a ModalComponent:
```
import React from 'react';
import {Modal, Text} from 'react-native';
export const ModalComponent = () => {
return (
<Modal visible>
<Text>Test</Text>
</Modal>
);
};
```
and a ModalComponent.test.tsx:
```
import 'react-native';
import React from 'react';
import {ModalComponent} from '../ModalComponent';
// Note: test renderer must be required after react-native.
import renderer from 'react-test-renderer';
it('renders correctly', () => {
renderer.create(<ModalComponent />);
});
```
Running the test throws the error "TypeError: mockModal is not a function".
After modifying the mockModal inside node_modules/react-native/jest/mockModal.js it works correctly.
Reviewed By: christophpurrer
Differential Revision: D33771136
Pulled By: lunaleaps
fbshipit-source-id: c09ada8d2f864f5568b3379616a6cace9fb9921e
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:
The overflowInset uses negative values to indicate extending from parent view. This diff fixes the math so that it's correctly check if the point is within overflowInset.
Changelog
[Android][Fixed] - Fix math for detecting if children views are in parent's overflowInset area.
Reviewed By: genkikondo
Differential Revision: D33750129
fbshipit-source-id: 1a5a33a227280c687b158b4a81a56017b6f4f3e0
Summary:
As stated in [https://github.com/facebook/react-native/issues/28043](https://github.com/facebook/react-native/issues/28043) the requests with the `Octokit` lib is not optimal since tracking issues were raised. Since the issue could not be reproduced (see comments in the mentioned issue) I'm proposing to update the `Octokit` package to the newest version and add the required fields as stated [in the documentation](https://octokit.github.io/rest.js/v18#authentication).
## Changelog
[Internal] [Changed] - Changed requests of the internal code analysis
Pull Request resolved: https://github.com/facebook/react-native/pull/32891
Test Plan:
Ran the code analysis bot manually
```
cat <(echo eslint; npm run lint --silent -- --format=json; echo flow; npm run flow-check-ios --silent --json; echo flow; npm run flow-check-android --silent --json; echo google-java-format; node scripts/lint-java.js --diff) | GITHUB_PR_NUMBER="$CIRCLE_PR_NUMBER" node bots/code-analysis-bot.js
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
```
Reviewed By: christophpurrer
Differential Revision: D33793194
Pulled By: cortinico
fbshipit-source-id: 21b5f9f3911dd82e3254ab009637ab63aa36d30c
Summary:
Changelog: [internal]
Add comments and avoid using shared_ptr unnecessarily.
Why note shared_ptr? Using shared_ptr suggests we are transferring ownership of object, which we are not.
Reviewed By: javache
Differential Revision: D33741836
fbshipit-source-id: 56ebb098e6185793f05e2bb587005bb0f093c0c9
Summary:
changelog: [internal]
Yielding in RuntimeScheduler is shipped. This diff removes the gating around it.
Reviewed By: sshic
Differential Revision: D33740360
fbshipit-source-id: 267372e81e66dda96e451435954a7c3546cc6fbe
Summary:
Since 0.64, local code in `Bundle React Native code and images` step for iOS is not enough anymore.
This add support for [fnm](https://github.com/Schniz/fnm) that is widely used this days.
## 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] [Added] - Support fnm when detecting node binary
Pull Request resolved: https://github.com/facebook/react-native/pull/32890
Test Plan: I use fnm & it's working. Tested this code via patch-package.
Reviewed By: christophpurrer
Differential Revision: D33766842
Pulled By: cortinico
fbshipit-source-id: 77bbda2c7742de9ec64e6faa9a3526d3997bb4aa
Summary:
Dynamic nested components can cause tricky performance issues in React, as the reconciler will not be able to reuse the previously mounted component tree.
Changelog: [General] [Added] Added linter warning config for unstable nested components
Reviewed By: motiz88
Differential Revision: D33767283
fbshipit-source-id: 869ece99dc63cc3a150bae882d26df8541e8db59
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:
Enable eager intialization of FabricUIManager during intiialization of React Native.
This feature highly improved TTRC in Markeptlace Home
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D33585099
fbshipit-source-id: 0ffbc720bcb1edd1b04180189a52c82e9e2fa800
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:
The path to `Time.h` is currently hard-coded and does not take into
consideration the `--project-directory` flag when running `pod install`.
## Changelog
[iOS] [Fixed] - Fix `Time.h` patch not being applied when running `pod install --project-directory=ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/32961
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
../scripts/xcodebuild.sh ios/Example.xcworkspace build
```
Reviewed By: christophpurrer
Differential Revision: D33748789
Pulled By: lunaleaps
fbshipit-source-id: b125734eba30e552ae139e7ecd4e634c8fa1bcd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32946
Changelog: [Internal]
This fixes a bug where config file dir was incorrectly and breaks the codegen which runs when building an app.
Reviewed By: dmitryrykun
Differential Revision: D33724558
fbshipit-source-id: 0c04c1d41f2fb9b958da64fa414746695cea60cb
Summary:
…ansforms
On iOS, if a View is rotated with the a transform (e.g. <View style={{transform: {rotationZ: 5}}} />), the view has aliasing (see screenshot). Same for a skew transformation. We don't have the issue on Android
This behavior had originally being fixed by this PR https://github.com/facebook/react-native/pull/1999
However a new PR was merge ( https://github.com/facebook/react-native/pull/19360 ) that broke this. I think it was made to add antialiasing during perspective transforms but seems to have broken the antialiasing when rotationZ transforms
This PR adds back the antialising during rotation transform , while keeping it during perspective transform.
## Changelog
I changed the allowsEdgeAntialiasing condition, making it "true" when the m12 or m21 is not 0. From this article https://medium.com/swlh/understanding-3d-matrix-transforms-with-pixijs-c76da3f8bd8 , I've understood that in all rotation or skew transformations, m12 or m21 is different than 0 . In the other transformation (e.g. scale or translate) it stays at 0.
Although, I'm not a matrix transformation expert so I may be mistaken
Pull Request resolved: https://github.com/facebook/react-native/pull/32920
Test Plan:
I've written several views with all rotateX/Y/Z , skewX,Y and perpective transformation. Before the PR some transformation was showing aliasing on iOS (e.g. top-left view in the screenshot, don't hesitate to zoom in the image if you don't see it) and with this PR it does not have anymore
Before

After

Code I used to test
```
const commonStyle = {
width: 150,
height: 100,
backgroundColor: "red",
margin: 10,
}
const Test = () => (
<View style={{ flexDirection: "row" }}>
<View>
<View
style={[
commonStyle,
{
transform: [{ rotateZ: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateX: "30deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateY: "30deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateX: "30deg" }, { rotateY: "30deg" }, { rotateZ: "3deg" }],
},
]}
/>
</View>
<View>
<View
style={[
commonStyle,
{
transform: [{ skewX: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ skewY: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ skewY: "4deg" }, { rotateZ: "3deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ perspective: 1000 }],
},
]}
/>
</View>
</View>
)
```
Reviewed By: lunaleaps
Differential Revision: D33665910
Pulled By: sshic
fbshipit-source-id: 91163ec2a0897a73ddf0310d86afacea04b89bc7
Summary:
Per discussion in the previous diff D33672110, it's ok to add the `pointerEvents` prop to scrollview. This will help prevent scrolling on the ScrollView if pointerEvents is set to `box-none`, or `none`.
Corresponding doc changes are in https://github.com/facebook/react-native-website/pull/2936
Changelog:
[Android][Added] - Add new API in ScrollView and HorizontalScrollView to process pointerEvents prop.
Reviewed By: javache
Differential Revision: D33699223
fbshipit-source-id: 1cae5113e9e7d988fc4c4765c41d817a321804c4
Summary:
Bump Kotlin version to 1.6.10 with changes:
https://kotlinlang.org/docs/whatsnew16.html
Primarily:
- stabilization to several language features
- various type inference improvements
- support for annotations on class type parameters
## Changelog
[Android] [Changed] - Bump Kotlin version to 1.6.10
Pull Request resolved: https://github.com/facebook/react-native/pull/32936
Reviewed By: ShikaSD
Differential Revision: D33708397
Pulled By: cortinico
fbshipit-source-id: a09b4504c194676d18a749c5e297b7598e5f32b4
Summary:
Bump react-native-codegen version to include new fixes and improvements.
Changelog: [internal] Updated react-native-codegen version
Reviewed By: cortinico
Differential Revision: D33684175
fbshipit-source-id: bfc6cb627659c7cdfca2676894bece5f02aff767
Summary:
Adds changelog for new patch and removes an entry that was rolled back.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - add changelog entry for 0.67.1 & fix 0.67
Pull Request resolved: https://github.com/facebook/react-native/pull/32938
Test Plan: N/A
Reviewed By: ShikaSD
Differential Revision: D33709914
Pulled By: cortinico
fbshipit-source-id: 0829be764e7aeae6191aa2138eb8bc74d9c2a880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32923
As our Flipper version is quite old, let's bump it to one of the latest stable: 0.125.0
This required to update also the following:
- Flipper-Folly to 2.6.10 - This was needed as I aligned the versions to https://github.com/facebook/flipper/blob/v0.125.0/react-native/ReactNativeFlipperExample/ios/Podfile
- OpenSSL-Universal to 1.1.1100 - This was required with the `pod update` command
I've picked 0.125.0 as 0.127.x and following are crashing on Android
and will potentially require a bump of the NDK to r23:
See: https://github.com/facebook/flipper/issues/3245
Changelog:
[General] [Changed] - Bump Flipper to 0.125.0
allow-large-files
Reviewed By: mdvacca
Differential Revision: D33583090
fbshipit-source-id: 2a2020c3213273087ec4a152076f846e35e275c5
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:
Changelog: [Internal] Update the documentation to disable fabric in RN Tester.
RNTester build would fail if you previously built with fabric_enabled. This documentation adds the instruction to clean up before runing pod install.
In the future, we'd want to detect and do the clean up so that it doesn't fail in an obscure way.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D33173173
fbshipit-source-id: a396eb71edc7bf174d0eb392799f45ae74274b76
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:
Making the native ViewConfig for RCTModalHostView match its static ViewConfig.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D33303419
fbshipit-source-id: 6fac237d670ee221ad867f79e54d5a3576c156da
Summary:
Refactors MapBuffer-related `primitives.h` to be namespaced with `MapBuffer` class, to avoid name collisions and confusion later on.
Most of the size constants are moved to relevant .cpp files or updated to use `sizeof`.
Additionally, adds a little bit of documentation about `MapBuffer` serialization format.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33662487
fbshipit-source-id: 5a7a2b1c7f2bb13ee1edfc5fae51ba88c34f0d3c
Summary:
Serializes type information along with key/value in MapBuffer, asserting the data type on Java side during read. At the moment, accessing value with incorrect will result in a crash.
Other changes:
Adds a `getType` method to verify types before accessing them.
Removes `null` as a type, as just not inserting value and checking for its existence with `hasKey` is more optimal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33656841
fbshipit-source-id: 23a78daa0d84704aab141088b5dfe881e9609472
Summary:
Removes the need to store keys in incremental order by sorting them after before inserting into MapBuffer.
Updates MapBuffer to support random access on C++ side, actually retrieving values by keys and not bucket index.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33611758
fbshipit-source-id: c81e970613c8ecc688bfacb29ba038bf081a0c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32925
Changelog: [internal] I was testing with some sample proect without the codegen discovery, and I found a code path that doesn't work due to the escape charactors left.
Reviewed By: christophpurrer
Differential Revision: D33670881
fbshipit-source-id: 94bd4f0eea28ebf86001381f08e6ddbff7213793
Summary:
I realized while checking for a few other things that Detox's presence in the repo is actually not really motivated - since Jul 2020 the few tests that were using it were disabled https://github.com/facebook/react-native/commit/120ff7ccdebebdf814e478259ba1e4a8ef6f513e never to be reactivated since.
I noticed this while attempting to updating the Detox version to latest... which made me notice that the repo is still on a 16.x version while latest is 19.x (there are like 10 pages of releases between them: https://github.com/wix/Detox/releases) and I came to the conclusion that it's probably easier to just remove the old dusty code and eventually reintroduce it in the future if we ever consider it necessary.
## 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] [Removed] - Removing Detox from CI.
Pull Request resolved: https://github.com/facebook/react-native/pull/32907
Test Plan: CI - nothing breaks.
Reviewed By: lunaleaps
Differential Revision: D33623199
Pulled By: cortinico
fbshipit-source-id: 7d8d133629b62b66959b309f2ca21852d396c9fc
Summary:
Fix an issue in the AccessibilityExample on RNTester where the `Screen Reader` item would listen for the `reduceMotionChanged` event instead of the `screenReaderChanged` event
## Changelog
[General] [Fixed] - Fix screen reader event name on RNTester AccessibilityExample
Pull Request resolved: https://github.com/facebook/react-native/pull/32926
Test Plan:
1. Build iOS app
2. Navigate to the Accessibility page
3. Switch over to settings and change VoiceOver at `Settings>Accessibility>VoiceOver>VoiceOver`
4. Switch back to the app and see the results
https://user-images.githubusercontent.com/11707729/150266745-6a9eb547-00a7-4b94-bf19-b8d6e6f76122.mp4
Reviewed By: kacieb
Differential Revision: D33681780
Pulled By: cortinico
fbshipit-source-id: fbd4f3d9ef63997f2b4a40afc8a5adfe6172e525
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32932
As the title says, we dont' want to remove `libjscexecutor.so` when
baking release builds and having JSC enable as this leads to instacrashes.
Fixes#32928Fixes#32927
Changelog:
[Android] [Fixed] - Do not remove libjscexecutor.so from release builds
Reviewed By: ShikaSD
Differential Revision: D33681932
fbshipit-source-id: 5b59fd1fb76c80c191198d65c916bbbd9232c75b
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:
Changelog: [General][Fix] Fix SnapshotExample in rn-tester
Before this diff, the <Image> has no height. You can tell because the backgroundColor of <Image> is black but it doesn't show up on this surface.
Reviewed By: RSNara
Differential Revision: D33649085
fbshipit-source-id: 1b0fa0a82bce29923afee000d0828cbd90845abf
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:
Changelog: [JS] Migrate ScreenshotManager from NativeModule to TurboModule. Fix SnapshotExample in rn-tester.
`const ScreenshotManager = NativeModules.ScreenshotManager;` makes all of RNTesterAppRoute render blank in Bridgeless, because we throw a jsi::JSError when JS calls `NativeModule.get` while in Bridgeless.
Reviewed By: RSNara
Differential Revision: D33640935
fbshipit-source-id: 124a3b43e1440a7ca0071c95c4388350d2e4affa
Summary:
Fix for iOS displaying a RedBox for LogBox handled errors, this has been happening since RN 0.65 (in 64.2 and earlier, if it was handled by LogBox then it wouldn't trigger RedBox)
Fixes https://github.com/facebook/react-native/issues/32106
## Changelog
[iOS] [Fixed] - Stop RedBox from appearing for LogBox handled errors
Pull Request resolved: https://github.com/facebook/react-native/pull/32641
Test Plan: Manually tested. Seems to fix things (and RedBox still displays for things like 'Could not connect to development server') but I would appreciate RSNara or someone else who is more familiar with the code to confirm that the original switch was a mistake and not something deliberately changed.
Reviewed By: christophpurrer
Differential Revision: D33661481
Pulled By: cortinico
fbshipit-source-id: c9c262adb3f977ae3f13beb9575d3eaa2445f663
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840Closes#31516
I've cherry-picked the original PR that had merge conficts + updated all
the headers as the one for the TurboModule generators were not handled.
Original Commit Message from acoates
The codegen generates a Facebook copyright notice at the top of the generated files.
While this might make sense on the core files, this codegen will be run on external components too.
The notice also refers to a LICENSE file in the root of this project, which might not be there if this is run on another project.
I did a quick look at some of the codegen that we ship within windows dev tools, and it looks like we normally just have comments
saying the file was codegen'd and so the file shouldn't be manually edited.
Open to suggestions on what the comment header should say.
Changelog:
[General] [Changed] - Do not include Facebook license on users codegen'd code
Reviewed By: ShikaSD
Differential Revision: D33455176
fbshipit-source-id: b247e72efb242e79d99b388c80e4126633e5234d
Summary:
This fixes https://github.com/facebook/react-native/issues/32898 by reseting ReactInstanceManager state when `createReactContext` throws. By resetting the state, we allow future attempts at creating the React context.
## Changelog
[Android] [Fixed] - Fixed empty screen after retrying a BundleDownloader failure in dev mode
Pull Request resolved: https://github.com/facebook/react-native/pull/32901
Test Plan: Go through the steps to reproduce listed in https://github.com/facebook/react-native/issues/32898 and see that the React Native application starts.
Reviewed By: cortinico
Differential Revision: D33634178
Pulled By: ShikaSD
fbshipit-source-id: e54d12d5f33c9c7c0ca213113871b88c2f1dc261
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## 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] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary:
`const {CrashyCrash} = NativeModules` makes all of RNTesterAppRoute render blank in Bridgeless.
Remove this test example because the CrashyCrash has not existed since 2019, and no similar module exists in open source. [[github]](https://github.com/facebook/react-native/commit/8ec7e0966cf83ed29a39aab47c686bc60a124983)
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D33644122
fbshipit-source-id: ed10e8bf8ea9af9d5904afc2a7d9c2b3b3606978
Summary:
Rename `_header` to `header_` to align with the C++ naming scheme we use.
Rename `readKey` to `readUnsignedShort` as purpose of the method have changed.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33637127
fbshipit-source-id: a82f4d6c1b753b21e0567fbe919af98e4c78105d
Summary:
In the case of T110060790, there is a JavaScript crash that causes RN teardown to race with a ScrollView event being emitted, which ends up being reported as the "real" cause of the crash.
This is not correct, and it's better to just ignore this case. If there's no EventDispatcher, it means something has gone wrong (usually teardown) before, RN is in an inconsistent state, and we should
not crash here or report here.
Changelog: [Android][Fixed] Fix crash from ScrollView that occurs while reporting an error from JS
Reviewed By: mdvacca
Differential Revision: D33644692
fbshipit-source-id: 41c3defde795b804239cc8401c8aff71d017d59d
Summary:
Minor optimization, but spotted this while reviewing the implementation for D33622997
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33622996
fbshipit-source-id: 8712753803fc46e6a046d50f77454a813e4a641a
Summary:
`onPointerMove` events get dispatched with an `offset: [x, y]` attribute (API is not yet available in OSS, so subject to change), but `EventAnimationDriver` in RN Android is not able to extract values with such keys (even though the equivalent JS implementation does allow it).
(TODO: verify iOS behaviour)
Changelog:
[General][Added] - Animated.event can be used to extract values with numeric keys from native events
Reviewed By: mdvacca
Differential Revision: D32531117
fbshipit-source-id: 918a5443c5d8f5f8200d86bb67f84e8bc175c1d3
Summary:
The struct is copied directly to the buffer, so it is safe to read it back.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33624036
fbshipit-source-id: 7ee2b28b815690ab471832c0c622a075b5dd7d78
Summary:
Replaces dynamic manually managed array with a vector of bytes, removing the need for managing memory manually.
This approach is a little bit slower than before, as vector is allocating memory more conservatively. This can be improved in the future by providing an estimate for the data size.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33611759
fbshipit-source-id: a0e5e57c4e413206a9f891cd5630ecc9088a9bf7
Summary:
Instead of copying integer values into key/value data array, this implementation keeps a structured vector of `Bucket` structs (which is sized to be serialized later).
This approach provides multiple benefits to modify and access buckets (e.g. sort them based on the key, allowing for out of order inserts (D33611758))
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33601231
fbshipit-source-id: 62ace1374936cb504836d6eae672e909ea404e3f
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:
MapBuffer uses unsigned short in C++, but Java doesn't really have a type that represents that. That means that MapBuffer would be limited to max 32768 values instead of 65536, which doesn't make much sense as a limitation.
Considering weird (and usually not performant) handling of short values in Java in general, this change replaces them with ints, converting keys from short when needed with `key & 0xFFFF`.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33595308
fbshipit-source-id: a7adde8a207bb4aa1d81d367ab5d7b41ace2e291
Summary:
Adds a check to verify that we are not trying to insert a new view id into a non-existent set.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33621031
fbshipit-source-id: 8468af69bea250a70d656789ea819c39b55a9de6
Summary:
Benchmarks performance/correctness of mapbuffer with several different types of data
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33608299
fbshipit-source-id: 81b1e195aecac60ad1cc3ca416d1cf7b09feab32
Summary:
This method can produce unnecessary copy of the string, replacing it with reference to optimize.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33607765
fbshipit-source-id: e04eddffec063c0c8e173bfdf690e7b8e1050525
Summary:
As the title says, probot/stale is really unpredictable and happens to spam
a lot of issues, making hard for us to follow up on those that are really
relevant.
We're now using actions/stale and this file is no longer necessary.
Changelog:
[Internal] [Changed] - Removed .github/stale.yml as we're now using the Github Action
Reviewed By: mdvacca
Differential Revision: D33585581
fbshipit-source-id: 02a645ca98985edcee22d24c1ad4c0b7056fc15d
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:
Gradle Plugin Portal proxies jcenter which is quite unstable these days. This change updates plugin repositories to look into maven central and google first and use gradle plugin repo only as a fallback.
Changelog: [Internal] - Prioritize maven central for Gradle plugins
Reviewed By: cortinico
Differential Revision: D33550827
fbshipit-source-id: b436b05b0fd07865b56dd3e442d8399678dfff85
Summary:
I'm bumping the Gradle Plugin to the latest stable. That's needed as the newest
plugin now specifies a Maven `group` and can leverage implicit dependency substitution.
Changelog:
[Internal] [Changed] - Bump gradle-plugin to 0.0.4
Reviewed By: ShikaSD
Differential Revision: D33530286
fbshipit-source-id: 904f0a6585b468322f611ed82c57cee7025305d7
Summary:
Cleans up `ReadableMapBuffer` APIs and migrates to use `std::vector` instead of raw pointer array.
Also uses `fbjni` utility to allocate the bytes instead of making manual JNI calls.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33513027
fbshipit-source-id: afe7d320d12830503de4c9994117d849f0b25245
Summary:
Replaces raw array pointer inside `MapBuffer` with `std::vector`, which is more conventional "safer" way of storing dynamically sized arrays.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33512115
fbshipit-source-id: d875a2240f7938fd35c4c3ae0e7e91dc7456ff32
Summary:
React Native includes a `ReactNativeTestTools` file that imports `react-shallow-renderer`. This file is used by Jest tests. Since this file might be consumed by tests outside of the RN repo, the dependency should be promoted to `dependencies` to ensure it is actually present when RN is installed from npm.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D33475662
fbshipit-source-id: 8068294a8b6cade17754699c49a2dfe6d45d86de
Summary:
Draft PR that adds the changelog for 0.67. Generated via the changelog-generator script from 0.66.1 to 0.67-rc0, then updated up to 0.67-rc2, then to latest current (0.67.0-rc.6)
This is the new version of https://github.com/react-native-community/releases/pull/255. To make sure to not lose the feedback on the script on that PR, it has been [recorded here](https://github.com/react-native-community/releases/issues/257).
This PR should be fairly cleaned up compared to its counterpart, but please give it a read 👀 to make sure the entries are correct. The empty sections are currently still in place just in case some new entries should have to be added there.
This will only be published & merged once 0.67.0 is ready/almost ready to go.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - Add changelog for 0.67
Pull Request resolved: https://github.com/facebook/react-native/pull/32529
Test Plan: N/A
Reviewed By: lunaleaps, cortinico
Differential Revision: D33532931
Pulled By: GijsWeterings
fbshipit-source-id: b8cbbbea5cf6489a04009f047ce500df62a66767
Summary:
TurboModules: use weakSelf for block sent to main thread.
Changelog:
[iOS][Fixed] - Use weakSelf in objc block instead of self.
Reviewed By: RSNara
Differential Revision: D33488938
fbshipit-source-id: d03c98fb59fbd1fc4b67686251ebec541e5d3e6c
Summary:
## Context
Inside native ViewConfigs, events are declared using these bubbling/direct EventType maps:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
topFoo: {
registrationName: "onFoo"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**Pattern:** Note that the top name (i.e: topFoo) is just the registration name (i.e: onFoo) but with "on" replaced with "top".
On Android, registration names and top names don't have to follow this pattern. The top name can be **anything.** See ReactionsDockView:
https://www.internalfb.com/code/fbsource/[c430d46ed69a03a9d9f40cefa335a6d8bb92f8ec]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionsDockViewManager.java?lines=26-28%2C32-34%2C38
Here, ReactionDismissedEvent.EVENT_NAME is "topDismiss"
https://www.internalfb.com/code/fbsource/[c9f92314a5c46e561a831100dab82164808b05d0]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionDismissedEvent.java?lines=10-11%2C26
And so to provide you the flexibility to specify a custom topName, the codegen supports a customTopName in the direct/bubbling event types:
```
onDismissWithFeedbackReaction: DirectEventHandler<Event, 'topDismiss'>,
```
This generates the two bubbling event type entries in ReactionsDockView:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
// custom top name
topDismiss: {
registrationName: "onDismissWithFeedbackReaction"
},
// what the top name should actually be
topDismissWithFeedbackReaction: {
registrationName: "onDismissWithFeedbackReaction"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**The Problem:** The entry created for "topDismissWithFeedbackReaction" is not necessary. This additional entry creates a discrepancy between ReactionsDockView's static ViewConfig and native ViewConfig. Therefore, this diff removes the second unnecessary entry.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D33418730
fbshipit-source-id: 3988ff6906ad1b2e1ef988a19c64d1e042381ab1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32848
If we leverage the side-by-side configuration of the NDK
(see https://developer.android.com/studio/projects/configure-agp-ndk#agp_version_41)
we will not have to specify the NDK Path or Version at all.
We will automatically pick the best NDK version selected by AGP.
Changelog:
[Android] [Changed] - Use side-by-side NDK for Android
Reviewed By: ShikaSD
Differential Revision: D33475818
fbshipit-source-id: 16aa4acfc44b94e2f92df89d71e104bf46d7f162
Summary:
Previously we asked users to specify a dependency substitution
rule to properly use the React Native Gradle Plugin.
Here I'm updating the Gradle Plugins setup to allow to use implicit
dependency substitution. This requires to specify a Maven Group and Artifact
Name (through the project name).
This is backward compatible as users will still be allowed to specify a
dependency substitution rule if they wish.
Changelog:
[Android] [Changed] - Leverage Gradle implicit dependency substitution for Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D33404948
fbshipit-source-id: 3323f8e0738fd579ce8ae344cbdc0e4356e7dbd8
Summary:
Fixes https://github.com/facebook/react-native/issues/32835
## Changelog
[Internal] - Make `test_android_template` work regardless of the version
Pull Request resolved: https://github.com/facebook/react-native/pull/32841
Test Plan: Tested locally. Will wait for `test_android_template` to be green.
Reviewed By: hramos
Differential Revision: D33476511
Pulled By: cortinico
fbshipit-source-id: 29a96683afae64cadc9ae4332410cd4d5d9d3e6d
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:
With SVC enabled for codegenNativeComponent, use `UIManager.hasViewManagerConfig(viewManagerName)` instead of `UIManager.getViewManagerConfig(viewManagerName)` to check for whether the native component is in the app BUCK binary.
This is safe because `global.__fbStaticViewConfig` is gated with MC, and the purpose of SVCs is to stop using `getViewManagerConfig` to get view configs from the Paper view managers. Currently no QEs have SVCs enabled.
Changelog:
[Fabric][JS] For codegenNativeComponent, with SVC enabled, use UIManager hasViewManagerConfig instead of getViewManagerConfig
Reviewed By: RSNara
Differential Revision: D33511365
fbshipit-source-id: 58c7020903137e2b5c80ef34a956be04de51628b
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:
For every direct and bubbling event, RCTComponentData (iOS-only) creates a {eventName}: true entry in the component's ViewConfig validAttributes. This entry is unnecessary, and creates a discrepancy between ViewConfigs on iOS vs Android.
This diff removes this entry for all events to:
1. Reduce bloat in native ViewConfigs
2. Create consistency betweeen Android and iOS.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33303950
fbshipit-source-id: 870c8a2a6d41156ac89bd8554eb09f292bb6108e
Summary:
The CI is currently failing with:
```
Error extracting tarball /tmp/cache1419328940 : tar: root/.cache/yarn: Cannot mkdir: Permission denied tar: root/.cache/yarn/v6
```
The problem is that we're sharing the Yarn cache between two jobs (`test_js` and `test_ios_unit_jsc`) which are executed on two difference executors (a Machine vs a Docker container).
I've update the cache key to be `v5-yarn-cache-{{ .Environment.CIRCLE_JOB }}-{{ arch }}-{{ checksum "yarn.lock" }}` so the job name is accounted when computing the Cache Key.
Moreover the `test_js` test was also failing on `flow check` as one of the library we depend on (`resolve`) added a test with a malformed JSON. I'm fixing this failure as well so the CI is back green.
## Changelog
[Internal] - Updating Yarn Cache path to fix broken CI
Pull Request resolved: https://github.com/facebook/react-native/pull/32834
Test Plan: Verified that the external CI is green: https://github.com/facebook/react-native/pull/32834
Reviewed By: lunaleaps
Differential Revision: D33453702
Pulled By: cortinico
fbshipit-source-id: 52bf42db583eaf6aa913f1bb164566f8c3563d36
Summary:
Let's keep our Gradle infra deps up to date.
I'm bumping Gradle to 7.3.3 which fixes several Log4j CVEs,
AGP to 7.0.4 and the Download Task plugin to 4.1.2
Changelog:
[Android] [Changed] - Bump Gradle to 7.3.3 and AGP to 7.0.4
Reviewed By: mdvacca
Differential Revision: D33430789
fbshipit-source-id: b8f260beb4a9cc962ea3743610bfb4ead004d6cb
Summary:
`WritableNativeMap` has two constructors:
```c++
WritableNativeMap();
WritableNativeMap(folly::dynamic &&val);
```
but `WritableNativeMap` has only one constructor:
```c++
WritableNativeMap();
```
Without a second constructor, I am not able to create `WritableNativeMap` from the existing array. I added this second constructor because I need it for `react-native-reanimated`.
## Changelog
[Android] [Added] - Added missing constructor to WritableNativeArray
Pull Request resolved: https://github.com/facebook/react-native/pull/32796
Test Plan:
```c++
std::shared_ptr<jsi::Runtime> rt = facebook::hermes::makeHermesRuntime();
jsi::Value value;
WritableNativeMap::newObjectCxxArgs(jsi::dynamicFromValue(*rt.get(), value));
```
Reviewed By: cortinico
Differential Revision: D33285316
Pulled By: lunaleaps
fbshipit-source-id: 1bbd816892f34ae6fef747066893fe3b803c088d
Summary: Insert casts for implicit int -> CGFloat conversions. This warning category is generally benign and explicitly casting will preserve existing behavior.
Reviewed By: NSProgrammer
Differential Revision: D33303887
fbshipit-source-id: b21adbcf754e707adfe3f8eaa0fe9c3a65380cc5
Summary:
Adds an experimental replacement for preallocation revision checks on Android mounting layer. Instead of checking revisions of props, we remember tags of preallocated/previously allocated views and use this as a filter to avoid issuing extra create and preallocate commands on copy.
This method is a bit more expensive on memory, but is more precise than relying on revisions.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D33038768
fbshipit-source-id: fc98c2a7912e162a3845ca80488635bffaf8cc7f
Summary:
changelog: [internal]
You can read more about this rule on https://clang.llvm.org/extra/clang-tidy/checks/modernize-pass-by-value.html
# Isn't it wasteful to copy? Isn't reference more efficient?
This rule of thumb is no longer true since C++11 with move semantics. Let's look at some examples.
# Option one
```
class TextHolder
{
public:
TextBox(std::string const &text) : text_(text) {}
private:
std::string text_;
};
```
By using reference here, we prevent the caller from using rvalue to and avoiding copy. Regardless of what the caller passes in, copy always happens.
# Option two
```
class TextHolder
{
public:
TextBox(std::string const &text) : text_(text) {}
TextBox(std::string &&text) : text_(std::move(text)) {}
private:
std::string text_;
};
```
Here, we provide two constructors, one for const reference and one for rvalue reference. This gives the caller option to avoid copy. But now we have two constructors, which is not ideal.
# Option three (what we do in this diff)
```
class TextHolder
{
public:
TextBox(std::string text) : text_(std::move(text)) {}
private:
std::string text_;
};
```
Here, the caller has option to avoid copy and we only have single constructor.
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D33276841
fbshipit-source-id: 619d5123d2e28937b22874650366629f24f20a63
Summary:
changelog: [internal]
For some reason, using `TextLayoutManager::Shared` in `TextInputShadowNode` trips up clang tidy linter. We have a plan to move away from `*::Shared` anyway, so let's remove it from `TextInputShadowNode` now.
Why do we want to move away from `*::Shared`?
Using `TextLayoutManager::Shared` is confusing for people unfamiliar with Fabric's codebase. It expresses a concept of immutability but uses term `shared`. Term shared is already used in C++ `std::shared_ptr`.
Reviewed By: fkgozali
Differential Revision: D33186422
fbshipit-source-id: 10ee588735997f5fedc372a1d1e3d9cd9684178a
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:
Quick refactor of ReactRootView where I extract 'Fabric' check into a method
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D33269025
fbshipit-source-id: 2647d5870f3b5fcc5a940a5924a39ca43b5bebac
Summary:
This diff gates the useage of overflowinset to hit test algorithm to fabric renderer only.
Changelog:
[Internal][Android] - Use overflowInset for fabric only
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D33237281
fbshipit-source-id: e5cd78ee97f62f100d42d016241d1544fb0953ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32790
As the name says, I've added a `newArchEnabled` property that can be used to toggle the
New Architecture in the new app template. Users can use this to try the New Architecture in their
project by either:
* Set `newArchEnabled` to true inside the `gradle.properties` file
* Invoke gradle with `-PnewArchEnabled=true`
* Set an environment variable `ORG_GRADLE_PROJECT_newArchEnabled=true`
The Project property will also control if:
* ReactNative dependency should be built from source or not.
* The NDK should be enabled or not.
Please note that this requires RN 0.68.x to run properly (it won't work with 0.67 RCs) or a Nightly version of React Native.
Changelog:
[Android] [Added] - Setup a `newArchEnabled` property to Opt-in the New Architecture in the template
Reviewed By: ShikaSD
Differential Revision: D33065373
fbshipit-source-id: 32085f5b071d6243936bafd91425b5b43e5b5101
Summary:
Just clarifying the purpose of this library.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D33245053
fbshipit-source-id: b4325415774ca33b34b5ba53d222a19f88e2175f
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
The previous diff shows how `overflowInset` could improve hit test algorithm performance. This diff adds experiment to it in order to:
1. Understand the perf improvement in production
2. Provide quick way to rollback in production -- the changes are used by FB4A as well as VR
3. The changes will pass more instructions over JNI, which may have impact on perf.
To share the MC param values in both Java and C++ side, the value is hosted by `ReactFeatureFlags` and fetched in `FbReactInstanceHolder`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33179310
fbshipit-source-id: 327100d41f7b5a668ff0d2afabcdd1fc16cb5a18
Summary:
This diff adds `overflowInset` values in RN Android. These values are used to give an enlarged boundary of a view group that also contains all its children layout. Here is [the post](https://fb.workplace.com/groups/yogalayout/permalink/2264980363573947/) that discuss more on why this is useful. I steal the pic in that post here as TLDR:
{F687030994}
In the above case, we will get overflowInset for ViewGroup A as something like `top: 0, right: -20, bottom: -20, left: 0`.
This has been added in the [Fabric core](https://fburl.com/code/f8c5tg7b) and [in IOS](https://fburl.com/code/vkh0hpt6). In Android, since we used to ignore all event coordinates outside of a ViewGroup boundary, this is not an issue. However, that caused unregistered touch area problem and got fixed in D30104853 (https://github.com/facebook/react-native/commit/e35a963bfb93bbbdd92f4dd74d14e2ad6df5e14a), which dropped the boundary check and made the hit test algorithm in [TouchTargetHelper.java](https://fburl.com/code/dj8jiz22) worse as we now need to explore all the child node under ReactRootNode.
This perf issue is getting obvious when a view loads too many items, which matches our experience with "Hover getting slow after scrolling", "Hover getting slow after going back from PDP view", and "The saved list view (in Explore) is very fast (because it has very few components)"
To fix this issue, I added the support to `overflowInset` to RN Android by
1. Sending the `overflowInset` values from Binding.cpp in RN Android as a separate mount instruction
2. Update `IntBufferBatchMountItem.java` to read the int buffer sent over JNI, and pass the `overflowInset` values to `SurfaceMountingManager.java`
3. Creating new interface `ReactOverflowViewWithInset.java` and extending the existing `ReactOverflowView.java` usages
4. Adding implementation of getter and setter for `overflowInset` in various views
5. Update `TouchTargetHelper.java` to read the values and check boundaries before exploring ViewGroup's children
Note that in #3 I didn't change `ReactOverflowView.java` interface directly. I am concerned about backward compatibility issues in case this interface is being used in OSS. I suggest we deprecate it as we are not using it anymore in our code.
Changelog:
[Internal][Android]
Reviewed By: JoshuaGross
Differential Revision: D33133977
fbshipit-source-id: 64e3e837fe7ca6e6dbdbc836ab0615182e10f28c
Summary:
Tests for Native Modules. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081127
fbshipit-source-id: 3d7270dddd568090ec93d475a08a6a6011dad63c
Summary:
Tests for Native Components. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080789
fbshipit-source-id: ae71d384f6d93da6b89eeb179c4ba7ebcd6ae03d
Summary:
These files are directly copied from the flow parser to aid in reviewing the next two Diffs: D33080789 and D33081127.
The only things that were changed during the copy are the import/require paths to ensure this diff could ship independently. (For this diff, these tests will still test the flow parser instead of importing the typescript parser).
Changelog:
[Internal][Add] - Copy Flow parser tests to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33136296
fbshipit-source-id: 007e18618c9eba13728d19e4e342fbe9642adacc
Summary:
This adds the main entry point for the TypeScript parser as well as adds the logic to use the new parser if the spec file's extension is `.ts`
`js/react-native-github/packages/react-native-codegen/src/parsers/typescript/index.js` is mostly a direct copy from the flow parser.
Changelog:
[General][Add] - Choose Flow or WIP TypeScript Codegen parser based on spec's file extension
Reviewed By: RSNara
Differential Revision: D33081296
fbshipit-source-id: 267823685e6723e3c1f19752bbbe692e895c075b
Summary:
Similar to D33080623, this is the logic for parsing Native Modules and the files were copied from the flow parser and updated for TypeScript. The logic and code path is almost identical to the flow parser.
Also, like D33080623, while there is considerable duplication to the flow parser, I decided there are enough subtle differences to warrant keeping this logic separate.
Changelog:
[General][Add] - Add WIP TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081035
fbshipit-source-id: 5a196e4693df73c0fb88abafe2b4e6be032ea7ed
Summary:
These files are directly copied from the flow parser to aid in reviewing the next Diff, D33081035
Changelog:
[Internal][Add] - Copy Flow parser module logic to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33134982
fbshipit-source-id: 9afea2ce15404338fd2c920a8b7eafe980f18688
Summary:
This is the logic for parsing Native Components. The files were copied from the flow parser and updated for TypeScript specific types and differences in the shape of the AST. The logic and code path is almost identical to the flow parser.
While there is considerable duplication to the flow parser, I decided there are enough subtle differences to warrant keeping this logic separate.
Changelog:
[General][Add] - Add WIP TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080623
fbshipit-source-id: a68c8d4c4570e65a88a97dcea3cd18a6976c53c7
Summary:
These files are directly copied from the flow parser to aid in reviewing the next Diff, D33080623
Changelog:
[Internal][Add] - Copy Flow parser component logic to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33130222
fbshipit-source-id: ba7233b17d698793559da8b81bb7e1a78654e614
Summary:
These are utility functions that the TypeScript parser uses and are copied from and follows the same logic as the flow parser with some TypeScript specific changes. Also added dependency of `babel/parser` as the parsing engine we're using for TypeScript.
Changelog:
[General][Add] - Add foundation for WIP TypeScript parser for Codegen
Reviewed By: RSNara
Differential Revision: D33080527
fbshipit-source-id: d4bd515af549a41f07a2e3ee1a16b5ed678180b2
Summary:
This is a direct copy of the following files from the flow parser:
```
react-native-codegen/src/parsers/flow/errors.js
react-native-codegen/src/parsers/flow/utils.js
```
Changelog:
[Internal][Added] - Copy flow parser foundation files to aid in diff review
Reviewed By: RSNara
Differential Revision: D33137685
fbshipit-source-id: 1345c8bb0785c90b2bd64d4e6e2447f3fdb0ae6b
Summary:
Currently the codegen does not include component with field `interfaceOnly` set to `true` in the `ThirdPartyFabricComponentsProvider`.
These components need to be added to this file, so that non-core components can be used in fabric.
## Changelog
[General [Fixed] - Fixes GenerateThirdPartyFabricComponentsProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/32779
Test Plan:
Run codegen with component outside of core on iOS.
Check if components with and without `interfaceOnly` are added to `RCTThirdPartyFabricComponentsProvider`
Reviewed By: cortinico
Differential Revision: D33235363
Pulled By: ShikaSD
fbshipit-source-id: e7224d2123e4da0da912fe677dae32d3aaea2ec8
Summary:
changelog: [internal]
In an effort to make our codebase more approachable, I'm enabling more clang-tidy rules.
Read more about modernize-avoid-c-arrays in https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-c-arrays.html
Reviewed By: ShikaSD
Differential Revision: D33187162
fbshipit-source-id: c6b3888f67d095274bb492a01132985ae506c0d5
Summary:
the docs mostly use npx to run react native (https://reactnative.dev/docs/environment-setup) and I do not have react native installed globally, so I think npx should be used here as well
<!-- 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] - improved bug template
Pull Request resolved: https://github.com/facebook/react-native/pull/32788
Test Plan: not needed
Reviewed By: lunaleaps
Differential Revision: D33235384
Pulled By: cortinico
fbshipit-source-id: e8d50bb6172066da8d656d3efd0cb6cd17ab1487
Summary:
Binding.cpp shares many responsibilities, including surface management and mount. This change refactors mount (and mount items) into separate files, while retaining the same functionality and interface.
Changelog:
[Internal][Android] - Refactor mount into FabricMountingManager
Reviewed By: mdvacca
Differential Revision: D32977902
fbshipit-source-id: 07cdf5a19033fccaa81901e5b9a4d44192ec7853
Summary:
changelog: [internal]
I will be enabling more clang tidy rules in Fabric to make it easier for new contributors and standardise the codebase. \
You can read more about the rule in https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-bind.html
Reviewed By: ShikaSD
Differential Revision: D33162192
fbshipit-source-id: b4bb332f3134c42c49559a8baf10aeb7a7fdd87f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32769
Changelog: [Internal] Re-purpose bump-oss-version to guide releaser to correctly tag the release and trigger relevant CircleCI jobs
Reviewed By: sota000
Differential Revision: D33121691
fbshipit-source-id: 739f920cd9a04dfb436aff1abe9a05a51df4c32c
Summary:
Changelog: [Internal] Update the comments in publish-npm script to changes in release workflow and leverage `isTaggedLatest` utility.
A lot of this information will be moved to the Release wiki on Github
Reviewed By: ShikaSD
Differential Revision: D33110407
fbshipit-source-id: b01a555a3eed6e505a3b0ad220a0c2c54459ab03
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/32757
Changelog: [Internal] - Update release automation to still be manually triggered as from discussion: https://github.com/reactwg/react-native-releases/discussions/7
A releaser needs to do the following on a release branch like `0.99-stable`:
* For an initial release branch cut:
* Tag the head of the branch `git tag publish-v0.99.0-rc.0`
* `git push origin 0.99-stable --follow-tags`
* For cherry-picks on the pre-release:
* Make the picks on `0.99-stable`
* Tag the head of the branch `git tag publish-v0.99.0-rc.1`
* `git push origin 0.99-stable --follow-tags`
* For promoting pre-release to stable with intention of making this the `latest` npm version:
* Tag the head of the branch `git tag publish-v0.99.0`
* Tag the head of the branch `git tag latest`
* `git push origin 0.99-stable --follow-tags`
Follow-up diff to make this codified via a script
Reviewed By: sota000
Differential Revision: D33101594
fbshipit-source-id: 74b065229a3705fccbe1a25ed7ece4a28d9aa76d
Summary:
Changelog: [Internal] Remove un-necessary package installs which was using `npm install flow-bin --save-dev` which was wiping out our `node_modules` from the circleCI yarn install.
It was un-necessary as we already have `flow-bin` as a dependency in our current set-up.
In addtion, we were running `npm pack` without properly copying over our package.json dependencies (which occurs in `prepare-package-for-release`) for a consumable react-native package.
This may not have caused issue but technically we were creating an "incomplete" package to do our e2e testing on.
Reviewed By: charlesbdudley
Differential Revision: D33197965
fbshipit-source-id: 6583ef1f8e17333c0f27ecc37635c36ae5a0bb62
Summary:
Inits RootView to display size for the early surface start experiment.
Before that experiment, we always had the view measured before the surface was initialized, but here layout can sometimes happen before measure. Surface defaults use [0; Inf) for size constraints, potentially causing a crash in Yoga. This change avoids that by making a guess on default layout size with `displayMetrics`
Changelog: [Internal]
Reviewed By: feedthejim
Differential Revision: D33190397
fbshipit-source-id: 3b1b84135a4980ef2fde4024ec84a448199e00b8
Summary:
changelog: [internal]
Only execute tasks that are expired when in synchronous mode.
Reviewed By: philIip
Differential Revision: D33062746
fbshipit-source-id: 1825cb572202d1f5dc18eb2b481dd3c20e8e91ba
Summary:
This diff adds extra logging to track how long does it take to exeucte different stages of the fabric commit
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D33183070
fbshipit-source-id: 69e31bef69c9d9ec57dc7e00e4c36e278eb30cb6
Summary:
Just released a new version that supports Android App Bundle correctly
https://github.com/facebook/SoLoader/releases/tag/v0.10.3
Reviewed By: passy
Differential Revision: D33167010
fbshipit-source-id: 69c54b1674b06b05a01a468d9f324475e5c232cf
Summary:
changelog: [internal]
Just getting rid of some implicit type conversions and using std::max and std::min instead of macros.
Reviewed By: philIip
Differential Revision: D33161766
fbshipit-source-id: c72011c54f35a145afa236f1dc3d185b19e46cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32777
Changelog: [iOS][Added] Added the new architecture support to the new app template. To apply this change to your project, you will need to update your Podfile. You can try it by using "RCT_NEW_ARCH_ENABLE=1 pod instal" command which updates necessary C++ flags and enable the new codegen discovery required for the new architecture. As context, We've modified the iOS template to have code required to enable the new architecture (aka Turbo modules and fabric / renderer) which requires updating AppDelegate. We also added the support in RNTester as well. We will be sharing more documentation about the new architecture.
Reviewed By: dmitryrykun
Differential Revision: D33154825
fbshipit-source-id: a46b98308e9d29780b6a5245e8faa8be1e257802
Summary:
Similar to the previous diff, we should not allow view group that has clipChildren set to true to respond events that are out of bounds.
Changelog:
[Internal][Android]
Reviewed By: ShikaSD
Differential Revision: D33102331
fbshipit-source-id: de3a5ffdd5293ada1d2c211659e79edc697b5d15
Summary:
In D30104853 (https://github.com/facebook/react-native/commit/e35a963bfb93bbbdd92f4dd74d14e2ad6df5e14a), we added fix to the issue where touches on the child view that is outside of its parent view's boundary are not registered. The only exception to that is if the parent view has overflow style `overflow: hidden`. In that case, touches happen outside of the parent view should be ignored.
{F686521911}
That fix works, but it increases the complexity for the DFS algorithm used to find the touch target in two ways:
1. Before we only traverse views that contain the touch event point. If the touch event point is outside of the view, we won't step in and traverse that part of the tree. This is actually what caused the initial problem. The fix removed that boundary check (where `isTransformedTouchPointInView` used to do) and push it later. This increases the number of tree traversal a lot.
2. The check for `overflow: hidden` is happened after we find a potential target view, which means we've spent time to find the target view before we decide if the target view is even a candidate.
This diff aims to update for the #2 item above. Since we are checking the style of the parent view, not the target view, it's not necessary to check that after we find the target view. We could check the parent view and if it has `overflow: hidden` on it, any pointer event that are not in the boundary can be ignored already.
Changelog:
[Internal][Android]
Reviewed By: mdvacca, ShikaSD
Differential Revision: D33079157
fbshipit-source-id: c79c2b38b8affb9ea0fd25b5e880b22466ab7ed9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32775
Changelog: [Internal] Fix build issues for the new app template with the new architecture enabled
Reviewed By: philIip
Differential Revision: D33157325
fbshipit-source-id: ee63f38fbfc088ca193dfa1b48f4b6611257b787
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32770
Fest is EOL and is replaced by assertj, originally a fork of Fest. This change replaces the usages in internal tests and removes the dependency.
Changelog:
[Internal][Android] Replace fest with assertj
Reviewed By: genkikondo
Differential Revision: D33143454
fbshipit-source-id: c1cbe5b064d007018f73858b2913806c11aa08af
Summary:
Changelog: [internal] Refactor RCTAppSetupUtils to c functions.
Since RCTAppSetupUtils doesn't retain any states, we don't need it to be a class.
Reviewed By: philIip
Differential Revision: D33084352
fbshipit-source-id: 1372a2737eafffa46ee6e5164a970dd12699c71c
Summary: Changelog: [internal] Changed teh new architecture flag in the new app template to RCT_NEW_ARCH_ENABLED
Reviewed By: philIip
Differential Revision: D33083694
fbshipit-source-id: f2cc6c564c724b4ebed7b465a533464b6717ac27
Summary:
Changelog: [internal] Added fabric option to the default app template.
Use RCT_TM_FABRIC_ENABLED C++ flag to enable fabric.
Reviewed By: sammy-SC
Differential Revision: D33052956
fbshipit-source-id: 28313829c80abcf02baa521bdb0b70213c94a97f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32752
Changelog: [internal] Add an optional support for Turbomodule. Define RCT_TM_FABRIC_ENABLED to enable the new architecture.
Reviewed By: philIip
Differential Revision: D33052777
fbshipit-source-id: 6d32790586bb51f9c9244344522c95245c912114
Summary: Changelog: [internal] removed babel-plugin-codegen from the dependency. The dependency will exist in the app template.
Reviewed By: lunaleaps
Differential Revision: D33138950
fbshipit-source-id: f71fa4ca55d13715ccd1ade1424bc3cddbb10d1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32764
Changelog: [Internal] This diff refactors react_native_pods.rb so that it's a bit more readable/maintainable.
With the intorduction of the codegen discovery script, we have two script phases that shares some code. I've factored it out of the main file and wrote a snapshot test so that it's easier to see the output script file.
Reviewed By: cortinico
Differential Revision: D33045541
fbshipit-source-id: 9c80b5d7e11862cc44275e36882487a7d63e8125
Summary:
This diff stack enables codegen to parse TypeScript spec files and generate an identical schema to our current Flow parser.
This first diff is a small cleanup of our current flow parser.
Changelog:
[General][Fixed] - Fix typo in error string and improve consistency in Codegen's flow parser tests
Reviewed By: sota000
Differential Revision: D33080423
fbshipit-source-id: 7bf817761a7704d807a0b809c9f2270354b5c6fa
Summary:
Modernize our null annotations
From the swift blog:
This feature was first released in Xcode 6.3 with the keywords nullable and nonnull. Due to potential conflicts with third-party libraries, we’ve changed them in Xcode 7 to the _Nullable and _Nonnull you see here.
drop-conflicts
Reviewed By: cuva
Differential Revision: D33121042
fbshipit-source-id: 821f5ec858d9afd5bfb1d6081c669f4ca18a36ed
Summary:
Scheduler and JavaUIManager mutexes share the lifetime (between install-uninstall), so we can use singular shared lock to ensure that both sections are locked exclusively for install/uninstall and in shared mode for access.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33130686
fbshipit-source-id: bf283fd5410e386d2635645e17680a9f4cb7f288
Summary:
Allows `CxxModule` objects to set their `instance_` member before `getMethods()` is invoked, allowing for the `Method` callbacks to capture a weak reference to `getInstance()` if needed.
## 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] - Set CxxModules' Instance before retrieving their Method vector.
Pull Request resolved: https://github.com/facebook/react-native/pull/32719
Test Plan: Ensure this statement swap does not break any scenarios with existing CI validation.
Reviewed By: JoshuaGross
Differential Revision: D32955616
Pulled By: genkikondo
fbshipit-source-id: fd7a23ca2c12c01882ff1600f5aef86b1fe4a984
Summary:
Adds a return value to `MessageQueueThread#runOnQueue`, it's implementors and one caller.
It is currently possible for a callback to not be called (because the HandlerThread has been shutdown). If the callback is mission-critical (frees resources, releases a lock, etc) the callee has no indication that it needs to do something.
This surfaces that information to the callee.
Changelog:
[Android][Changed] - Made `MessageQueueThread#runOnQueue` return a boolean. Made `MessageQueueThreadImpl#runOnQueue` return false when the runnable is not submitted.
Reviewed By: RSNara
Differential Revision: D33075516
fbshipit-source-id: bd214a39ae066c0e7d413f2eaaaa05bd072ead2a
Summary:
When using the nightly builds, metro fails with an error because of missing scripts/packager-reporter.js. The file is not included in the published files so this is why.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Add missing scripts/packager-reporter.js file in npm published files
Pull Request resolved: https://github.com/facebook/react-native/pull/32763
Test Plan: Test that nightly builds work when adding the missing file.
Reviewed By: motiz88
Differential Revision: D33128315
Pulled By: ShikaSD
fbshipit-source-id: 617d124205edf63dbca8da50336ca895f5ce866a
Summary:
changelog: [internal]
Just moving code that doesn't belong to UIManagerBinding out of the class.
Reviewed By: philIip
Differential Revision: D33060412
fbshipit-source-id: 2d54929072cef14fd1fa6b70bde382ae21ecff45
Summary: Changelog: [internal] Adding snapshots for script_phases. These snapshots are taken from working scripts.
Reviewed By: cortinico
Differential Revision: D33045627
fbshipit-source-id: fbc1e005954cd185fb5f9b48c55a073ad9d5523a
Summary: Changelog: [internal] Move script_phases script out of react_native_pods.rb so that it's easier to review/debug.
Reviewed By: cortinico
Differential Revision: D33054423
fbshipit-source-id: 460de83a38959a1e45e37f8eda7fe364026fb571
Summary:
Fabric uses a cache where it stores the result of the text measurement in C++ (to avoid unnecessary text measurement that are very costly). This cache has a "max size" of 256 and this size is not enough to store all the texts we have in the screen
In my tests, the amount of texts being measured are ~290 and after scrolling many times they increase to 611.
This diff increases the size of the TextMeasure to 1024 for users in the experiment. As a result this improves performance of HoverEvents by +5x times (see test plan)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33112788
fbshipit-source-id: e15feecf0f54da62b252892d37a64fb4ead29e22
Summary: Changelog: [internal] Fixing a couple of bugs when running with USE_CODEGEN_DISCOVERY.
Reviewed By: mdvacca
Differential Revision: D33115937
fbshipit-source-id: bb770b406b6dbebfefccac488a7c40caaafa6ca6
Summary:
The generated fabric components provider includes fabric headers that won't be included when building without fabric.
This checks the fabric enabled param and skip generating the provider in that case.
## Changelog
[iOS] [Fixed] - Don't generate fabric component provider if fabric is not enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/32761
Test Plan: Test that an app with codegen discovery enabled now builds properly with fabric disabled.
Reviewed By: ShikaSD
Differential Revision: D33111968
Pulled By: sota000
fbshipit-source-id: 3704e11b1e614369f1c652e8cb1acba51cf7ffad
Summary: Changelog: [Internal] Remove this workflow for now as there are some errors and we want to revisit this action and move it under react-native-community
Reviewed By: sota000
Differential Revision: D33103444
fbshipit-source-id: c64bb79df8700af110ddbfbfa3d60ac9a849c964
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32755
Changelog: [Internal] Make the Reat-Codegen script_pahses only triggered when the in-app libaries are modified. When other libraries like ones inside node_modules are modified, you'll need to run `USE_CODEGEN_DISCOVERY=1 pod install` to update the source.
Reviewed By: cortinico
Differential Revision: D33007986
fbshipit-source-id: 0546bbd1d57cd54a482d71b43b296484de60a92c
Summary:
With the updates to touch processing rolled out, we can remove the feature flag and clean up the old code. The old path is now used exclusively by legacy renderer and Fabric uses new `EventEmitter#receiveTouches` method to process touches.
Changelog:
[Changed][Android] - Update touch processing internals
Reviewed By: mdvacca
Differential Revision: D32953664
fbshipit-source-id: 517a4ce6ce9bc15528c2db94d7d11bdff8b78743
Summary:
Applies suggestions from default preset that make sense in our codebase
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33010231
fbshipit-source-id: 6bc9edf01fd9bd9938d211e3494dd1a127b24eaa
Summary:
Applies suggestions from clang-tidy. The automatic linter seems to be broken atm, so I used default config from Android Studio, filtering out meaningless suggestions.
Changelog: [Internal]
Reviewed By: cortinico, sammy-SC
Differential Revision: D32994138
fbshipit-source-id: e8edf53f0cb8b0eda4ff8bb8bf8f5196827efd68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32731
Changelog: [internal] Trigger codegen discovery script when building React-Codegen so that users won't have to run pod install every time modifying fabric / turbomodule library.
Reviewed By: cortinico
Differential Revision: D32979871
fbshipit-source-id: 18550b6b010a9a2b8b7513aaa3b6a7322ea83eff
Summary:
changelog: [internal]
[CALayer opacity] is of type `float`, not `CGFloat`.
Reviewed By: philIip
Differential Revision: D33058967
fbshipit-source-id: 98b214e32f6d35e904a7abb0e01c2d01da50a285
Summary:
Changelog: [internal] Move initital setups in AppDelegate to util classes.
This will make it easy to apply the new architecture changes in the future.
Reviewed By: cortinico
Differential Revision: D33051517
fbshipit-source-id: 16e326b7816fae83df65450c545e7dce1a93b9d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32749
Changelog: [Internal] Move the use_react_native_codegen_discovery call to use_react_native.
Found out that pre_install doesn't get invoked until all podspecs are read. This wouldn't work because I want use_react_native_codegen_discovery to generate React-Codgen podspecs.
I also think it's better to have less logic in Podfiles as it's hard to update once users set it up.
Reviewed By: cortinico
Differential Revision: D33054318
fbshipit-source-id: 6d62be454610c8a1d55988fe376ee3f187510a36
Summary:
Changelog: [Internal] changing the extention from AppDelegate.m to AppDelegate.mm in the app template to support the new architecture.
Most changes were generated when opening the xcworkspace.
Reviewed By: cortinico
Differential Revision: D33051442
fbshipit-source-id: f472a9df26db11a02fc9f7d0544f0207e7c3e7ca
Summary: Changelog: [internal] Add /template/ios/build to gitignore. The folder is auto generated for ios.
Reviewed By: cortinico
Differential Revision: D33051582
fbshipit-source-id: ccf84fa0594d1fbbf224d92004dd05987c9deae7
Summary:
Follow up to https://github.com/facebook/react-native/issues/32683 to also link hermes-inspector statically.
## Changelog
[Android] [Fix] - Static link for hermes-inspector
Pull Request resolved: https://github.com/facebook/react-native/pull/32694
Test Plan: Tested a clean build and made sure hermes-inspector.so doesn't exist anymore.
Reviewed By: cortinico
Differential Revision: D32791208
Pulled By: ShikaSD
fbshipit-source-id: 6076b263469b9e2c6176d488d13292d4f1731dcc
Summary:
changelog: [internal]
Provide `UIManager` to `UIManagerBinding` in constructor to make the API safer.
Reviewed By: philIip
Differential Revision: D32668892
fbshipit-source-id: a15cd295196a60c3f46997e59c05c4f90503e18d
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/32737
Changelog: [Internal] Adding packages/babel-plugin-codegen to react-native. This will add a missing piece to enable the new architecture in nightly build.
Reviewed By: ShikaSD
Differential Revision: D33034294
fbshipit-source-id: 766b97ddaddeaf0813ed9cf9b08a81eac93052ac
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:
lunaleaps did [0.66.4](https://github.com/facebook/react-native/releases/tag/v0.66.4) yesterday - this PR adds the entries for it in the changelog.md file.
## Changelog
[Internal] [Changed] - add changelog entry for 0.66.4
Pull Request resolved: https://github.com/facebook/react-native/pull/32733
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D33017547
Pulled By: cortinico
fbshipit-source-id: 2ffad5d65c7b308686f29395fb6fc54b85804bf0
Summary:
So I was adding a new HTTPCookie prop to our WebView native component and found that my build was [failing](https://www.internalfb.com/diff/D32602297?dst_version_fbid=338931330931416) due to "redefinition of `value`". Looks like we use the name of the prop as a variable name during codegen, and this can conflict with some other hardcoded variable names. Rather than try and come up with a better prop name, I figured we can just append some string to our codegen name to reduce the chance for conflicts.
Changelog:
[Internal][Changed] - Change codegen variable naming to prevent conflicts to prop names
Reviewed By: JoshuaGross
Differential Revision: D32967807
fbshipit-source-id: 1b3631ec783b229eddfd3c801ffbb397910fc882
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:
The IDE warning suggests that passing folly::dynamic by value will create a copy on each call.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D32978154
fbshipit-source-id: a47a60c332a9d299eb2110d3537dfab0bc2398b6
Summary:
feels like this should be shared across oss
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D32940936
fbshipit-source-id: 76fa8fdac5a768586f7f3e916af2c57685a70e12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32724
Changelog: [internal] Fix analyze_pr which was getting stuck at apt-get install openssl ca-certificates
Added -y so that it will install openssl without asking Y/n question.
```
The following packages will be upgraded:
openssl
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
Need to get 620 kB of archives.
After this operation, 1024 B disk space will be freed.
Do you want to continue? [Y/n]
```
Reviewed By: TheSavior
Differential Revision: D32977991
fbshipit-source-id: 6a2e88f7fe61061fd5c18fc8cb28a3b9bfeedaf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32723
D32128979 (https://github.com/facebook/react-native/commit/baded0f9e3e2be43da0c046bd35f4a69362cbb45) added a fabric example to RNTester, and that broke the circle CI test because of a build issue introduced by an build ordering issue (codegen for the example component didn't happen in time). Using codegen discovery the issue wouldn't happen, so I made it only install when use_codegen_discovery == 1.
Caveat is that this would make opening the New Architecture Example throw an error since the native module doesn't exist when running pod install without USE_CODEGEN_DISCOVERY flag. Therefore, I added a message that codegen discovery needs to be enabled in order to try out the example.
Changelog: [internal] Fix rn-tester build
Reviewed By: mdvacca
Differential Revision: D32974821
fbshipit-source-id: b0318ebf122ba00c0121c17a819a730133ab67be
Summary:
I added some functionalities to react-native-codegen to support the new architecture. Publishing the new version so that those are available to use.
Changelog: [internal] Updated react-native-codegen version
Reviewed By: cortinico
Differential Revision: D32941951
fbshipit-source-id: f1ab3d72c76ac153939c634655a4725b4f49d48d
Summary:
#Changelog: [Internal] - This is an attempt to fix public publishing of eslint-plugin-specs. Currently, internal consumption of this package assumes access to `react-native-codegen/src` but for external usage, we leverage the published `react-native-codegen` which transforms files out to the `lib` folder vs. `src`.
For a similar-ish suit, this change is adding a prepublish step that will very basically update the references.
Reviewed By: mdvacca
Differential Revision: D32910080
fbshipit-source-id: f5e508090cbbf5097a848ddef3b721002a6c6277
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
Originally introduced in D2022018
Tried to make the processor optional when no rounding is required, but found even that was not strictly necessary.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D32675492
fbshipit-source-id: 8dfdbf0e4347155045f77b1fba00a59086fe7a33
Summary:
This diff adds a new architecture example to RN Tester for the iOS App
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128979
fbshipit-source-id: b008671553065f4965ba332ac06e01f54d70b331
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]
Event `onChangeText` does not exist in TextInput. Let's remove this method to avoid confusion.
Reviewed By: philIip
Differential Revision: D32882056
fbshipit-source-id: 37eb260b84dd7d6cce412ce1bc39c0cbf9cab112
Summary:
Changelog: [Internal] babel-plugin-codegen.js to fallback to use lib instead of src.
The bubel plugin uses react-native-codegen/src but it's not compatible when react-native-codegen is installed as a separate dependency (which is the case for OSS).
Reviewed By: cortinico
Differential Revision: D32908846
fbshipit-source-id: 1d3e3a3485e94e2f051e220d76dd2dbcdd8070a8
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:
This class is not used and can be safely deleted
Changelog: [Internal] Delete unused Android event emitter
Reviewed By: mdvacca
Differential Revision: D32916706
fbshipit-source-id: 6dceb6b6ed9d201d96454bf0d646853c5c893d59
Summary:
Changelog: [internal] Fixes the output path for the fabric provider.
The old path wouldn't work when the pod installation path is not the same as the app dir.
Reviewed By: cortinico
Differential Revision: D32911493
fbshipit-source-id: 74a8481a2e8397024645d7daff2897e4b0b5454e
Summary: Changelog: [internal] We added generate-artifacts.js and generate-provider.js for codegen, and this diff adds that to the package.json so that it gets included.
Reviewed By: cortinico
Differential Revision: D32910033
fbshipit-source-id: 4982704fd3dac12b9cb64c4b3facb496abef4343
Summary:
This diff add custom prediction for fling distance support. This is needed for customize fling animator to calculate predicted fling distance, instead of using the overscroller that may not be used by the animator.
More context on this -- when fling happens, our code will first predict the final fling position `p`, apply the snapping logic to decide the expected snapping position `pSnapping` given `p`, scroll velocity and children layout, then trigger the overscroller (existing) or custom fling animator to finish the fling.
Currently, the prediction logic is done with overscroller, and custom fling animator has no control over how the predicted fling distance should be. Changes in this diff allow the animator to override `getExtrapolatedDistance` method and provide that information.
Changelog:
[Android][Added] - Add new API for custom fling animator to provide predicted travel distance for its fling animation.
Reviewed By: mdvacca
Differential Revision: D32571734
fbshipit-source-id: d34b969206f8b6cb5c68d2f50a18749bfebbc97e
Summary:
React-native Xcode build steps (such as "Build JS Bundle") rely on `find.node-sh` to find the correct node binary, using nvm if present. We do this because Xcode may run build steps in a fresh shell environment, presumably for repeatable builds.
This PR fixes `find-node.sh`, to respect any `.nvmrc` file that may be present in the build environment.
Today: `find-node.sh` will set the shell environment to the system node version, and ignores any `.nvmrc` the project may provide to pin node for repeatable builds. By ignoring `.nvmrc`, node versions may differ depending on system environment — between developer laptops, or between developer and CI environments. 😞
This problem has been been noticed before in https://github.com/facebook/react-native/issues/8887
### Should this fix happen upstream?
Unfortunately this nvm behavior [is intended](https://github.com/nvm-sh/nvm/issues/2053), for backwards compatibility
## 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] - find-node.sh now respects .nvmrc
Pull Request resolved: https://github.com/facebook/react-native/pull/32712
Test Plan:
Before:
```bash
# nvm isn't loaded
$ which nvm
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v17.0.1
```
After:
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v16.13.0
```
After (no .nvmrc, should preserve previous behavior):
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ source ./scripts/find-node.sh
$ nvm ls|grep default
default -> v14.17.1
# Expected: v14.17.1
$ node --version
v14.17.1
```
Reviewed By: sota000
Differential Revision: D32889629
Pulled By: ShikaSD
fbshipit-source-id: 527384055e303a87bad43413fb66a7fd117d1a63
Summary:
Retrying D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195) 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:
Changelog: [Internal] Adding an option to change the component name for react native codegen.
This will help some use cases where the target name and the actual component names are different.
Reviewed By: fkgozali
Differential Revision: D32852437
fbshipit-source-id: 054a62214cf8bcfea5662b8fba6582d9d7209f90
Summary:
This diff refactors method `predictFinalScrollPosition` in `ReactScrollView` and `ReactHorizontalScrollView` to the helper class. This will make future changes to the prediction logic easier.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32571735
fbshipit-source-id: 7e7e21ac51f929a017cd43de094ed39478fe4032
Summary:
This diff fixes an edge case where scroll to the end of the list may trigger a bounce back effect.
This issue is a regression from D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea) (See [this comment](https://www.internalfb.com/diff/D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea)?dst_version_fbid=263960175698224&transaction_fbid=566201141113715)) that zero velocity fling at the end of the scroll view makes the next fling animator use previous post animation position. This is due to cached `postAnimationValue` is applied mistakenly.
- Pass velocity instead of velocity sign to the helper class
- Update helper class logic to decide if we need to use post animated value from last fling animation
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32566010
fbshipit-source-id: 1c61659030151f8f2c7648ca901b8b4158835538
Summary:
This diff fixes an edge case where fling and snap failed to find the correct target position when children views not fill up all the scrollable space. In this case, the target position would be calculated as the end of the scrollable space, which case the snap logic to go to the end of the scrollable area, instead of stop at the expected snapping position.
Changelog:
[Android][Fixed] - Fix fling and snap with recycler viewgroup where fling to the end of scrollable distance when it goes over current rendered children views.
Reviewed By: mdvacca
Differential Revision: D32565459
fbshipit-source-id: 319ef6e2d4e1c4deb9e45ed02c1bff7d807575c3
Summary: Changelog: [Internal] Add a `isTaggedVersion` function to filter out commits from release automation.
Reviewed By: sota000
Differential Revision: D32842035
fbshipit-source-id: 14bb262a1d2a96ffda87c759a3202c4f9a356141
Summary:
Bump deprecated-react-native-prop-types dependency to ^2.3.0. This version contains a .windows.js fork of some deprecated props. Current version has missing information for Windows, breaking CI for react-native-windows repository.
## Changelog
[General] [Changed] - Upgrade deprecated-react-native-prop-types dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/32700
Reviewed By: lyahdav, rozele
Differential Revision: D32816801
Pulled By: yungsters
fbshipit-source-id: f6a8507637075b1a936d91c264bbd8a462505f48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32698
Changelog: [Internal] - Renaming the eslint-plugin-codegen to eslint-plugin-specs as a better descriptor for this package. Part of the plan is to publish as a public npm package
Reviewed By: RSNara
Differential Revision: D32777702
fbshipit-source-id: 7776c481871031dba1280d87fb76b777ecc23339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32693
Changelog: [Internal] this diff adds dependecies to the buck files so that an internal app that referes RNtester will work as intended.
Reviewed By: cortinico
Differential Revision: D32778338
fbshipit-source-id: d4703903c2227283fe9c70f02bb7da420d936fbb
Summary:
changelog: [internal]
Background executor has been shipped on both platforms for a long time.
I've kept the flag around because I wanted to run tests and compare Concurrent Mode vs Background Executor. The intention was to see if we can get rid of Background Executor to simplify the threading model.
Since then, React team has moved away from Concurrent Mode towards more gradual rollout of concurrent rendering and it no longer makes sense to do this comparison. Right now, we don't have a concern with concurrent rendering and Background Executor. If we ever want to run the an experiment, this gating will need to be added again.
Reviewed By: javache
Differential Revision: D32674798
fbshipit-source-id: a1e51c9c5b8e48efa4cb0f25379d58e7eb80ccd9
Summary: Changelog: [Internal] Adding an option in RN Tester to enable the new codegen discovery option where it uses generate-artifacts.js to codegen native files. It also updates generate-artifacts.js to support the case where react-native is not within node_modules. It also updates the option name for rn-demo-app.
Reviewed By: cortinico
Differential Revision: D32777912
fbshipit-source-id: f2b76fa61573e3d4507a9f16f8243ac7ca006900
Summary:
I've noticed that the `performance.now()` implementations differ on iOS and Android.
iOS:
```objc
PerformanceNow iosPerformanceNowBinder = []() {
// CACurrentMediaTime() returns the current absolute time, in seconds
return CACurrentMediaTime() * 1000;
};
```
Android:
```c++
double reactAndroidNativePerformanceNowHook() {
auto time = std::chrono::steady_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::nanoseconds>(
time.time_since_epoch())
.count();
constexpr double NANOSECONDS_IN_MILLISECOND = 1000000.0;
return duration / NANOSECONDS_IN_MILLISECOND;
}
```
For consistency, I thought why not just use the same implementation on both iOS and Android.
It also seems more logical to use Chrono on iOS, since it has nanosecond precision and we just multiply it to milliseconds, whereas `CACurrentMediaTime` multiplies to seconds, and we divide it down to milliseconds again.
## Changelog
(internal change only)
Pull Request resolved: https://github.com/facebook/react-native/pull/32695
Test Plan:
Run on iOS and Android:
```ts
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: feedthejim
Differential Revision: D32793838
Pulled By: ShikaSD
fbshipit-source-id: e7967780be95956a75a3a3757311af0077976d23
Summary:
Changelog: [Internal] Remove warning about creating a pull request to a release branch
We want to support this use case as we want pick requesters to land the cherry-picks themselves and rely on CircleCI automation to test
Reviewed By: cortinico
Differential Revision: D32780819
fbshipit-source-id: 882625a016653dbf480da33fd499d3718b2b5524
Summary:
changelog: [internal]
UIManager::animationTick is thread safe. Let's make it obvious by marking the method const.
Reviewed By: javache
Differential Revision: D32669102
fbshipit-source-id: 49e35d0f0a5c5d1b03baa1cbf9cdece082909e85
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
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:
I've been seeing a couple crashes related to missing hermes-executor-common.so, seems to happen on specific android versions, but can't repro. I investigated this so file more and noticed it is incorrectly linked as a static library here https://github.com/facebook/react-native/blob/b8f415eb6cdc0e0e7a7413b6f9defdcee304d9e8/ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/Android.mk#L20. There doesn't seem to be any reason for this to be a shared lib so I changed it to be compiled as a static lib.
## Changelog
[Android] [Fixed] - Make hermes-executor-common a static lib
Pull Request resolved: https://github.com/facebook/react-native/pull/32683
Test Plan:
- Verify there is no more hermes-executor-common-{release,debug}.so
- Test locally in an app to make sure it build and run properly.
- Verify that the crash happening on play store pre-launch report doesn't happen anymore.
Reviewed By: ShikaSD
Differential Revision: D32754968
Pulled By: cortinico
fbshipit-source-id: cb57e2d81edb4cbdb1f003dab45c53e594a5a62a
Summary:
Changelog: [Internal] Revert --sourcemap-output argument
Reverting on main from discussion from the 67 release:
https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1705266
Original commit changeset: 0c2d98746b36
Reviewed By: GijsWeterings
Differential Revision: D32734743
fbshipit-source-id: cc3130581d01bdcdc9f5d483161ae9506fdbf7b8
Summary:
changelog: [internal]
Attempt at fixing a crash in `Scheduler::uiManagerDidCloneShadowNode` by setting delegate to nullptr explicitly.
I don't think this will make a difference because `scheduler_` is released at the end of `dealloc` but it is worth a shot. Maybe some complex interaction between Obj-C and C++ comes into play here.
In this diff I also removed `_animationDriver = nullptr` because dealloc will do that automatically.
Reviewed By: philIip
Differential Revision: D32720901
fbshipit-source-id: 227ced2331384c47e8d15a323ee8a621bbb3d179
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:
Changelog: [Internal] Update CircleCI to auto-deploy release branch on push
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff updates the relevant CircleCI workflows
Reviewed By: sota000
Differential Revision: D32702420
fbshipit-source-id: e20cdeb53eb4a8ce7e54e083e3e14bd89e11b789
Summary:
Changelog: [Internal] - Extract logic from bump-oss-version specific to prod releases
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `prepare-package-for-release` script referenced by extracting it out of `bump-oss-version` and leveraging `set-rn-version`. It adds some helper functions to `version-utils` with tests
Reviewed By: sota000
Differential Revision: D32556610
fbshipit-source-id: eb4ddc787498744156f985ab6d205c5d160e279b
Summary:
Changelog: [Internal] Copy over universal (across dry-run, nightly, release) work in `bump-oss-version` script
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `set-rn-version` script referenced by extracting it out of `bump-oss-version`
Reviewed By: sota000
Differential Revision: D32556608
fbshipit-source-id: 6c2868c01ddd930375279a5105bcd0d447f65734
Summary:
Changelog: [Internal] - Add getNextVersionFromTags to determine next release version off a release branch
In more detail - this work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
This function is later used in `prepare-package-for-release` script in D32556610 to bump the version
Reviewed By: cortinico, ShikaSD
Differential Revision: D32556609
fbshipit-source-id: 7d93ead0b34318a58ffeb876715fbd34d6041f4e
Summary:
The helper class for ScrollView should not need to detect the scroll direction. If it has to do so, that means the corresponding logic should live in the `ReactScrollView` or `ReactHorizontalScrollView` respectively.
This diff is to remove the scroll direction detection logic from the scroll view helper. Long term we should keep it this way as the shared code got moved to the helper class from the scroll view classes.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32514429
fbshipit-source-id: 2165f2eba90cc25d14834c39148fe8ce8805bea6
Summary:
This diff fixes two edge case (similar to a race condition) that caused unexpected behaviors.
**Problem one**
{F680816408}
The previous fling animation is not canceled when user starts to scroll or drag. This is causing both the animation and scroll are setting the scroll position. Depends on the animation path and scroll speed, there may be cases where the [velocity calculation](https://fburl.com/code/010lsu72) ends up getting reversed values. See P467905091 as an example where you can see `mXFlingVelocity` goes back and forth from positive to negative.
It's hard to see if the wrong values are in the middle, but if that happens in the end of user gesture, the velocity for the next fling would be wrong. It shows a "bounce back" effect, and can be triggered when user makes small quick joystick scrolls in one direction.
**Problem two**
{F680821494}
There is a gap between animator's `onAnimationEnd` lifecycle method [finished](https://fburl.com/code/6baq04ne) and the `Animator#isRunning` API to return false. This is causing issues for `getPostAnimationScrollX` where we [decide to return](https://fburl.com/code/hzzugvch) the animated final value or the scroll value. User may see the `-1` value got used for the next fling start value, and the whole scroll view goes back to the beginning of scroll view and starts to fling.
This happens when the previous fling animation finishes and the animated final value is set to -1, but at the same time the next fling starts before `isRunning` returns false for the previous animation.
**Solution**
The problems are fixed by
- Do not reset animated final value to -1 in `onAnimationEnd` method
- Add `mIsFinished` states and use it to track animation finish signal, instead of using `isRunning` API
- Update logic where we decide to return the correct value for the next animation starts point. We will return previous animated final value when the animation got canceled, and user is going towards that value from the current scroll value.
Changelog:
[Android][Fixed] - Fixed edge case for quick small scrolls causing unexpected scrolling behaviors.
Reviewed By: javache
Differential Revision: D32487846
fbshipit-source-id: f1b0647656e021390e3a05de5846251a4a2647ff
Summary:
If `value` is of type `float`, it will still fall through to the `react_native_assert` below, exploding. The `map` type is handled correctly.
Changelog: [Internal][Fixed] Fix fromRawValue(EdgeInsets) from single float case falling through to float array and exploding
Reviewed By: javache
Differential Revision: D32648848
fbshipit-source-id: e70cddd291a8f52d6ee3de5fef11b0bb7aee92cd
Summary:
The `__apply_Xcode_12_5_M1_post_install_workaround` script changes the `IPHONEOS_DEPLOYMENT_TARGET` to `11.0` for all pods. This causes problems if the pods were targetting `12.0` or higher. Many expo modules are targetting `12.0`.
I fixed this issue by checking the existing version and only bumping the target if it is lower than `11.0`.
See also: this discussion post by mikehardy https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523
## 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] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail
Pull Request resolved: https://github.com/facebook/react-native/pull/32633
Test Plan:
### Test (failing before this patch, passing after this patch)
1. pick an iOS Pod that has a minimum deployment target of iOS 12 or higher, I chose the Braintree package
2. `npx react-native init myrnapp`
3. Open `ios/Podfile` and add the pod as a dependency: `pod 'Braintree', '~> 5'` (and upgrade the Podfile target to 12 (`platform :ios, '12.0'`))
4. Compile the app.
Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0
After applying this patch: ✅ Build succeeds
Reviewed By: fkgozali
Differential Revision: D32638171
Pulled By: philIip
fbshipit-source-id: 0487647583057f3cfefcf515820855c7d4b16d31
Summary:
The `add-version-label-issue` CI is failing if the version label is not found.
That is happening for previous versions of RN where the Labels are missing.
Changelog:
[Internal] [Changed] - Do not report a CI failure if add-version-label-issue is red
Reviewed By: sammy-SC
Differential Revision: D32723953
fbshipit-source-id: 878d2632b3a78311a01363b8f8a9181ae543a253
Summary:
As the title says. It's now safe to enable Fabric by default inside RNTester.
Changelog:
[Internal] [Changed] - Enable Fabric by default inside RN-Tester
Reviewed By: fkgozali
Differential Revision: D32723540
fbshipit-source-id: dab786694ba9ceb238570608713b5243a730aada
Summary:
Preallocation can take 10-20% of time when creating new nodes. (according to systrace measurements). At the moment, we are executing all preallocation calls in JS thread, potentially slowing down the progress there. Moving them to bg thread is a simple micro-optimization that ensures we return the node to JS as soon as possible.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32677843
fbshipit-source-id: 3df47ae9aa365a8db720d71e2423c87659e9128c
Summary:
Removes extra .so files by merging built-in components into libfabricjni.so
These components shouldn't be referenced in outside modules, so merging them is trivial atm.
Changelog:
[Internal][Android] - Compile native components into static libraries
Reviewed By: cortinico
Differential Revision: D32677572
fbshipit-source-id: fc1a6c5a2832ee49e438c30856562f85677514ea
Summary:
Noticed we explicitly dropped the `allow_jni_merging` while not actually using it anywhere, and that we didn't have `fbandroid_allow_jni_merging` on some other libs.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D32355868
fbshipit-source-id: 6bd3fcc395e3dcacf4a8fc1033d471b2ffb0e8af
Summary:
Changelog: [internal]
Nothing was using `stop` parameter, let's get rid of it.
Reviewed By: philIip
Differential Revision: D32669018
fbshipit-source-id: dc2d52048a2f7dd3785dd959270087001c778962
Summary:
This task is supposed to really clean all the files that are generated
as part of a build and bring you to a clean state.
Changelog:
[Internal] [Changed] - Create a `cleanAll` Top Level Gradle task.
Reviewed By: ShikaSD
Differential Revision: D32649942
fbshipit-source-id: 20b72ad4e1c0ef046aaaba94e2331176dca49abf
Summary:
This diff makes the fling animator cuztomizable, so that the subclasses can have their own animation for fling behavior.
Before the diff, we rely on the `OverScroller` to `fling`, which has some issues with Spline interpolation being messed up due to the clamped fling distance (See more details in T105464095). This may not be a big issue for mobile when user touches screen, but in VR environment this shows up very clearly with joystick events. To fix that properly without affecting mobile behavior, I added a new interface `HasFlingAnimator` from the helper, and implemented with default fling animator in the OSS ScrollView.
We should consider adopt a suitable animator for mobile platform, as the non-smooth fling effect is also happening in mobile.
- Add interface `HasFlingAnimator` to `ReactScrollView` and `ReactHorizontalScrollView`
- Add default fling animator
- Depend on if the default animator is used, customize the flingAndSnap behavior
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D32382806
fbshipit-source-id: 08f03350f6a9b9fc03414b4dcb9977b9f33603ba
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368
Summary:
Seems like the Gradle plugin was left behind when bumping AGP.
This bump is quite significant as AGP removed several dependencies from their
exported one so I had to reimport them again (ideally we should move to kotlinx-serialization).
I've also addressed a couple of Kotlin compiler warnings that were not related to
the AGP Api (those will be addressed at a later time).
Plus I've also fixed the target Java version to 11 as the compiler was complaining
that Java target was at 11 while Kotlin Jvm target was defaulted at 8
Changelog:
[Internal] [Changed] - Bump AGP to 7.x inside the react-native-gradle-plugin
Reviewed By: ShikaSD
Differential Revision: D32667745
fbshipit-source-id: 044930bf6cc49065eff4af1c9be79de76d5b368b
Summary:
Custom metro port not working without exporting variables from `.packager.env`
## Changelog
[General] [Fixed] - Fix support for custom port
Pull Request resolved: https://github.com/facebook/react-native/pull/32666
Test Plan: run `react-native run-android --port=8082` and `react-native run-ios --port=8082`
Reviewed By: yungsters
Differential Revision: D32694233
Pulled By: cortinico
fbshipit-source-id: 42e803d56b83608024b901d2a3024733ed7099b7
Summary:
This Diff fixes a crash happening as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The crash happens as `mFabricViewStateManager` is accessed during
the ctor of the superclass, and is not yet initialized.
Fixes#31572
Changelog:
[Android] [Fixed] - Fix crash on ReactEditText with AppCompat 1.4.0
Reviewed By: ShikaSD
Differential Revision: D32674975
fbshipit-source-id: efa413f5e33527a29fbcfa729e8b006ecb235978
Summary:
Changelog:
[iOS][Fixed] This is a quick speculative fix since we know `CFRunLoopPerformBlock` does not push/pop an autorelease pool.
Reviewed By: appden
Differential Revision: D32657298
fbshipit-source-id: 4641ad89baf7889ba4bf80e6e64e26de02818cb8
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:
a lot of unused code here, cleaning it up
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32640185
fbshipit-source-id: 2917b4e3ea9c08ccb520250de509f0253d5dae61
Summary:
a year ago or so, there was a change that updated the way RCTBundleURLProvider creates the IP url depending on if HERMES_BYTECODE_VERSION existed, and this test was never updated, so fixing it accordingly
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32638669
fbshipit-source-id: 3824b90570f60ad5299939b09b99fb56d2b3ddaa
Summary:
we couldn't run the RNTesterUnitTests before because these tests didn't respect the nullability specification. after this diff, we can run the tests.
as for the tests.... well 2 are still failing, i'm taking a look at them.
Changelog:
[iOS][Fixed] - fixed RCTImageLoaderTests
Reviewed By: sammy-SC
Differential Revision: D32635689
fbshipit-source-id: d68ae6a3e7f1370d7d76d68c7a6d9812928e6c12
Summary:
The Codegen is generating a broken output if using the default library name: `Packages<GradleModuleName>Spec`.
This diff is fixing the codegenerator to don't call the `.lowerCase` on the library name when generating the Makefile.
Changelog:
[Android] [Fixed] - Do not .lowerCase the library name when codegenerating TurboModule Specs
Reviewed By: ShikaSD
Differential Revision: D32597578
fbshipit-source-id: dee729a44134d7b3878074507191bb2a1c200608
Summary:
AGP 7.x is changing the path where we can find
the precompiled static libraries. Therefore is getting complicated
to share prebuilt `.a` files. I'm updating `libruntimeexecutor` to be
a shared library instead so this will solve this issue for now.
Changelog:
[Internal] [Changed] - Update libruntimeexector to be a shared lib rather than a static lib
Reviewed By: ShikaSD
Differential Revision: D32646112
fbshipit-source-id: ce42e930076c1d3b5f54f3d8adcca1c38909d0fb
Summary:
Bump Android Gradle Plugin to 7.
## Changelog
[Android] [Changed] - Bump Android Gradle Plugin to 7.
This will make Java 11 a requirement for users that are either:
* Cloning react-native to contribute
* Using react-native while building from source.
* Creating new project from the template.
Pull Request resolved: https://github.com/facebook/react-native/pull/32589
Test Plan: CI is green
Reviewed By: ShikaSD
Differential Revision: D32427945
Pulled By: cortinico
fbshipit-source-id: c1ea464d87c3e397616c55154b3d8b1c3ea6c592
Summary:
here's a way we can mock C apis - however i am not sure if the flag i'm using is correct
used in D31949237
Changelog:
[General][Added] - add macros to be able to stub C functions in tests
Reviewed By: RSNara
Differential Revision: D31949238
fbshipit-source-id: 0f18a65f810f1b855dbc844f11f5a304c1e5ecea
Summary:
after D32591685, no one is using this. delete
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D32591686
fbshipit-source-id: 11ffb8cbf0fef605b7aefa47347db3ccc6e7d7fe
Summary:
similar to android, we want to handle removing dropped surfaces. in this diff, we add the API to do so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32557069
fbshipit-source-id: 2487c459df3f1f412ad0da77568d6c0ab0a1298c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32642
This Diff adapts the Dangerfile to be a bit more friendly
for PRs that are exported from Phabricator. Specifically,
I'm disabling the check for Test Plan as those are not exported
externally. The check for Summary and Changelog are instead adapted
to work with the format exported for Phabricator.
Changelog:
[Internal] [Changed] - Make Danger Phabricator-friendly
Reviewed By: yungsters
Differential Revision: D32594622
fbshipit-source-id: e31f29defdd926a267cecc9efa6d63de2e580f43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32640
This Diff shows how an application can provide a custom Fabric Components Registry.
The idea is to extend the CoreComponentsRegistry from rncore to provide the extra
components that are generated from RNTester.
Please note that this Diff can't be shipped as it is and should be rebased on top of:
- D32493605 (https://github.com/facebook/react-native/commit/aa4da248c12e3ba41ecc9f1c547b21c208d9a15f) As the CLANGFORMAT is disabled for RNTester at the moment
- D32045059 (https://github.com/facebook/react-native/commit/d29f3d2a6b84c17ad057f4e9c8dc35b3fe16fb19) and D32128979 as they're effectively adding the sample component and the iOS code.
Changelog:
[Internal][Added] - Adding a Custom Fabric Component to RNTester
Reviewed By: ShikaSD
Differential Revision: D32498360
fbshipit-source-id: 1a737359498dddb571c8a445bec18e5dbcf53e04
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 prevents view flattening for views that are handling some events in the JS side
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253124
fbshipit-source-id: acda2b12287f0a9c39a810b23a101765093ba217
Summary:
This diff updates the internals of Fabric to add support for onEnter/onExit/onMove events.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253128
fbshipit-source-id: 5b30e927bda0328ba1332801f66a6caba77f949b
Summary:
This diff updates the BaseViewManager in order to store metadata in views that are handling JS events.
This information will be used later in the stack to optimize dispatching of hover events and fix viewFlattening bugs
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D32253127
fbshipit-source-id: b6b74f0b1a5b8cc652b3ac3fff42165ee4ce85e1
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 hook up the event emitter onScroll event to the native text input view
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32523146
fbshipit-source-id: d8035deacc8a511577a6fb892ac55c9e07b14392
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: [Internal]
# Context
Whilst looking at Marketplace Loom traces, ShikaSD made the remark that we could potentially start the JS work much earlier instead of waiting for the View.onMeasure call, a behaviour that is already built-in Venice.
Reviewed By: ShikaSD
Differential Revision: D32559505
fbshipit-source-id: cc6337955ad2b6a6581a0347f1f976679eaca54d
Summary:
This is expected with Suspense/CM enabled. We are measuring the perf impact of extra CREATE instructions atm, and will revert the change if it regresses too much.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D32558829
fbshipit-source-id: 2e0c91be3aba4ca632814739aed6b8964e21b5a8
Summary:
This PR add [volta](https://volta.sh/) support to find-node.sh for use by `scripts/react-native-xcode.sh`, `scripts/generate-specs.sh`, etc.
## Changelog
[iOS] [Added] - add volta support to find-node.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/32611
Test Plan:
Manually tested with volta installed node (and [relevant change](https://docs.volta.sh/guide/understanding#managing-your-project) added to the project's package.json). Without this patch, the `Bundle React Native code and images` Build Phase fails, with it, it succeeds.
Tested with both `curl https://get.volta.sh | bash` installed and `brew install volta`. One check works for both because the `node` shim will always be installed to the same location (and the required environment variable exports are the same also)
Wasn't sure if you'd want the package.json change applied to rn-tester? Shouldn't affect people who don't use volta. Shout if you want me to add it to this PR.
Reviewed By: cortinico
Differential Revision: D32498267
Pulled By: yungsters
fbshipit-source-id: 93ee187bd2178bfcd8f9009a1a0668c6f5583aa3
Summary:
This diff refactors the scroll animation from `ReactScrollView` and `ReactHorizontalScrollView` into the `ReactScrollViewHelper` to reduce repeated code. The `Animator` is now shared between all the scroll views in the app, which I believe is the right behavior.
It also helps to make the animator changes in future diffs apply to both horizontal and vertical scroll view.
- Move `reactSmoothScrollTo` to `smoothScrollTo` in the helper class
- This means one Animator for all ScrollViews
- Move `updateStateOnScroll` to the helper class
- Add interface for accessing instance scroll state properties in ScrollView
- This means each ScrollView keeps their own scrolling state
- Use `Point` class for pairs of x and y values
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32372180
fbshipit-source-id: 529180eea788863689c3b440191ed50c5a6f04e5
Summary:
This diff supports monorepo/custom configuration where node_modules may not be located under app_root.
The default (RN_root, '..') should support most cases, but I also added an option to provide a custom location for users to set.
Changelog: [internal]
Reviewed By: ShikaSD
Differential Revision: D32469957
fbshipit-source-id: 6b8a6c775c21bde72ef542e34973701d698f678f
Summary:
resolving issue in https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
we didn't hook up the onScroll event to the fabric text input component yet, so this stack does that
in this diff, we add the onScroll event to the event emitter
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D32479450
fbshipit-source-id: 3ac0e6f87a4bf391e3ceee24b5765e3e41ecc59d
Summary:
As we're working on C++ code for RNTester to integrate Fabric, we should enable CLANGFORMAT for the files over there.
Changelog:
[Internal] [Changed] - Enable CLANGFORMAT on fbsource/xplat/js/react-native-github/packages
Reviewed By: ShikaSD
Differential Revision: D32493605
fbshipit-source-id: 7b5d63f6d2fae1a1aa1e782738953c8cd2cdbe4b
Summary:
This diff adds a very simple example to show the use of new architecture in a component.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32045059
fbshipit-source-id: f388bfb765241122de425fbef61cea0620cd31ac
Summary:
This diff actually adds the usage of ThirdPartyFabricComponentsProvider. We cannot land this until we start using generate-artifacts.js at pod install time.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128889
fbshipit-source-id: 9af39d73c8b5fe3ff9d70190fd83f679914bfd27
Summary:
This diff adds a support to generate ThirdPartyFabricComponentProvider when codegen discovery isn't enabled. This functionality will be removed when we start using the new way of generating code as a default.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D32420306
fbshipit-source-id: 219bcdf6cb186196ca62e651086dedab485b063e
Summary:
This messes with python version selection. At least based on
the comments, it is no longer needed, as /opt/local/bin appears to be
empty on my devserver and on a sandcastle host.
D32337004 revealed the problem. T105920600 has some more context. I couldn't repro locally, so D32451858 is a control (which I expect to fail tests) to confirm that this fixes the test failures.
#utd-hermes
Reviewed By: neildhar
Differential Revision: D32451851
fbshipit-source-id: 4c9c04571154d9ce4e5a3059d98e043865b76f78
Summary:
Ensures (under a flag) that CREATE instructions will be issued even if the node was supposed to be preallocated before from create or clone. This addresses cases when differ considers nodes to be deleted->created, but we skip the "create" part because of revision check.
Changelog:
[Internal] Disable node revision checks during mount under a flag
Reviewed By: sammy-SC
Differential Revision: D32440831
fbshipit-source-id: 4da8c4961fd7bc43c8f4166798bdfb5d897184e0
Summary:
Changelog:
[Internal][Fixed] - I have been reading this header file recently and discovered some typos
Reviewed By: kodafb
Differential Revision: D32455214
fbshipit-source-id: c27291943476014b787ee1641fd8642056bdbc5a
Summary:
This reverts commit fcead14b0e.
This should close https://github.com/facebook/react-native/issues/32509 . There was a bug where il8nManager.forceRTL() wouldn't work on app launch, and required an app restart. That was caused by an earlier change (https://github.com/facebook/react-native/pull/31032) which should not be necessary (the deadlock it was attempting to fix was actually caused by separate code).
## 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] - Fixed bug where forceRTL did not work on app launch
Pull Request resolved: https://github.com/facebook/react-native/pull/32574
Test Plan: Simple revert back to previously working code.
Reviewed By: RSNara
Differential Revision: D32315034
Pulled By: GijsWeterings
fbshipit-source-id: dae6c1f0a2481e53f2f1e80f1ac083947681ef99
Summary:
Bump Gradle to 7.3, also configure gradle cache key to include gradle version so that we don't keep cache for other versions and have smaller cache, faster CI.
## Changelog
[Android] [Changed] - Bump Gradle to 7.3
Pull Request resolved: https://github.com/facebook/react-native/pull/32588
Test Plan: CI is green
Reviewed By: ShikaSD
Differential Revision: D32427806
Pulled By: cortinico
fbshipit-source-id: 776406ef3aa7962cf3a4abc178e3c8a4762a01e0
Summary:
motivation: I have a custom setup and needed to provide `react.cliPath`. I mistakenly provided path to `react-native-community/cli` which resulted into JS bundle not being generated. This error message provides a little more detail.
## 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] - Improved error message in react.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/32593
Test Plan: I guess it's not needed in this case
Reviewed By: ShikaSD
Differential Revision: D32427929
Pulled By: cortinico
fbshipit-source-id: 2be340a8be15c8ec08873c0368a36b449c8b5030
Summary:
Bump react-native-android docker image to 5.0, which includes JDK 11.
## Changelog
[Internal] [Changed] - bump react-native-android docker image to 5.0, which includes JDK 11.
Pull Request resolved: https://github.com/facebook/react-native/pull/32186
Test Plan: Android CI must be green
Reviewed By: ShikaSD
Differential Revision: D30897954
Pulled By: cortinico
fbshipit-source-id: 9b6696bac424ab188a0443b8315edbb9596dd166
Summary:
There will still be a case where this script is used when fabric is disabled. This diff adds the flag so that whether to generate fabric components can be controlled by the user.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32380881
fbshipit-source-id: 786931848b1eca5015c8f58f4361b395c8d341cc
Summary:
This moves the output location for turbo modules from build/generated/ios/react/renderer/components/ to build/generated/ios/ so that the third party modules can use Spec/Spec.h to import. In the future we might use the same folder structure for both components and modules.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32340162
fbshipit-source-id: 6ad7c8ae92e072cd26e44b47914afa33618acbcb
Summary:
FBReactNativeSpecs.podspec is currently only acting as a config for codegen. It should not include any sources. This would fix unintended build error related to FBReactNativeSpecs-generated file.
Changelog: [internal]
Reviewed By: philIip
Differential Revision: D32267102
fbshipit-source-id: 27b510198666dc26a890cd7a6f873a04a9df66ca
Summary:
Fixed a bug in `react_native_assert` that was not effectively letting the app
call `abort()`. The app was actually printing on log twice.
Ref: https://developer.android.com/ndk/reference/group/logging#__android_log_assert
Changelog:
[Android] [Changed] - Let react_native_assert really abort the app
Reviewed By: JoshuaGross
Differential Revision: D32204080
fbshipit-source-id: ca16c50aaf4e41a2318277c233be0e944b2ad8f1
Summary:
I'm adding a `EmptyReactNativeConfig` for Java as we had a similar class in C++.
Ideally inside the Playbook we can allow users to use this class rather than having to
create an anonymous inner class.
Changelog:
[Internal] [Added] - Introduce EmptyReactNativeConfig inside Java
Reviewed By: ShikaSD
Differential Revision: D32277916
fbshipit-source-id: f6bbeb0477681d536dfd89930b732609add7c43a
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:
Summary
bugfix for multiple shadow threads rendered at the same time, small probability crash.
Changelog
Android
Fixed
ViewManagersPropertyCache.class
Background:


4 tab(RN Page) has 4 ReactInstanceManager.
4 ReactInstanceManager has 4 shadow threads and 4 JS threads.
4 RN Page if rendered at the same time. small probability crash
the key crash log(full log at the end):
java.lang.IllegalArgumentException: method com.facebook.react.uimanager.LayoutShadowNode.setWidth argument 1 has type com.facebook.react.bridge.Dynamic, got java.lang.String
need Dynamic and got String.
Reasons of crash: PropSetter class field : VIEW_MGR_ARGS, VIEW_MGR_GROUP_ARGS, SHADOW_ARGS, SHADOW_GROUP_ARGS is static.
one shadow thread put data in static array, it was changed by another shadow thread before method invoke.
No.1 shadow thread put "Dynamic" in static array.
No.2 shadow thread put "String" in the same static array(replace the "Dynamic").
No.1 shadow thread invoke method with the static array as params. the crash..
The solution:
use ThreadLocal instead of static array.
Pull Request resolved: https://github.com/facebook/react-native/pull/32167
Test Plan:
I make 4 tab page rendered at the same time and test 100 times. it is not crash again.
about 15% chance of crash before fixed.
Crash stack:
2021-09-08 11:56:07.392 16776-17062/com.shopeepay.merchant.id.debug E/unknown:ViewManager: Error while updating prop width
java.lang.IllegalArgumentException: method com.facebook.react.uimanager.LayoutShadowNode.setWidth argument 1 has type com.facebook.react.bridge.Dynamic, got java.lang.String
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:111)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
2021-09-08 11:56:07.488 16776-17062/com.shopeepay.merchant.id.debug E/unknown:ReactNative: CatalystInstanceImpl caught native exception
com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'width' in shadow node of type: RCTView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:125)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
Caused by: java.lang.IllegalArgumentException: method com.facebook.react.uimanager.LayoutShadowNode.setWidth argument 1 has type com.facebook.react.bridge.Dynamic, got java.lang.String
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:111)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
2021-09-08 11:56:07.488 16776-17062/com.shopeepay.merchant.id.debug E/com.shopeepay.merchant.id.debug: com.shopee.app.react.util.ReactJSException: Error while updating property 'width' in shadow node of type: RCTView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:125)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
2021-09-08 11:56:07.571 16776-16776/com.shopeepay.merchant.id.debug E/com.shopeepay.merchant.id.debug: com.shopee.app.react.util.ReactJSException: Trying to add unknown view tag: 1519
at com.facebook.react.uimanager.NativeViewHierarchyManager.manageChildren(NativeViewHierarchyManager.java:487)
at com.facebook.react.uimanager.UIViewOperationQueue$ManageChildrenOperation.execute(UIViewOperationQueue.java:209)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:917)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1028)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:48)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1088)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.615 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.626 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.674 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.677 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.686 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.698 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:08.406 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:08.423 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:09.594 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
Reviewed By: cortinico
Differential Revision: D31904828
Pulled By: ShikaSD
fbshipit-source-id: 1337a1e9f0320417b441efe84e9066f15ffcd12e
Summary:
Changelog: [Internal]
* Sets a default custom reporter in `scripts/packager.sh` that redirects Metro's logs to a JSON file when the `RCT_PACKAGER_LOG_PATH` environment variable is set. Otherwise we use Metro's `TerminalReporter`, [like the CLI does by default](https://github.com/react-native-community/cli/blob/0993f627869f4de0e5a8a9a950d38a9f15e18fb2/packages/cli-plugin-metro/src/commands/start/runServer.ts#L124).
* Modifies `scripts/launchPackager.command` to write logs to `$RCT_PACKAGER_LOGS_DIR` (and in particular use the JSON reporter) if this environment var is set.
* Uses [`open -n`](https://ss64.com/osx/open.html#:~:text=Open%20a%20new%20instance%20of%20the%20application) to execute `launchPackager.command` from Xcode, so that environment variables are reliably passed to the script even if a Terminal process is already running.
Reviewed By: yungsters
Differential Revision: D32295290
fbshipit-source-id: 4d783e1f94d122d3a35c104b2b02dbfaf8e1a1a3
Summary:
Adds a phase to generate-artifacts.js to generate the third party components provider for fabric. The output path needs to align with where the rest of generated files go (the work is wip).
Changelog:[internal]
Reviewed By: hramos
Differential Revision: D32128834
fbshipit-source-id: 8721b8a19bcf01bb388a293ce17162b4e578a72a
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 https://github.com/facebook/react-native/commit/63038500a23d2dc10798cc116bb70c03064db8bc#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:
lunaleaps did [0.66.3](https://github.com/facebook/react-native/releases/tag/v0.66.3) yesterday - this PR adds the entries for it in the changelog.md file.
## Changelog
[Internal] [Changed] - add changelog entry for 0.66.3
Pull Request resolved: https://github.com/facebook/react-native/pull/32576
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D32321194
Pulled By: yungsters
fbshipit-source-id: dadffb21fd9ece245acf761947e8fef544a00b7d
Summary:
Currently, we don't have a way to extend RCTFabricComponentsPlugins in OSS. This diff adds a codegen to generate ThirdpartyFabricComponentsProviderwhich will be used to extend RCTFabricComponentsPlugins.
It works almost exactly the same as RCTFabricComponentsPlugins, and in the future we might want to consider merging them together.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128760
fbshipit-source-id: b4f3a082f94c3053251cc6a0323c488f649deaa9
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:
Update the version of flow-parser used by JSCodeshift to the latest, so it can handle new syntax like indexed access types.
Fix up some jscodeshift scripts that had failing tests due to updated parser.
Reviewed By: yungsters
Differential Revision: D32226600
fbshipit-source-id: cdd045bad523df9bf14af35ddab9516fc75ce900
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:
Upgrades ESLint to v7.28.0. This is the latest version before v8.0.0, which would be a more involved upgrade.
Upgrades all ESLint-related dependencies to their latest version, except for [eslint-plugin-flowtype](https://github.com/gajus/eslint-plugin-flowtype/). This is because eslint-plugin-flowtype@8.0.0 dropped support for ESLint v7.
Configures ESLint for Metro to extend `plugin:prettier/recommended`.
## Changelog
[General][Changed] - Upgraded packages to the latest versions for ESLint v7.
Pull Request resolved: https://github.com/facebook/react-native/pull/32560
Test Plan:
Run this on an open source checkout of `facebook/react-native`:
```
# See no new errors or warnings.
$ yarn run lint
```
Run this internally:
```
$ js1 test xplat/js/tools/__tests__/dependency-constraints-test.js
```
Verify linting works:
```
js1 lint xplat/js/RKJSModules/Libraries/Core/
```
Reviewed By: lunaleaps
Differential Revision: D32258399
Pulled By: yungsters
fbshipit-source-id: d11b3fc3e33770157a90f3dee352cf80b39c442c
Summary:
Renames `Keyboard.removeEventListener` to `Keyboard.removeListener`.
When I implemented the compatibility layer in {D26589441 (https://github.com/facebook/react-native/commit/035718ba97bb44c68f2a4ccdd95e537e3d28690c)}, 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:
Changelog:
[Android][Added] Adding new API `onChildEndedNativeGesture` to the RootView interface to let its implementations notify the JS side that a child gesture is ended.
Reviewed By: javache
Differential Revision: D32228745
fbshipit-source-id: ad1f26546dd60f9c5a569b0bc3ad5020a01b90cc
Summary:
The conversion between std::string and Java strings is failing when initializing the `SurfaceHandler`. Instead of manually converting strings, this change makes native init use built-in fbjni helper instead.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32281900
fbshipit-source-id: 056fce56b40c036d454925c8734bbf2a16f327ff
Summary:
The `Event.getSurfaceIdForView` method I added recently is actually a duplicate of `UIManagerHelper.getSurfaceId`, except that the latter doesn't support RootViews very well.
Changelog:
[Android][Changed] - Improved UIManagerHelper.getSurfaceId and removed Event.getSurfaceIdForView
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D32102175
fbshipit-source-id: 01741df6b646037a4575e9ca302ea248af9fd6f3
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
Summary:
NOTE: Second attempt at merging https://github.com/facebook/react-native/pull/32486 (D32080994 (https://github.com/facebook/react-native/commit/25d4cb98b07434a98cbc415cdf248bd8e20ab8b8)).
This is a fixed version of the https://github.com/facebook/react-native/issues/32380 PR. It solves a typo, prevents variable substitution in the patch file, and moves it to a better place in the script so that CURRENT_ARCH is actually detected before checking whether to patch.
The `config.sub` included in glog is too old and does not recognize `arm64-*` as a valid arch when building. This, combined with an out of date Flipper-Glog version, results in persistent build failures on Apple Silicon machines.
p.s. i assume all the podfile lock changes were caused by me running this on an Apple Silicon Mac, and thus all the pod checksums were run against the arm64 versions of those pods rather than the normal x86_64 versions. if this is an issue I can revert the changes to that file, but it would seem to be an inevitable issue in future PR diffs...
## Changelog
- [iOS] [Fixed] - Apple Silicon builds of glog & Flipper-Glog
Pull Request resolved: https://github.com/facebook/react-native/pull/32486
Test Plan: See `react-native-oss-ios` Sandcastle job succeed.
Reviewed By: fkgozali
Differential Revision: D32256761
Pulled By: yungsters
fbshipit-source-id: c7f32b72287018f070910b26aad02aa0adf4a61f
Summary:
This is a nit, but the capitalization of `ComponentFactory` is wrong
and should be lowercase. I'm fixing it.
Changelog:
[Internal] [Changed] - Fix capitalization of ComponentFactory in RNTester
Reviewed By: ShikaSD
Differential Revision: D32247341
fbshipit-source-id: e8a9f264139f20d85a8e00fad947b2c9465ef630
Summary:
I've unified the function that is responsible of getting the `reactNativeArchitectures` property
to a single one (ideally we could move it inside the Gradle Plugin in the future).
I've also added a property in the `gradle.properties` file. This makes easier for users to customize the
architecture to build without having to specify a CLI flag or edit multiple gradle files.
Changelog:
[Android] [Added] - Make the `reactNativeArchitectures` property more discoverable
Reviewed By: ShikaSD
Differential Revision: D32244997
fbshipit-source-id: 33180544400f9abe63e9b539ff16fefa17a024ba
Summary:
Currently the release build of RNTester is broken
as it's loading the debug native libraries. I had to create
separate tasks for the two variants as we can't benefit
of automatic variant matching between project (as of now till
we use prefabs or find another approach).
Changelog:
[Internal] [Fixed] - Fix Release build of RNTester
Reviewed By: ShikaSD
Differential Revision: D32203637
fbshipit-source-id: 5c260a365626e9b3c66e76166086711236a38264
Summary:
Changelog: [Internal] - Don't fail build_npm_package when there is no PR environment set to post the link to.
The script will fail with an error thanks to changes: https://github.com/facebook/react-native/commit/86491749ee67562e424209f644f7273061633687
Reviewed By: fkgozali
Differential Revision: D32221758
fbshipit-source-id: ceb7fb654e4c13e195f20e28798e66e6854bcbcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32543
Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version
Context:
* There are two types of tags, git and npm, they are unrelated.
* When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version.
* When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version.
* npm and git's `latest` tag should always point to our most recent stable version
This change:
* Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest"
* If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag
* Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`.
* This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version.
Reviewed By: hramos
Differential Revision: D32196239
fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
Summary:
Changelog: [Internal] Remove unnecessary logic and new parseVersions function
Changes:
* Remove `tagsForVersions` which in the past got all the tags for the `currentCommit` to figure out which one we're releasing to. I believe this is redundant because the CircleCI envvar `CIRCLE_TAG` should already have the version that we're releasing -- this is set in `bump-oss-version`. Note: this will only be set for full-on releases, (re: not nightly or commitly)
* Re-arrange some logic to group where we set `releaseVersion` and separate where we call `bump-oss-version` script for dryRun (commitly) && nightly builds
Reviewed By: hramos
Differential Revision: D32196237
fbshipit-source-id: 10f21f71bad1ea0496c5eb9094271cc4454a2544
Summary:
lunaleaps did a few patch releases over the last few days. This PR adds the entries for them in the changelog.md file.
## Changelog
[Internal] [Changed] - add changelog entries for 0.64.3, 0.65.2 and 0.66.2
Pull Request resolved: https://github.com/facebook/react-native/pull/32549
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D32205887
Pulled By: cortinico
fbshipit-source-id: c4b173730c6bdf1349c29df26d136aa9f6d4568d
Summary:
For native animations,
* Add NS_ASSUME_NONNULL_BEGIN / END to RCTNativeAnimatedNodesManager since most of its params are nonnull.
* Explicitly mark nullable params.
Reviewed By: philIip
Differential Revision: D32209819
fbshipit-source-id: c881294d8ba8c2cdcaa931801c977cd5bbe764f4
Summary:
Make viewName in native animations nullable, because viewName is not used when the RCTAnimationNode is managed by Fabric.
Changelog: [Internal] Minor: Make viewName nullable in native animated modules for Fabric
Reviewed By: philIip
Differential Revision: D32196270
fbshipit-source-id: 76d05dc7fd2850efb097f953ccd22fd3f6d80599
Summary:
Use generate-artifacts.js script when USE_CODEGEN_DISCOVERY envvar is set to 1 at `pod install` time. Setting this envvar will disable the old codegen script.
Added `[Codegen]` prefix to all codegen log output.
Note: This script is not ready for production use at the moment.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31693778
fbshipit-source-id: 25da95bdb33315ac42c6dfb40334e22ec9823cb1
Summary:
When switching between split screen or resizing the screen window on Android causes a restart by reconstructing the app components as described on this issue https://github.com/facebook/react-native/issues/25040
## 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
-->
[Android] [Fixed] - Don't reconstruct app components https://github.com/facebook/react-native/issues/25040
Pull Request resolved: https://github.com/facebook/react-native/pull/32536
Test Plan:
### How to reproduce
- create a new project
- build app and install on Android
- minimize app and start split screen
Expected:
- App enters split screen
Result:
- App restart
Same issue can be seen when resizing the split screen window
Reviewed By: cortinico
Differential Revision: D32175433
Pulled By: yungsters
fbshipit-source-id: 93dccaa134074eea260cca61eba2150444fa5688
Summary:
C++-only TurboModules, not to be confused with [TurboModules](https://www.internalfb.com/intern/wiki/React_Native/Building_Product_Experiences/Intro_to_Native_Modules/), directly allows you to call C++ from JS instead of going through the native layer. Referred to modification of C++-only TurboModule D30158226 and https://fburl.com/code/rcf73a42 for C++ to JS call (jsInvoker is an object that can schedule work on the JavaScript thread)
This example shows JS to C++ call and storing a JS function in C++ to call later.
Notes:
* To use the module, import the C++ module directly in objc.
* Meanwhile, create a js spec and use it in RN code. Spec methods don't need to be marked as optional.
* C++ and js spec will be linked when built
Reviewed By: RSNara
Differential Revision: D32080496
fbshipit-source-id: 9c214ca22c18f793d5f8b54997d129bdfa73e61a
Summary:
The current warning assumes the ruby binary to be single arch, but the ruby version shipping with macOS is universal `universal.arm64e-darwin20`. This PR changes the check to search for `arm64` in any position instead of just the beginning to fix false positives.
## Changelog
[iOS] [Fixed] - Fix Rosetta2 CocoaPods warning on Apple Silicon
Pull Request resolved: https://github.com/facebook/react-native/pull/32498
Test Plan:
### Before
On M1 Mac `pod install` using system ruby always yields a warning.
### After
`pod install` does not yield a warning.
`arch -x86_64 pod install` yields a warning.
Reviewed By: fkgozali
Differential Revision: D32013176
Pulled By: sota000
fbshipit-source-id: 84f517c210318b5d073d161b6849b9aee367bba6
Summary:
Running `pod install` from outside the `ios` folder fails because the
path to `React-Codegen` is wrong:
```
% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
[!] No podspec found for `React-Codegen` in `ios/build/generated/ios`
```
## 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] - `pod install --project-directory=ios` fails due to wrong path to `React-Codegen`
Pull Request resolved: https://github.com/facebook/react-native/pull/32489
Test Plan:
1. Verify that `pod install` still works in `/packages/rn-tester`
2. Verify that `pod install --project-directory=ios` also works:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
```
Reviewed By: lunaleaps
Differential Revision: D32158140
Pulled By: sota000
fbshipit-source-id: 98f12b0073cd911cb9de06201222d866ef7649a4
Summary:
## Rationale
- **Consistency with Static View Configs**: In Static View Configs, if there isn't a diff or process function, we do not generate a property for it.
- **Type-safety**: The [Flow type for attributes](https://fburl.com/code/tafncg5c), doesn't allow null diff/process functions.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32152924
fbshipit-source-id: 4156158c5fe09868feec1a0c55aa411d2bd72a27
Summary:
Setting `reactNativeDebugArchitectures` currently does not seem to work for RNTester, since it sets `abiFilters` which conflicts with the `splits` option we're already setting.
Gradle then complains:
```
neildhar@neildhar-mbp ~/f/x/j/react-native-github (default) >
./gradlew -PreactNativeDebugArchitectures=x86_64 :packages:rn-tester:android:app:installJscDebug
> Configure project :ReactAndroid
Unable to detect AGP versions for included builds. All projects in the build should use the same AGP version. Class name for the included build object: org.gradle.composite.internal.DefaultIncludedBuild$IncludedBuildImpl_Decorated.
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':packages:rn-tester:android:app'.
> com.android.builder.errors.EvalIssueException: Conflicting configuration : 'x86_64' in ndk abiFilters cannot be present when splits abi filters are set : x86_64,x86,armeabi-v7a,arm64-v8a
```
Consolidate everything with the `splits` option.
In addition, it's convenient to also be able to control the native architecture for release builds.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D31834075
fbshipit-source-id: c6375d2a1e242981d0017f6e0a9d428b074a3fbd
Summary:
CircleCI stopped populating `CIRCLE_PULL_REQUEST` without providing an
alternative, so now it's impossible to get the PR number unless it comes
from a forked repo.
## Changelog
[Internal] [Fixed] - ignore bundle size reporter failures
Pull Request resolved: https://github.com/facebook/react-native/pull/32490
Test Plan: CI should ignore bundle size reporter failures.
Reviewed By: fkgozali
Differential Revision: D32008694
Pulled By: lunaleaps
fbshipit-source-id: 68e25ac2fbb23c1d7a55e667c90aec3a61302b8a
Summary:
Ensures that copy of the native touch objects happens before consuming them.
The reverse order seems accidental after refactor, as copying objects doesn't consume them whereas adding to a native array does. This behavior didn't show up during testing in dev environment (only affects CANCEL events), and it seems to be the cause of high-firing crash on production.
Changelog: [Internal] Copy touch objects before consuming them in the new touch path.
Reviewed By: mdvacca
Differential Revision: D32112036
fbshipit-source-id: e9ec47689b7ceb0a40a23bab9f03367c4acb8632
Summary:
Makes new touch processing path check for double dispose on touch events.
Old event dispatcher has a race condition which makes it double-dispose some events, so we need to make sure it also processes touches correctly.
Changelog: [Internal] Check for double dispose when sending touch event
Reviewed By: cortinico
Differential Revision: D32110250
fbshipit-source-id: d6a12cbac60f9ff5e836cfaca5a47c467bea06c7
Summary:
This pull request aims to remove iOS 11 availability check which is no longer needed.
The minimum iOS deployment target for React Native is iOS 11 but we still have iOS 11 version check like below.
```
if (available(iOS 11.0, *)) {
```
This is a continuation pull request of https://github.com/facebook/react-native/pull/32151
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Remove iOS 11 availability check
Pull Request resolved: https://github.com/facebook/react-native/pull/32488
Reviewed By: yungsters
Differential Revision: D32006312
Pulled By: ryancat
fbshipit-source-id: 0ee6579e433a15d3d220a52d2ccd6931b0513971
Summary:
We are in the middle of a Prettier upgrade and some of the files which disagree between Prettier v1.x and v2.x are now being flagged by `eslint-plugin-prettier` as lint errors.
The correct fix here is probably to update `eslint-config-prettier` and `eslint-plugin-prettier`, but I am landing this first to unbreak CI.
Reviewed By: mendoncakeegan
Differential Revision: D32129458
fbshipit-source-id: a5206a5ef58f1d7614f9459c99b9e39109be6de9
Summary:
**Motivation:** Readability. It was hard to tell how componentName, paperComponentName, and paperComponentNameDepreacted produced the NativeComponentRegistry.get call.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D32108276
fbshipit-source-id: ea7c9fe4dc50cdd6fec94b5cd25f7bbcfb451ef6
Summary:
This is a fixed version of the https://github.com/facebook/react-native/issues/32380 PR. It solves a typo, prevents variable substitution in the patch file, and moves it to a better place in the script so that CURRENT_ARCH is actually detected before checking whether to patch.
The `config.sub` included in glog is too old and does not recognize `arm64-*` as a valid arch when building. This, combined with an out of date Flipper-Glog version, results in persistent build failures on Apple Silicon machines.
p.s. i assume all the podfile lock changes were caused by me running this on an Apple Silicon Mac, and thus all the pod checksums were run against the arm64 versions of those pods rather than the normal x86_64 versions. if this is an issue I can revert the changes to that file, but it would seem to be an inevitable issue in future PR diffs...
## Changelog
- [iOS] [Fixed] - Apple Silicon builds of glog & Flipper-Glog
Pull Request resolved: https://github.com/facebook/react-native/pull/32486
Test Plan:
- Clone this branch on both an Apple Silicon- & Intel-based Mac
- Run `pod install` in `packages/rn-tester`
- Confirm that build passes successfully
Reviewed By: cortinico
Differential Revision: D32080994
Pulled By: yungsters
fbshipit-source-id: 76a7c5bba20d91905455920609c890e92bb5b980
Summary:
For the sake of the playbook, I'm bumping the codegen to the latest stable.
This is needed as there was a change in the Android NDK Makefile that wasn't shipped yet.
Changelog:
[Internal] [Changed] - Bump codegen to 0.0.10
Reviewed By: hramos
Differential Revision: D32101355
fbshipit-source-id: c20268f1ea93ebad8f92f760874a43c8ceeaf9f9
Summary:
For the sake of the playbook, I'm bumping the Gradle Plugin to the latest stable.
Specifically a change in how CLI args are parsed (D31908041 (https://github.com/facebook/react-native/commit/70785e3d5a41bc85cea83aec0240e9f11aeff1ff)) was not backward compatible,
therefore we need to migrate users to the new version.
Changelog:
[Internal] [Changed] - Bump gradle-plugin to 0.0.3
Reviewed By: hramos
Differential Revision: D32101577
fbshipit-source-id: 9a29b988a4b520a8ece10a90a9a4bedc02ec16ad
Summary:
This PR adds the following GitHub actions:
- https://github.com/lucasbento/core-workflow-create-version-label - Create version labels (such as `Version: 0.65.1`) whenever there's a new release;
- https://github.com/lucasbento/core-workflow-apply-version-label - Apply a version label to opened/edited issues based on the version mentioned on the issue body.
## Changelog
N/A.
## Few things to keep in mind
- A label named "Version: unspecified" must be created;
- The GitHub action to create labels will only run when there's a new release or if one is edited, it will then create all the other labels bases on the previous releases until it encounters one that already exists.
---
Example of issue with version label: https://github.com/lucasbento/test-issue-forms/issues/4
Pull Request resolved: https://github.com/facebook/react-native/pull/32508
Reviewed By: cortinico
Differential Revision: D32055682
Pulled By: lunaleaps
fbshipit-source-id: 04d3e942eb1f71b3bc1d5a643b0156c35ef5f00b
Summary:
## Rationale
**Disclaimer**: This is an incremental step towards more maintainable/readable react-native-codegen generators. In the future, we may want to replace these templates/string concat logic with *something better*. But until we decide what that *something better* is, let's at least get rid of all this gross string find/replace.
Benefits of using Function templates over String.prototype.replace.
- **Self-documenting**: Template Functions enumerate/describe their exact data dependencies in their signature. You no longer have to read the template implementation to see what data you need to pass into the template.
- **Improved Readability**: JavaScript syntax highlighting makes it really easy to see where/how the data is inserted into the templates. Also template variables used be prefixed/suffixed with ::, which made things really confusing in C++ code (e.g: wtf is `::_CLASSNAME_::EventEmitter::::_EVENT_NAME_::`?).
- **Simpler Interpolation**: Don't have to worry about .replaceAll vs .replace, or calling these replace functions with regexes or strings.
- **Template Type-safety**: Ensure that the correct data types are passed to the component templates (e.g: flow will complain if you accidentally pass null/undefined when a template expects a string).
- **Template Type-safety**: Ensure that we don't pass in extra data to templates (this diff catches/fixes instances of this error). Ensure that we don't forget to pass in data to the template.
- etc.
After this diff, both our Component and NativeModule generators will be using template functions. This string find/replace exists no more in react-native-codegen.
This is also a very surface-level change. I made no efforts to simplify these templates. Let's take a look at that later, as necessary.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32021441
fbshipit-source-id: f8f27069bcbf9d66dcafb7d1411da1f938eb6dcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32443
This diff removes all the custom Gradle machinery to build the native code and delegates to AGP
the triggering of the `ndk-build` command. This means that the native build will be now invoked
with the `:ReactAndroid:externalNativeBuild<Variant>` task.
An important thing to notice is that that task will always run, and will delegate to Make the
compilation avoidance. If you invoke the task twice, the second time it will be significantly faster.
On my machine this takes ~6/7 mins the first time, and 30 seconds the second time.
There are some gotchas that are worth noting:
* The native build will run on every build now. Given the complexity of our native build graph,
even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the
targets and mention that there is no work to be done. I believe this could be impactful for local
development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI
of the target device (e.g. arm64 for a real device and so on).
This reduces the native build to ~10 seconds.
* All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be
considered invalid. Therefore they will re-extract the header files inside the folders that are
used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building
locally, if you plan to edit react-native-gradle-plugin and relaunch
rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here
would be to invoke the tasks like
```
gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \
-x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \
-x generateCodegenSchemaFromJavaScript
```
Changelog:
[Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task
Reviewed By: ShikaSD
Differential Revision: D31683721
fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
Summary:
Change usages of `exports.foo` and `module.exports.foo` to just `foo`.
This will fix future errors when Flow no longer allows reads from `exports`/`module.exports`.
Changelog: [Internal]
Reviewed By: bradzacher
Differential Revision: D32009490
fbshipit-source-id: bb609b37ba948b44c3877f8dbbfa9137b963586b
Summary:
The debug message stays `Building RNTester with Fabric enabled.` even if we set `fabric_enabled = false`
This pull request changes the message like below when `fabric_enabled = false`
`Building RNTester with Fabric 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
-->
[iOS] [Fixed] - Fix the debug message for Fabric in rn-tester
Pull Request resolved: https://github.com/facebook/react-native/pull/32502
Reviewed By: sota000
Differential Revision: D32027858
Pulled By: lunaleaps
fbshipit-source-id: baf5301581e354f588830acd12a5e8171799b1ca
Summary:
Make `generate-specs-cli.js` use named arguments.
Updated all `generate-specs-cli.js` callsites to make use of named arguments.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31908041
fbshipit-source-id: f2cb5967db3c3b847e1095e35e8d5d21585be27b
Summary:
When calculating the offset range, we assume the first item is always at offset zero position and skipped that (as the smallerOffset is zero). However, this may not be the case in some situations. This diff changes the range measuring loop to always start from the first item.
Changelog:
[Android][Fixed] - Do NOT skip the first child view in the scroll view group when measuring the lower and upper bounds for snapping.
Reviewed By: mdvacca
Differential Revision: D31887086
fbshipit-source-id: af7221a621b2719d057afa6b64aa91c94ac01295
Summary:
Publishing a new version of the Gradle plugin as we need to distribute some
changes before releasing the playbook to the public.
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.0.2
Reviewed By: ShikaSD
Differential Revision: D31957686
fbshipit-source-id: ef6742a205f2b568714c349dcb6481af33254b9b
Summary:
I'm removing the `src/test` folder from the npm bundle as it's not really
needed for the sake of distributing the gradle plugin.
Changelog:
[Internal] [Changed] - Do not publish tests inside the react-native-gradle-plugin npm package
Reviewed By: ShikaSD
Differential Revision: D31956449
fbshipit-source-id: b84138d24a7c51c44b92ebfc84f35afb3668dee5
Summary:
While working updating the codeden Makefile template for Android, I've removed
the `libreact_debug` and `libreact_render_debug` dependencies as they were unused in a
simple turbomodule. Turns out that `:ReactAndroid` is depending on having those dependencies.
Moving the build file to use AGP APIs, triggers this scenario and is making `ReactAndroid`
failing to build (see the build status for https://github.com/facebook/react-native/pull/32443).
I'm updating the codegen Makefile template to reintrodce the two libraries + I've update the prebuilt
makefile (used in the playbook) to include `react_debug` prebuilts as they were missing.
Changelog:
[Internal] [Changed] - Re-add libreact_debug to codegen makefile and add prebuilts for them
Reviewed By: ShikaSD
Differential Revision: D31900675
fbshipit-source-id: ff188c0498a0dca4a951a548a580ca8dd0674782
Summary:
Some of the prerendered surfaces rely on Android context being present to have correct theming (e.g. for platform colors) and measurements of platform components. This change uses context provided to initialize the surface as themed context before view is attached.
This way it is possible to configure theming with `ContextThemeWrapper` the same way as Litho does it for prerendering. The assumption is that any kind of customization done through Android theme will be applied from prerendering entry point as well.
Changelog: [Internal] - Use context from surface for prerendering
Reviewed By: mdvacca
Differential Revision: D31906091
fbshipit-source-id: 344fc96eb2f85ba5b762bee64d1a29443b3fd1d3
Summary:
I missed to push this change in the previous diff D31809012 (https://github.com/facebook/react-native/commit/f7e4c07c84b636fc33c64b434964c8a64c43438f).
This diff adds a check so that only when fabric is enabled it include the React-graphic dependency.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D31919354
fbshipit-source-id: 0b4e7f489155f868cdf58bec3f61f309470ca0c6
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Several desktop forks (`react-native-macos`, `react-native-windows`, `react-native-web`) support mouse events, and while the stock Pressable component has the ability to support mouse events, it seems we aren't forwarding some props properly from Pressable -> Pressability.
Pressability will calculate onMouseEnter / onMouseLeave event handlers based on the `onHoverIn/onHoverOut` callbacks passed into PressabilityConfig.
https://github.com/facebook/react-native/blob/ad0d4534a751ed05f84ff971714c8f7a4d1deb3a/Libraries/Pressability/Pressability.js#L552
However, Pressable does not pass take in onHoverIn/onHoverOut props to pass to PressabilityConfig, so we can't take advantage of this functionality. This change should simply address that by passing the props through.
## 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] - Pressabel not passing hover props and event handlers to PressabilityConfig
Pull Request resolved: https://github.com/facebook/react-native/pull/32405
Test Plan: I fixed a similar issue in `react-native-macos` that I am now trying to contribute back upstream. https://github.com/microsoft/react-native-macos/pull/855
Reviewed By: yungsters
Differential Revision: D31667737
Pulled By: sota000
fbshipit-source-id: f0bbe48302703bb2c45280d2afeec8d7a4586b6a
Summary:
As per the XMLHttpRequest specification [1], getAllResponseHeaders() should return a string of headers with lowercased names and sorted by their uppercase representation, with each header ending with '\r\n'.
[1] https://xhr.spec.whatwg.org/#the-getallresponseheaders()-method
## Changelog
[General] [Changed] XMLHttpRequest.getAllResponseHeaders() now returns headers with names lowercased and sorted in ascending order, as per specification
Pull Request resolved: https://github.com/facebook/react-native/pull/32363
Test Plan:
Test derived from Web Platform Test repository:
https://github.com/web-platform-tests/wpt/tree/master/xhr
Reviewed By: yungsters
Differential Revision: D31626217
Pulled By: sota000
fbshipit-source-id: 299d005facbe1c15b8cda5eed6750db75addca80
Summary:
Adding an error check to make debugging easier when codegen fails when invalid library_type option is passed.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31907880
fbshipit-source-id: c1ffa6bbd7b3e4faede88da2ee8d3378fa086780
Summary:
Currently, some filtering of generated files are done in multiple places (e.g. generate-specs-cli.js, react_native_pods.rb, etc). I am introducing this arguments so that only needed files are generated for components and modules.
Changelog: [internal]
Reviewed By: hramos, cortinico
Differential Revision: D31878098
fbshipit-source-id: d2dc8f51ea14a5d0ba1548bd481814220c9ae3a2
Summary: Changelog: [Internal] Remove github action to close upgrade-related issues. We will be moving these issue to react-native repo and using this tag
Reviewed By: cortinico
Differential Revision: D31837195
fbshipit-source-id: 51fdd6efd88c0ebd5c504730406b217c8dbb3a88
Summary:
Fixes https://github.com/facebook/react-native/issues/27052
Since react-native 0.62, the `devDisabledIn${buildType}` syntax has stopped working for apps with multiple `productFlavors`. This PR adds the `disableDevForVariant` lambda to allow dev mode to be disabled for different variants.
## 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
-->
[Android] [Fixed] - Fix devDisabledIn not working with multiple productFlavors
Pull Request resolved: https://github.com/facebook/react-native/pull/30606
Test Plan:
I added the following log into `react.gradle` and ran the Android build for my app:
```
println("devEnabled: ${targetName}, ${devEnabled}")
```
```
# build.gradle
project.ext.react = [
entryFile: "index.android.js",
enableHermes: true, // clean and rebuild if changing
bundleInLive: true,
disableDevForVariant: {
def variant -> variant.name.toLowerCase().contains('release') || variant.name.toLowerCase().contains('live')
},
]
...
flavorDimensions 'branding'
productFlavors {
cve {
dimension 'branding'
}
whce {
dimension 'branding'
}
}
```
Console output:
```
Reading env from: env/cve/live
devEnabled: CveDebug, true
devEnabled: CveRelease, false
devEnabled: CveLive, false
devEnabled: WhceDebug, true
devEnabled: WhceRelease, false
devEnabled: WhceLive, false
```
Reviewed By: cortinico
Differential Revision: D31649977
Pulled By: ShikaSD
fbshipit-source-id: 520734314f4bca7608b8dca67c7c5ce0be6d31a5
Summary:
Fixes https://github.com/facebook/react-native/issues/32434: RCTLogBox window is orphaned, covering entire screen.
After this change, the logbox window once again is removed from the screen.
## Changelog
Some third-party SDKs may hold references to created UIWindow, UIViewController, or UIView objects. Doing so means that the current code's `hide` method that releases the reference to the UIWindow in LogBox will not cause the window to be dealloc'd, and thus instead it will remain on the screen. This change explicitly hides the LogBox window when the reference is released, so that even if some other SDK holds onto the window it will still be taken off the screen.
<!-- 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] - 32434
Pull Request resolved: https://github.com/facebook/react-native/pull/32435
Test Plan:
1. Use console.warn to generate a yellow warning message in log box. Also install a third-party SDK that holds onto a reference to UIWindow -- for example the Facebook SDK, the Data Dog SDK, or any number of other SDKs that use `swizzling` to intercept calls like `viewDidAppear:`.
2. click the log
3. tap "dismiss"
4. try to tap anywhere
5. Use Xcode view debugger to inspect the UI state
## Expected
The app still responds to the touch.
In Xcode, there is not an extra UIWindow covering the screen
Reviewed By: philIip
Differential Revision: D31794242
Pulled By: sshic
fbshipit-source-id: 28aa247b3ed3fd60b8e7c2ed7d0606cbf5c42408
Summary: Changelog: [Internal] Fix up basic styling of dark mode for examples. Individual examples still may be broken and will be fixed up individually
Reviewed By: yungsters
Differential Revision: D31710790
fbshipit-source-id: 6ca4fb8a6238f38ff484ec91518057b243ba1d7b
Summary:
Single and composite animations were handled inconsistently in AnimatedMock. Also added a guard to prevent callbacks from triggering additional animations, since we had a test-scenario that did exactly that.
Changelog:
[General][Fixed] - Composite animations will now be ran immediately when the app is in testing mode
Reviewed By: yungsters
Differential Revision: D31826967
fbshipit-source-id: a6416b42e227fe79f5c3a55a9c51beb8451874f8
Summary:
Bumping the codegen to a new version to ship a change to the Android template.
Changelog:
[General] [Changed] - Bump react-native-codegen to 0.0.9
Reviewed By: hramos, mdvacca
Differential Revision: D31762139
fbshipit-source-id: 71a96210a3577c12ff3c9f9013c6e72adf4a0ecb
Summary:
Deprecates `prop-types` from React Native.
Existing use cases will be presented with a warning to migrate to the newly published `deprecated-react-native-prop-types` module.
In a subsequent release, these will be removed from React Native.
Changelog:
[General][Changed] - Accessing `Image.propTypes`, `Text.propTypes`, `TextInput.propTypes`, `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, or `ViewPropTypes` now emits a deprecation warning.
Reviewed By: kacieb
Differential Revision: D29019309
fbshipit-source-id: 21e518e588fa05c498cc75ba81f69cfa8a9d0613
Summary:
Fix the `scripts/update-ruby.sh` so it always use the correct [bundle config](https://bundler.io/man/bundle-config.1.html#DESCRIPTION). In the current version it wasn't using the correct configuration inside the `template/` directory, resulting in incorrect platform for `template/Gemfile.lock`.
While at that, update the gems to their latest version:
- ethon 0.14.0 -> 0.15.0
- json 0.5.1 -> 0.6.0
- zeitwerk 2.4.2 -> 2.5.1
- bundler 2.2.28 -> 2.2.29
## Changelog
No changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/32456
Test Plan:
Run `bump-oss-version.js` and see `template/Gemfile.lock` lists `ruby` as the `PLATFORM` (no diff in that line).
## References
- https://github.com/facebook/react-native/commit/e18cf90d71d0bef2e2a0caf30a89e53129152965#r58230816
Reviewed By: yungsters
Differential Revision: D31841524
Pulled By: charlesbdudley
fbshipit-source-id: 695c245fcb344c866afed45f747e04233e5c91e4
Summary:
Adds utility script which crawls through a React Native app's Node dependencies and, for each compatible library, generates the relevant native code artifacts.
This script is for development purposes, and is not hooked into the existing codegen integration by design.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D28915433
fbshipit-source-id: de36d3e1dc0e11aad3ca55cea5e6731db09c5377
Summary:
The `ReactScrollView.java` constructor is using `ReactContext` instead of `Context`, which is inconsistent to the horizontal scroll view. This is the result from D3863966 (https://github.com/facebook/react-native/commit/2cf2fdbc04bc5309f6942ed464ad61cd06a26ce8) when an OSS issue needs to be addressed. That issue and all call sites to use the `ReactContext` are deprecated now.
Revert this back to use `Context` to be less restrictive.
Changelog:
[Android][Fixed] - Revert `ReactScrollView` to use `Context` instead of `ReactContext` in the constructor to be less restrictive.
Reviewed By: javache
Differential Revision: D31819799
fbshipit-source-id: 3f00d64850aebd2e20615033b2e1f1c721fed37e
Summary:
Changelog: [internal]
This change had to be reverted because it caused some issues internally at Facebook. After we solved those we re-applied the changes but this also has issues in OSS apps. Specifically, the option in Metro to inject modules to execute before the EntryPoint (in this case `InitializeCore`) doesn't work if those modules aren't part of the bundle in the first place.
This reverts again so we can think about a long-term solution for this.
Original commit changeset: ba145a30ead5
Reviewed By: ShikaSD
Differential Revision: D31825736
fbshipit-source-id: 393b3d5d2a726951a9ac386dc2b1c19ef4a916a5
Summary:
Colocate the surface ID generate with the code that consumes it. This allows us to re-use this method in other event emitter locations.
Changelog: [Android][Changed] Add helper to get surfaceId for event dispatching
Reviewed By: philIip
Differential Revision: D31651881
fbshipit-source-id: 109e189f90261d3ba0077ffa519c3d12a9111439
Summary:
Changelog:
[Android][Changed] RootView's onChildStartedNativeGesture now takes the child view as its first argument
Reviewed By: philIip
Differential Revision: D31399515
fbshipit-source-id: b9438f6118e604a04799ef67d0b46303a06d6434
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
Adds the `glob` type definition via `flow-typed` so that the `combine-js-to-schema-cli.js` script does not need a Flow suppression.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D31800809
fbshipit-source-id: 3e01a096d2153639a619a7152bd06332df57f06b
Summary:
Many have reported about the misguiding error `Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so` even though they don't use Hermes (for example issues https://github.com/facebook/react-native/issues/26075#25923).
**The current code does not handle errors correctly when loading JSC or Hermes in `ReactInstanceManagerBuilder`**.
**ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManagerBuilder.java:**
```java
try {
return new HermesExecutorFactory();
} catch (UnsatisfiedLinkError hermesE) {
// We never get here because "new HermesExecutorFactory()" does not throw an exception!
hermesE.printStackTrace();
throw jscE;
}
```
In Java, when an exception is thrown in static block, it will be RuntimeException and it can't be caught. For example the exception from `SoLoader.loadLibrary` can't be caught and it will crash the app.
**ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/HermesExecutor.java:**
```java
static {
// Exception from this code block will be RuntimeException and it can't be caught!
SoLoader.loadLibrary("hermes");
try {
SoLoader.loadLibrary("hermes-executor-debug");
mode_ = "Debug";
} catch (UnsatisfiedLinkError e) {
SoLoader.loadLibrary("hermes-executor-release");
mode_ = "Release";
}
}
```
This PR fixes the code so that the original exception from failed JSC loading is not swallowed. It does not fix the original issue why JSC loading is failing with some devices, but it can be really helpful to know what the real error is. For example Firebase Crashlytics shows wrong stack trace with current code.
I'm sure that this fix could have been written better. It feels wrong to import `JSCExecutor` and `HermesExecutor` in `ReactInstanceManagerBuilder.java`. However, the main point of this PR is to give the idea what is wrong with the current code.
## 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
-->
[Android] [Fixed] - Fix error handling when loading JSC or Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/30749
Test Plan:
* from this PR, modify `ReactAndroid/src/main/java/com/facebook/react/jscexecutor/JSCExecutor.java` so that JSC loading will fail:
```java
// original
SoLoader.loadLibrary("jscexecutor");
// changed
SoLoader.loadLibrary("jscexecutor-does-not-exist");
```
* Run `rn-tester` app
* Check from Logcat that the app crashed with correct exception and stacktrace. It should **not** be `java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so`
Tested with Hermes
```
SoLoader.loadLibrary("hermes-executor-test");
```
Got this one in logcat
```
09-24 20:12:39.552 6412 6455 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes-executor-test.so
```
Reviewed By: cortinico
Differential Revision: D30346032
Pulled By: sota000
fbshipit-source-id: 09b032a9e471af233b7ac90b571c311952ab6342
Summary:
Changelog: [Internal]
these are returning bools for some reason even though no one is using the returned value. changing them to return void
Reviewed By: RSNara
Differential Revision: D31594241
fbshipit-source-id: 04c115b573b74996eaf2fef631eedb12c6734ea8
Summary:
Changelog: [Internal]
`start` and `stop` are already part of `RCTSurfaceProtocol` which is a public protocol conformance, we don't need to add these to this header, it's just extra work for the compiler
Reviewed By: RSNara
Differential Revision: D31776005
fbshipit-source-id: d89ad4dbe35e1b67cfa750c6414c40f9b4fc7f24
Summary:
This diff updates the Makefile generated by `react-native-codegen`
to include the correct list of modules. Specifically I've removed some modules that are unused
like `libreact_debug` and added others that are necessary for the build to compile correctly
such as `libfbjni`.
Plus I've bumped the C++ version to 17 as we had a mixture of 14 and 17 across the codebase.
Changelog:
[Internal] [Changed] - Update codegen template to include correct native modules and C++17
Reviewed By: mdvacca
Differential Revision: D31754427
fbshipit-source-id: 8490fa5c5ad298689b564f760c3fc65550c94547
Summary:
Similary to the `release_blocker_form` we already have, this is migrating the
Bug report template to be an issue form.
Changelog:
[Internal] [Changed] - Move Bug Report Issue template to Issue Form
Reviewed By: lunaleaps
Differential Revision: D31729676
fbshipit-source-id: e78d5f4e8776fead17d45d340d98932cc41681e9
Summary:
I missed some spots where an unsupported key (fbandroid_compiler_flags) was being referenced.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31796826
fbshipit-source-id: 491b5121ef6461bef4a59c6aef65ce61f683341f
Summary:
This Diff is adapting the codegen configuration for ReactAndroid
to specify a path for the codegen package. I've used the `findNodeModulePath`
so this will work for both:
* The top level OSS project as `node_modules` will be at the top level
* The scenario where ReactAndroid will be included and built from source (as `node_modules` is in the `..` folder).
Changelog:
[Internal] [Changed] - Use explicit codegen path in ReactAndroid
Reviewed By: mdvacca
Differential Revision: D31730920
fbshipit-source-id: 6637da5d0098114f4379bcaeb8a40e976c46f194
Summary:
SurfaceHandlerBinding uses string from JVM memory when initializing, which is released before it is used. If JVM manages to collect this memory before instance init, it can lead to use-after-free.
Changelog:
[Internal] - fix memory corruption in cxx binding of surface handler
Reviewed By: mdvacca
Differential Revision: D31794515
fbshipit-source-id: 3944ebd065f42a516f036096d07c0126a43c912f
Summary:
Turns out that the Java generator is (as expected) outputting only Java code.
Therefore the C++ and the Markdown files are still generated by `react-native-codegen`.
I'm updating the logic to make sure the Java generator is not mutually exclusive and
overrides the output of `react-native-codegen`
Changelog:
[Internal] [Changed] - useJavaGenerator output should override the react-native-codegen one
Reviewed By: sshic
Differential Revision: D31754428
fbshipit-source-id: 3e6dae8212fbfebd28247ec17e88243871265808
Summary:
This diff is making sure that we're not failing the build
if either `ANDROID_NDK_PATH` or `ANDROID_NDK_VERSION` are missing.
Currently if any of the two is missing, a Gradle sync will fail.
This is problematic for the New Arch Rollout playbook as users will
import the `:ReactAndroid` project to build from source, and those
properties are instead defined at the `react-native` top level project.
Changelog:
[Internal] [Changed] - Safely access the project NDK properties
Reviewed By: sshic
Differential Revision: D31731291
fbshipit-source-id: ce4b762998ed545b3ec7ddcc07abbe4452602190
Summary:
I had to make this change when enabling Fabric in OSS. Without the full path, it can't find the modules like processColor within node_modules.
Changelog: Internal
Reviewed By: motiz88
Differential Revision: D31300424
fbshipit-source-id: 59b82470ec1ce63b63704931786e22b98f4bf046
Summary:
This bug is caused by RNAndroid dispatching an incorrect sequence of events to JS when the user taps on a Text.
Taking into consideration the example P462662009, when the user taps of the "Inner" text, RN Android is dispatching three events:
topTouchStart, topTouchStart and topTouchEnd.
The information stored on the first two JS events is correct, but the problem is that it is duplicated. This sequence of events makes Pressability to dispatch the event to the incorrect target.
This was originally introduced in D3035589 (https://github.com/facebook/react-native/commit/39fdce259dd46de8fd715efbfd12ede4bc24c8c2) (2016)
In this diff I'm changing the way RN Android bubbles events when the user taps on a ReactTextView. From now on, events won't be bubbled anymore, and they will be handled by the ReactRootView.onInterceptTouchEvent: https://fburl.com/code/rbt8$
Additionally, I'm creating a FeatureFlag in case this change has a unknown side effect that's only detected in production.
I will create a MC for FB4A in the next diffs of the stack
changelog: [Fixed][Android] Fix onPress event for nested Text in RN Android
Reviewed By: javache
Differential Revision: D31628461
fbshipit-source-id: 177397d4369191a3c97e2f86e801757b27ee5121
Summary:
Changelog: [Internal]
Now that Flow releases include a type def of `queueMicrotask`,
we can just inherit it from Flow
Reviewed By: yungsters
Differential Revision: D31754482
fbshipit-source-id: f42f8ec955f898d7a964ff85b6061d4840590d4d
Summary:
Creates a new `StaticViewConfigValidator` module that does strict, bidirectional validation. This is notably different from `verifyComponentAttributeEquivalence`, which is undirectional validation.
This will enforce that two configs are equivalent so we can start addressing the inconsistencies (especially per platform). It also improves upon the reporting format by providing more details about the invalidations.
It is hidden behind a `strict` runtime configuration parameter.
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D29024229
fbshipit-source-id: 10271945e089183f505205bd41de5e01faea7568
Summary:
The new architecture generates code that needs to be included in the xcode project. This diff adds a method that will be called when calling "pod install". There will be following diffs that will add the usage of this function.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31699330
fbshipit-source-id: 491de7f60afee69aae750bbda6a687cea2526cc0
Summary:
this little PR remove `accesibilityStates` config in validAttributes, like comment says it can be removed after next release.
## Changelog
[General][Removed] - `accessibilityStates` no longer passed through to RCTView.
Pull Request resolved: https://github.com/facebook/react-native/pull/29656
Reviewed By: philIip
Differential Revision: D31732866
Pulled By: yungsters
fbshipit-source-id: 83b6eb223e76537a09c13ccdb382317421ab4585
Summary:
The documentation of back easing contains a old link that
is now stale. I'm updating it to link to https://easings.net/#easeInBack
Fixes https://github.com/facebook/react-native/issues/32419
Changelog:
[Android] [Fixed] - Fixes documentation for back Easing animation
Reviewed By: hramos
Differential Revision: D31728560
fbshipit-source-id: 99f7aa60d3748af5429b4ae1aa6cbd79326c5fe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32418
This commit does 2 things:
* Process and store stats for *-stable branches, in addition to main
* Print out the new stats to stdout, so that CI jobs can display them for verification purpose
This also means a new field `branch` is used for the Firestore data.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D31717251
fbshipit-source-id: 9dbfa8fb8f0243c013dcd822230400d26c09eaa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32426
This diff refactors the extractHeader and extractJni tasks to a single Gradle task in the `.internal` package.
The reason for this change is that those two tasks were always running, therefore invalidating the
whole native build cache.
Changelog:
[Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task
Reviewed By: mdvacca, ShikaSD
Differential Revision: D31682942
fbshipit-source-id: 191cc77902e82c0425949cee743d240ded790137
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32427
This diff refactors the `prepareJSC` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareJSC` was just a plain `Task` and not a `Copy` task.
It was defining a top level `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the JSC headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareJSC to an internal task
Reviewed By: ShikaSD
Differential Revision: D31682293
fbshipit-source-id: 3d4cd9d9ce2fcd45e61f3c8c6685b69a622a1912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32424
This diff refactors the `prepareBoost` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareBoost` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Boost headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareBoost to an internal task
Reviewed By: ShikaSD
Differential Revision: D31662120
fbshipit-source-id: 87ba82c634da832ee54c3d13561df45d3fd71381
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32425
This diff refactors the `prepareLibevent` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareLibevent` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Libevent headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareLibevent to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661988
fbshipit-source-id: e55c2179a187fa156f701c25bae3b48a796e2660
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32421
This diff refactors the `prepareGlog` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareGlog` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Glog headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareGlog to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661668
fbshipit-source-id: efcd5505a67d6c9f02fcab7a5c3255a160215661
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32422
While working on the NDK AGP Api I realized that the `enableVmCleanup` function,
that is supposed to cleanup the extra `.so` files from the final artifacts, is broken
for apps with variants. Specifically say for a `liteDebug` app it tries to search for `.so` files inside:
```
intermediates/stripped_native_libs/lite/debug/out/lib
```
while the `.so` files are located inside:
```
intermediates/stripped_native_libs/liteDebug/out/lib
```
I've fixed changing the token of the path from `targetPath` to `variant.name`
Changelog:
[Android] [Fixed] - Fix enableVmCleanup not working for apps with product flavors
Reviewed By: ShikaSD
Differential Revision: D31654704
fbshipit-source-id: 4af3478a3079ebcde4bd8e0c62bf4df7b6c75c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32420
While working on the NDK AGP Apis, I realized the the `applyAppPlugin` is accessed
too early inside the Gradle plugin. Specifically is accessed once the plugin is applied,
and the extension is not configured afterwards. This means that the extension is always set
the default values.
I'm fixing it moving it inside the `project.afterEvaluate` that was already need to access
the variant informations.
Changelog:
[Internal] [Changed] - Fix applyAppPlugin being accessed too early in the React App Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D31652984
fbshipit-source-id: e7ead3f8acb24372bf953fd90ad2a5dfbbeeeec0
Summary:
The [first implementation of `TextAttributes` in Fabric](https://github.com/facebook/react-native/commit/62576bcb7832e08c6fd9f9482285882c37a2ece5) included two separate props instead of `textDecorationStyle`: `textDecorationLineStyle` (single, double, ...) and `textDecorationLinePattern` (dot, dash, dotdash, ...). These two props were implemented in C++ and iOS but never supported in JS.
Pre-Fabric (and CSS) on the other hand use a single prop `textDecorationStyle: 'solid' | 'double' | 'dotted' | 'dashed'`.
This diff implements this same API in Fabric, and removes the unused `textDecorationLineStyle` and `textDecorationLinePattern` props.
Changelog:
[iOS][Fixed] - Implement `textDecorationStyle` on iOS and remove unused `textDecorationLineStyle` and `textDecorationLinePattern` from Fabric.
Reviewed By: dmitryrykun
Differential Revision: D31617598
fbshipit-source-id: f5173e7ecdd31aafa0e5f0e50137eefa0505e007
Summary:
While reworking our media picker, I ended up replacing the RNFetchBlob library to use `fetch()`, leveraging React Native's file resolver (especially to interpret `photos://` URI paths).
The migration process was pretty straightforward, however I kept getting RCTConvert errors when calling `fetch` with a `PUT` method and a blob body:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
+[RCTConvert NSString:]
RCTConvert.m:59
-[RCTBlobManager handleNetworkingRequest:]
-[RCTNetworking processDataForHTTPQuery:callback:]
-[RCTNetworking buildRequest:completionBlock:]
-[RCTNetworking sendRequest:callback:]
__invoking___
-[NSInvocation invoke]
-[NSInvocation invokeWithTarget:]
-[RCTModuleMethod invokeWithBridge:module:arguments:]
Test Plan:
I'll put my `fetch` snippet here. This is using a third-party library in order to get a signed URL, but it is otherwise pretty straightforward.
This snippet would trigger an error before the changes introduced by this PR.
```js
// Setup (specific to third-party lib)
const key = `file/path/in/bucket`
const params = {
Key: key,
Bucket: 'my.awesome.bucket',
}
const s3url = await s3.getSignedUrl('putObject', params)
// Letting RN handle how to retrieve a platform-specific resource URI
const localFetch = await fetch(localPath)
// Getting the blob to upload as octet-stream
const blob = await localFetch.blob()
// Actually uploading
await fetch(s3url, {
method: 'PUT',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/octet-stream',
},
body: blob,
})
```
Reviewed By: RSNara
Differential Revision: D31625636
Pulled By: sota000
fbshipit-source-id: a7770018bc3ff2f41321b1bd26ec145b86b18784
Summary:
The size information is currently not used for release branches. Further, the CI step failed because there is no PR associated with commits in RC branch. This commit fixed that error by skipping the entire work altogether.
Sample error: https://app.circleci.com/pipelines/github/facebook/react-native/10161/workflows/3625732a-531f-435d-83b6-1dbc638e1bab/jobs/215405/parallel-runs/0/steps/0-125
In theory, we should be storing RC bundle sizes as well, but the current backing Firebase DB has not been configured with proper index:
```
Error [FirebaseError]: The query requires an index.
...
```
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D31705912
fbshipit-source-id: 26757174f7937cb23d8e55066b833ae15ec011e3
Summary:
Changelog: [Internal]
making these imports a little more optimal & clean
Reviewed By: javache
Differential Revision: D31594240
fbshipit-source-id: 076610454a6f3c35ac58e97bd9f887b05b86f5bb
description:Report a reproducible bug or regression in React Native.
labels:["Needs: Triage :mag:"]
body:
- type:markdown
attributes:
value:|
Please provide all the information requested. Issues that do not follow this format are likely to stall.
- type:textarea
id:description
attributes:
label:Description
description:Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest React Native release to make sure your issue has not already been fixed - https://reactnative.dev/docs/upgrading.html
validations:
required:true
- type:input
id:version
attributes:
label:Version
description:What react-native version does this appear on?
placeholder:ex. 0.66.0
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:Provide a detailed list of steps that reproduce the issue.
validations:
required:true
- type:textarea
id:extra
attributes:
label:Snack, code example, screenshot, or link to a repository
description:|
Please provide a Snack (https://snack.expo.dev/), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
You may provide a screenshot of the application if you think it is relevant to your bug report.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve
Please note that a reproducer is mandatory. Issues without reproducer are more likely to stall and will be closed.
about:Questions and doubts related to technical questions for the New Architecture should be directed to the Working Group. Instructions on how to join are available in the README.
description:Report a reproducible bug or a build issue when using the New Architecture (Fabric & TurboModules) in React Native.
labels:["Needs: Triage :mag:","Type: New Architecture"]
body:
- type:markdown
attributes:
value:|
Please provide all the information requested. Issues that do not follow this format are going to be closed.
This issue report is reserved to bug & build issues for users on the New Architecture. If you're not using
the New Architecture, please don't open issues on this category.
- type:textarea
id:description
attributes:
label:Description
description:|
Please provide a clear and concise description of what the bug or issue is. Include screenshots if needed.
Please make sure you check the New Architecture documentation first, as your issue might
already be answered there - https://reactnative.dev/docs/next/new-architecture-intro
validations:
required:true
- type:input
id:version
attributes:
label:Version
description:What react-native version does this appear on? Please test against the latest stable version. Bug reports against older versions are more likely to stall.
placeholder:ex. 0.68.0
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:Provide a detailed list of steps that reproduce the issue.
validations:
required:true
- type:textarea
id:extra
attributes:
label:Snack, code example, screenshot, or link to a repository
description:|
Please provide a Snack (https://snack.expo.dev/), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
You may provide a screenshot of the application if you think it is relevant to your bug report.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve
Please note that a reproducer is mandatory. Issues without reproducer are more likely to stall and will be closed.
description:File an issue against the current release candidate.
labels:["Needs: Triage :mag:","pre-release"]
body:
- type:markdown
attributes:
value:|
Please use this form to file an issue against the current release candidate. See current releases [here](https://github.com/facebook/react-native/releases).
- type:input
id:version
attributes:
label:Version
description:What release candidate version does this appear on? Please refer to [release candidate versions](https://github.com/facebook/react-native/releases).
placeholder:ex. 0.66.0-rc.2
validations:
required:true
- type:input
id:target
attributes:
label:Build Target(s)
description:What target(s) are encountering this issue?
placeholder:iOS simulator in release flavor
validations:
required:true
- type:textarea
id:environment
attributes:
label:Developer Environment
description:Please list relevant versions of system, tooling. Ex. OS, processor, Xcode, etc.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Issue and Reproduction Steps
description:Please describe the issue and list out commands run to reproduce.
Please use this form to file an issue if you have upgarded or are upgrading to [latest stable release](https://github.com/facebook/react-native/releases/latest) and have experienced a regression (something that used to work in previous version).
- type:input
id:new-version
attributes:
label:New Version
description:This is the version you are attempting to upgrade to.
placeholder:ex. 0.66.1
validations:
required:true
- type:input
id:old-version
attributes:
label:Old Version
description:This is the version you were on where the behavior was working.
placeholder:ex. 0.65.1
validations:
required:true
- type:input
id:target
attributes:
label:Build Target(s)
description:What target(s) are encountering this issue?
placeholder:iOS simulator in release flavor
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `react-native info`
description:Run `react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Issue and Reproduction Steps
description:Please describe the issue and list out commands run to reproduce.
You can participate in the conversation on the status of this release in the [working group](https://github.com/reactwg/react-native-releases/discussions).
---
To help you upgrade to this version, you can use the [upgrade helper](https://react-native-community.github.io/upgrade-helper/) ⚛️
---
See changes from this release in the [changelog PR](https://github.com/facebook/react-native/labels/%F0%9F%93%9D%20Changelog)
Please report documentation issues in the [`react-native-website`](https://github.com/facebook/react-native-website/issues) repository.
close:true
"Type: Upgrade Issue":
comment:>
Do you need help upgrading to a newer React Native version? Visit the [Upgrade Support repository](https://github.com/react-native-community/upgrade-support) or use the [upgrade helper](https://react-native-community.github.io/upgrade-helper/) to see the changes that need to be made to upgrade your app.
close:true
"Resolution: For Stack Overflow":
comment:>
We are using GitHub issues exclusively to track bugs in the core React Native library. Please try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native) as it is better suited for this type of question.
It looks like your issue is missing a reproducible example. Please provide a <a href="https://snack.expo.io">Snack</a> or a repository that demonstrates the issue you are reporting in a <a href="https://stackoverflow.com/help/minimal-reproducible-example">minimal, complete, and reproducible</a> manner.
It looks like your issue is missing a reproducible example. Please provide a <a href="https://snack.expo.dev">Snack</a> or a repository that demonstrates the issue you are reporting in a <a href="https://stackoverflow.com/help/minimal-reproducible-example">minimal, complete, and reproducible</a> manner.
# Configuration for probot-stale - https://github.com/probot/stale
# Number of days of inactivity before an issue becomes stale
daysUntilStale:90
# Number of days of inactivity before a stale issue is closed
daysUntilClose:7
# Issues with these labels will never be considered stale
exemptLabels:
- Good first issue
- "Type: Discussion"
- Partner
- Core Team
- "Help Wanted :octocat:"
- "Impact: Regression"
- "Resolution: PR Submitted"
- "Resolution: Backlog"
# Label to use when marking an issue as stale
staleLabel:Stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment:>
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs.
You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open.
Thank you for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment:>
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.
stale-issue-message:'This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
days-before-stale:180
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for 7 days with no activity.'
Thank you for your interest in contributing to React Native! From commenting on and triaging issues, to reviewing and sending Pull Requests, all contributions are welcome. We aim to build a vibrant and inclusive [ecosystem of partners, core contributors, and community](ECOSYSTEM.md) that goes beyond the main React Native GitHub repository.
Thank you for your interest in contributing to React Native! From commenting on and triaging issues, to reviewing and sending Pull Requests, all contributions are welcome.
We aim to build a vibrant and inclusive [ecosystem of partners, core contributors, and community](ECOSYSTEM.md) that goes beyond the main React Native GitHub repository.
The [Open Source Guides](https://opensource.guide/) website has a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. Contributors and people new to open source alike will find the following guides especially useful:
* [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
### [Code of Conduct](https://github.com/facebook/react-native/blob/HEAD/CODE_OF_CONDUCT.md)
As a reminder, all contributors are expected to adhere to the [Code of Conduct](https://github.com/facebook/react-native/blob/HEAD/CODE_OF_CONDUCT.md).
## Ways to Contribute
If you are eager to start contributing code right away, we have a list of [good first issues](https://github.com/facebook/react-native/labels/good%20first%20issue) that contain bugs which have a relatively limited scope. As you gain more experience and demonstrate a commitment to evolving React Native, you may be granted issue management permissions in the repository.
There are other ways you can contribute without writing a single line of code. Here are a few things you can do to help out:
1.**Replying and handling open issues.** We get a lot of issues every day, and some of them may lack necessary information. You can help out by guiding people through the process of filling out the issue template, asking for clarifying information, or pointing them to existing issues that match their description of the problem. We cover more about this process in the [Issue Triage wiki](https://github.com/facebook/react-native/wiki/Triaging-GitHub-Issues).
2.**Reviewing pull requests for the docs.** Reviewing [documentation updates](https://github.com/facebook/react-native-website/pulls) can be as simple as checking for spelling and grammar. If you encounter situations that can be explained better in the docs, click **Edit** at the top of most docs pages to get started with your own contribution.
3.**Help people write test plans.** Some pull requests sent to the main repository may lack a proper test plan. These help reviewers understand how the change was tested, and can speed up the time it takes for a contribution to be accepted.
Each of these tasks is highly impactful, and maintainers will greatly appreciate your help.
### Our Development Process
We use GitHub issues and pull requests to keep track of bug reports and contributions from the community. All changes from engineers at Facebook will sync to [GitHub](https://github.com/facebook/react-native) through a bridge with Facebook's internal source control. Changes from the community are handled through GitHub pull requests. Once a change made on GitHub is approved, it will first be imported into Facebook's internal source control and tested against Facebook's codebase. Once merged at Facebook, the change will eventually sync back to GitHub as a single commit once it has passed Facebook's internal tests.
You can learn more about the contribution process in the following documents:
We also have a thriving community of contributors who would be happy to help you get set up. You can reach out to us through [@ReactNative](http://twitter.com/reactnative) (the React Native team) and [@ReactNativeComm](http://twitter.com/reactnativecomm) (the React Native Community organization).
### Repositories
The main repository, <https://github.com/facebook/react-native>, contains the React Native framework itself and it is here where we keep track of bug reports and manage pull requests.
There are a few other repositories you might want to familiarize yourself with:
* **React Native website** which contains the source code for the website, including the documentation, located at <https://github.com/facebook/react-native-website>
* **Releases** are coordinated through the <https://github.com/react-native-community/releases> repository. This includes important documents such as the Changelog.
* **Discussions** about the future of React Native take place in the <https://github.com/react-native-community/discussions-and-proposals> repository.
* **High-quality plugins** for React Native can be found throughout the [React Native Community GitHub Organization](http://github.com/react-native-community/).
Browsing through these repositories should provide some insight into how the React Native open source project is managed.
## GitHub Issues
We use GitHub issues to track bugs exclusively. We have documented our issue handling processes in the [Issues wiki](https://github.com/facebook/react-native/wiki/Triaging-GitHub-Issues).
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. In those cases, please go through the process outlined on that page and do not file a public issue.
## Helping with Documentation
The React Native documentation is hosted as part of the React Native website repository at https://github.com/facebook/react-native-website. The website itself is located at <https://reactnative.dev/> and it is built using [Docusaurus](https://docusaurus.io/). If there's anything you'd like to change in the docs, you can get started by clicking on the "Edit" button located on the upper right of most pages in the website.
If you are adding new functionality or introducing a change in behavior, we will ask you to update the documentation to reflect your changes.
### Contributing to the Blog
The React Native blog is generated [from the Markdown sources for the blog](https://github.com/facebook/react-native-website/tree/HEAD/website/blog).
Please open an issue in the https://github.com/facebook/react-native-website repository or tag us on [@ReactNative on Twitter](http://twitter.com/reactnative) and get the go-ahead from a maintainer before writing an article intended for the React Native blog. In most cases, you might want to share your article on your own blog or writing medium instead. It's worth asking, though, in case we find your article is a good fit for the blog.
We recommend referring to the [CONTRIBUTING](https://github.com/facebook/react-native-website/blob/HEAD/CONTRIBUTING.md) document for the `react-native-website` repository to learn more about contributing to the website in general.
## Contributing Code
Code-level contributions to React Native generally come in the form of [pull requests](https://help.github.com/en/articles/about-pull-requests). These are done by forking the repo and making changes locally. Directly in the repo, there is the [`rn-tester` app](/packages/rn-tester) that you can install on your device (or simulators) and use to test the changes you're making to React Native sources.
The process of proposing a change to React Native can be summarized as follows:
1. Fork the React Native repository and create your branch from `main`.
2. Make the desired changes to React Native sources. Use the `packages/rn-tester` app to test them out.
3. If you've added code that should be tested, add tests.
4. If you've changed APIs, update the documentation, which lives in [another repo](https://github.com/facebook/react-native-website/).
5. Ensure the test suite passes, either locally or on CI once you opened a pull request.
6. Make sure your code lints (for example via `yarn lint --fix`).
7. Push the changes to your fork.
8. Create a pull request to the React Native repository.
9. Review and address comments on your pull request.
1. A bot may comment with suggestions. Generally we ask you to resolve these first before a maintainer will review your code.
2. If changes are requested and addressed, please [request review](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) to notify reviewers to take another look.
10. If you haven't already, please complete the [Contributor License Agreement](https://github.com/facebook/react-native/wiki/Contributor-License-Agreement) ("CLA"). **[Complete your CLA here.](https://code.facebook.com/cla)**
If all goes well, your pull request will be merged. If it is not merged, maintainers will do their best to explain the reason why.
### Step-by-step Guide
Whenever you are ready to contribute code, check out our [step-by-step guide to sending your first pull request](https://github.com/facebook/react-native/wiki/How-to-Open-a-Pull-Request), or read the [How to Contribute Code](https://github.com/facebook/react-native/wiki/How-to-Contribute-Code) wiki for more details.
### Tests
Tests help us prevent regressions from being introduced to the codebase. The GitHub repository is continuously tested using Circle and Appveyor, the results of which are available through the Checks functionality on [commits](https://github.com/facebook/react-native/commits/HEAD) and pull requests. You can learn more about running and writing tests in the [Tests wiki](http://github.com/facebook/react-native/wiki/Tests).
## Community Contributions
Contributions to React Native are not limited to GitHub. You can help others by sharing your experience using React Native, whether that is through blog posts, presenting talks at conferences, or simply sharing your thoughts on Twitter and tagging @ReactNative.
## Where to Get Help
As you work on React Native, it is natural that sooner or later you may require help. In addition to the resources listed in [SUPPORT](.github/SUPPORT.md), people interested in contributing may take advantage of the following:
* **Twitter**. The React Native team at Facebook has its own account at [@reactnative](https://twitter.com/reactnative), and the React Native Community uses [@reactnativecomm](https://twitter.com/reactnativecomm). If you feel stuck, or need help contributing, please do not hesitate to reach out.
* **Proposals Repository**. If you are considering working on a feature large in scope, consider [creating a proposal first](https://github.com/react-native-community/discussions-and-proposals). The community can help you figure out the right approach, and we'd be happy to help.
* **React Native Community Discord**. While we try to hold most discussions in public, sometimes it can be beneficial to have conversations in real time with other contributors. People who have demonstrated a commitment to moving React Native forward through sustained contributions to the project may eventually be invited to join the React Native Community Discord.
To learn more about how to contribute check out the Contributing section on the React Native website:
We aim to build a vibrant and inclusive ecosystem of partners, core contributors, and community that goes beyond the main React Native GitHub repository. This document explains the roles and responsibilities of various stakeholders and provides guidelines for the community organization. The structure outlined in this document has been in place for a while but hadn't been written down before.
We aim to build a vibrant and inclusive ecosystem of partners, core contributors, and community that goes beyond the main React Native GitHub repository. This document explains the roles and responsibilities of various stakeholders and provides guidelines for the community organization. The structure outlined in this document has been in place for a while but had not been written down before.
There are three types of stakeholders:
* **Partners:** Companies that are significantly invested in React Native and have been for years.
* **Partners:** Companies significantly invested in React Native and take responsibility for the React Native vision and community.
* **Core Contributors:** Individual people who contribute to the React Native project.
* **Community Contributors:** Individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization.
## Partners
Partners are companies that are significantly invested in React Native and have been for years. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Partners think of React Native as a product: they understand the trade offs that the project makes as well as future plans and goals. Together we shape the vision for React Native to make it the best way to build applications.
Partners are companies that are significantly invested in React Native and demonstrate ownership. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Examples of this may include large scale contributions to `react-native` or owning essential tools or libraries.
React Native's current set of partners include Callstack, Expo, Facebook, Infinite Red, Microsoft and Software Mansion. Many engineers from these companies are core contributors, and their partner responsibilities also include:
Partners think of React Native as a product; they understand the trade offs that the project makes as well as future plans and goals. Together we shape the vision for React Native to make it the best way to build applications.
* **[Callstack](https://callstack.com/):** Manages releases, maintains the [React Native CLI](https://github.com/react-native-community/react-native-cli) and organizes [React Native EU](https://react-native.eu/)
***[Expo](https://expo.io/):** Builds [expo](https://github.com/expo/expo) on top of React Native to simplify app development
***[Facebook](https://opensource.facebook.com):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
***[Infinite Red](https://infinite.red/):** Maintains the [ignite cli/boilerplate](https://github.com/infinitered/ignite), organizes [Chain React Conf](https://cr.infinite.red/)
* **[Microsoft](http://aka.ms/reactnative):** Develops [React Native Windows](https://github.com/Microsoft/react-native-windows) and [React Native macOS](https://github.com/microsoft/react-native-macos) for building apps that target Windows and macOS
* **[Software Mansion](https://swmansion.com/):** Maintain core infrastructure including JSC, Animated, and other popular third-party plugins.
Baseline responsibilities of partners include:
*Attending monthly meeting
*Contributing to the release process. Examples include being a [community releaser](https://reactnative.dev/contributing/release-roles-responsibilities#release-role-2-community-releaser), testing new releases, technical support for release issues.
*Engage on the core contributor Discord
In terms of open source work, pull requests from partners are commonly prioritized. When you are contributing to React Native, you'll most likely meet somebody who works at one of the partner companies and who is a core contributor:
Our current partners and other areas of ownership:
***[Coinbase](https://www.coinbase.com/):** Publishes [posts](https://blog.coinbase.com/tagged/react-native) advocating React Native usage. Supports `@react-native-community/datetimepicker` and other community modules to migrate to the new architecture. Supports releases in testing and feedback.
***[Callstack](https://callstack.com/):** Maintains the [React Native CLI](https://github.com/react-native-community/react-native-cli) and [other community libraries](https://github.com/callstack), organizes [React Native EU](https://react-native.eu/) and hosts [The React Native Show podcast](https://www.callstack.com/podcast-react-native-show)
***[Expo](https://expo.dev/):** Builds [Expo Go and SDK](https://github.com/expo/expo), [Snack](https://snack.expo.dev/), and [Expo Application Services](https://expo.dev/eas). Maintains [React Native Directory](https://reactnative.directory/), stewards [React Navigation](https://reactnavigation.org/) along with other partners.
***[Infinite Red](https://infinite.red/):** Maintains the [ignite cli/boilerplate](https://github.com/infinitered/ignite), organizes [Chain React Conf](https://cr.infinite.red/), hosts the [React Native Radio podcast](https://reactnativeradio.com), publishes the [React Native Newsletter](https://reactnativenewsletter.com)
***[Meta](https://opensource.fb.com/):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
***[Microsoft](https://twitter.com/ReactNativeMSFT):** Develops [React Native Windows](https://github.com/Microsoft/react-native-windows) and [React Native macOS](https://github.com/microsoft/react-native-macos) for building apps that target Windows and macOS; maintains [rnx-kit](https://github.com/microsoft/rnx-kit), [react-native-test-app](https://github.com/microsoft/react-native-test-app) and coordinates cross-companies efforts such as the [bundle working group](https://github.com/microsoft/rnx-kit/discussions/categories/bundle-working-group).
***[Shopify](https://www.shopify.com/):** Maintains React Native open source libraries such as [flash-list](https://github.com/Shopify/flash-list) or [@shopify/react-native-skia](https://github.com/Shopify/react-native-skia) and sponsors Software Mansion.
***[Software Mansion](https://swmansion.com/):** Maintain core infrastructure including JSC, Animated, and other popular third-party plugins and organizes [App.js Conf](https://appjs.co/)
***[Wix.com](https://wix.engineering/open-source):** Maintains a variety of React Native open source projects ([see all](https://github.com/orgs/wix/repositories?q=react-native)), including: [Detox](https://wix.github.io/Detox/) end-to-end testing library for React Native apps, [RN UILib](https://wix.github.io/react-native-ui-lib/), [RN Navigation](https://wix.github.io/react-native-navigation/), [RN Calendars](https://wix.github.io/react-native-calendars/) and [RN Notifications](https://github.com/wix/react-native-notifications).
This list may fluctuate in response to newcomers who meet our partner definition. In terms of open source work, pull requests from partners are commonly prioritized. When you are contributing to React Native, you'll most likely meet somebody who works at one of the partner companies and who is a core contributor:
## Core Contributors
@@ -38,13 +47,19 @@ Core contributors are individuals who contribute to the React Native project. A
These are behaviors we have observed in our existing core contributors. They aren't strict rules but rather outline their usual responsibilities. We do not expect every core contributor to do all of the above things all the time. Most importantly, we want to create a supportive and friendly environment that fosters collaboration. Above all else, **we are always polite and friendly.**
Core contributor status is attained after consistently contributing and taking on the responsibilities outlined above and granted by other core contributors. Similarly, after a long period of inactivity, a core contributor may be removed.
Core contributor status is attained after consistently contributing and taking on the responsibilities outlined above and granted by other core contributors. Similarly, after a long period of inactivity (~6 months or more), a core contributor may be contacted to understand if they’re still interested in being part of the program.
We aim to make contributing to React Native as easy and transparent as possible. All important topics are handled through a [discussion or RFC process on GitHub](https://github.com/react-native-community/discussions-and-proposals). We are always looking for active, enthusiastic members of the React Native community to become core contributors.
You can use this [form](https://forms.gle/4jpA4QeNUvAUDnNe8) to either:
* Apply yourself to become a Core Contributor. Make sure to include a list of valuable contributions you did to the React Native repository and ecosystem.
* Nominate someone to become a Core Contributor.
As a core contributor, you will have access to the core contributor Discord which is used for light-weight coordination and discussion.
**We aim to make contributing to React Native as easy and transparent as possible.** We have discussion groups dedicated to the [new architecture rollout](https://github.com/reactwg/react-native-new-architecture), [releases](https://github.com/reactwg/react-native-releases), and [general questions and proposals](https://github.com/react-native-community/discussions-and-proposals). We are always looking for active, enthusiastic members of the React Native community to become core contributors.
## Community Contributors
Community contributors are individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization. This organization exists as an incubator for high quality components that extend the capabilities of React Native with functionality that many but not all applications require. Facebook engineers will provide guidance to help build a vibrant community of people and components that make React Native better.
Community contributors are individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization. This organization exists as an incubator for high quality components that extend the capabilities of React Native with functionality that many but not all applications require. Meta engineers will provide guidance to help build a vibrant community of people and components that make React Native better.
// These indices need to be kept in sync with the indices in native (see NativeAnimatedModule in Java, or the equivalent for any other native platform).
// $FlowFixMe[prop-missing]
acc[functionName]=i+1;
returnacc;
},{});
})():$FlowFixMe)
:NativeAnimatedModule;
/**
* Simple wrappers around NativeAnimatedModule to provide flow and autocomplete support for
* the native module methods
* Wrappers around NativeAnimatedModule to provide flow and autocomplete support for
* the native module methods, and automatic queue management on Android
*/
constAPI={
getValue:function(
getValue:function(
tag:number,
saveValueCallback:(value:number)=>void,
):void{
invariant(NativeAnimatedModule,'Native animated module is not available');
'Animated: `useNativeDriver` is not supported because the native '+
'animated module is missing. Falling back to JS-based animation. To '+
'resolve this, add `RCTAnimation` module to this app, or remove '+
'`useNativeDriver`. '+
'Make sure to run `bundle exec pod install` first. Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md',
);
_warnedMissingNativeAnimated=true;
if(process.env.NODE_ENV!=='test'){
if(!_warnedMissingNativeAnimated){
console.warn(
'Animated: `useNativeDriver` is not supported because the native '+
'animated module is missing. Falling back to JS-based animation. To '+
'resolve this, add `RCTAnimation` module to this app, or remove '+
'`useNativeDriver`. '+
'Make sure to run `bundle exec pod install` first. Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md',
);
_warnedMissingNativeAnimated=true;
}
}
returnfalse;
}
@@ -380,8 +560,12 @@ function transformDataType(value: number | string): number | string {
@@ -90,6 +95,7 @@ class TimingAnimation extends Animation {
frames,
toValue:this._toValue,
iterations:this.__iterations,
platformConfig:this._platformConfig,
};
}
@@ -164,5 +170,3 @@ class TimingAnimation extends Animation {
this.__debouncedOnEnd({finished:false});
}
}
module.exports=TimingAnimation;
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.