Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
Summary:
Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled.
```jsx
// usage
PlatformColorIOS({
light: '#eeeeee',
dark: '#333333',
highContrastLight: '#ffffff',
highContrastDark: '#000000',
});
// {
// "dynamic": {
// "light": "#eeeeee",
// "dark": "#333333",
// "highContrastLight": "#ffffff",
// "highContrastDark": "#000000",
// }
// }
```
This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors)
---
The react native docs mention that more keys may become available in the future, which this PR is adding:
> In the future, more keys might become available for different user preferences, like high contrast.
https://reactnative.dev/docs/dynamiccolorios
## 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
-->
[iOS] [Added] - High contrast dynamic color options for dark and light mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/31651
Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert
Reviewed By: lunaleaps
Differential Revision: D28922536
Pulled By: p-sun
fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1
Summary:
Changelog: [internal]
There is a possibility of race between updating scrollview's state and virtualised list asking for layout of individual cells.
To make sure the race doesn't happen, state must be updated before dispatching onScroll event.
Android has implemented a different mechanism to tackle this issue in D28558380 (https://github.com/facebook/react-native/commit/b161241db2ef74d2e4bff36d4972f5f0312dcc44).
Reviewed By: JoshuaGross
Differential Revision: D28642737
fbshipit-source-id: 33874beac69fc5a66eeb7f459fd89cd0b00dafcf
Summary:
Changelog: [internal]
Originally added in D17814260 (https://github.com/facebook/react-native/commit/ffc7ec992c66417039b0fa14f1afd54a9cd2f882) to make parallax effect work in Dating.
This diff hides it behind a flag so we can properly evaluate what's the cost of sending scroll events to Paper.
Reviewed By: JoshuaGross
Differential Revision: D28608283
fbshipit-source-id: fa4d8944ad6b5e767363e231942f13fec9d18cb5
Summary:
Changelog: [internal]
Extend LeakChecker so it is available on Android (or any other platform as it is completely in C++ now).
Reviewed By: JoshuaGross
Differential Revision: D28600243
fbshipit-source-id: c77a003e3ffc6171e61c998508c9f34f10bb65ca
Summary:
After D28435078, NativeModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the NativeModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435430
fbshipit-source-id: 1ce00c3fb3c63b024d7e24895ff96c541a6fa654
Summary:
This protocol is no longer necessary, because we introduced the bridgeless-compatible abstraction: RCTCallJSModuleMethod.
Changelog: [iOS][Removed] - Delete RCTCallJSModuleMethod protocol
Reviewed By: fkgozali
Differential Revision: D28395446
fbshipit-source-id: 0ad606ce7935b24bfbd6e0c2f35fbde480a8a6ff
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
This diff has the bridge attach RCTCallableJSModules to our NativeModules.
Changelog: [Internal]
Differential Revision: D28395447
fbshipit-source-id: 01ca62442013826d28ba0f710e28a5963f5efb65
Summary:
This is a Bridgeless-compatible API to allow our NativeModules to call JSModule methods.
Changelog: [iOS][Added] - Introduce RCTCallableJSModules API for NativeModules
Differential Revision: D28395448
fbshipit-source-id: b7929ba8b4cc4410361961b45efa23c76baacd24
Summary:
RCTJSInvokerModule invokeJS can do the work done by setInvokeJSWithModuleDotMethod. Therefore, this diff reduces the surface area of Venice, and gets rid of setInvokeJSWithModuleDotMethod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232947
fbshipit-source-id: aa0d8497a1e0fba29109ca86a39de5d9e5b10c9c
Summary:
This protocol is no longer necessary, because we migrated all our NativeModules to synthesize bundleManager = _bundleManager;
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28232441
fbshipit-source-id: 0bd54fa49299574db8a75247c97b466476037f4f
Summary:
After this diff, every NativeModule that has `synthesize bundleManager = _bundleManager`, will get access to an RCTBundleManager, that it can use to read from/write to the bridge's bundle URL.
Changelog: [iOS][Added] - Attach RCTBundleManager to NativeModules
Reviewed By: PeteTheHeat
Differential Revision: D28086319
fbshipit-source-id: 6e4cd815d300e9036957ec8c743e947d2cb3f365
Summary:
## Rationale
The TurboModuleManager should only be concerned with modules. The bridge and RCTInstance integrate the TurboModuleManager with the rest of React Native. Therefore, abstractions used by TurboModules that reach into the rest of React Native should be attached by the bridge or by RCTInstance.
## Changes
In this diff, we pull RCTViewRegistry attachment out of the TurboModuleManager. In bridge mode, it'll be attached to TurboModule by the bridge. In bridgeless mode, it'll be attached to TurboModules by the RCTInstance.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28086320
fbshipit-source-id: 9d99835bdbb66bb6a41fbd0d8a3970cefae16b81
Summary:
Previously it defaults to using transparent color (iOS default), but when using `RCTSurfaceHostingProxyRootView` we actually manually set to `[UIColor whiteColor]`. However, if the surface is initialized via a different API, the color wasn't set. To avoid confusion and backward incompatibility, let's just set the same background color here.
We can decide in the future if the default color should be transparent instead.
Changelog: [Fixed][iOS] RCTSurfaceHostingView default background color is now consistent with RCTRootView
Reviewed By: RSNara
Differential Revision: D27973748
fbshipit-source-id: c506afbc5629df6647277aa2323f084773c8e760
Summary:
To prepare for the new architecture, introduce the following enforcement:
* Defining `RCT_NEW_ARCHITECTURE` in the build flag automatically enables violation reporting
* At runtime, call RCTEnableNewArchitectureViolationReporting() to enable/disable reporting - it takes effect with the future violations
* When violation reporting is enabled:
* RCTWarnNotAllowedForNewArchitecture(): log warning about a violation, but doesn't assert
* RCTEnforceNotAllowedForNewArchitecture(): assert when a violation happen
Also in this commit:
* Add warning when RCTRegisterModule() is called as a side effect of RCT_EXPORT_MODULE(). Many modules still need this, so we can't enforce it yet.
* Add enforcement when the bridge is initialize, because the new architecture cannot have the bridge.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D27847359
fbshipit-source-id: a8c4a8151cec3915ec707ce6b78f860af4bb0708
Summary:
In order to move away from the legacy system (bridge etc), we need to decouple the new architecture assumptions from it. This flag and assertion functions will help track the runtime and report violations along the way. The goal is to have 0 violation before switching over to the pure new architecture.
Note: this is not used right now.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27783246
fbshipit-source-id: 61f0d77c129bddcde7f24a803432f2d359c5bff3
Summary:
Changelog: [internal]
Introducing LeakChecker. A tool that checks if all native components have been cleaned up when surface is stopped.
**Known shortcomings**:
- LeakChecker is only enabled in debug builds and the existence of leaks is logged to console.
- For now, Leak Checker looks at N-1 screen. This is intentional as there is a known limitation of React that doesn't free up all shadow nodes when surface is stopped. Because of this, the use of LeakChecker is not intuitive and I'll work with React team to try to work around this.
- It doesn't help locating the leak, it only informs that leak is present. I'll be looking into ways to help locate the leak.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D26727461
fbshipit-source-id: 8350190b99f24642f8e15a3c2e1d79cfaa810d3d
Summary:
If a root view is initialized with a bridge that is already loaded, then it immediately will initialize its content view with a zero size, which results in that content view's size being calculated according to its content instead of the size set on the root view after initialization. This would lead to a race condition where sometimes the content view has a smaller size than the root view.
Changelog:
[iOS][Added] - Allow RCTRootView to be initialized with a frame
Reviewed By: PeteTheHeat
Differential Revision: D27052637
fbshipit-source-id: 384ab3be27c92c0d84d34d49afb697882335d890
Summary:
Live reloading has been deprecated in favor of fast refresh for years, this diff removes remaining references to it.
Changelog: [iOS] Delete deprecated "live reloading" setting
Reviewed By: fkgozali
Differential Revision: D26983596
fbshipit-source-id: c7f86e7ec511f80e53659bccd8f40ac4f0cac27c
Summary:
We want to be able to instrument touch processing delays in JS, which does not have access to systemUptime; therefore we want a UNIX timestamp, which JS has access to and can compare to the touch time.
It only matters that there is relative consistency between multiple touch events in JS, which is still the case; so this should have no impact on product code.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26705430
fbshipit-source-id: 2acd52ae5873a44edf1e0cb126a9a6c87203d8fa
Summary:
changelog: [internal]
### When does leak happen?
Leak happens anytime a callback isn't executed inside native module, it will never get cleaned up.
Imagine a native module with method that takes onSuccess and onFail callbacks. Only one of them will be called at any time and the other one will leak.
### Why does it leak?
It leaks because when `CallbackWrapper` is created using `CallbackWrapper::createWeak`. Inside `CallbackWrapper::createWeak`, the newly created object is inserted into `LongLivedObjectCollection`. This object collection will keep it alive until `CallbackWrapper::destroy` is called, which isn't called in case closure isn't executed.
### Solution
Introduce class RCTBlockGuard which ties cleanup of resources to lifetime of the block.
Reviewed By: RSNara
Differential Revision: D26664173
fbshipit-source-id: 9348f7c39eb317cf1e8e5d59e77a378e5e04f3eb
Summary:
Changelog: [Internal]
Problem:
The Bridge holds and exposes the bundle URL for native modules to inspect via `bridge.bundleURL`.
Solution:
This follows the same pattern we've been using for attaching objects to native modules: declare a protocol with the required object, attach that object during module init.
Differential Revision: D26289581
fbshipit-source-id: 35ae83912e392be84f55c8d056c8da15ba75060f
Summary:
Changes:
* RCTMountingManager got two dedicated methods that designate some external view as a Surface viewport;
* The wiring between views now happens right in `start` and `stop` methods (because there is no reason to do it later); now it's symmetrical and straightforward;
* A couple of Surface legacy statuses were removed; they are not used and do not convey useful information anyway.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26095434
fbshipit-source-id: 37828e093a40a1ad22ad78f110c18a8f27781ba7
Summary:
After this diff, NativeModules can synthesize the RCTModuleRegistry, and use that to query for UIViews of components, given their reactTags.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25645052
fbshipit-source-id: bb17606cc4862d07b739ef2c31a5e57f59201364
Summary:
## Problem
Many of our NativeModules use the bridge to access the UIManager. They then use the UIManager to call viewForReactTag. This makes all these NativeModules Venice-incompatible. P155700869
## Solution
This diff introduces a Venice-compatible API called RCTViewRegistry that will implement viewForReactTag. When the bridge exists, RCTViewRegistry will delegate to the UIManager. When the bridge doesn't exist, it'll delegate to RCTSurfacePresenter. Fingers crossed, this should allow us move ~50 NativeModuels off the bridge.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25641391
fbshipit-source-id: 144f4f7a35af1245401ad640068852dd66bbf65d
Summary:
## Description
During TurboModule method invocation, when we convert JavaScript callbacks (i.e: jsi::Functions) into ObjC blocks inside the TurboModule jsi::HostObject, we [push them into an array](https://fburl.com/diffusion/r1n75ikx) that [gets cleared after the method gets invoked](https://fburl.com/diffusion/ubbvdmfs).
Prior to this experiment, we pushed these ObjC blocks into the array without copying them first. This goes contrary to ObjC best practices, which suggest that if you need to retain a block past its creation context for later invocation, you should defensively copy it to prevent it from being freed early. See the [Apple docs](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1):
> Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap.
The diff that introduced the fix: D23764329 (https://github.com/facebook/react-native/commit/9b76e217bb16935069f0ea5b60f4c4d9b73f86d6).
Reviewed By: PeteTheHeat
Differential Revision: D25617672
fbshipit-source-id: 24863b31a2d82c8d39a91c8ea8eb3a62724b800a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Summary:
The bridge now creates the RCTModuleRegistry, and assigns it to all NativeModules it creates.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414108
fbshipit-source-id: 81c6a05bde0e52cff8ed60297f27d8aa3ff15a87
Summary:
NativeModules and TurboModules should use this API to lookup other NativeModules/TurboModules.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414341
fbshipit-source-id: d8fab3d1b30b940fc5d1faa56bf195b9fda8d377
Summary:
## Problem
Many of our NativeModules are TurboModule-compatible. All our TurboModules currently use the bridge to require other NativeModules/TurboModules. As we migrate more surfaces to Venice, this lookup in many of these TurboModules will break, because the bridge will be nil.
## Initial Solution
We migrate all these TurboModules over to the turboModuleRegistry. In FBiOS, this will work because all NativeModules are TurboModule-compatible, and should [have the turboModuleRegistry attached to them by the TurboModuleManager](https://fburl.com/diffusion/d747fbc3). However, this solution has a few problems:
- If the TurboModule is used within a TurboModule-disabled app, it will break, because turboModuleRegistry will be nil on the module. Therefore, this solution isn't portable/flexible across apps.
- Longer term, we should deprecate synthesize bridge inside NativeModules. With this approach, we can't remove the synthesize bridge = bridge call from the NativeModule.
## Suggested Solution
Both NativeModules and TurboModules will be given access to an `RCTModuleRegistry` object. The RCTModuleRegistry object will use the TurboModuleManager when available and the Bridge when available to query for NativeModules and TurboModules. Otherwise, it'll just return nil.
When we do a lookup via this RCTModuleRegistry:
- In Venice, the bridge will be nil, so we won't search the bridge.
- In FBiOS, the bridge and the TurboModuleManager will be non-nil, so we'll first search the bridge, and then the TurboModuleManager.
- In standalone apps, the TurboModuleManager will be nil, so we'll only do a lookup on the bridge.
Long story short, RCTModuleRegistry will do the right thing in all scenarios.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25412847
fbshipit-source-id: 13f41276158d90c68ab4925e518d71a2f369c210
Summary:
## Android API
```
// Before we initialize TurboModuleManager
ReactFeatureFlags.useTurboModuleJSCodegen = true
```
## iOS API
```
// Before we initialize RCTBridge
RCTEnableTurboModuleJSCodegen(true);
```
## How is the JS Codegen actually enabled?
The above native flags are translated to the following global variable in JavaScript:
```
global.RN$JSTurboModuleCodegenEnabled = true;
```
Then, all our NativeModule specs are transpiled to contain this logic:
```
interface Foo extends TurboModule {
// ...
}
function __getModuleSchema() {
if (!global.RN$JSTurboModuleCodegenEnabled) {
return undefined;
}
// Return the schema of this spec.
return {...};
}
export default TurboModuleRegistry.get<Foo>('foo', __getModuleSchema());
```
Then, in our C++ JavaTurboModule, and ObjCTurboModule classes, we use the TurboModule JS codegen when the jsi::Object schema is provided from JavaScript in the TurboModuleRegistry.get call.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D24636307
fbshipit-source-id: 80dcd604cc1121b8a69df875bbfc87e9bb8e4814
Summary:
Cleaning up an old experiment, it was `static true` for a couple of months already.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24642808
fbshipit-source-id: 50ba955490d848a9c1698e1c6d0c296e833386f3
Summary:
These are new markers that will be placed around initializing an RCTInstance.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24607905
fbshipit-source-id: 8e83a2476e2ae878c523217aeb5a3b4bfc5bf911
Summary:
Fabric has a feature that preallocates views before mounting even need them. We never tested the impact of this feature thought. This diff adds a way to enable/disable it and run an experiment.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24355612
fbshipit-source-id: fefd653e57232044cd7b28b160e12a4ef85dbb8b
Summary:
Changelog:
[General][Added] - Adds the Hermes runtime bytecode version number to the JS bundle requestURL. This allows Metro with Bytecode to work with prebuilt binaries.
Reviewed By: cpojer
Differential Revision: D24327852
fbshipit-source-id: e8ee8db4f9b01f0500ab9dd851b5818c4adf3303
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Joel Arvidsson
Birkir Gudjonsson
Samuel Susla
Andres Suarez
Ramanpreet Nara
Kevin Gozali
Scott Kyle
Peter Argany
Joshua Gross
Valentin Shergin
Keion Anvaripour
Lulu Wu