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:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
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:
We see crashes in `updateProps:oldProps:` methods in several components, and we suspect it might happen because of the props object being null.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25535605
fbshipit-source-id: f278a5cec47b7fd54d31d015427fa918c02d913b
Summary:
We see crashes in this method, so we need asserts to understand why exactly it happens.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25535606
fbshipit-source-id: 8b0d275825a028f51343e4ab91682c8299904e8d
Summary:
This should make `testID` prop work as it works in pre-Fabric renderer on iOS.
On Android it should already work fine.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D25524890
fbshipit-source-id: 3f25eb427d4449abaab790099546be18ae573f98
Summary:
Ran `xbgs .accibilityManager`, and found all the NativeModules that used the bridge to access AccessibilityManager. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25504726
fbshipit-source-id: fcfb1fffbeedc136ee160d043949d9859300b1e3
Summary:
Ran `xbgs .redBox`, and found all the NativeModules that used the bridge to access RedBox. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25507829
fbshipit-source-id: 91033ca4c57d5be5e8e6fa904b636960ec12c584
Summary:
Ran `xbgs .devSettings`, and found all the NativeModules that used the bridge to access DevSettings. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503402
fbshipit-source-id: 26afc45cd1bc63d5de99ea331e7b2949b66be7ce
Summary:
All NativeModules that access the _bridge from self to require the DevSettings NativeModule now instead get the DevSettings NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503289
fbshipit-source-id: ebd1fd45d40aca37c0ead83bbaab59fa99d45044
Summary:
Ran xbgs `.devMenu`, and found all the NativeModules that used the bridge to access DevMenu. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499960
fbshipit-source-id: 70478616d44808f3788dd0b194da155db0877db9
Summary:
This is an extension of D25449795. I searched for all usages of .eventDispatcher within NativeModules, and migrated them all to the Venice-compatible RCTModuleRegistry API.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25473844
fbshipit-source-id: 2b8deec236e019f3adfb59fadd745c249ff822f4
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (https://github.com/facebook/react-native/commit/0ed81b28d3d786ea3b1cf0b932a008ef1f806ec4).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
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:
`RCTAlertController` creates a new window, and presents itself in that window.
RCTAlertController strongly retains the window, and the window strongly retains RCTAlertController when presenting it.
This adds a new method to break that cycle once alert is dismissed.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25312413
fbshipit-source-id: e4048922aa697eb42c4c149827bac61bc7bc5528
Summary:
Hermes being a subspec of ReactCore causes some build issues when RN is included in 2 different targets. It also causes it to include a lot of additional dependencies that it doesn't need. This moves it to a separate podspec loosely based on other specs in ReactCommon.
## Changelog
[iOS] [Fixed] - Move hermes to a separate podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/30478
Test Plan: Test that it builds and run properly in an app
Reviewed By: fkgozali
Differential Revision: D25308237
Pulled By: hramos
fbshipit-source-id: b4cc44ea2b1b854831e881dbbf9a2f30f6704001
Summary:
Changelog: [internal]
This avoids getting NaN in JS. Paper does it as well.
Reviewed By: shergin
Differential Revision: D25243147
fbshipit-source-id: 48dd1aa6daa7de23550850bd5d30fc3b20e6828d
Summary:
This method allows a surface to re-render from scratch, without having to delete and reinstantiate the surface.
Changelog: [iOS] Added reset method to RCTFabricSurface to help with reloads
Reviewed By: RSNara
Differential Revision: D25000509
fbshipit-source-id: f74170aa78cc84491ad2679f130ed3c8965bbe34
Summary:
Before this change, RCTImageComponentView on every state update extracted the raw pointer to ImageResponseObserverCoordinator and stored this as an instance variable. This worked fine but the code relied on an assumption that `oldState` argument of `updateState:oldState` is always valid (because the `oldState` is what retained that pointer).
Now, because of some issue, seems that `oldState` value is not always correct, so to work around this problem and to make the code more robust, this diff implements a slightly different approach.
Now we don't store the raw pointer to ImageResponseObserverCoordinator as an instance variable; instead, we store a retaining pointer to a state object and retrieve the pointer to an ImageResponseObserverCoordinator on demand. The diff also introduces a new function `_setStateAndResubscribeImageResponseObserver` that incapsulates updating `_state` object, unsubscribing from the previous coordinator, and subscribing for a new one.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24880820
fbshipit-source-id: 1c4d8ea91ae07dd217447e43cd3dde7b6f02dc40
Summary: We don't need ConcreteStateTeller in <Image> component because we don't even update the state from the component. I will change the logic around the state in the next diff, so we have to remove ConcreteStateTeller first.
Reviewed By: sammy-SC
Differential Revision: D24880822
fbshipit-source-id: bc993bc04ef9f6df79bcbc51941ad6bf64baae58
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:
This change introducing using `updateStateWithAutorepeat` for state updates in RCTSafeAreaViewComponentView. This way we can reduce the number of active commits and reduce jumps & relayout passes.
The approach with a callback is better than using `_lastPaddingStateWasUpdatedWith` because:
* When we compare the values, we can compare them with actual previous padding numbers stored in Shadow Tree.
* The value stored in a UIView instance can go away because of a view being remounted because of flattening.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24719345
fbshipit-source-id: 9bf1ae284875b4c99cf23be2fcc9a829eb8a895e
Summary:
This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet.
Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0)
Fixes https://github.com/facebook/react-native/issues/28810 (as above)
Checklist:
- [x] Adjust release scripts to create Hermes bytecode bundle
- [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project)
- [x] Test on a new React Native application in both Debug and Release (Device)
- [x] Test on an RNTester application in both Debug and Release (Device)
- [x] Add missing `i386` to Hermes framework and enable Bitcode
- [x] Inspect CI failures for possible regressions
- [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810
- [x] Release new Hermes and test against it that everything works
## Changelog
[IOS] [FEATURE] - Enable Hermes on iOS
[INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues
[INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI
[INTERNAL] - Fix building RNTester in Release mode
[INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!`
[INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI
[INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway
Pull Request resolved: https://github.com/facebook/react-native/pull/29914
Test Plan:
Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now.
Preview: (note "Engine: Hermes")
<img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png">
Reviewed By: hramos
Differential Revision: D24684845
Pulled By: cpojer
fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
Summary:
Historically, `UIScrollView`s in React Native do not cancel touches started on `UIControl`-based views (as normal iOS `UIScrollView`s do).
This diff implements this behavior.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24661106
fbshipit-source-id: 1fb98d62f9e1528f11e7699d460aaefcec534e97
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:
This re-uses the same logic as `logTaggedMarker` for `logTaggedMarkerWithInstanceKey`. When no instanceKey specified, use 0.
Changelog: [Internal]
Differential Revision: D24607919
fbshipit-source-id: 4a29e5ece9a5462eb1163185d26370ee873f1412
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:
Changelog: [internal]
The condition inside `[RCTCxxBridge handleMemoryWarning]` was preventing JS VM from handling memory pressure if React Native was loading. This seems incorrect as loading only occurs once at the startup but memory pressure event occurs mostly after React Native was initialised. Therefore, JS VM wasn't handling memory pressure events.
Reviewed By: shergin
Differential Revision: D24646724
fbshipit-source-id: 7b4420fe675261e434c3427c8ad366ba0086a453
Summary:
According to the crash, RCTEventEmitter is being asked to emit events before RN is set up {emoji:1f928}. Neither the bridge, nor bridgeless mode is ready to send events.
In this scenario, drop the events on the floor instead of crashing.
Changelog: [Internal]
Reviewed By: naftaly
Differential Revision: D24634701
fbshipit-source-id: 933e5dfd15e5ee7c2215489305c71de46e78a9e5
Summary:
To unify with Android, this uses the target off the same BUCK file.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24522269
fbshipit-source-id: 5aa0c08962890b884081faeb1ec801aebec9c2dd
Summary:
Changelog: [internal]
Problem:
`props.transform` gets out of sync with `self.layer.transform`.
To avoid writing out value of transform matrix, in the follow example I will only consider identity matrix and non-identity matrix. It is sufficient to demonstrate the point.
1. View is reused with transform being something besides identity. This causes `props.transform` and `self.layer.transform` to be non-identity.
2. View is taken from pool and animated with transform set to non-identity.
3. React JS props arrive and set `view.props` to identity but `self.layer.transform` stays unchanged because it is managed by native animation. This is the point where `props.transform` and `self.layer.transform` get out of sync.
4. Native animation wants to set transform to identity to finish the animation. But inside `[RCTViewComponentView updateProps:oldProps:]` `self.layer.transform` does not get set because current `view.props` is already identity.
Solution:
After native animation layer calls `[RCTViewComponentView updateProps:oldProps:]`, verify that values were set. If they weren't, set them directly without depending on `[RCTViewComponentView updateProps:oldProps:]`.
Reviewed By: JoshuaGross
Differential Revision: D24538442
fbshipit-source-id: ba8c59c5c9bb751306118bd1c7f0ccd9d0fb7fba
