Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48678
While diagnosing a recent issue in which `AnimatedValue` instances were not being correctly updated as expected, the insertion effects feature flag was identified as a root cause.
Upon further investigation, it appears that this is because the `onUserDrivenAnimationEnded` listener was not implemented the same way in the two feature flag states:
- When `useInsertionEffectsForAnimations` is disabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in a passive effect, after all nodes have been attached.
- When `useInsertionEffectsForAnimations` is enabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in an insertion effect when attaching nodes.
The bugs occurs because `useAnimatedProps` checks whether native driver is employed to decide whether to listen to `onUserDrivenAnimationEnded`. However, we do not know whether native driver will be employed during the insertion effect. (Actually, we do not necessarily know that in a passive effect, either... but that is a separate matter.)
This fixes the bug when that occurs when `useInsertionEffectsForAnimations` is enabled, by moving the listening logic of `onUserDrivenAnimationEnded` into a passive effect. This is the same way that it is implemented when `useInsertionEffectsForAnimations` is disabled.
Changelog:
[Internal]
Reviewed By: javache, sammy-SC
Differential Revision: D68171721
fbshipit-source-id: 50b23348fd4641580581cacebc920959651f96a7
Summary:
Whenever I run `yarn lint --fix` I noticed that this test is not formatted correctly. This fixes it.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48692
Test Plan: CI
Reviewed By: sammy-SC
Differential Revision: D68207001
Pulled By: cortinico
fbshipit-source-id: 2a6c44ca02249f6662b03c87f0c4d4f3eb5a3054
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48690
We don't intent to use the prealpha logic in the near future so it makes sense to remove it for
to simplify our already complicated release process. We can always revive it if we wish.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68205691
fbshipit-source-id: 22a3416335052a4bf6a76faa6e6af622254a6e56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48689
We don't intent to use the prealpha logic in the near future so it makes sense to remove it for
to simplify our already complicated release process. We can always revive it if we wish.
Changelog:
[Internal] [Changed] - RNGP - Cleanup prealpha logic from the Gradle Plugin
Reviewed By: cipolleschi
Differential Revision: D68205665
fbshipit-source-id: 81d5257544df97b566421164944e3b6e71f06635
Summary:
In the old arch, stylistic sets were supported however in the new arch support was not added. It seems that fontVariant support was actually initially missed on iOS fabric however a limited version was added in https://github.com/facebook/react-native/pull/44112 . I referenced that PR and also old arch implementation for these changes.
<img width="480" alt="Screenshot 2025-01-14 at 11 15 18 AM" src="https://github.com/user-attachments/assets/ec32a356-fadd-4281-83b9-15871bbcd18f" />
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Support stylistic sets for fontVariant
Pull Request resolved: https://github.com/facebook/react-native/pull/48674
Test Plan:
- Verified that the "Unsupported FontVariant" native log no longer displays on both platforms
- On iOS was easy to test in the tester app as SF supports stylistic sets by default:
```
<Text>
Stylistic{'\n'}
<Text>Normal: ${'\n'}</Text>
<Text style={{fontVariant: ['stylistic-four']}}>
Stylistic Four: $
</Text>
</Text>
```
<img width="391" alt="Screenshot 2025-01-14 at 11 59 29 AM" src="https://github.com/user-attachments/assets/1ede258e-783f-448f-8300-4c8c710796ef" />
- On Android I could not find any system fonts that support stylistic sets by default so I added Raleway and confirmed with a W character
I did not add font variant example to the tester apps as I felt it could be confusing for people at a glance to understand why there is only a system font example on iOS and why I chose the specific stylistic set.
Reviewed By: cipolleschi
Differential Revision: D68205738
Pulled By: javache
fbshipit-source-id: 03ce572d3c8ecafca71fe00fc0e88eeafc2558bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48664
Simplify ViewManager base-class by making `ViewManager`'s delegate non-nullable and using a single path for updating properties.
The ViewManagerDelegate API can map back to the original ViewManagerSetter API transparently, allowing us to remove the codepath from `ViewManagerPropertyUpdater`.
Changelog: [Android][Removed] `ViewManagerPropertyUpdater.updateProps` is deprected, use the related ViewManager APIs instead
Reviewed By: mdvacca, rshest
Differential Revision: D68120420
fbshipit-source-id: cd8b906dc36d4803dbe09ee0283654285eb81fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48658
Migrate to Kotlin before I make further changes to this. Generics are really tricky due to our previous usage of raw generics on the Java side, but were worked around by some combination of unchecked cast and `Nothing`
Changelog: [Internal]
Reviewed By: mdvacca, rshest
Differential Revision: D68102210
fbshipit-source-id: 90013f09db0826f571a4e2a84132ae3b49fa299d
Summary:
This change improves the E2E testing by downloading the iOS RNTesterApp that is built in CI instead of building it locally. This should let us save 10 to 20 minutes when we test a new release.
## Changelog:
[Internal] - Use the RNTester app built in CI for release testing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/48637
Test Plan:
- build the app in ci
- run `yarn test-e2e-local -c <my-token>` and `yarn test-e2e-local -h false -c <my-token>` and verify that the iOS app is not built, but run in the simulator
Reviewed By: cortinico
Differential Revision: D68161477
Pulled By: cipolleschi
fbshipit-source-id: 577d110f9ff0197a2d3348a08a60e60a4d0a752b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48547
For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why
I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input.
This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method.
**In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`.
Changelog: [Android] [Fixed] - TextInputs can now receive focus via external keyboard
Reviewed By: NickGerleman
Differential Revision: D67953398
fbshipit-source-id: 506006769a7c8a63f0a9b7ce27cfbe8578777790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48677
E2E tests are flaky again.
Let's bump maestro to see if stability improves.
This will also remove some noise from the logs, make them easier to read.
## Changelog
[Internal] - Bump maestro version
Reviewed By: cortinico
Differential Revision: D68160005
fbshipit-source-id: 40a25f974dfda75785bf08d8d236e771b44d13cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48672
## Changelog:
[General] [Fixed] - Buttons becoming unresponsive when transform is animated
# The problem
D67872307 changes when `ensureUpdateSubscriptionExists` is called to in `__attach`. This breaks the functionality because `__attach` is called before flag `__isNative` is set and subscriptions are never setup.
# Fix
The diff sets up subscriptions in `__makeNative` method.
Reviewed By: yungsters
Differential Revision: D68154908
fbshipit-source-id: e2ac108b064a66dda08902653d6bd20286f92458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48666
The New Architecture sample is getting too big and the two views are not visible anymore.
I'm fixing this but having buttons side by side.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68153245
fbshipit-source-id: 5557fd40f81078fe3994d8efe0e73784e043ed78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48670
The `LICENSE-docs` was needed when this repo was also containing the reactnative.dev docs.
As this is not the case anymore, this file is unncessary.
Changelog:
[Internal] [Changed] - Remove unnecessary LICENSE-docs
Reviewed By: cipolleschi
Differential Revision: D68156336
fbshipit-source-id: 489bf2cb95916c20eb61bfb00e34b8e271bc08e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48656
While working on 0.78, I realize we were not testing the template app with JSC.
This change should fix this.
## Changelog:
[Internal] - Disable Hermes for the JSC E2E tests with Maestro
Reviewed By: cortinico, fabriziocucci
Differential Revision: D68147849
fbshipit-source-id: 4fbe005b5d04d6163a37041d1bd57fd48a9dfda8
Summary:
On bridgeless mode, `reactHost` is kept in memory even after destroying the `DefaultReactNativeHost` in brownfield scenario. Since it keeps references to the modules, they are not deallocated, and their `initialize` methods are not fired again when creating new instance of `react-native` later. It breaks the behavior of e.g. `react-native-screens`, which wants to listen for mutations and should get new `FabricUIManager`: https://github.com/software-mansion/react-native-screens/blob/20b7e83782cd5f79ddd0d61dadc13eeb4db4b258/android/src/main/java/com/swmansion/rnscreens/ScreensModule.kt#L45.
In this commit we change the `DefaultReactNativeHost.clear()` method to also invalidate the instance retained inside `DefaultReactHost`
## Changelog:
[ANDROID] [FIXED] - Make DefaultReactNativeHost.clear() also invalidate DefaultReactHost
Pull Request resolved: https://github.com/facebook/react-native/pull/48338
Test Plan: In brownfield scenario, destroy the instance of RN and see that modules are also destroyed.
Reviewed By: cipolleschi
Differential Revision: D67977140
Pulled By: cortinico
fbshipit-source-id: 1804f093ab1a905bef499078ddec32a13c50cc85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48659
Changelog:
[Internal] - Replaced ExactReactElement_DEPRECATED with React.Node as a children type in ScrollViewStickyHeader
Reviewed By: fabriziocucci
Differential Revision: D68151420
fbshipit-source-id: d4406de67176ae1fea95b8b2ea85f41dc7f5045e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48660
RN-Tester is currently instacrashing on release due to a migration to Kotlin for HermesExecutor
This fixes it.
Changelog:
[Internal] [Changed] - Fix crash for Hermes Release due to HermesExecutor migration
Reviewed By: javache
Differential Revision: D68151666
fbshipit-source-id: 31f404ec518831cf2151dc670cdf8553427ae8ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48609
# Motivation
This is an attempt at modernizing the export syntax in some of the files in `Libraries/StyleSheet/`. It will allow these files to get properly ingested by modern Flow tooling.
# This diff
- Migrates the use of `module.exports` into `export default` for files located in `Libraries/StyleSheet/*.js`. Some files were omitted due to ballooning complexity, but will be addressed in other Diffs.
- Updating internal *require*s to use ".default", no product code seems to be affected.
- Migrating `require`s into `import`s where applicable, taking into account the performance implications (context: https://fb.workplace.com/groups/react.technologies.discussions/permalink/3638114866420225/)
- Updates the current iteration of API snapshots (intended).
- Updates `react-native-codegen`'s require of processColorArray, analogous to D42346452.
Changelog:
[General][Breaking] - Deep imports from some files in `StyleSheet/` can break when using the `require()` syntax, but can be easily fixed by appending `.default`
Reviewed By: javache
Differential Revision: D68017325
fbshipit-source-id: 3c5b94742f101db0b2914c91efab6003dba2b61a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48602
See context in D64532446 / https://github.com/facebook/react-native/pull/47086
These argument types were already consumed as nullable in various OSS libraries, which prevents correct Kotlin migration of this code.
Changelog: [Android][Changed] Deprecated ViewManagerDelegate#setProperty and ViewManagerDelegate#receiveCommand
Reviewed By: mdvacca
Differential Revision: D67277871
fbshipit-source-id: a0743584891c7b2b4b50fff11de15da0078d5a1a
