Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36042
Pull Request resolved: https://github.com/facebook/react-native/pull/36028
Use aliasMap both in parsers and generators instead of using aliasMap in half of the places and aliases in the other.
This would also allow us to introduce "enumMap" more easily in the next commit.
Changelog: [Internal] rename module exports from "aliases" to "aliasMap"
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42888752
fbshipit-source-id: cf1929fcebde994d07e5c6bda5ab71106d417b21
Summary:
This is a prototype to add circular dependencies detection on CMake for ReactCommon and ReactAndroid.
It can be enabled per module and works as follows:
```
set(ALLOWED_HEADER_IMPORT_PATHS
react/renderer/graphics
react/debug)
check_for_circular_dependencies("${ALLOWED_HEADER_IMPORT_PATHS}")
```
The allowed header import path must be manually specified as libraries are exposing wrong header search paths (so can't be reused).
The CI will be red till the circular dependency on `graphics` is resolved.
Changelog:
[Internal] [Changed] - Add macro to detect circular dependencies on Cmake
Reviewed By: cipolleschi
Differential Revision: D42927036
fbshipit-source-id: b1393dfd43fd042e2ebf1d5b46b24bd9f5e20d58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36039
This change bumps AGP to 7.4.1 so we can remove a lot of the unnecessary changes
we had to do to support AGP 7.3.x
I've also removed the explicit version in the template as now the AGP version
is provided by RNGP. That means that the user will get the correct version they need.
This also bumps the default CMake version in user space to 3.22 which resolves a lot
of warning when users are building with the New Architecture enabled.
Changelog:
[Android] [Changed] - Bump AGP to 7.4.1
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D42960353
fbshipit-source-id: 9065f975c1694d266a86b2d3fe805e6e2b1c4aa1
Summary:
- Bridgeless is using a deprecated FabricUIManager constructor which bridge doesn't use, and is the only one using it, this diff migrated bridgeless to use the same FabricUIManager constructor as bridge
- Remove static view config check (mShouldDeallocateEventDispatcher), instead use Bridgeless check since SVC is enabled in Bridgeless but not in Bridge.
Changelog:
[Android][Changed] - Align creation of FabricUIManager with bridge
Reviewed By: javache
Differential Revision: D42681489
fbshipit-source-id: b9c7c4a81a98db52e881138cc85be0e85df636d9
Summary:
Changelog: [Internal] Support hovering in/out of root views
Prior to this change, we did not have signal when an input device moved out of the root view and so our internal state would not be aware and we would not trigger enter/leave events.
This diff starts listening to `HOVER_EXIT` events as dispatched from `onInterceptHoverEvent` and assumes that's the right event to signal a cursor has moved out of the root view. We dispatch the relevant leave events for this case and update our internal state to ensure the next `HOVER_MOVE` in our rootview, will properly dispatch the enter events.
## Investigation for creating this diff
Determining the signal for when an inputDevice enters/exits our rootview wasn't straight-forward.
From my understanding Android event dispatching follows a similar capture, bubbling phase as web. With `onIntercept..` handlers to swallow events. See this explanation: https://suragch.medium.com/how-touch-events-are-delivered-in-android-eee3b607b038 and this video talk: https://youtu.be/EZAoJU-nUyI?t=929
However when trying to understand hover enter/exit events on the root view, my understanding of this logic broke down.
Here's what confused me:
* When moving a cursor from inside to outside the root view, I would receive `HOVER_ENTER/EXIT` MotionEvents on `onInterceptHoverEvent` and since we did not swallow them, we'd receive those same events on the bubble up in `onHover`. That makes sense.
* However, when I hovered from the rootview into a child view, I would receive MotionEvents of `HOVER_ENTER/HOVER_EXIT` in the `onHoverEvent` handler of the rootview without having seen them in the `onInterceptHoverEvent` (re: capture phase down). This was confusing, where was the capture down?
* What tips me off that these events (`HOVER_ENTER/EXIT`) don't follow the classic capture, bubbling model as explained in the linked article, is that I don't receive `HOVER_ENTER/HOVER_EXIT` events for each child view in the root view's `onInterceptHoverEvent`.
* Like when a cursor moves from root -> child, I'd expect to motion events 1. exit for the rootview, 2. enter for the child view. But I never receive the 2. from the root view --
* I also wonder if the wording for `HOVER_EXIT` events mean that these events are directly dispatched to the view? Re: ["This action is always delivered to the window or view that was previously under the pointer."](https://developer.android.com/reference/android/view/MotionEvent#ACTION_HOVER_ENTER)
* There also seems to be some optimizations around the dispatch path as mentioned in this video at this timestamp: https://youtu.be/EZAoJU-nUyI?t=929 for the UP gesture.. so maybe there's some optimization happening with hover events? I'm not sure how hover events are account for in gesture handling for Android.
Reviewed By: vincentriemer
Differential Revision: D42817315
fbshipit-source-id: 412c971c1d1e7afc0d67fadcc4417189967fe48c
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.2
Pull Request resolved: https://github.com/facebook/react-native/pull/36032
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D42928179
Pulled By: cipolleschi
fbshipit-source-id: 1eb7b399e58c6e78a6961dc98198fb747df5ceb3
Summary:
The [previous pull request](https://github.com/facebook/react-native/pull/35812) enables defining interfaces and using them in a turbo module, but all members are flattened, this is not the best option for codegen for object oriented languages.
In this pull request, an optional member `baseTypes` is added to aliased objects. Members are still flattened for backward compatibility, if a codegen doesn't care about that nothing needs to be changed.
### Example
```typescript
interface A {
a : string;
}
interface B extends A {
b : number;
}
```
#### Before the previous pull request
`interface` is not allowed here, you must use type alias.
#### At the previous pull request
`interface` is allowed, but it is translated to
```typescript
type A = {a : string};
type B = {a : string, b : number};
```
#### At this pull request
Extra information is provided so that you know `B` extends `A`. By comparing `B` to `A` it is easy to know that `B::a` is obtained from `A`.
## Changelog
[GENERAL] [CHANGED] - Turbo module codegen support interface with inheritance in module
Pull Request resolved: https://github.com/facebook/react-native/pull/36011
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: rshest
Differential Revision: D42882650
Pulled By: cipolleschi
fbshipit-source-id: 32d502e8a99c4151fae0a1f4dfa60db9ac827963
Summary:
While working on T143721371 I've noticed that we still have an exposed context
for `react-native-bot` which gives access to `PAT_TOKEN` and `PAT_USERNAME`.
As those two variables are unused, we can fully clean this us.
Changelog:
[Internal] [Changed] - Remove the `react-native-bot` context from CircleCI
Reviewed By: cipolleschi
Differential Revision: D42886196
fbshipit-source-id: 4eba7a53557fe7af7d87650052630eea2d2d3934
Summary:
The fixed error guides users toward the right missing dependency. The original error pointed to the old name.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[INTERNAL] [FIXED] - Display correct codegen dependency name when not found
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Display correct codegen dependency name when not found
Pull Request resolved: https://github.com/facebook/react-native/pull/36013
Test Plan: This is an error message wording change.
Reviewed By: jacdebug
Differential Revision: D42881807
Pulled By: cipolleschi
fbshipit-source-id: d96fb867cfe27ae922d398ab981f5797cb51a269
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. When a ScrollView's content is laid out, onLayoutChange is triggered. This is also fired when the views are hidden, which is not desirable as the layout may not be accurate when the view is hidden. Check that the scroll view is showing before attempting a scroll.
Changelog:
[Internal][Fixed] - In onLayoutChange, only scroll if the view is shown and the content view is ready
Reviewed By: sshic
Differential Revision: D42808119
fbshipit-source-id: 0197ae55fa7d80e52c2ea483609e62d512a117f3
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. There is an edge case where on onLayout for a ScrollView, its content may not have been laid out yet. This happens in some cases when a scroll view is hidden via display: 'none' (resulting in setVisibility(INVISIBLE)). Check that the content view is laid out before attempting a scroll.
Changelog:
[Internal][Fixed] - In onLayout, only scroll if the content view is ready
Reviewed By: sshic
Differential Revision: D42794750
fbshipit-source-id: 654a380bcae306da2704d3e190423c8de125833d
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. On iOS, when a UIScrollView (or its ancestor) is hidden, its scroll position is set to 0 (its window also becomes nil). When it is shown again, its scroll position is not restored.
When a scroll is attempted when the scroll view is hidden, we keep track of the last known offset before it was hidden. Then, in updateLayoutMetrics (which is triggered when the view is shown), we apply the pending offset if there is one. This is [consistent with Android's behavior in ReactScrollView.java](https://www.internalfb.com/code/fbsource/[2930f8c146af62ad63673c8d34e9876b77634c05]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=289).
Changelog:
[Internal][Fixed] - In onLayoutChange, only scroll if the view is shown and the content view is ready
Reviewed By: cipolleschi
Differential Revision: D42815359
fbshipit-source-id: 4b209c1e54edf3f5c0bea902b48450a1a2e9661a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35992
Fixes https://github.com/software-mansion/react-native-gesture-handler/issues/2382
I've just realized that the default value fo `jsRootDir` is not entirely correct.
That's the root of the folder where the codegen should run.
For apps, it should be defaulted to `root` (i.e. ../../)
For libraries, it should be defaulted to `../` (currently is root).
This causes a problem where libraries without either a `codegenConfig` or a `react{ jsRootDir = ... }`
specified in the build.gradle will be invoking the codegen and generating duplicated symbols.
Changelog:
[Android] [Fixed] - RNGP - Properly set the `jsRootDir` default value
Reviewed By: cipolleschi
Differential Revision: D42806411
fbshipit-source-id: ffe45f9684a22494cc2e4d0a19de9077cb341365
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35982
This reflects better what the former `emitPartial` was doing - emitting an object with set props.
Changelog: [Internal] - Renamed emitPartial to emitObject
Reviewed By: christophpurrer
Differential Revision: D42740958
fbshipit-source-id: 4f974c6911bc129e698323a8039bbd7aa7602461
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35981
This reflects better what the former `emitObject` was doing - emitting a generic object.
It would also allow us to rename `emitPartial` to `emitObject` in the next diff whence the function name `emitObject` will be free.
Changelog: [Internal] - Renamed emitObject to emitGenericObject
Reviewed By: christophpurrer
Differential Revision: D42740871
fbshipit-source-id: 1b9112464695b8abeccc95eed908b0b45a0e3bf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36004
Changelog: [Internal]
This fixes CircleCI job, which is responsible for publishing bumped packages. We should not check for `stderr`, apparently `npm` uses it to store debug information:
- https://github.com/npm/npm/issues/118#issuecomment-325440
So we've tried to use this on 0.71-stable before and it succesfully published one package, but have exited right after it because `stderr` was not empty
Reviewed By: cortinico, cipolleschi
Differential Revision: D42836212
fbshipit-source-id: 6f2a9a512121683268fe6aae6a187fccb8d9dfbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36003
This diff adds 4 tests in CircleCI to make sure we don't regress in the support of Dynamic Frameworks for the old architecture.
## Changelog
[iOS][Fixed] - Add CircleCI tests for dynamic frameworks with the Old Architecture.
Reviewed By: cortinico
Differential Revision: D42829895
fbshipit-source-id: 5669be45d4f55161a11a6ece161b2a2aa384a644
Summary:
I discovered that 0.69 could run React Native as Dynamic framework with Hermes and starting from 0.70 that's not possible anymore.
This diff restore that possibility.
Notice that now Hermes provisdes JSI and Dynamic Frameworks requires that all the dependencies are explicitly defined, therefore, whenever we have a pod that depended on `React-jsi`, now it also has to explicitly depends on `hermes-engine`
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the Old Architecture with Hermes
Reviewed By: cortinico
Differential Revision: D42829728
fbshipit-source-id: a660e3b1e346ec6cf3ceb8771dd8bceb0dbcb13a
Summary:
I discovered that 0.69 and 0.70 could run React Native as Dynamic framework with JSC and starting from 0.71 that's not possible anymore.
This diff restore that possibility.
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the old architecture
Reviewed By: cortinico
Differential Revision: D42829137
fbshipit-source-id: 848672f714d8bab133e42f5e3b80202b350d5261
Summary:
In a mono-repo the `react-native` package could be hoisted compared to the app directory, in which case it's not a good strategy for the `react-native-xcode.sh` script to guess the app project root relative to the location of itself. Instead I suggest to relying on a build setting provided by Xcode to derive the default app path.
I could have use the `SRCROOT` instead. According to https://stackoverflow.com/questions/36323031/what-the-different-between-srcroot-and-project-dir this is equivalent and also a bit less ambiguous as I see it. I.e. I would expect most Xcode projects to be located in the `ios` directory of the app.
As a workaround, before this merge, users can add the following to their "Bundle React Native code and images" build phase or `ios/.xcode.env` file:
```shell
export PROJECT_ROOT="$PROJECT_DIR/.."
```
This build phase can also be used for users wanting to revert this default behaviour once merged.
## Changelog
[iOS] [Changed] - Changed default `PROJECT_ROOT` (used in when bundling for iOS) to rely on the `PROJECT_DIR` build setting.
Pull Request resolved: https://github.com/facebook/react-native/pull/35970
Test Plan:
I've updated this locally and verified this does indeed pick up the correct app path - even in a mono-repo.
To verify this:
- Instantiate the template with this patch applied.
- Update the "Run scheme"'s "Build Configuration" to "Release".
- Build the app without errors.
Reviewed By: cortinico
Differential Revision: D42842636
Pulled By: cipolleschi
fbshipit-source-id: 040c31ac59a8abec5f5b38f795c8e74649420bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35991
Changelog: [Internal]
While cherry-picking all this logic to `0.71-stable` branch, we've discovered several issues where some packages were failing to be published on Verdaccio proxy
This was failing only on node v16+, after some research, I've noticed that there might be a race-condition and npm unable to grab this token before first `npm publish` executes
Although this still work well on `main` branch, I am backporting it to keep aligned with `0.71-stable`
Reviewed By: christophpurrer, cortinico
Differential Revision: D42806081
fbshipit-source-id: af244d26ea529e6085ed5b2d731623dfaf78a14d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
I'm moving nightlies from scheduled workflow to scheduled pipeline.
We're not able to manually retrigger nightlies as they're a scheduled workflow and don't expose a parameter. Here I'm cleaning it up.
Plus I'm:
1. Removing the `main_only` reference which is unused
2. Setting up the `run_release_workflow` and `run_nightly_workflow` parameters.
## Changelog
[INTERNAL] - Migrate nightly from scheduled workflow to scheduled pipeline
Pull Request resolved: https://github.com/facebook/react-native/pull/35977
Test Plan: Will wait for CI results.
Reviewed By: cipolleschi
Differential Revision: D42776969
Pulled By: cortinico
fbshipit-source-id: d4ef9654d23cb91f85ce2b38e75e27dc0c575e95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35961
Pull Request resolved: https://github.com/facebook/react-native/pull/35960
This fixes#35864
This feature allows using `$Partial<Obj>` in flow and `Partial<Obj>` in TypeScript based on the spec mentioned here: https://flow.org/en/docs/types/utilities/#toc-partial.
We currently only allow passing an Obj to Partial so
```
export type SomeObj = {
a: string,
b?: boolean,
};
export type PartialSomeObj = Partial<SomeObj>;
```
should work.
and also-
```
export type PartialSomeObj = Partial<{
a: string,
b?: boolean,
}>;
```
But not
```
export type PartialSomeObj = Partial<Partial<{
a: string,
b?: boolean,
}>>;
```
This can be improved in the future by a recursive unwrapping of the value inside the `Partial` annotation.
Changelog:
[General] [Added] - Allow the use of "Partial<T>" in Turbo Module specs.
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42640880
fbshipit-source-id: 03a3fccc38ccfc7a5440fe11893beb68e77753f3
Summary:
We still see crashes for T112157805 and this diff is to add missing information to help diagnose the issue better.
We added a line of log to indicate which `mountItem` triggered the exception.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D42556576
fbshipit-source-id: 4283c34cb18d601ca7b80d3524c9c65cc4ae3f8a
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:
changelog: Enable Layout Animations on iOS
[LayoutAnimations](https://reactnative.dev/docs/next/layoutanimation) in New Architecture have been disabled in OSS on iOS because of unresolved crash. This crash only happens rarely. Turning on LayoutAnimations in OSS should be safe and brings New Architecture to parity with old.
Reviewed By: fkgozali
Differential Revision: D42708774
fbshipit-source-id: b0f7febee3aa4f0ddac25556644198ebe79378c1
Summary:
While buildling locally, those two warnings pop up.
- ANDROID_LD being unused by the CMake toolchain. I'm removing it.
- The Download task encountering a weak eTag. I'm updating it:
https://github.com/michel-kraemer/gradle-download-task
Changelog:
[Internal] [Changed] - Fix a couple of warnings in the ReactAndroid:hermes-engine build
Reviewed By: dmytrorykun
Differential Revision: D42738919
fbshipit-source-id: 7bd8785ad5b7431d557e2f8c8876b7c3f7294a43
Summary:
Fixes conflicts in pod build settings like the one below:
Example warning
> Can't merge user_target_xcconfig for pod targets: ["RNReanimated", "hermes-engine"]. Singular build setting CLANG_CXX_LANGUAGE_STANDARD has different values.
Background:
> The former attribute xcconfig is deprecated and will cause a linter error when pushing new versions to trunk. The new attributes are available as pod_target_xcconfig and user_target_xcconfig, which makes their effects more clear. The latter attribute (user_target_xcconfig) should be used with great care, because well designed Pods should be self-contained and make as few assumptions about their environment as possible. Furthermore, this attribute can cause conflicts when different values are specified by two Pods for a build setting which doesn't allow multiple values and so cannot be merged.
- https://blog.cocoapods.org/CocoaPods-0.38/
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix cocoapods warning about merging user_target_xcconfig
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35954
Test Plan:
- Run in example app
## Related PR
- https://github.com/facebook/hermes/pull/903
Reviewed By: christophpurrer
Differential Revision: D42737921
Pulled By: jacdebug
fbshipit-source-id: 75d087a5287e660a703342d6e0ad6632f05f3c4c
