Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47612
Changelog: [internal]
Just using babel-register so we can use Flow types in the code for the RN integration tests runner.
Reviewed By: sammy-SC
Differential Revision: D65948801
fbshipit-source-id: 6c54b0463fe4b71c818ff1c4faa973cc8b13b5d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47615
Changelog: [internal]
Fixes `.not` not being applied in some cases, and no logging the "not" label in case of error, and `.toBe` being flipped.
Reviewed By: javache
Differential Revision: D65952221
fbshipit-source-id: 030c0597b661d34e6324d69e5676375150a74f2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47624
Changelog:
[iOS][Fixed] - fix `r` & `d` not working from Metro sometimes
While investigating these bugs, I've come across some cases where `r` (Reload) & `d` (Open Dev Menu) not working in Metro.
* T206141946 / [WP: Reconnecting dev tools does not work after restarting the app](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1107620434125533)
* T206754760 / [WP: Can't launch DevTools from Metro sometimes](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1112235073664069/)
This is because when we
1. Start app without Metro
1. Start Metro
1. Reload from Dev Menu (rage shake)
`RCTPackagerConnection` did not get notified about the change in bundle URL. It'd stay "listening" to the commands from the local bundle instead of Metro
.
Reviewed By: robhogan
Differential Revision: D65973309
fbshipit-source-id: a67a58b405bb78dfe56b814f2ec0bbee9e530e46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47596
Improves the Flow type of `usePressability` so that if the `config` argument is non-nullable, the return value is non-nullable. This helps reduce unnecessary null checks.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D65908791
fbshipit-source-id: 77de4391d8141d698a5689e617b692b337d01ae5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47588
This is unnecessary - we can pass the params directly instead of first populating them in a Rect.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D65843834
fbshipit-source-id: 92bb3faa622bba81792fe92e357bc1667894d4ef
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
