Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45688
Box shadows are handled as part of different drawables. We have other cases where we want to show multiple drawables at once, such as for ripple feedback, or more commonly, for app-wide TextInput styles (which adds padding).
With more multi-background scenarios in the future, and CSSBackgroundDrawable already way overloaded, the arch here I want to go towards is less drawables, as hidden implementation details, with single responsibilities, more often switched out. Once path logic is extracted, this would also allow for better fast-paths, like not needing to create a (heavy) CSSBackgroundDrawable, for simple views with a color background.
`CompositeBackgroundDrawable` is then a more structured LayerDrawable, which also lets us mutate or retrieve information from specific layers, and enforces the different types of layers are correctly z-ordered.
`BackgroundStyleApplicator` is the public API for manipulating these styles, inspired by the existing `ReactViewBackgroundManager`. There are some important design differences.
1. The only per-view state is the publicly accessible background drawable. This means the applicator can be used on arbitrary views, and eventually used in BaseViewManager for all views (once all the QEs settle)
2. We have reliable accessors for every setter, which seem to be what folks use externally for animation
3. We work consistently in CSS device independent pixels (for the most part...)
4. More structure/safety in how we refer to edges vs uniform
5. Overflow state is not kept on the applicator, so views can set/keep their own defaults
Overflow clipping must still be implemented per-view, during drawing unfortunately.
Changelog:
[Android][Added] - Add BackgroundStyleApplicator for managing view backgrounds
Reviewed By: joevilches
Differential Revision: D60252279
fbshipit-source-id: 4c6da3e128d4da94f35d50c30c7c412cb513cc12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45734
Rather than enumerating all platforms the iOS podspec should not compile this inverts the source_files field to an allowlist for only files relevant to iOS.
## Changelog
[Internal]
Reviewed By: cipolleschi
Differential Revision: D60291091
fbshipit-source-id: a0f7e3181ec527e39602c4523622f836a04183d9
Summary:
With the React revert from 19 to 18.3.1 of 0.75 the template is not compatible with main anymore.
As a quick solution, we are disabling the e2e tests running on main.
## Changelog
[Internal] - disable E2E template tests
Reviewed By: cortinico
Differential Revision: D60387687
fbshipit-source-id: 74d4133477bcfdc8ba5909b46d9180ac372ec6bb
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `GeneratePackageListTaskTest.kt` to AssertJ testing library
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45790
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: sammy-SC
Differential Revision: D60382287
Pulled By: cortinico
fbshipit-source-id: 338c771db9d407f0d83e1c62a8c13ac26d898926
Summary:
The Maestro team just released a new version of maestro which dies in our CI
This change pins the version to something we know it's working, so we can decide when to move to the next version
## Changelog
[Internal] - Pin Maestro version
Reviewed By: cortinico
Differential Revision: D60380466
fbshipit-source-id: af842b7922736cc08300ac3bceef2d6110bcd913
Summary:
`getGradleDependenciesToApply` tries to call `implementation:` in all libraries, including the ones that are not supported on Android.
## Changelog:
[INTERNAL] [FIXED] - Filter out platform-specific libraries from the auto-linking gradle plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/45749
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D60374769
Pulled By: cortinico
fbshipit-source-id: 33c83e9cc39d81b0e5c497570a936831ebb345f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45708
# Changelog: [Internal]
This was originally highlighted by linter in D59975264, but I forgot to fix it.
Reviewed By: robhogan
Differential Revision: D60282937
fbshipit-source-id: 2869634f2d2111a5e2a81871b38b15a122b3ed8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45528
Right now these exist in static view config (iOS BaseViewConfig), but not native view config, so the props don't work without bridgeless/SVCs, and we would get warnings if doing viewconfig validation.
This change adds the props to native view configs as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59940432
fbshipit-source-id: 89d57d4e58de2a55b749c68274ef0d2271f69100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45630
removeOutstandingSurfacesOnDestruction is safe to fully release, we are deleting the flag
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D60142272
fbshipit-source-id: 5e7470d52cfc964b72f0cec7224a234ce9e6c2c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45422
When `ReactNativeFeatureFlags.setAndroidLayoutDirection()` is set, we assume in components like ReactHorizontalScrolView that the Yoga contextual layout direction has been set on the underlying component, and skip using I18nManager global direction.
These native views are also used in Paper, so we need to make the change there as well to avoid regressions.
This change mechanically ports the change from Fabric to Paper, at the same layer as used in Fabric (applying ShadowNode layout to the Android view tree).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D59708408
fbshipit-source-id: 52d6fa80c102250eae7ccccedd7184569f6a727f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45753
Let's turn this off, for clients where the feature flag isn't wired to a config, until the issue with `removeClippedSubviews` is resolved.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60273063
fbshipit-source-id: 6302a7e1f204459ec7f5cbdb26a521e07e023458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45690
ViewManager layer often uses `YogaConstants.UNDEFINED` (`NaN`) as null-state value. Teaching PixelUtil how to handle `NaN` values makes glue code around easier. I think this technically isn't needed, since the resultant operations would become `NaN`, but it seems like poor form/hard to reason about to propagate NaN into arithmetic or library functions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60265329
fbshipit-source-id: b2f4abaefb30ebd58c2644d072bb7e5bc4b3ee7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45691
1. Add some accessors, so we can keep accessors and setters symetric
2. Use the shared BorderStyle enum added in last diff
3. Fix some missing invalidation on setting style
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252276
fbshipit-source-id: 3dde6ad5926f109cefc7247da4ba1894694b1867
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45687
This adds some more enums and data classes to encapsulate style values we are working with for border/background rendering. Right now, a lot of these are passed around as strings, or raw ints (of differing ordinals). These will be used as the public API of `BackgroundStyleApplicator` up the stack.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252277
fbshipit-source-id: 0f8001869421ffffae9727c7904bf5e395505c08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45685
We built these to be able to parse web style string values, but the types only allow object form, and the TypeScript type is wrong.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60263730
fbshipit-source-id: 7a6e93924a92e8e62346645cb4f8ab1a37dca34f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45722
Splitting the ReactImageView convertion to another file, to see if this is causing further failures.
Changelog:
[Internal] [Changed] - Convert ReactImageManager to Kotlin
Reviewed By: rshest
Differential Revision: D60285050
fbshipit-source-id: 68415782a40c1eacf4e67fbdd2d70c962c0600c0
Nick Gerleman
Eric Rozell
Riccardo Cipolleschi
omerayhan-shft
Andrew Datsenko
gustavoabel
Miguel Daipré
Gabriel Donadel
Ruslan Shestopalyuk
Ruslan Lesiutin
Omar Bafagih
David Vacca
Arushi Kesarwani
Nicola Corti