Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43068
This diff adds `react-native-test-library` package.
It contains native module and native component example, and targets both the new and the old architecture. It has structure similar to many OSS React Native libraries, and is supposed to be used to test the integration with third-party libraries.
It is integrated with RNTester as the **OSS Library Example** screen.
{F1457510909}
**Change Background** tests native commands.
**Set Opacity** tests native props.
**Get Random Number** tests native module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D50793835
fbshipit-source-id: ff6daefab10e6e9f13049e3013f8f63cfa8a929e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43995
With a previous change, we started taking snapshots of the Modal every time a Fabric mounting event was happening. this might cause perf regression when a modal is presented, and there is no need to take a snapshot that often.
This change moves the snapshotting code right before the dismissal of the Modal.
## Changelog
[iOS][Changed] - Move the snapshotting code before the dismissal.
## Facebook
This should fix T179288585, T184520225
Differential Revision: D55914776
fbshipit-source-id: 6679babf7f72aef7254113497116d5482640e789
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43999
Currently NewArch-BridgeMode is partially broken when creating views via `ReactDelegate`.
That's because we're using the ctor that doesn't account for `Boolean: fabricEnabled`.
That means that the `RootView` that it will be created are all having setIsFabric(FALSE).
This is causing problems like whitescreens on several reload + multiple warnings such as:
```
E com.facebook.react.bridge.ReactNoCrashSoftException: Cannot get UIManager because the context doesn't contain an active CatalystInstance.
```
Fixes#43692
See for more context on this issues: https://github.com/facebook/react-native/issues/43692
Changelog:
[Android] [Fixed] - Fix bridge mode by constructing ReactDelegate correctly
Reviewed By: cipolleschi
Differential Revision: D55921078
fbshipit-source-id: 2c21d089a49538402d546177bcdb26c8d7d5fbc1
Summary:
This current consists of a bunch of TypeScript code, which will be ported to Flow in the stack.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55741526
fbshipit-source-id: 1dc30d2ab63e0526dd6fed17ccf7cce9f57bdbee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43994
We received [this issue](https://github.com/facebook/react-native/issues/43764) from OSS where an app can't connect to Metro on reloads in the following scenario:
* Start the App when metro does not run.
* Observe the error screen
* Start Metro
* Press Reload
* Observe the error message again
While the desired behavior should be to connect to Metro now that this is running.
The root cause of the problem is that the RCTHost is initialized with a value of the `bundleURL` that is `nil`. Upon reload, the RCTHost is **not** recreated: the instance is restarted, but with the previous `bundleURL`, which is still `nil`.
The solution is to initialize the `RCTHost` with a closure that re-evaluate the `bundleURL` whenever it is invoked and to evaluate it only on `start`, to keep the initialization path light.
This way, when the app is started with Metro not running, the `bundleURL` is `nil`. But when it is reloaded with Metro starting, the `bundleURL` is properly initialized.
Note that the changes in this diff are not breaking as I reimplemented (and deprecated) the old initializer so that they should work in the same way.
## Changelog:
[iOS][Fixed] - Let RCTHost be initialized with a function to provide the `bundleURL` so that it can connect to metro on Reload when the url changes.
Reviewed By: dmytrorykun
Differential Revision: D55916135
fbshipit-source-id: 6927b2154870245f28f42d26bd0209b28c9518f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43963
changelog: [internal]
This experiment did work out. Let's clean it up
Reviewed By: cortinico
Differential Revision: D55797519
fbshipit-source-id: a5da97a7d31b9395b25bfd37db567054721599b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43971
It turns out that we forgot to add a listener for the orientation change event in Bridgeless.
We used to have `UIApplicationDidChangeStatusBarOrientationNotification` but this is slightly unreliable because there might be use cases where the status bar has been hidden and, therefore, the event is not triggered.
This should fix an issue reported by OSS.
## Changelog:
[iOS][Fixed] - Make sure that the New Architecture listens to orientation change events.
Reviewed By: cortinico
Differential Revision: D55871599
fbshipit-source-id: c9b0634ec2126aa7a6488c2c56c87a9610fa1adf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43852
Changelog: [internal]
Just a small refactor so we rely less on shared pointers within `RuntimeSCheduler_Modern`.
Reviewed By: javache
Differential Revision: D55646389
fbshipit-source-id: d01dcba7b1551d349d21717ba585828ed7fb3259
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43853
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the logic to report the timing of events to a separate class (outside `PerformanceEntryReporter` that now is agnostic to the rendering infra).
Reviewed By: sammy-SC
Differential Revision: D55646392
fbshipit-source-id: 5032a36b23d0741b19fb74cb04f0af3d3d476ef0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43854
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the `PerformanceEntryReporter` and related classes to their own target in `ReactCommon/react/performance/timeline` that's not coupled with any rendering logic.
Reviewed By: sammy-SC
Differential Revision: D55646391
fbshipit-source-id: a759ed39c893a0bc14246c7ee608b1727e6ee4cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43849
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This refactors `PerformanceEntryReporter` to make the class not depend on the native module that uses it. Instead of using the `RawPerformanceEntry` type from the native module, we define `PerformanceEntry` in `PerformanceEntryReporter` and use it as the source of truth in the native module instead.
Thanks to the bridging template sytem we have, we can convert the raw objects passed from JS to the C++ structs, defining how the enums are converted from and to JS.
Reviewed By: sammy-SC
Differential Revision: D55646394
fbshipit-source-id: 9cf5a7db6ecb221ca08320d0aaae7e7bc8d91804
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43848
Changelog: [internal]
This makes it easier to see the behavior of the new Event Timing API in RN.
Reviewed By: sammy-SC
Differential Revision: D55646393
fbshipit-source-id: 441fed789a980211783f04095303a139e7b08483
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43847
Changelog: [internal]
(This is an internal change because the API hasn't been released in OSS yet)
This fixes 2 problems in how we dispatch `PerformanceObserver` notifications:
1. If an observer callback throws an error, the remaining observers don't receive notifications.
2. We're notifying observers with an empty list of events when they don't match the filters.
Reviewed By: javache
Differential Revision: D55646390
fbshipit-source-id: 6511c7babd45517baf42076308268ea89afe1265
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43993
changelog: [internal]
clean up tests. The logic is exactly the same, just renaming few variables and deleting unused ones.
Reviewed By: javache
Differential Revision: D55689499
fbshipit-source-id: fffef1051798f1787210cced5e681fa3fe47842b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43985
This is just personal preference.
The name "OnJsError" makes the intent of the abstraction clear: an instance of OnJsError is a function that gets called when a js error is caught.
The name "JsErrorHandlingFunc" is not as good.
Changelog: [General][Breaking] - JsErrorHandler: Rename JsErrorHandlingFunc to OnJsError
Reviewed By: christophpurrer
Differential Revision: D55563580
fbshipit-source-id: 4d20bc984e6633aeac6193b9276a88d76961df2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43957
Right now, JsErrorHandler is only used to handle fatal exceptions.
So, let's just scope handleJsError down to handleFatalError.
Changelog: [General][Breaking] - JsErrorHandler: Rename handleJsError to handleFatalError
Reviewed By: cortinico
Differential Revision: D55547901
fbshipit-source-id: 261e0c8fea2852bc95e53c688d90d012d4abea34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43956
I think we should try to centralize all things js error handling related inside JsErrorHandler. So, I moved this bool into JsErrorHandler.
This makes ReactInstance easier to understand: it removes one member variable from ReactInstance.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547897
fbshipit-source-id: 73d1e0eedf3896c42cda4ce1013863960585da2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43955
Just makes it easier to pass around JsErrorHandler.
We'll need this in D55547897, when we start storing the "has fataled" boolean inside the JsErrorHandler.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D55547898
fbshipit-source-id: 162faaeff43bada0301de29111b2c17f7ef878c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43952
getRuntimeScheduler() allows things to schedule work on the js thread by bypassing main bundle buffering.
This is unsafe: almost everything should be using the buffered runtime executor, unless it sets up bindings used in the main bundle.
I filed a task for the investigation to see if there's any problems. And added it to the code in this diff.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547899
fbshipit-source-id: 7785b9777e93f36ea0278993332662ed45a20cf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43861
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/22517999373069959/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725451
fbshipit-source-id: fea231c0f11f41013bcf7a8a9b5cf65badf82503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43981
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/27021599000417439/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725602
fbshipit-source-id: b8b77bf97de5a0eda5b077d6c5441b9af36fc26b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43967
Following up https://github.com/facebook/react-native/issues/43943, the metro loading banner is presented twice in Bridgeless mode.
This happens because both the RCTInstance and the RCTHost are listening to the Reload Command and issuing the instructions to refetch the JSBundle and to present the banner.
The RCTInstance should not concern itself with lifecycle events, owned by the RCTHost.
## Changelog:
[iOS][Fixed] - Avoid to show Metro Loading banner twice.
Reviewed By: cortinico
Differential Revision: D55870640
fbshipit-source-id: addb67d3226f7d7db20736309172a42fc15f3aa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43864
This change tries to vendor boost. It has several sustainable benefits:
- Reduce the download time to download boost
- Reduce the time to install pods
- Reduce the time to build the project
- Protects us from SEVs due to boost download link being down (happened twice already)
- Fixes how we build boost: currently it is a pseudo-target in iOS with no code, this makes all the symbols weak and this does not plays nicely with the new Apple linker.
## Changelog:
[Internal] - Vendor boost from React Native
Reviewed By: cortinico
Differential Revision: D55742345
fbshipit-source-id: 75abb5a2875e949b3dae299d2e18cb648c46151e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43968
Changelog: [Internal]
When going from a Fusebox build to a non-Fusebox build of the same app, users can accidentally connect a previously opened Fusebox frontend to a non-Fusebox backend (or vice versa).
To prevent this, here we assign a distinct "device ID" to the Fusebox backend on both Android and iOS. This will prevent a mismatched CDT frontend from reconnecting to the app after a backend change, forcing the user to close and reopen the debugger.
Reviewed By: hoxyq
Differential Revision: D55870800
fbshipit-source-id: 8552e009ef1e43b512d35035c98d1a859e3ccf91
Dmitry Rykun
Riccardo Cipolleschi
Nicola Corti
Blake Friedman
Fabrizio Cucci
Christoph Purrer
Samuel Susla
Rubén Norte
Andrew Datsenko
Ruslan Shestopalyuk
Alan Lee
Ramanpreet Nara
Zeya Peng
Ruslan Lesiutin
Moti Zilberman