Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Upgrades all of our JavaScript tooling to use `yargs@^17.5.1`.
Of all [release notes](https://github.com/yargs/yargs/releases), these are the major version notes:
- [v17.0.0](https://github.com/yargs/yargs/releases/tag/v17.0.0)
- [v16.0.0](https://github.com/yargs/yargs/releases/tag/v16.0.0)
A cursory inspection suggests that these breaking changes are unlikely to seriously impact our use cases (or can be fixed forward).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D39550338
fbshipit-source-id: 5b2c5265f8c7a95ab0cc9bab62873f9e4355f32f
Summary:
Adding support for application to hook into further tracing methods
## Changelog
[General][Added] - Add additional Systrace support
Reviewed By: NickGerleman
Differential Revision: D38673212
fbshipit-source-id: 55a90a0cd57809bca5f01da7acddcf253e5852ba
Summary:
Changelog: [Internal] Remove unused RuntimeExecutor from UIManagerBinding constructor
Since [UIManager is the class that has a reference to RuntimeExecutor](https://github.com/facebook/react-native/blob/ce50c43986bae05ad62552be46f4d5bb4a46f097/ReactCommon/react/renderer/uimanager/UIManager.h#L35-L36), there's no reason for `UIManagerBinding` to own a reference to RuntimeExecutor too.
The purpose of `UIManagerBinding` is to bind the Fabric `std::shared_ptr<UIManager>` in C++ to `global.nativeFabricUIManager` in JS.
Doing this cleanup to make the next diff easier.
Reviewed By: sammy-SC
Differential Revision: D39490927
fbshipit-source-id: 4c393dccc6985bef44e3b0afc32b9f79bea25f80
Summary:
We already support attaching-on-reload when a debugger was a previously connected, and this connection logic seems to slow down app startup by 2 seconds in debug mode when running on device.
Changelog:
[Internal][Removed]
Reviewed By: jpporto
Differential Revision: D39272704
fbshipit-source-id: deb8651798cb9a13b81e1703920d3f9bd58869d2
Summary:
A previous change made the RuntimeAdapter contain a HermesRuntime (as opposed to an arbitrary JSI Runtime).
Now that it's known to be a HermesRuntime, expose that type information to the Inspector, so a runtime type check can be skipped (which is failing in some builds, despite the concrete type being what's expected).
Changelog: [internal]
Reviewed By: neildhar
Differential Revision: D39429109
fbshipit-source-id: ad5ae0604ac208da2002fd37e38d24319b45aebd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34514
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 3/n - Move RCTTurboModuleRegistry.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirety of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
Reviewed By: RSNara
Differential Revision: D38971168
fbshipit-source-id: 3b1b23d422f965a5a14bc4178d32b844906f2c8b
Summary:
Changelog: [Internal] Move Bridge-only constants into a separate file
- Move Bridge only constants from RCTBridge.h into RCTBridgeConstants.h.
- Move shared constants from RCTBridge.h into RCTConstants.h.
This way, new architecture does not need to import RCTBridge.h just for the constants.
Reviewed By: sammy-SC
Differential Revision: D39085713
fbshipit-source-id: 40177cbed72a326b40ec448c98751d1dd3464504
Summary:
changelog: [internal]
Add more clang tidy rules to prevent common class of bugs.
Reviewed By: javache
Differential Revision: D39245194
fbshipit-source-id: 5521c5c4653d7005b96ebba494e810ba5075afbc
Summary:
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.
- Need to call `registerForProfiling` to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
- `runInExecutor` didn't work and call its callback. Not sure exactly why, but using `executor_->add` like we do in a lot of other places to run code on the executor works.
- `GetHeapUsageRequest` seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. `GetHeapUsageRequest` doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use `runInExecutor` instead.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Fix hermes profiler
Pull Request resolved: https://github.com/facebook/react-native/pull/34129
Reviewed By: cortinico
Differential Revision: D37669469
Pulled By: philIip
fbshipit-source-id: 6cf3b2857ac60b0a1518837b9c56b9c093ed222f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
Configure the runtime to allow use of the sampling profiler in the Chrome Debug Server.
Note: this does not actually start and stop the profiler; this change just makes the sampling profiler available to the runtime.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D39100833
fbshipit-source-id: 60d1f4e5ea2191fdf88b7f2e733557fa6128e205
Summary:
Implement Runtime.compileScript, which is a dev tools request to compile a given script, optionally persisting the compiled result.
There are 3 main cases:
- Unsuccessful compilation, populates the exception details output. (We could retrieve the line and column number from the exception message, but it felt a bit too hacky.)
- Successful unpersisted output, returns an empty result, indicating success
- Successful persisted output, returns a result with a unique scriptID that identifies the prepared script.
The script IDs end with an index that can be used to infer the location in the vector storing persisted scripts.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38761119
fbshipit-source-id: 504faad0149d1637682fa11d285f71736c3133e5
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
X-link: https://github.com/facebook/hermes/pull/793
Add a JSI API for constructing `ArrayBuffer`s from a user provided
`jsi::MutableBuffer`.
Changelog: [General][Added] Added ability to construct ArrayBuffers from existing memory buffers.
Reviewed By: jpporto
Differential Revision: D37744467
fbshipit-source-id: 9d9ece00d1dbde341846c45fa30c935b5fa81e9a
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of `convertRawProp` for `std::optional` since we can handle that in a `fromRawValue` specialization instead.
To make this work, we need to remove `noexcept` from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D37055069
fbshipit-source-id: 8ce121a9b187f068d3ab790c6fae66d53e6338d2
Summary:
As title, replace json serialization/deserialization and folly with MapBuffer for js error handling in Android.
Changelog:
[Android][Changed] Replace Folly with MapBuffer for passing js error data
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D38460202
fbshipit-source-id: e13a47722964baa9e0a16bb138456a19350f809e
Summary:
Currently the PropSetter parser parses all border{TopLeft,TopRight,...}Radius props except for `borderRadius`.
This is the fix.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678226
fbshipit-source-id: 8c5d67a652c2b327aa50a997e8e886630fe139c0
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for mapbuffer
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - mapbuffer
Reviewed By: cipolleschi
Differential Revision: D38699253
fbshipit-source-id: c1c8f8693b6da4e3428f8f280e1ca4d5c5d0f853
Summary:
Changelog: [iOS][Internal] - Add iOS implementation of the button property of the PointerEvent object
This implements the `button` property on the PointerEvent object by storing the button which caused the down event in the `ActiveTouch` and reporting that button through `pointerdown` and `pointerup` events and -1 on all others. This diff also includes a small fix to the `pressure` property which was introduced due to `button` being correctly implemented.
Reviewed By: yungsters
Differential Revision: D38632543
fbshipit-source-id: 9dbbb23a9251f2e661faf37fdf206b9f0b26bc5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34403
This change mirrors D38457812 (https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690) which added -Wpedantic to ReactCommon targets, but for the Android build used by OSS. This should ensure contributors see the same warnings locally as the internal build would produce.
Changelog:
[Android][Changed] - Enable -Wpedantic in OSS Android Targets
Reviewed By: cortinico
Differential Revision: D38632454
fbshipit-source-id: 19a036ee3f902eb9d47c568aef448af9d8562358
Summary:
The `RuntimeAdapter` may be used after `disableDebugging` has been called. To ensure the `RuntimeAdapter` is alive long enough for this use, the Inspector should continue to control `RuntimeAdapter`'s lifetime (which is currently done via a `unique_ptr` that's moved into the Inspector).
Callers need a way to identify the `RuntimeAdapter` after it has been moved into the Inspector so that debugging can be disabled via `disableDebugging`.
This could be done by switching from a `unique_ptr` to a `shared_ptr` (so the caller can keep a copy), but consumers don't really have a reason to hang onto the `RuntimeAdapter` instance. Instead, leave the `RuntimeAdapter` inside a `unique_ptr`, and have consumers use a token to identify instances.
Update all consumers of this API to use this new token interface.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38513256
fbshipit-source-id: 33580747cd8365d25dbddbe289f0c41141e3bc6a
Summary:
Add ability to store and retrieve a list of MapBuffer as an entry of MapBuffer.
```
Example:
MapBuffer1
{
key1: "test string",
key2: MapBuffer2,
key3: [MapBuffer3, MapBuffer4]
}
```
Changelog:
[General][Added] Add ability to store and retrieve a list of MapBuffer
Reviewed By: JoshuaGross
Differential Revision: D38460204
fbshipit-source-id: 3e721418be2dca6d5f15f665753844d6f531e31c
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38355134
fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
