Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51931
This cleans up the whole `JSEngineResolutionAlgorithm` and all the API related to it.
As now we offer support only for Hermes and JSC is provided via a community package.
This is breaking as it affects Expo, but I'll reach out to Kudo to make sure this is integrated properly.
No other breakages other than this.
Changelog:
[Android] [Removed] - Remove and cleanup JSEngineResolutionAlgorithm
Reviewed By: mdvacca
Differential Revision: D76337620
fbshipit-source-id: e43d5d1164f368f5fa395971bca9c05821492dfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51872
This converts to Kotlin and internaline MountingManager.
The only usage in OSS is react-natve-live-markdown:
https://github.com/Expensify/react-native-live-markdown/issues/693
They're using reflection to access Mounting Manager, which they shouldn't.
Other than them, I wasn't able to find meaningful usages of `MountingManager`
Changelog:
[Android] [Breaking] - Convert to Kotlin and internalize MountingManager
Reviewed By: rshest
Differential Revision: D76126338
fbshipit-source-id: 5ab491f86d697a82b8e5b02b031877020dfa3e9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51844
These just redefine the existing `receiveCommand` from the ViewManagerDelegate which already has this codegen'ed
Changelog: [Internal]
Reviewed By: cortinico, rshest
Differential Revision: D75869325
fbshipit-source-id: c8ba482075c2586caf33f46a871b5b5e16fda213
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51806
Correct the type of args, which is always non-null. This is backwards-compatible as subclasses can override this method with a more permissive nullable type and still be substitutable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75869317
fbshipit-source-id: 8f6c9119140794447eca55be24483a35450d7bb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51724
Moves focus change listener logic from `ReactViewManager` to `BaseViewManager` so all view managers that extend the class can get focus/blur event dispatching for free. This does so by applying event listeners where `addEventEmitters` is called, so any extending classes must try to call `super.addEventEmitters` or implement it themselves. In the case of TextInput, this logic is re-implemented because the component emits an additional event when the text input is blurred and I wanted to avoid duplicate calls to get the event emitter for the view instance.
In addition, I've added logic and a test case to ensure that any preexisting focus change listeners set on the view instance are called. There can only ever be one focus change listener tied to a view instance, so this ensures that ones created during view instantiation are retained. However, this does not guarantee that events are emitted for downstream users who overwrite the focus change listener later in the view's lifecycle (i.e. in response to a prop change or an extending view manager that doesn't call `super.addEventEmitters`). There is no clean way to enforce that the `BaseViewManager` focus change listener is always set without changing the generics and introducing a significant breaking change.
Changelog: [Android][Added] - Adds support for onFocus/onBlur event dispatching logic to all native views that implement `BaseViewManager`
Reviewed By: NickGerleman
Differential Revision: D75579321
fbshipit-source-id: 02e1e6d0e78e9d05e4ec5bb59789f3097b73b3f8
Summary:
Migrate com.facebook.react.views.text.ReactTextViewManager to Kotlin.
In this diff, `ReactTextAnchorViewManager` is made public again as it's extended by `ReactTextViewManager`.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.views.text.ReactTextViewManager to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51721
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: mdvacca
Differential Revision: D75829457
Pulled By: NickGerleman
fbshipit-source-id: 425e9ec14f17de5470677b73d68873647bf28675
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51758
ViewManager’s may implement a measure function (using MapBuffer, or ReadableMap). This isn’t used automatically, but may instead be used, by calling into FabricUIManager via JNI, and passing the component name of the view manager to use.
This is only ever called manually, through specific C++ ShadowNodes. Confusingly, for some cases, like `TextInput`, we use the measure function on `RCTText` instead, because this call to FabricUIManager is hidden behind `TextLayoutManager`. This ends up really breaking Facsimile, since we want to measure these in a different way, while still measuring `TextInput` without preparing a layout.
This mechanism is also used to inject `ReactTextViewManager` from the Text View Manager, into the measurement process, for both Text, and TextInput.
I think we would ideally remove and replace the current View Manager measurement mechanism entirely. The interface doesn’t do what it claims to, and requires calling private Java methods via JNI, which we shouldn’t be encouraging external libraries to do. Only a single 3p librar (react-native-picker) uses this, but we have a lot of internal usages, and the current facility is valuable, for translating surface ID into a context. Ie we could not deprecate it without a well thought out replacement.
Instead, this change:
1. Removes the "generalized" version of this for MapBuffer, only ever used by Text
2. Given ourselves a `measureText` function, that will use a spannable processor provided, but go through TextLayoutManager, instead of trying to use this generalized path
3. Documents some of the weirdness of the current setup, without yet deprecating it
This will let the Facsimile View Manager:
1. Provide a ReactTextViewManagerCallback, like the previous version allowed, that influences measurement of both Text, and TextInput (which is... strange, but... not trying to boil the ocean here)
2. TextInput can now measure text, even if Facsimile View Manager doesn't implement this traditional measure interface
Changelog:
[Android][Breaking] - Remove FabricUIManager.measureMapBuffer() and MapBuffer measure functions on ViewManager. Please use ReadableMap variant.
[Android][Breaking] - Remove FabricUIManager.measure overload which accepts attachment positions
Reviewed By: javache
Differential Revision: D75826792
fbshipit-source-id: 6739b1e2e214351b9b95ba782d73cf4278211ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51680
Right now there are 2 flavors of vertical text alignment: `verticalAlign` and `textVerticalAlign`. Both do the same thing currently. For Facsimile, we actually want to "properly" implement `verticalAlign` so that it matches the web version, while leaving `textVerticalAlign` the same. That will take some time, however, so for now we are just going to implement the way it currently works, while fixing some issues with inline View's
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D75475915
fbshipit-source-id: ba6ff7c831bf769e9e60831ed215ab64faf143a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51810
Tweaking the visiblity of some of the fields `NativeModuleRegistry` after the Kotlin migration
of that class.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D75959962
fbshipit-source-id: b3d53fc29af3b0fe32a7bd6a61898814acf90123
Summary:
Migrate com.facebook.react.bridge.NativeModuleRegistry to Kotlin.
In this diff, `JavaModuleWrapper` and some of its functions/properties had to be made public again as they are exposed by the migrated class – and if the functions are kept internal, there are crashes in legacy arch due to the C++ usages.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.bridge.NativeModuleRegistry to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51734
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: rshest
Differential Revision: D75938404
Pulled By: cortinico
fbshipit-source-id: 088286d4b100d1013cff43b81db39c6aec10f4e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51767
This is going to convert the last class inside `com.facebook.react.views.view` to Kotlin.
I still need to assess if this is going to be breaking or not for our users. Potentially some
breakages for Kotlin consumer could happen (see changes on ReactViewManager).
I'll follow-up with an investigation on that one.
Changelog:
[Android] [Changed] - Convert ReactViewGroup to Kotlin
Reviewed By: mdvacca
Differential Revision: D75797215
fbshipit-source-id: 5d58faa651d5959909a4b0237aad9c4209895083
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51570
As the title suggests: adds support strictly to `View` components on Android for `onFocus` and `onBlur` events. This is especially helpful for apps that respond to controller or remote inputs and aligns with existing support for the `focusable` prop.
In order to make this change cross-compatible with text inputs, `TextInputFocusEvent` has been deprecated in favor of the `BlurEvent`/`FocusEvent` types now available from core. Their type signatures are identical but `BlurEvent`/`FocusEvent` should be the type going forward for all views that intend to support focus/blur. Text inputs intentionally do not forward information about their state upon focus/blur and docs specifically call out `onEndEditing` as a means of reading state synchronously when blurring. Therefore, the changes to the native side to remove the event type specifically for text inputs is not breaking.
Changelog: [Android][Added] - Support for `onFocus` and `onBlur` function calls in `View` components
Reviewed By: mdvacca
Differential Revision: D75238291
fbshipit-source-id: b991d1f24fc094ba9d5d466201ecd058f59258e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51575
Before we were relying on absolute focus direction to determine the next focusable view inspired by Recycler View's implementation. This turned out to be inaccurate since FocusForward and FocusBackward do the ordering differently.
For FocusForward and FocusBackwards the children of the root node are ordered first from top to bottom then, row groups are created by getting views with the same vertical position and then everything else is sorted left to right.
Android creates an array with this order and then just focuses the next or previous element of this list. We don't do this but now FocusForward and FocusBackward follow the some comparisons used to build this array on Android.
Also, there was an issue with nested children within an accessible view, this just needed a bit of refactor on the focusSearch function so that we can tell when we actually need to trigger our custom focus search
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D75301251
fbshipit-source-id: 93b708092299afa778ba5938b093c2c38209b497
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51626
This just migrates the `MapBuilder` file to Kotlin.
Users on Kotlin should still use the built-in collection extensions rather than using this class that will go away at some point in the future.
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D75448739
fbshipit-source-id: 2bfa24ad9bd37bd571ea4551bd9a10e848841e0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51625
This just migrates this class to Kotlin, which is also the last class in this package.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest
Differential Revision: D75448161
fbshipit-source-id: d5457dd8017fd459d166d2945ff440c303943db2
Summary:
Migrate com.facebook.react.views.text.TextAttributes to Kotlin.
`TextTransform` is exposed in the `textTransform` var setter, and there doesn't seem to be a clean way to avoid having to make the `TextTransform` class public again. I have limited its companion to keep it internal as much as possible.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.views.text.TextAttributes to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51448
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: cortinico
Differential Revision: D74978129
Pulled By: rshest
fbshipit-source-id: ea0594f01738b8c8f4696434fe76974bbb9ff661
Summary:
In https://github.com/facebook/react-native/pull/50734, `LayoutAnimationController` was migrated to Kotlin and all of its methods are now marked as final.
However, this class is used and extended by `react-native-reanimated` in order to provide Layout Animations for Android on the Old Architecture. With all its methods being marked as final, the builds are failing.
This PR restores the possibility to extend `LayoutAnimationController`.
## Changelog:
[ANDROID] [FIXED] - Restored the possibility to extend `LayoutAnimationController`
Pull Request resolved: https://github.com/facebook/react-native/pull/51479
Test Plan: I've checked that this PR fixes build errors caused by `LayoutAnimationController` in react-native-reanimated.
Reviewed By: cipolleschi, mdvacca
Differential Revision: D75079557
Pulled By: cortinico
fbshipit-source-id: beeb700cbad87362dda4b60941124562c4753815
Summary:
Expo inherits from the DevServerHelper class, and needs it to be declared as open, the same goes for its public interface.
Expo is using this in `DevLauncherDevServerHelper` and overrides the methods:
- getDevServerBundleURL
- getDevServerSplitBundleURL
- getSourceUrl
- getSourceMapUrl
- isPackagerRunning
This PR fixes this by adding the open to the class and to the methods that should be open
## Changelog:
[ANDROID] [FIXED] - Made DevServerHelper and its method open so that they can be overridden.
Pull Request resolved: https://github.com/facebook/react-native/pull/51323
Test Plan: Verify that we can build against Expo.
Reviewed By: cipolleschi
Differential Revision: D74876479
Pulled By: cortinico
fbshipit-source-id: 0037d6f7cee190a690ec3ec59896df04f46797b2
Summary:
After conversion to Kotlin we could no longer override the removeView function since it is no longer open. The rest of this class can be overridden as before, but since functions are final by default this doesn't work for the new `removeView` function.
Expo is overriding the `removeView` functions in `GroupViewManagerWrapper.kt` (a lot of other ViewManager methods are also overridden here, but the `removeView` is introduced in `ViewGroupManager` and needs to be open as well. `GroupViewManagerWrapper.kt` is a replacement view manager that adds support for a delegate that will receive callbacks whenever one of the methods in the view manager are called.
This commit fixes this by making the removeView function explicitly open.
## Changelog:
[ANDROID] [FIXED] - Made function `removeView` open in Kotlin class
Pull Request resolved: https://github.com/facebook/react-native/pull/51322
Test Plan: Verify that Expo can build against this class.
Reviewed By: javache
Differential Revision: D74807744
Pulled By: cortinico
fbshipit-source-id: 55f4b9deccb7d82ceb78be1d56c2b99a6f7e3ce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51338
There was some problems removing this feature flag earlier in that, on older android versions, we would try to focus the top most text input whenever any other text input would try to blur. This was ultimately and issue with how Android implements `clearFocus`. To fix this, lets block the focusability of all views while we clear the focus, then re-enable.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74760594
fbshipit-source-id: 2811c08ad6ed0855da0a4d7fca89fb08f84905c2
Summary:
Original commit changeset: 4682cf709aa2
Original Phabricator Diff: D73954790
I want to pick this into 0.80 so users can enable the feature flag so this doesn't break older versions
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74754010
fbshipit-source-id: 75dc96516b00035984741b43814d6fc7df6be0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51336
Original commit changeset: 12dcaf0c9c35
Original Phabricator Diff: D74678847
I plan on reverting this so that we can in turn revert the diff that this diff fixed so we can pick it into RN 0.80 so that users have some fix on all versions. Right now 0.80 will be broken for older android devices
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74754164
fbshipit-source-id: fda17da3e9b61ca13f68f6681726ffb3f4f4f6c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51302
We got https://github.com/facebook/react-native/issues/51072#issue-3035616801 which demonstrates that if we have 2 text inputs on a screen we cannot blur them. If you try to blur any, focus jumps to the first one.
This seems to be a bug with Android's `clearFocus` per https://developer.android.com/reference/android/view/View#clearFocus(), this behavior is intended when we are not in touch mode, yet it happens regardless of what mode we are in on this version.
I modified this a bit to swallow `requestFocus` calls if we are in touch mode. This should be fine as no JS focus calls will go through this path. On hardware keyboard focus and focus from `clearFocus`
Changelog: [Android] [Fixed] - Fix bug where focus would jump to top text input upon clearing a separate text input.
Reviewed By: mlord93
Differential Revision: D74678847
fbshipit-source-id: 12dcaf0c9c350d3ed697ff81e8dfb205b7942119
Summary:
This PR refactors the entire ReactAndroid package to replace manual `Arguments.createMap()…` and `Arguments.createArray()…` calls with the new Kotlin DSL helpers `buildReadableMap { … }` and `buildReadableArray { … }`. All eligible call sites have been migrated to the DSL, except in functions whose signatures explicitly declare or return WritableMap or WritableArray.
No runtime behavior changes are introduced; existing functionality and tests continue to pass unchanged.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] Apply Collections DSL on ReactAndroid package
Pull Request resolved: https://github.com/facebook/react-native/pull/51145
Test Plan:
```
yarn android
yarn test-android
```
Reviewed By: rshest
Differential Revision: D74401357
Pulled By: cortinico
fbshipit-source-id: 0f7b7dfbb7b495675bc4730bdf018666e9041884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51183
D58818560 tried to deduplicate some code, but introduced an error, where we no longer correctly incorporate the width MeasureMode into the text layout that we create, instead, passing `YogaMeasureMode.EXACTLY`.
In effect, this means the Android layout created always takes up the maximum allowable space, even if content is smaller. This is later masked, because our returned measure when `AT_MOST` is based on maximum line length, and the layout is then recreated when drawing a TextView, but means:
1. Attachments may not be positioned correctly, when using a non-left-aligned paragraph alignment
2. Directly drawing the layout shows the wrong thing
Changelog:
[Android][Fixed] - Fix TextLayoutManager MeasureMode Regression
Reviewed By: rshest
Differential Revision: D74366936
fbshipit-source-id: 3eda8c716ba9790a61c2da19023e140afbb6971d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51174
Allows the start and end of the scrollview to be faded to different values independently by passing an object containing a "start" and "end" value to the fadingEdgeLength prop.
To support non-uniform edge lengths we use the [FadingEdgeStrength](https://developer.android.com/reference/android/view/View#getTopFadingEdgeStrength()) api to set different values for the start/end of the scrollview. The FadingEdgeStrength value is multiplied by the FadingEdgeLength value [internally by Android when drawing the view.](https://cs.android.com/android/platform/superproject/+/android15-qpr1-release:frameworks/base/core/java/android/view/View.java;l=25007)
Because the value of FadingEdgeStrength is required to be between 0 and 1, we set setFadingEdgeLength to the max value and set the smaller side as a percentage of that value.
Changelog: [Android][Added] Allow fadingEdgeLength to be set independently on the start and end of the scrollview
Reviewed By: martinbooth
Differential Revision: D74222606
fbshipit-source-id: 7010ca803cc48450ab98c2a457fdc72ff47c29d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51141
This diff introduces ReactSoftExceptionLogger.CategoryMode to limit categories used on soft errors, the limiation will only create a lint warning but won't create a compilation error.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D74263367
fbshipit-source-id: 56fb2ef0ad3d24810172af300e43ecc1f479464f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51065
This adds infrastructure to let us start storing cached Android text layouts as part of a `ParagraphShadowNode`. After this, we will clear them out, and propagate them to state. Right now, the flag doesn't do much, apart from extra work.
This is done by adding `TextLayoutManagerExtended::supportsPreparedLayout()`, and `TextLayoutManager::PreparedLayout` types, to shim between platforms, then on Android, we add a `PreparedLayout`, which is for now just an Android layout, with extra field (`maxNumberOfLines`, for some reason not exposed on recent versions).
Android `TextLayoutManager` java side is split a little bit, so that we reuse all the existing logic for prepared layouts. I tried to set up the boundary, so that we don't reserialize a MapBuffer after preparation, and for simplicity, this means source of truth for attachment count, and attachment sizes, now lives on the layout. This means we need to change boundary a bit, where we are no longer able to pass in a buffer to fill from C++ side of attachment positions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D73970149
fbshipit-source-id: ff71c227e062c16fe52a4eb3ba2acbebf3d96e56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51039
We added a feature flag in case this broke things. Its been about 4 months now with now issues, I think we can clean this up.
Changelog: [Android][Fixed] - Can now focus TextInput with keyboard
Reviewed By: NickGerleman
Differential Revision: D73954790
fbshipit-source-id: 4682cf709aa2f34ba69e76a35d07a908edb28f23
Nicola Corti
Mateo Guzmán
Pieter De Baets
Peter Abbondanzo
Nick Gerleman
Joe Vilches
Natalia
Jorge Cabiedes Acosta
Tomasz Zawadzki
Christian Falch
HyunWoo Lee
Fabrizio Cucci
Mohamed Salama
Mark Verlingieri
Maddie Lord
David Vacca