Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47595
Enables the `useInsertionEffectsForAnimations` feature flag by default. This changes `useAnimatedProps` to enqueue updates to the `AnimatedNode` graph in `useInsertionEffect` instead of `useLayoutEffect`.
The main motivation for `useInsertionEffect` is to avoid unmounting `AnimatedNode` graphs when an `Activity` subtree becomes hidden.
Both `useInsertionEffect` and `useLayoutEffect` occur during the commit phase. Although they occur at different moments in the commit phase, the different is difficult to observe and unlikely to impact product code.
One observable impact is that with `useInsertionEffect`, animations can now be started from layout effects.
Changelog:
[General][Changed] - The `AnimatedNode` graph will not occur during the insertion effect phase, which means animations can now be reliably started during layout effects.
Reviewed By: mdvacca
Differential Revision: D65906157
fbshipit-source-id: d09b2f1b76079eecafbed8c6f5d8ee4695a1f81c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47551
## Summary
I'm working to get the main `react-native` package parsable by modern
Flow tooling (both `flow-bundler`, `flow-api-translator`), and one
blocker is legacy `module.exports` syntax. This diff updates files which
are [synced to
`react-native`](https://github.com/facebook/react-native/tree/main/packages/react-native/Libraries/Renderer/shims)
from this repo.
## How did you test this change?
Files were pasted into `react-native-github` under fbsource, where Flow
validates ✅.
DiffTrain build for [5c56b873efb300b4d1afc4ba6f16acf17e4e5800](5c56b873ef)
Test Plan: Sandcastle tests
Reviewed By: sammy-SC
Differential Revision: D65672576
Pulled By: huntie
fbshipit-source-id: 3d1f2eee0a4872d6a167cbc10e9f022e20f2bdc3
Summary:
This PR adds support for negative values in enums.
Currently when we try to use an enum with negative value:
```ts
enum MyEnum {
ZERO = 0,
POSITIVE = 1,
NEGATIVE = -1,
}
export interface Spec extends TurboModule {
useArg(arg: MyEnum): void;
}
export default TurboModuleRegistry.get<Spec>('Foo');
```
It will fail:
```
Enum values can not be mixed. They all must be either blank, number, or string values.
```
This is because negative values are parsed as `UnaryExpressions` which have `-` operator in front and value as argument.
With the new approach codegen properly generates enums with negative values.
## Changelog:
[GENERAL] [ADDED] - Codegen: Support negative values in enums
Pull Request resolved: https://github.com/facebook/react-native/pull/47452
Test Plan: I've added tests to see if everything is working properly
Reviewed By: vzaidman
Differential Revision: D65887888
Pulled By: elicwhite
fbshipit-source-id: edb25f663dc58afa68c69cb84a47cfc67fc1f7e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47577
Changelog: [Android][Fixed] ensure setSelection in onAttachedToWindow is within text range
Reviewed By: javache
Differential Revision: D65824906
fbshipit-source-id: 3dc7d27bf4f9a10762f11fa4a0bcae8af13c7db7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47585
We have two classes named ReactFontManager and during the Kotlin migration this got mixed up.
Changelog: [Android][Fixed] Fixed crash in legacy ReactFontManager
Reviewed By: fabriziocucci
Differential Revision: D65877606
fbshipit-source-id: d9dc4f29045ad377adb216216334af5501c5546e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47567
Changelog: [Android][Changed] Invocations to JS will now invoke their callbacks immediately if the instance is ready. Surface starts will not wait for the main thread to become available to dispatch the work in JS.
Reviewed By: rshest
Differential Revision: D65661888
fbshipit-source-id: c67802bd56fac6bc6c145b96d823274e2b97de69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47566
Changelog: [Android][Changed] TurboModules marked as requiring eager init will now be constructed on the mqt_native thread to increase concurrency in React Native init.
Reviewed By: rshest
Differential Revision: D65661887
fbshipit-source-id: c1863ea44771de5caedc2968a325abcc7022c792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47579
BridgeReactContext is public only for testing. I'm annotating it with VisibileForTesting to make it explicit
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D65705093
fbshipit-source-id: d4d7c4195926e2d0397e805b4c49b0710a82a7eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47565
Changelog: [internal]
We unified the feature flags for the event loop in https://github.com/facebook/react-native/pull/47084, but we left the legacy flags defined for temporary backwards compatibility.
We don't need that anymore, so we can clean them up.
Reviewed By: fabriziocucci
Differential Revision: D65606068
fbshipit-source-id: 403c278cef2afc8eddf07592d88cadc58765f660
Summary:
This PR follows up on https://github.com/facebook/react-native/issues/47182 and https://github.com/facebook/react-native/issues/47348 by adding `force-cache`, the final missing option to align caching controls with the existing behavior on iOS.
Local caching behavior remains unchanged: if a cached image is available locally, it will be returned; otherwise, a network request will be made.
When an image request is sent over the network, the `force-cache` option sent from the sent fJS side will now use the `okhttp3.CacheControl.FORCE_CACHE` directive.
## Changelog:
[ANDROID] [ADDED] - Image `force-cache` caching control option
Pull Request resolved: https://github.com/facebook/react-native/pull/47426
Test Plan:
New example added to the RNTester under the cache policy examples. Then inspecting that the cache control is set correctly before sending it in the `okhttp3.Request` builder.
```kt
FLog.w("ReactNative", "fetching uri: %s, with cacheControl: %s", uri, cacheControlBuilder.build().toString())
// fetching uri: https:...png?cacheBust=force-cache, with cacheControl: no-store, max-stale=2147483647, only-if-cached
```
This case was a bit more tricky to test in terms of e2e as it would involve some caching in the server as well, I'm open to suggestions to make this more complete.
Reviewed By: javache
Differential Revision: D65490360
Pulled By: Abbondanzo
fbshipit-source-id: f807a9793f85caea39c59a370d057b9a1d450a78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47520
Right now, when a 3p library needs to register a component in the component system, we have to crawl the library to try and get the mappng, best effort.
With this approach, we are enriching the `codegenConfig` property to allow library developers to define the mapping themselves.
For example:
```json
//...
"codegenConfig": {
//..
"ios": {
"componentProvider": {
"RNTMyNativeView": "RNTMyNativeViewComponentView"
}
}
},
```
means that the JS component `RNTMyNativeView` will be mapped to the `RNTMyNativeViewComponentView` class.
This also work for local apps, and it warns the users about what libraries are using the deprecated approach, so they can open an issue or a PR to those libraries.
## Changelog:
[iOS][Added] - Allow 3p developers to specify the association between components and classes in Fabric
Reviewed By: dmytrorykun
Differential Revision: D65666061
fbshipit-source-id: 692e753635873ff9260e131d2d18ed226b2378c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47518
This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns.
1. We are generating it in the user space, not in the node_modules (fixes the circular dependency)
2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation
The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation.
The assumption is that components have a function in their `.mm` file with this shape:
```objc
Class<RCTComponentViewProtocol> <componentName>Cls(void)
{
return <ComponentViewClass>.class;
}
```
I verified on GH that all the libraries out there follow this pattern.
A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`.
We will implement that as the next step and we will support both for some versions for backward compatibility.
## Changelog
[iOS][Changed] - Change how components automatically register
Reviewed By: dmytrorykun
Differential Revision: D65614347
fbshipit-source-id: a378b8bc31c1ab3d49552f2f6a4c86c3b578746b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47517
The `RCTThirdPartyLibraryComponentProvider` has been introduced to automate the component registration of third party libraries in the apps. However, it has some serious flaws:
* It is generated in the React/Fabric folder, which means that it is generated in node_modules
* It is generated when the user installs the components in the app, which means that we can't prebuild and redistribute React Native as a binary
* it does not work with Frameworks and dynamic linking: in this scenarion, Fabric must build in isolation and if there are third party libraries involved, the lookup of the `xxxCls` function will fail
This change removes the generation of the `RCTThirdPartyLibraryComponentProvider`. In the next diffs we will implement a different mechanism to register components
## Changelog
[iOS][Changed] - Stop generating the RCTThirdPartyLibraryComponentProvider
Reviewed By: dmytrorykun
Differential Revision: D65601939
fbshipit-source-id: 9cc8c46102827d124b93b8aa6705b5e6014695c1
Summary:
Resolve warning on ios build:
```
.../ios/Pods/Headers/Public/React-Core/React/RCTAppearance.h:16:60 A function declaration without a prototype is deprecated in all versions of C
```
## 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
-->
[IOS] [FIXED] - Resolve deprecated function prototype warning in RCTAppearance.h
Pull Request resolved: https://github.com/facebook/react-native/pull/47564
Test Plan:
Jest Result (`yarn test`):
```
Test Suites: 234 passed, 234 total
Tests: 2 skipped, 4899 passed, 4901 total
Snapshots: 1687 passed, 1687 total
Time: 46.387 s
Ran all test suites.
```
Reviewed By: cipolleschi
Differential Revision: D65816584
Pulled By: javache
fbshipit-source-id: 212021c39dfde7e638752940e67a9f964d2194ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47531
When the activity is paused, or destroyed, we should disable the devsupportmanager. (This performs cleanup).
When the activity is resumed, we should re-enable devsupportmanager. (This performs re-initialization).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65689053
fbshipit-source-id: 99de0906b8cdc84f56b4d334ac0eeecc7b436dd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47528
After the js pipeline fails to handle the error, reset the hasHandledFatalError var.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65678387
fbshipit-source-id: ac7cd4724954ea78bf33542e208c5f5d3dba5383
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47529
RuntimeExecutor, RuntimeScheduler, etc. can execute arbitrary c++ on the javascript thread.
If that c++ throws a non-jsi::JSError, it will bypass the js error handler (and start tearing down the react instance 😱).
Let's have the js error handler manage all exceptions raised while native is calling into js. This is more sane.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D64626610
fbshipit-source-id: 40132f24b4e2737ae3f055fbd09153111404e5bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47468
Across our scroll view implementations on iOS, we fire `onMomentumScrollEnd` whenever the scroll view finishes decelerating, whether it comes from a user's touch or call to `setContentOffset` with animations. But we omit dispatching the `onMomentumScrollBegin` event in the latter cases.
This change updates both old and new architecture to dispatch `onMomentumScrollBegin` when a view-command-driven scroll occurs with animation, like `scrollTo` or `scrollToEnd`.
Changelog:
[iOS][Fixed] - Fixed `onMomentumScrollBegin` event not firing on command-driven scroll events
Reviewed By: javache
Differential Revision: D65556000
fbshipit-source-id: bc4b778c63d8a032e1d8e00b9d4d5f83a5d651d6
Summary:
Follow up from https://github.com/facebook/react-native/issues/47433, adding some missing scenarios in the unit tests for the image component in Android.
## Changelog:
[INTERNAL] [ADDED] - Improving Android `ImageResizeMode` unit tests
Pull Request resolved: https://github.com/facebook/react-native/pull/47527
Test Plan:
```bash
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D65735794
Pulled By: Abbondanzo
fbshipit-source-id: a420274c78d9eadf0439870cfaae4d16247c6034
Summary:
On android the isGrayScaleEnabled method of AccessibilityInfo always returns false due to missing implementation. This PR fills the gap by providing the native module logic for checking grayscale mode.
## Changelog:
- Added native module code to check for grayscale mode on android
- Updated js accessibility info module to return the correct promise instead of default false for isGrayScaleEnabled()
- Moved the test for isGrayScaleEnabled() out of ios scope to common Android and iOS scope
[ANDROID] [ADDED] - logic to check for grayscale mode on android
Pull Request resolved: https://github.com/facebook/react-native/pull/47497
Test Plan:
Tested on :
- Google Pixel 7 Pro (Android 14)
- OnePlus 12 (Android 14)
- Pixel 6 (Android 15)
Reviewed By: cortinico
Differential Revision: D65662583
Pulled By: javache
fbshipit-source-id: 39f9ce37c9375b5380257847395393045eedbadc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47494
Changelog: [General][Changed] AttributedString `appendFragment` and `prependFragment` take an rval instead of a const ref; append/prependAttributedString have been removed
Reviewed By: mdvacca
Differential Revision: D65603864
fbshipit-source-id: 1160a9e2064470f826bea66736b4fce13caa3a73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47543
TaskCompletionSource is public but it shouldn't, in this diff I'm making it intenral
changelog: [Android][Breaking] Reduce visibility of TaskCompletionSource class
Reviewed By: javache
Differential Revision: D65738324
fbshipit-source-id: 61db35a408162c53398b20e45a52f3eb46de1eae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47540
Continuation is only used inside RN, we should make it internal
changelog: [Android][Changed] Reduce visibility of Continuation to internal, although this interface wasn't being exposed in any public API
Reviewed By: javache
Differential Revision: D65738329
fbshipit-source-id: 6fb1b9e9a253eafad0f6eb1e4c1363d6254846da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47548
changelog: [internal]
This race condition only shows itself with flag `useOptimizedEventBatchingOnAndroid`
# Problem
EventBeat assumes method `induce` will be called repeatedly on every UI tick. This is true for iOS and existing implementation of event beat on Android. The first early exist inside of `induce` method is built with this assumption.
`useOptimizedEventBatchingOnAndroid` on Android changes this. `induce` will only be called after FabricUIManager.onRequestEventBeat is invoked and then it will stop. For one `FabricUIManager.onRequestEventBeat` call, `EventBeat::induce` is called once. And there is a chance for race condition.
Here is a simplified implementation of `induce`. This method may be called many times in sequence. The caller will set [isRequested_](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/renderer/core/EventBeat.cpp#L25) and then invoke [FabricUIManager.onRequestEventBeat](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/jni/react/fabric/AndroidEventBeat.cpp#L43). Notice how `FabricUIManager.onRequestEventBeat` is debounced if `isRequested_` flag is true.
```
void EventBeat::induce() const {
if (!isRequested_ || isBeatCallbackScheduled_) {
// isRequested_ is not set to false in case isBeatCallbackScheduled_) is true.
return;
}
isRequested_ = false;
isBeatCallbackScheduled_ = true;
auto beat = std::function<void(jsi::Runtime&)>(
// on JS queue
isBeatCallbackScheduled_ = false;
// beatCallback_(runtime)
}
runtimeScheduler_.scheduleWork(std::move(beat));
}
```
This can get into a state where `isRequested_` is not reset back to false even though `EventBeat::induce` is called when `isBeatCallbackScheduled_` is true.
`AndroidEventBeat::request` -> `isRequested_` is set to true -> `FabricUIManager::onRequestEventBeat` -> `EventBeat::induce` -> `isRequested_` is set to false -> `isBeatCallbackScheduled_` is set to true -> `AndroidEventBeat::request` -> `FabricUIManager::onRequestEventBeat` -> `EventBeat::induce` (early exit because `isBeatCallbackScheduled_` is true) -> `beat` is executed on the JS thread.
From this point on, subsequent calls to `AndroidEventBeat::request` are always debounced because flag `isRequested_` is true.
Any subsequent event on Android will end up calling `EventBeat::induce` and the mechanism gets unstuck.
# The fix
The fix is simple, any time `EventBeat::induce` is called, make sure `request_` flag is set to false. This then satisfied the expectation of `useOptimizedEventBatchingOnAndroid` optimisation.
Reviewed By: rubennorte
Differential Revision: D65566258
fbshipit-source-id: 5f15da8f5cb722b329f9f72b9ddca8e2cac04144
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47547
In [#47176](https://github.com/facebook/react-native/pull/47176) we disabled the generation of the component registration for app specific components as it was creating a circular dependency between the app and React Native.
However, we made a couple of typos that make it not work as expected and users picked up those typos soon.
This change fixes them for good.
## Changelog
[iOS][Fixed] - Properly stop generating component registration for components defined in app.
Reviewed By: blakef
Differential Revision: D65750433
fbshipit-source-id: 1a879c5be014905558b9fd05e6f16ac36b784ed6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47534
This diff is introducing a new method to destroy React instance that allows the caller to be notified when the destroy finishes
This is necessary for apps to act upon destroy of the react instance
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D65721107
fbshipit-source-id: 2d3d9755db38461ba381b86c72df5869c542379b
