Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40879
Introduce StableReactNativeAPI annotation, the goal of this annotation is to describe classes, interfaces and members that are considered Stable and will remain part of the new architecture of React Native
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D50195996
fbshipit-source-id: a64a27217a6fd885d2c188a6847565b3413bb232
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40860
This diff adds support for the `AS` expression in TS sources. The following codegen declaration should work now:
```
export default codegenNativeComponent<NativeProps>(
'MyComponentView',
) as HostComponent<NativeProps>;
```
Changelog: [General][Added] - Handle TSAsExpression when looking for the codegen declaration
Reviewed By: shwanton
Differential Revision: D50225241
fbshipit-source-id: 247a3d341d742b548e82318d0fa21dff9884d2bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40871
If we pass isPressable to the native props object (via TextAttributes), we can use this information to bypass hit testing on some spans. This is rather important on some platforms where pointerenter/pointerleave/ mousemove events force frequent hit testing.
## Changelog:
[General] [Internal]
Reviewed By: javache
Differential Revision: D50228473
fbshipit-source-id: 4fce85f4b18617fbe10d3c804e943484bf990664
Summary:
Adds changelog for the 0.71.14 version.
## 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
-->
[INTERNAL] [CHANGED] - Add 0.71.14 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/40863
Reviewed By: robhogan
Differential Revision: D50228147
Pulled By: huntie
fbshipit-source-id: cb6ad2abac53825a935205fb7646d8fa32ba8302
Summary:
The reference to runtime assumes the queue will ensure references to runtime are valid when invoked. This
isn't the case if you create a breakpoint, Hermes hit that breakpoint and your refresh the app. This consistently
will crash the app.
The fix is to not assument this, similar to ReactCommon/react/runtime/hermes/HermesInstance.cpp
Reviewed By: javache
Differential Revision: D50225678
fbshipit-source-id: b45cae1f5f687bc8c699fd74b187376a547012c5
Summary:
## Changelog:
[Internal] - Fix Nighlties that were broken due to changes for double publishing
Reviewed By: cortinico
Differential Revision: D50225219
fbshipit-source-id: dd1b96a956bb282caa40bd6f99b9a82554958746
Summary:
I'm removing the node >= 18 restriction on react-native/normalize-colors as that's unnecessary
as is currently breaking the ecosystem for users on Node 16 on previous versions of React Native.
Changelog:
[General] [Fixed] - normalize-colors should not impose node >= 18
Reviewed By: robhogan
Differential Revision: D50215144
fbshipit-source-id: cdfb90f4274754ad5b04fa2cad339419d45bbcba
Summary:
## Changelog:
[Internal] - Run all the tests in CI when not on a PR
Reviewed By: cortinico
Differential Revision: D50220596
fbshipit-source-id: be1a30d713e9d427858cf22bd3ca9549ad513057
Summary:
This is just a type refactoring to make the typing of the `defaultSource` prop of the Image component more explicit and descriptive (using the `ImageRequireSource` type makes it more clear that we can use the require statement to set an image asset as default source) and this is also more consistent with the `source` prop typing.
Currently :
- The typing of default source is `ImageURISource | number | undefined`
- The typing of source is `ImageSourcePropType` which is equal to `ImageURISource | ImageURISource[] | ImageRequireSource` and `ImageRequireSource` is equal to `number`.
In this PR we change the typing of default source to `ImageURISource | ImageRequireSource | undefined` to make more clear that the number of the default source prop refers to the use of the require statement with an asset file.
## Changelog:
[GENERAL] [CHANGED] - use ImageRequireSource instead of number for the defaultSource prop typing of the Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/40801
Test Plan: No one required since it's a small typing refactoring.
Reviewed By: christophpurrer
Differential Revision: D50209922
Pulled By: NickGerleman
fbshipit-source-id: c25f3c6f145f357ff1cb0b1c7b54a19bf1dec824
Summary:
It looks like objects properties aren't guaranteed to have a stable order. Sort them, before we serializae and print them to the screen in the interop test. This should reduce interop test flakyness.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D50148860
fbshipit-source-id: a6ed1433d4dd35cafa5c9f7d09c4cca194c31d81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40792
Similarly to D49792717, simplify the careful logic we have with CallbackWrapper and RCTBlockGuard and instead rely on bridging's `AsyncCallback` so safely handle jsi::Function for us.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49862756
fbshipit-source-id: 289f2d5ef622f47eb3fccf0cc7a52cc13a83b028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39952
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
Changelog: [General] Deprecated RAIICallbackWrapperDestroyer. Use AsyncCallback instead for safe jsi::Function memory ownership.
Reviewed By: RSNara
Differential Revision: D49792717
fbshipit-source-id: 9f2f3b00c71ad1b86427dee3749c6d98ef0f5678
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40794
I accidentally stumbled upon the `UIManager` object on JS side and realised it was being exported as `any`. So I've extracted the interface `UIManagerJSInterface` and applied where it seems to make sense, although, after chatting with javache it could be useful to further narrow down the interface given what's currently implemented by the `BridgelessUIManager`.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50137691
fbshipit-source-id: ccc746fa1dfbb3290e0b73dfa14c65833b238e07
Summary:
Currently, the template has a `buildToolsVersion = '34.0.0'` specified in the top level .gradle file but it's not currently using it.
This is causing the build to fallback to the default version provided by AGP which is 33.x
This is also causing the CI to download buildtools 34.0.0 as they're not in the container (causing network flakyness).
I'm also bumping the docker container to v12 as we bumped NDK 26 which is missing in the v11 container.
## Changelog:
[INTERNAL] [FIXED] - Make sure template is consuming the right buildToolsVersion
Pull Request resolved: https://github.com/facebook/react-native/pull/39956
Test Plan: CI should be green
Reviewed By: christophpurrer
Differential Revision: D50019777
Pulled By: cortinico
fbshipit-source-id: a2ab7a7bd7c55624d5c050b45e69086c5f25ba6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40767
Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```
Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage
Reviewed By: cortinico
Differential Revision: D50017783
fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1
Summary:
Currently, when we build the app in production mode the `DevtoolsOverlay` & `TraceUpdateOverlay` are bundle
## Changelog:
[GENERAL][REMOVED]: removed `DevtoolsOverlay` & `TraceUpdateOverlay` from production bundle
<!-- 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/40749
Test Plan:
1. Build the app in production mode
2. Check that both `DevtoolsOverlay` & `TraceUpdateOverlay` are included in the bundle
Reviewed By: robhogan, NickGerleman
Differential Revision: D50121208
Pulled By: hoxyq
fbshipit-source-id: 3e1fb506c679ec79b116dea9772d372cd2ea9ca9
Summary:
Commit 8b88883071 broke the Cache for RNTester because the cached version of the pods does not know about the exitence of SocketRocket 6.1.0
Bumping the keys should force a redownload of the cocoapods specs repo
## Changelog:
[Internal] - Bump RNTester cache keys
Pull Request resolved: https://github.com/facebook/react-native/pull/40789
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D50169281
Pulled By: cipolleschi
fbshipit-source-id: 83e251495bfa43d62384470efe97c5505d76684f
Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1
Original commit bumping SocketRocket -> https://github.com/facebook/react-native/commit/8ce471e2fa802cc50ff2d6ab346627cb5f6d79b4
## Changelog:
[IOS] [CHANGED] - Bump SocketRocket to 0.6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/40774
Test Plan: Run rntester locally
Reviewed By: cipolleschi
Differential Revision: D50137261
Pulled By: arushikesarwani94
fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39988
Changelog: [Internal]
in this pr, we integrate the sync void configuration with our feature flag infra
Reviewed By: luluwu2032
Differential Revision: D50030743
fbshipit-source-id: 03505e5e1f74aa90dc16f33fa4e93f9de9660dae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39989
Changelog: [Internal]
we need some configuration path to turn on the sync void method execution behavior, doing that here
Reviewed By: luluwu2032
Differential Revision: D50028200
fbshipit-source-id: a2501b622685e4bafa5e2a5031275cc8bc5050b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39970
Changelog: [Internal]
in this diff, i add the logic that makes void return values run synchronously
Reviewed By: javache
Differential Revision: D49613770
fbshipit-source-id: ef840fb3ee130430505d000a7cf74e094f9d1405
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40777
In this diff I'm removing the deprecation of NativeModule.onCatalystInstanceDestroy() method, changing it to DeprecatedInNewArchitecture
changelog: [Android][Breaking] Mark NativeModule.onCatalystInstanceDestroy() method as deprecated in new architecture
Reviewed By: christophpurrer
Differential Revision: D50141027
fbshipit-source-id: a4c4911bdadc27f981f3af0522317e6dd08d9344
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40775
In this diff I'm introducing the BaseReactPackage class to the public API of React Native Android. the goal is for this class to replace TurboReactPackage, which will be Deprecated in the New Architecture
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D50128456
fbshipit-source-id: a65e1eb0d81b94e442799226784f73f489eabb73
Summary:
X-link: https://github.com/facebook/hermes/pull/1151
Pull Request resolved: https://github.com/facebook/react-native/pull/40746
This feature was missing in JSC's JSI implementation, which is preventing from rolling out NativeState-based features in React Native.
Changelog: [General][Added] JSC support for the NativeState API in JSI
Reviewed By: neildhar
Differential Revision: D49229022
fbshipit-source-id: 1787c1d1b4803212d84da8f55b7d5a460a9d33c2
Summary:
Very simple change, there's a typo in the word "perspective" whilst naming the possible transform property types.
## Changelog:
[INTERNAL] [FIXED] - Fix typo in PerspectiveTransform type
Pull Request resolved: https://github.com/facebook/react-native/pull/40771
Test Plan: -
Reviewed By: javache
Differential Revision: D50133297
Pulled By: arushikesarwani94
fbshipit-source-id: bd742b1bccc5d015e5e8095b1d2b83765fee3d6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40751
In D48379915 I fixed inverted `contentOffset` in `onScroll` events on iOS. I thought I tested on Paper, but I think this was during a period where the Paper route in Catalyst was actually launching Fabric (oops).
In Paper, at least under `forceRTL` and English, `[UIApplication sharedApplication].userInterfaceLayoutDirection` is not set to RTL. We instead have a per-view `reactLayoutDirection` we should be reading.
This sort of thing isn't currently set on Fabric, which checks application-level RTL. This seems... not right with being able to set `direction` in a subtree context, but Android does the same thing, and that would take some greater changes.
Changelog:
[iOS][Fixed] - Fix iOS Paper Scroll Event RTL check
Reviewed By: luluwu2032
Differential Revision: D50098310
fbshipit-source-id: e321fca7b2f7983e903e23237bc2d604c72f98a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39646
We can dramatically simplify this code and remove quirks/hacks, now that we can assume layout events are always fired top down.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D49628669
fbshipit-source-id: 7de5bbc4597eba1c59aaa7672c70e76d2786c7ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40748
The ordering of `onLayout` events is non-deterministic on iOS Paper, due to nodes being added to an `NSHashTable` before iteration, instead of an ordered collection.
We don't do any lookups on the collection, so I think this was chosen over `NSMutableArray` for the sake of `[NSHashTable weakObjectsHashTable]`, to avoid retain/release. Using a collection which does retain/release seems to cause a crash due to double release or similar, so those semantics seem intentional (though I'm not super familiar with the model here).
We can replicate the memory semantics with ordering by using `NSPointerArray` (which is unfortunately not parameterized). This change does that, so we get consistently top-down layout events (matching Fabric, and Android Paper as of D49627996). This lets us use multiple layout events to calculate right/bottom edge insets deterministically.
Changelog:
[iOS][Changed] - Deterministic onLayout event ordering for iOS Paper
Reviewed By: luluwu2032
Differential Revision: D50093411
fbshipit-source-id: f6a9d5c973b97aede879baa8b952cc1be2447f28
