Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50197
Adds `setRuntimeData` and `getRuntimeData` JSI APIs. This provides a
convenient way for users to store some custom data associated with an
UUID.
For the default implementation of this feature, store the runtime data
in the global map that is shared between all VMs. This is done to keep
JSI lightweight and stateless, instead of adding data members.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D71579532
fbshipit-source-id: 553e28fbf80c93e268d475860197a00d2c5bacf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50270
Add UUID struct to JSI. This will be used in the incoming changes, such
as identifying JSI interfaces and storing custom runtime data.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D71826382
fbshipit-source-id: e0d9bc20fb0f0e75407b9c88e731623e6a9975dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51206
When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width.
This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing!
1. Way back in 2020, yungsters made D21056031 introducing this logic to "shrink wrap" text which is wrapped.
2. "Shrink wrapping" is not how web works when text is wrapped, (though it is how it works when there is explicit newline), and https://github.com/facebook/react-native/pull/47435 later undid this change
3. https://github.com/facebook/react-native/pull/37790 made changes specific to the case of trailing newline, because the logic to "shrink wrap" did not handle correctly.
After D74366936, which changes width used for layout creation to correctly respect `Layout.desiredWidth`, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace.
It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74368513
fbshipit-source-id: df5d7b773ad1888ebca1966ee4020a5c2ce7fd64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51221
In the case of an empty root node, we don't need `buildStubViewTreeWithoutUsingDifferentiator` to create the initial `StubViewTree`
When testing with Fantom, this caused an additional unnecessary clone of RootShadowNode.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D74472766
fbshipit-source-id: 076e859a6c5795e9026c7a5f8246a5658db4a94b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51214
D74381864 caused a series of crashes to spike due to .IncompatibleClassChangeError: Class 'android.content.res.TypedArray' does not implement interface 'java.lang.AutoCloseable'
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D74468593
fbshipit-source-id: 70c14bdba4f229d4f59a01da3b56cd4fec29752f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51070
Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.
### Breaking
`didCompleteNetworkResponse` now throws an Error instead of throwing a string.
In dev, we use [lazy bundling](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0605-lazy-bundling.md#__loadbundleasync-in-metro) which allows us to re-build only the parts of the app that are changed.
However the function that loads these lazy bundles in `loadBundleFromServer.js` for requests that reach `didCompleteNetworkResponse` with an error **throws a string representing the error message** which makes debugging very inconvenient because it lacks stack trace and error type. Throwing strings is not a standard practice. We better throw an error in these cases so it can be handled better.
Why a special type of error?
* As you can see in the "after", in the test plan below, even with a stack trace, it might be hard to know where this error originates from
* Also so extra information can be added on it. Currently adding "url"
* Also to support error handling based on the type of error
Reviewed By: hoxyq
Differential Revision: D73925027
fbshipit-source-id: a0f98d283ec8842696f1b87864fb63cb30c0c028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51210
Changelog: [internal]
This adds a safety mechanism to Fantom tests to prevent LogBox from swallowing errors.
Now we validate that LogBox isn't installed when running tasks, so we can properly fix error reporting in tests.
Reviewed By: rshest
Differential Revision: D74464749
fbshipit-source-id: ef5e814b14aedbc681a4c7f9f8f60f454b239b6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51211
Changelog: [internal]
This modifies the setup for Fantom so:
1. We don't inject "InitializeCore" by default.
2. We define a default environment setup module for Fantom with good defaults (LogBox, etc. disabled).
We also migrate all existing tests to use the new module.
The goal of this is to prevent LogBox from being used in tests so we can properly fix error propagation in the work loop (so they're not intercepted by it).
Reviewed By: rshest
Differential Revision: D69003812
fbshipit-source-id: 00353b5055e3700943a08ea67f698d49e068555b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51209
Changelog: [internal]
This refactors `InitializeCore` to extract the initialization logic to a separate configurable module.
By default, this does the same thing it does now, but the new module could be used without `InitializeCore` to set up the environment forcing disabling developer tools (e.g.: for testing in Fantom in development environments).
Reviewed By: rshest
Differential Revision: D69003811
fbshipit-source-id: ab85b10e4f21adccd8844a848d3272c407832031
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51208
Changelog: [internal]
Adding a few more test cases to make sure error handling is fixed considering these use cases.
Reviewed By: rshest
Differential Revision: D74459974
fbshipit-source-id: 9a5865a9a09dd64535b4d38307db6c30f213b45f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51197
This change adds the Package.swift file that can finally build React Native core using SPM
## Changelog:
[Internal] - Add Swift PM file to uild React Native Core using SwiftPM
Test Plan:
prepare the repo with
```
node packages/react-native/scripts/ios-prebuilds.js
```
and by downloading the ReactNativedependencies from the CI
Then open the Package.swift file in Xcode. I successfully built:
- iOS
- iOS Simulator
- Mac Catalyst
Reviewed By: lenaic
Differential Revision: D74393435
Pulled By: cipolleschi
fbshipit-source-id: 7d61ad1d09444a0c16e865062ae448ec1e7ef5ad
Summary:
After unobserve is called, the shadow node actually isn't deleted from the `targetToShadowNode` WeakMap. So, if the element is kept around, the shadow node will leak.
We suspect this doesn't happen in practice. But, still it's good to just do this cleanup, just in case.
Changelog: [General][Fixed] Fix potential leak inside IntersectionObserver
Reviewed By: lunaleaps, yungsters
Differential Revision: D74361644
fbshipit-source-id: 1a5ccce1486aa200fc7318c689bfa887f713c284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51148
Intersection observer should not be holding on to shadow nodes.
This diff migrates the javascript infra to instead use families.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74262804
fbshipit-source-id: cc090be54f7312ce32b853ddf86567bb43e676b8
Summary:
IntersectionObserverManager now uses families to manage IntersectionObservers.
This diff just migrates its apis to family too.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74263375
fbshipit-source-id: d2e5fda327dfc75f0f711932626643d49cb3322f
Summary:
X-link: https://github.com/facebook/yoga/pull/1809
Pull Request resolved: https://github.com/facebook/react-native/pull/51181
We want to know if an artifact created during measurement can fully be reused after final layout, but the final layout is allowed to be slightly larger due to pixel grid rounding (while still allowing reuse). It's hard to tell after the fact, whether it is larger because of this rounding (though the measure is used), or if it may be a pixel larger for valid reasons.
We can expose the unsnapped dimensions of a node to give us this information, and to correlate measurement artifacts.
This is most of the time the same as the layout's measured dimension, though I don't think it's safe to use this, since anything else measuring the node after could clobber this (I think `YGNodeLayoutGetOverflow` may also be prone to this as a bug).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74292949
fbshipit-source-id: 05011c66a9a9480544313eb1dfe2c46bf7742bac
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/51180
Android's TextLayoutManager may return widths greather than the max measure constraint.
Yoga will clamp these, but this sort of issue points to a logic bug, and creates issues when we are looking at caching text measurements based on constraint reuse.
Let's debug assert that we don't do that, and fix a case of rounding up at a pixel boundary, to ensure that it doesn't go above max width. This should theoretically be safe, since Yoga is already doing this clamping, which is what dictates final size of the TextView.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74291373
fbshipit-source-id: 44166f2e47323384cb00f3cf4c32f398e298a63e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51195
This change adds a script that prepares the repository by creating hard links to the header files in the `.build` folder that is also gitignored
## Changelog:
[Internal] - Add sdcript to setup the repository so that we can build it properly.
Test Plan:
run:
```
node packages/react-native/scripts/ios-prebuilds.js
```
observe the folder `.build` being created with all the files.
Reviewed By: cortinico
Differential Revision: D74393116
Pulled By: cipolleschi
fbshipit-source-id: 4951e61b49db83fbebbcc265ae025f53185fec81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51194
This change adds an utils script to set up folders when needed.
## Changelog:
[INTERNAL] - Add utils script
Test Plan: This is tested in the next diff of the stack.
Reviewed By: cortinico
Differential Revision: D74393298
Pulled By: cipolleschi
fbshipit-source-id: db3db61ec938d2ebe5c0bf5ae0a42aa20c673bb0
Summary:
- Added multiple targets to Package.swift
- WIP: Builds up untill we need to touch files in React/Base
## Changelog:
[INTERNAL] - WIP: prebuilding using Swift packages
Pull Request resolved: https://github.com/facebook/react-native/pull/50766
Test Plan: This will be tested in a diff in the stack.
Reviewed By: cortinico
Differential Revision: D74386522
Pulled By: cipolleschi
fbshipit-source-id: 7bac3c21a362c4ef79d0104727cdd3494419012f
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/51167
Adding the ScrollView properties that are android specific to the common ScrollView props so that they can be diffed in a getDiffProps implementation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74327335
fbshipit-source-id: 8e5683d4bf7fe0f6d54d4b97f535731721c60292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51192
The `build-types` script cannot currently resolve `react-native/assets-registry` and `react-native/js-polyfills`. This diff moves imported types from these packages to `react-native` to include them in generated types.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74392568
fbshipit-source-id: cbce977b710f54dc53ce1b0fc080704b420490d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51096
**Problem:** `Activity.onBackPressed()` has been deprecated and with targetSdk 36, predictive back will be enforced and the API no longer called. We need to migrate to backward compatible AndroidX `OnBackPressedCallback`.
- https://developer.android.com/about/versions/16/behavior-changes-16#predictive-back.
**Solution:**
`OnBackPressedCallback` is registered conditionally only if it is `targetSdk` 36 or greater.
If the callback in enabled, `onBackPressed()` is not called and callback is used regardless of `android:enableOnBackInvokedCallback` property in <application> or <activity> set in AndroidManifest.xml.
As a workaround callback is manually calling existing `onBackPressed()`.
This is done rather than removing onBackPressed() completely and using only `OnBackPressedCallback` as we are not sure of the impact of removing the implementation entirely. Once we determine it is safe to do so then, we should remove the workaround and fully transition to `OnBackPressedCallback`
* I also surveyed child classes extending ReactActivity for overridden `onPressedBack()` usage and found only one usage which will be handled later.
NOTE: `ReactDelegate.onHostResume()` sets up the `DefaultHardwareBackBtnHandler` using `ReactActivity` (https://fburl.com/ul47tbeo) and will be called from JS `BackHanderl.exitApp` (https://fburl.com/code/a4l2pjsw). Calling `BackHanderl.exitApp` enables predictive back to work.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D74161428
fbshipit-source-id: 2e081ba6922b315e9d1746e83a41bab5277fa62e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51136
This diff attaches doc block to ProgressBarAndroid copied from the manual TS types.
Generated types result:
```ts
import * as React from "react";
import type $$IMPORT_TYPEOF_1$$ from "./ProgressBarAndroidNativeComponent";
type ProgressBarAndroidNativeComponentType = typeof $$IMPORT_TYPEOF_1$$;
import type { ProgressBarAndroidProps } from "./ProgressBarAndroidTypes";
export type { ProgressBarAndroidProps };
declare let ProgressBarAndroid: (props: Omit<ProgressBarAndroidProps, keyof {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}> & {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}) => React.ReactNode;
/**
* ProgressBarAndroid has been extracted from react-native core and will be removed in a future release.
* It can now be installed and imported from `react-native-community/progress-bar-android` instead of 'react-native'.
* see https://github.com/react-native-community/progress-bar-android
* deprecated
*/
declare const $$ProgressBarAndroid: typeof ProgressBarAndroid;
declare type $$ProgressBarAndroid = typeof $$ProgressBarAndroid;
export default $$ProgressBarAndroid;
```
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D73855212
fbshipit-source-id: c6c09ea68c9f61f305f96c0954370bb938fc59d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51135
In generated types default exported variables are re-declared which shadows attached tags and doc blocks. This transform moves necessary comments on top of re-declarations to keep them accessible.
Example output for SafeAreaView:
```ts
import type { ViewProps } from "../View/ViewPropTypes";
import View from "../View/View";
import * as React from "react";
declare const exported: (props: Omit<ViewProps, keyof {
ref?: React.Ref<React.ComponentRef<typeof View>>;
}> & {
ref?: React.Ref<React.ComponentRef<typeof View>>;
}) => React.ReactNode;
/**
* Renders nested content and automatically applies paddings reflect the portion
* of the view that is not covered by navigation bars, tab bars, toolbars, and
* other ancestor views.
*
* Moreover, and most importantly, Safe Area's paddings reflect physical
* limitation of the screen, such as rounded corners or camera notches (aka
* sensor housing area on iPhone X).
*/
declare const SafeAreaView_DEFAULT: typeof exported;
declare type SafeAreaView_DEFAULT = typeof SafeAreaView_DEFAULT;
export default SafeAreaView_DEFAULT;
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74249424
fbshipit-source-id: 5cdd1c746e7fed99e3d3427d6ebf4c0e7ba3f3fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51189
Changelog: [Internal]
Adds a Github action that validates that the typegen script can successfully translate every necessary Flow file to TypeScript.
Reviewed By: huntie
Differential Revision: D74390916
fbshipit-source-id: 8c6d554c8681a2b92a8b182244a329ee538d9e53
Summary:
Selectively disabling autolinking of a native dependency with components registered in the codegen configuration in react-native.config.js causes builds to crash upon launch on iOS. This is because the generated `RCTThirdPartyComponentsProvider.mm` file contains references to the excluded library using `NSClassFromString` causing the returned NSDictionary from `+[RCTThirdPartyComponentsProvider thirdPartyFabricComponents]` to be populated with nil values and therefore crashing the app. This has been confirmed in 0.78.2 and 0.79.2 but probably exists in 0.77.x as well.
The issue has been further described in https://github.com/facebook/react-native/issues/51077.
## Changelog:
[IOS][FIXED] - Skip codegen for selectively disabled libraries in react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/51078
Test Plan:
1. Install a library that has the componentProvider field set in the codegen config (see reproducer) and install the iOS pods.
2. Build the app.
3. App should run successfully without any crashes.
Reviewed By: cortinico
Differential Revision: D74248371
Pulled By: cipolleschi
fbshipit-source-id: 1ff7b477ed3d94ca45616ae243d3d2d30bd897db
Summary:
Follow up from https://github.com/facebook/react-native/issues/51061 – Static code analysis detected several redundant constructs across the codebase. Most of the ones fixed here are marked as warnings/weak warnings, likely code smells post-migration from Java.
Doing another small round to clean up some of them.
## Changelog:
[INTERNAL] - Kotlin: Clean up redundant constructs
Pull Request resolved: https://github.com/facebook/react-native/pull/51170
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: rshest
Differential Revision: D74381864
Pulled By: cortinico
fbshipit-source-id: 25244cdf384875f7cc4e2d091c8b247710de5ecf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51162
We specify the java target version to 17 for ReactAndroid but not for hermes-engine.
This is causing it to be the default (8) which will cause our build to fail on JDK 21.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D74325107
fbshipit-source-id: 39ba745be4fa754fb0b0408160202940a61fcd94
Summary:
Enables `DEFINES_MODULE` in `React-jsc.podspec`
After upgrading app to RN `0.79`, when installing pods with JSC enabled there is an error being thrown that
`The following Swift pods cannot yet be integrated as static libraries`
`The Swift pod 'RNFlashList' depends upon 'React-jsc', which does not define modules. ...`
when installing packages that use Swift
## Changelog:
[IOS] [CHANGED] - enable `DEFINES_MODULE` in `React-jsc.podspec`
Pull Request resolved: https://github.com/facebook/react-native/pull/51160
Test Plan: RNTester runs and builds correctly
Reviewed By: huntie
Differential Revision: D74325357
Pulled By: cipolleschi
fbshipit-source-id: b994b7e678633440d5e362ae6965b2d5188d34f1
Summary:
Switches to use the version imported through diff train for `eslint-plugin-react-hooks`. This should allow us to finally use component syntax in RN.
bypass-github-export-checks
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D74203162
fbshipit-source-id: d9ea17e5c6533e8df0889404a7f7798f6f5061c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51138
The co-opting logic failed to account fo the case where the entire text view as a link and therefore turns off ax. In this case I think it makes sense to re-focus that element again so the user can interact with the link.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D74262675
fbshipit-source-id: c8d11cdff76cd92170581d167d5a8df64d0dd101
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51155
changelog: [internal]
we have experienced breakages where we stopped propagating accessibility prop to the mounting layer. These tests should catch it.
Reviewed By: fabriziocucci
Differential Revision: D74317767
fbshipit-source-id: 72c6d8c788afe3a9d4d41f7cfc0aa37605b20b6a
Chi Tsai
generatedunixname89002005287564
Nick Gerleman
Mateo Guzmán
Pieter De Baets
Nicola Corti
Vitali Zaidman
Rubén Norte
Christian Falch
Yannick Loriot
Ramanpreet Nara
Ramanpreet Nara
Mark Verlingieri
Nick Lefever
Dawid Małecki
Alan Lee
Fabrizio Cucci
Jakub Piasecki
Alex Hunt
ismarbesic
React Native Bot
Kacper Rożniata
Intl Scheduler
Maddie Lord
Jan Kassens
Joe Vilches
Samuel Susla