Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50214
This diff is a second step toward the TS AnimatedProps alignment. In this change the rest of the extended types and recursions in `WithAnimatedValue` are applied.
Changelog:
[Internal] - Aligned AnimateProps to match TS types.
Reviewed By: huntie
Differential Revision: D71623036
fbshipit-source-id: d4777e25c3bf3119608938ee4cd246cdc4c4f7ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50195
In Flow, all AnimatedProps properties are set to `any` and misaligned with Typescript definitions. This diff is a first step toward the TS AnimatedProps. The problem can be broken down into a few parts, at each point more types will be extended in WithAnimatedValue and the rest will be set to `any`. This approach enables smoother migration and validation.
Changelog:
[Internal] - Check for Builtin and Nullable types in WithAnimatedValue to align closer to TS types.
Reviewed By: huntie
Differential Revision: D71551006
fbshipit-source-id: 9316227f4ba32bdaa5be8097483a03ae19bf516f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50221
This was already rolled out by default previously, but we wanted to complete further testing internally before cleaning up the flag.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D71735311
fbshipit-source-id: b9d32787081fbe3d7fb740067d3709624028fa23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50223
This is an implementation detail of React and better not make it leak everywhere. It's not used quite often even in react-native codebase, so it's better to just suppress the error on each call site. Currently it's typed as any, so there is not much type safety lost anyways.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D71687426
fbshipit-source-id: 7373bcd9bedcfcb95a10fa02e6a04399ccab91f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50216
Call TouchesHelper directly from TouchEvent and remove the need for `RCTModernEventEmitter.receiveTouches`. This enables `Animated.Event` to process these events too, since they are now being delivered just like any other event.
Changelog:
[Android][Fixed] Enables Animated.Event to be used with onTouchMove in the new architecture.
[Android][Removed] Removed deprecated EventDispatcher#receiveTouches
Reviewed By: Abbondanzo
Differential Revision: D71114177
fbshipit-source-id: 61ca43ef5334b5514c4980a05b61b674d9a52c5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50231
Changelog: [Internal]
RCTDeviceInfo uses KVO to listen to frame changes in the application's keyWindow. On initialization, it reads the global keyWindow and adds itself as a listener. When RCTDeviceInfo is cleaned up, it reads the global keyWindow again, and removes itself as an observer.
However, this makes an assumption that the keyWindow is always the same. This is not always true - for example, when a UIAlert is presented, the OS creates a new temporary keyWindow to host the alert in order to make sure it is the first responder. If the cleanup is called then, the app will crash because there is no RCTDeviceInfo observing it. Another example is the LogBox, which also temporarily creates a new keyWindow.
The fix is simple, we can capture a reference to the application's keyWindow on initialization, but make sure it is weakly held as the keyWindow is usually managed by iOS. Then, when we remove the listener, it is always guaranteed it is the window that we are observing.
Reviewed By: javache, cipolleschi, realsoelynn
Differential Revision: D71667722
fbshipit-source-id: 103baf980b79b413fb29e6c3deff81dae33671c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50218
These were added in D70129295 to BaseViewManager but did not exist in the JS interface.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D71737288
fbshipit-source-id: 751d26fb9116daf45d09f3853fe37cad29a8903a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49982
In D68708899, we removed dataURI inlining of sources and source maps into `Debugger.scriptParsed` CDP notifications.
After that, all message handling for which we need to preserve order is implemented completely synchronously, so there's no need for a promise queue to preserve order.
This removes the redundant queue.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D71036230
fbshipit-source-id: d17fb7d06a038b379fe45b4e1c742dbf8ff12f78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50036
This is my friday round of fixing some warnings in our codebase.
Those are all minor bits that should be fixed.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D71209124
fbshipit-source-id: 40aa231e049025bbff9dff8a572784bb1a9f324b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50187
D70668516 broke some SSTs, where asset that previously was black, showed up as clear.
I was assuming that was because we fixed a separate bug where assets could erroneously show as black layer, but these tests were actually just using a black asset.
Real bug here, is that the change led to only setting image when we have a displayLink, ie showing on screen, where before, we set image (implicitly at first frame) as layer content.
This change fixes that behavior, so first frame is rendered as part of off-screen view rendering, for images considered animatable.
Changelog:
[iOS][Fixed] - Fix animated images missing from offscreen render
Reviewed By: cipolleschi
Differential Revision: D71590856
fbshipit-source-id: f5da690b27f2da0f6979f25ece031ff0d418cca6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50193
This fix makes sure that we convert to JSException only NSException thrwn by sync methods.
Currently, nothing in the stack will be capable of understanding that js error if it is triggered by an exception raised by an asyc method.
See https://github.com/reactwg/react-native-new-architecture/discussions/276 for further details
We need to cherry pick this in 0.78 and 0.79
## Changelog:
[iOS][Fixed] - Make sure the TM infra does not crash on NSException when triggered by async method
Reviewed By: fabriziocucci
Differential Revision: D71619229
fbshipit-source-id: b87aef5dd2720a2641c8da0904da651866370dc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50175
This change logs warning in the RN Dev Tools and in the Xcode console when a legacy module is used through the interop layer.
The `moduleName.methodName` warning is logged only once per usage not to flood the users with Warnings.
## Changelog:
[iOS][Added] - Add warnings when a legacy module is used in the Interop Layer.
Reviewed By: cortinico
Differential Revision: D71561348
fbshipit-source-id: f3ec830ddb07c4d0ab34534ad2baf95e75b1a3b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49897
This change introduces the first warning for the New Architecture warning.
When modules are registered through the RCT_EXPORT_MODULE (or its variants) a warning is emitted.
Note: currently it is only emitted on the Xcode console.
I'm looking into ways to emit it also in the RN DevTools console.
## Changelog:
[iOS][Added] - Show warnings in the New Architecture when modules are loaded using RCT_EXPORT_MODULE
Reviewed By: cortinico
Differential Revision: D70789672
fbshipit-source-id: 06cb6cafbe7f65142a92d2e1ab9bc4ff59d0312a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50194
Changelog: [internal]
Just a small improvement of the diagram to make it more symmetrical and expand on what parts of the system are used within the rest of the RN repo.
Reviewed By: javache
Differential Revision: D71620577
fbshipit-source-id: 6b9398f416fd529eea192e82cad844212278492c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50192
Third party libraries depend transitively agains the React-renderercss modules because it is imported by Fabric.
Without this change, the use_frameworks on iOS does not works when a 3P library is imported.
This changes fix the behavior and we need to cherry pick them in 0.79.
## Changelog:
[iOS][Fixed] - Make sure 3p libraries depends on React-renderercss to work with use_frameworks
Reviewed By: fabriziocucci
Differential Revision: D71618395
fbshipit-source-id: 70c12dcbeb2dfa5fd7513c27d5c069a1f3c95966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50170
This is needed in D71470038 and later, where submodules of `jsinspector-modern` need to operate with CDP message payloads. We functionally split out these files as a library to avaoid a dependency cycle.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D71551561
fbshipit-source-id: 527479399d7563883c1b6599f884b7857e79bd77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49824
The way this works is each element on the list of `accessibilityElements` says that each element should go before the next element in its list. For example:
Imagine the default focus order:
```
[A, B, C, D, E]
```
If I set `accessibilityElements` to be:
```
[E, D, C, B, A]
```
That's just re ordering the focus order to be reversed, but what happens if I miss elements?
If I set `accessibilityElements` to be:
```
[D, B]
- D should go before B
```
Then my resulting order will be:
```
[A, D, B, C, E]
```
Because we follow the default order, then we find `B` but `D` should go before `B` so we first go to `D` and then finally go back to `B` and then continue our default order
This algorithm works with nested elements and it doesn't need to be exhaustive
We are also borrowing the concepts of Containers and elements from iOS.
We will disable views according to iOS logic to facilitate code shareability
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D70129295
fbshipit-source-id: 5ada03c7e5eb71a7b0a9d205296c2fa4366a3643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50080
I'm renaming ReactNativeFeatureFlagsProviderHolder -> ReactNativeFeatureFlagsJavaProvider to make naming consistent with documentation and remove the concept of "Holder" which is not part of the original design
changelog: [internal] internal
Reviewed By: rubennorte
Differential Revision: D71333170
fbshipit-source-id: be89c3aafe5d9b1c9699aff224c7c8511bdf9327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50180
Prepare for the change that makes `React.ComponentType` an alias of `component(...Props)`, which comes with stricter checking and making the props automatically readonly.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D71566900
fbshipit-source-id: cefcc10fda9a9777532f25b325412b0d50ebb9b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50106
## Changelog:
[General] [Added] - Create TurboModuleWithJSIBindings interface
So c++ TurboModules can initialize some private members with reference to `jsi::Runtime`
Reviewed By: lenaic
Differential Revision: D71396842
fbshipit-source-id: 59d32e4cbf2c5081912a4c828acc66ceb8702855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50158
Compile-out UIManagerModule from FpsDebugFrameCallback
The setViewHierarchyUpdateDebugListener does not exists on Bridgeless and NotThreadSafeViewHierarchyUpdateDebugListener is deprecated and marked for deletion on the new architecture.
The new architecture exposes a different API called ItemDispatchListener that's a sort of replacement for NotThreadSafeViewHierarchyUpdateDebugListener. Although it's not the same.
FpsView is broken in old/new arch and needs to be rebuild, I believe this behavior needs to be rethinked in the future. For now I'm excluding usages of NotThreadSafeViewHierarchyUpdateDebugListener and setViewHierarchyUpdateDebugListener for apps running on the new arch enabled by default.
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D71050642
fbshipit-source-id: 662deb064ffc2322b560618fac3203ab4e86c277
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50164
Based on analysis this method is only used by legacy architecture, this diff adds an assert if NativeModuleRegistry.onBatchComplete() is used in new architecture
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D71050638
fbshipit-source-id: 7a9791230880d2431e6b136735653a8ab4c34d7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50160
In this diff we are removing UIManagerModule from NativeAnimatedModule
This code wasn't executing when fabric is enabled, with this change the code that references UIManagerModule will be stripped out
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D71050641
fbshipit-source-id: fbedd5b9e1a9efb45c2fb7558d97fc639897c28c
CodemodService Bot
Dawid Małecki
Pieter De Baets
Sam Zhou
Yurii Nakonechnyi
Phillip Pan
Mateo Guzmán
Vitali Zaidman
Nicola Corti
Jakub Piasecki
Nick Gerleman
Riccardo Cipolleschi
Rubén Norte
Alex Hunt
Jorge Cabiedes Acosta
Ramanpreet Nara
David Vacca
Zeya Peng