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:
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/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:
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:
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:
## 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:
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:
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/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:
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/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:
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
Summary:
Android 13 adds a new `POST_NOTIFICATION` runtime permission, which can only be requested if the `targetSdkVersion` of the app is set to 33. Since we upgrading Catalyst to SDK 33, let's add it as one of the permission examples.
Changelog:
[Android][Changed] - Add POST_NOTIFICATION runtime permission to RNTester
Reviewed By: fkgozali
Differential Revision: D38850138
fbshipit-source-id: 4cf7a5f60dd0891d7ada40aca37f0489d9d0d190
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:
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.
<!-- 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: 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:
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:
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
# Conflicts:
# Libraries/Animated/createAnimatedComponent.js
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
# Conflicts:
# ReactAndroid/cmake-utils/ReactNative-application.cmake
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
# Conflicts:
# package.json
# template/package.json
# yarn.lock
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:
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:
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: 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:
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:
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:
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:
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
[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:
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:
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:
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:
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:
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:
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:
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:
Stable v9 of the CLI, no major changes compared to previous alpha releases.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.72.1
cc kelset huntie
## 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] - Upgrade RN CLI to v9.0.0, Metro to 0.72.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34447
Test Plan: CI
Reviewed By: huntie
Differential Revision: D38838499
Pulled By: robhogan
fbshipit-source-id: 552e2e708270557e2b74c1a3b8d3325774fb0c48
# Conflicts:
# template/package.json
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:
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:
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:
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
# Conflicts:
# yarn.lock
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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
# Conflicts:
# yarn.lock
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:
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:
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:
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:
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.io/), 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.io/), 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.
# 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:
@@ -12,14 +12,14 @@ There are three types of stakeholders:
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.
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:
React Native's current set of partners include Callstack, Expo, Infinite Red, Meta, Microsoft and Software Mansion. Many engineers from these companies are core contributors, and their partner responsibilities also include:
* **[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/)
* **[Expo](https://expo.dev/):** Builds [expo](https://github.com/expo/expo) and [EAS](https://expo.dev/eas) on top of React Native to simplify app development
* **[Meta](https://opensource.fb.com/):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
* **[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.
* **[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/)
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:
@@ -44,7 +44,7 @@ We aim to make contributing to React Native as easy and transparent as possible.
## 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');
* Copyright (c) Facebook, Inc. and its affiliates.
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
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.
Distiller
Riccardo Cipolleschi
Luna Wei
Muhammad Hur Ali
Distiller
Riccardo Cipolleschi
Stian Jensen
Lorenzo Sciandra
Distiller
Thibault Malbranche
Distiller
Rob Hogan
Distiller
Lorenzo Sciandra
Distiller
Riccardo Cipolleschi
Harry Yu
Dmitry Rykun
Peter Velkov
Marek Fořt
Distiller
Nicola Corti
Pieter De Baets
Luna Wei
Nick Gerleman
Joshua Gross
Distiller
Alec Winograd
Distiller
wood1986
David Angulo
Oleksandr Melnykov
Distiller
Distiller
David
Distiller
Nicola Corti
Distiller
Samuel Susla
Krystof Woldrich
Gianluca Spada
Distiller
Anandraj Govindan
Garrett Forbes Monroe
Distiller
Paige Sun
Kudo Chien
Gabriel Donadel Dall'Agnol
Nick Gerleman
Distiller
Roman Melnyk
Danilo Bürger
Satyajit Sahoo
Rasmus Eneman
Janic Duplessis
Evan Charlton
Zihan Chen (MSFT)
Distiller
Distiller
Michał Pierzchała
Tommy Nguyen
LeoTM
Distiller
Alexander Eggers
Christoph Purrer
JoseLion
Distiller
Sparsha Saha
Oskar Kwaśniewski
Alex Hunt
Mike Hardy
Distiller
George Zahariev
Vincent Riemer
Héctor Ramos
Michael Anthony Leon
John Porto
Pieter De Baets
Genki Kondo
Ernest Surudo
Ron Edelstein
Ramon Medel
Ben
Kevin Gozali
Pieter Vanderwerff
Evan Yeung
Xin Chen
Simon-TechForm
Deepak Jacob
Dustin Shahidehpour
Varun Sharma
Rob Hogan
Sim Sun
Arkkeeper
Marshall Roch
Mark Verlingieri
Sam Zhou
Dusan Klinec
Neil Dhar
Lulu Wu
lbaldy
hduprat
Zachinquarantine
Kunal Farmah
Yann Pringault
Simek
Luis Santana
Jordan Brown
Ramanpreet Nara
Tim Yung
Kacie Bawiec
fabriziobertoglio1987
Alpha Shuro
Geraint White
Jack Worden
Tim Shamilov
Brad Zacher
Rick Hanlon
Nikita Lutsenko
Ruslan Latypov
Artem Goncharov
CodemodService FBSourceClangFormatLinterBot
Olivier Payen
Supreet Singh
Scott Kyle
luoxuhai
Charles Dudley
Christian Ruink
Carmi Grushko
Zolboobayar Gantumur
Arinjay Sharma
David Vacca
Shubho Sadhu
Jake Holland
Daniel Espino García
Antoine Doubovetzky
Jérémy Barbet
vincent-paing
Andy Zolyak
Moti Zilberman
Michael Lee (Engineering)
Daniel Abramowitz
Eric Hartzog
Franco Meloni
Rubén Norte
Vlad Hnatiuk
Nicola Corti
Arushi Kesarwani
Blair Vanderhoof
Rachit Mishra
Brent Kelly
Hetan Thakkar
Tianyu Li
Ken Tominaga
Dulmandakh
Derek Thurn
Lizzi Lindboe
Harry Yu
Mike Masam
islandryu
Matin Zadeh Dolatabad
Aniket Mathur
Baoshuo Ren
Steven Vascellaro
Oleksandr Melnykov
Gijs Weterings
Chaoshuai Lu
Alex Liang
John Wang
MaeIg
Richard Howell
Krzysztof Magiera
Ersan Kavafoglu
J.T. Yim
Anand Bashyam
Panagiotis Vekris
Phillip Pan
NikoAri
Brett Lavalla
Vladyslav Stepanov
Hugo Cuvillier
Alex Landau
almouro
Fadi Quader
Marces Engel
Simen Bekkhus
Keion Anvaripour
Sam Goldman
Chris Olszewski
Andrei Shikov
Joe Frambach
William Candillon
Wei Han
Imran Shitta-Bey
bang9
Kunal Farmah
Mike
Erich Graham
Joachim Reiersen
Vojtech Novak
Abishek Sethuraman
Tatiana Kapos
Krisztiaan
Oleg Kot
Vegas Murphy
Samuel Susla
Arthur Kushka
Brian Vaughn
Nick
Xavier Deguillard
caioagiani
Facebook Community BotandFacebook Community Bot
Richard Barnes
Qiao Tan
Daniel Andersson
skychx
Diego Pasquali
Kevin Lin
HeyImChris
Gilson Takaasi Gil
Dimitri Bouche
Gal Shirin
Ian Childs
Mo Wang
Andres Suarez
Danilo Bürger
jonathanmos
Dave McCabe
Amy Lee
Alfonso Curbelo
maaxg
Kuba Holuj
Minsik Kim
Hamid
Chiara Mooney
Muhammad Numan
Raphael Herouart
Marc Rousavy
Moses DeJong
Michel Kraemer
Orta Therox
Felipe Perez
Keshav Kolur
Andrei Shikov
Elias Nahum
owjsub
Dmytro Voronkevych
joshua
Max Thirouin
Sota Ogo
Mattéo Martin
AKB48
Michelle Laurenti
Oliver Sartun
Eric Rozell
Liam Jones
Michaël De Boey
Sam Kline
Asaf Korem
grgr-dkrk
Mengke Ding
Krzysztof Piaskowy
Ubax
Juan Tejada
Adam Cmiel
Julio C. Rocha
Marshall Mann-Wood
Simon Farshid
Amy Huyen
Alex Koller
Ian Grayson
Marc Rousavy
Liron Yahdav
zpd106
Yuan Dai
Tom Spencer
David Ashinsky
Peter Carpenter
enniel
Nawbc
Jeffrey Hyer
Jesse Katsumata
Jimmy Lai
Marc Horowitz
Saad Najmi
Marcel Lasaj
chenmo187
Niklas Mischkulnig
Lucas Bento
rayzr522
Mikey
somena1
Rachel Lang
Joel Arvidsson
Moshe Berman
Stefanos Markidis
Andrew Scherkus
Andrew Rahn
Connor Tumbleson
Gustavo Sverzut Barbieri
Tuomas Jaakola
Xuan Huang
luism3861
Jordan Becker
