Summary:
See title. Not used in this diff; see next diff in stack.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26001014
fbshipit-source-id: 475eb265f1c27bd9aff978a49652764a50287e47
Summary:
Even though CommitHooks, in general, should be implemented as part of the Core and explicitly registered inside the code, sometimes it's handy to pass specify some additional commit hooks during Scheduler initialization (e.g. hooks that are parts of DevEx tools). Now it's possible.
We will use it soon in Timeline feature.
Changelog: [Internal] Fabric-specific internal change.
Differential Revision: D25920577
fbshipit-source-id: 00f33b7b576c9812afd70c364b5cceb3521da16b
Summary:
Original commit changeset: 3ed8e78e31b0
Backing-out D25938851 (https://github.com/facebook/react-native/commit/69b3016171bb2f994dd4a62c34c2c4645b5a7d56) and D25935785 (https://github.com/facebook/react-native/commit/bdea479a1faa0f1f7d7c9d9162212cce94bc9720). Based on analysis documented in T83141606, I believe this issue should be fixed in JS.
Additionally, this crash actually has nothing to do with (un)flattening or the differ; it is a side-effect of stale ShadowNodes being cloned, which I believe is either UB or a contract violation. Either way, it should probably be fixed either in JS, or in node cloning. So this isn't the right solution for this issue and should be reverted.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25949569
fbshipit-source-id: 8cf1094a767da98fff4430da60d223412e029545
Summary:
It is the correct way to deal with the measure function.
I believe it can fix the crash we see with TextInput state update. The crash is probably caused by invalid value of `shadowNodeRawPtr` in `YogaLayoutableShadowNode::yogaNodeCloneCallbackConnector`.
It's hard to reconstruct the full chain of events but I think it's related: Yoga's dirty flag influences cloning, so the improper setting of this flag can misalign "natural" ShadowNode cloning (influenced by changes in the tree) and YGNode-initiated cloning (triggered by layout process).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25937710
fbshipit-source-id: a4e7c9dd8f5e6598fc662f4c6ee8061fd795e20d
Summary:
This implements the `MeasurableYogaNode` trait in `YogaLayoutableShadowNode`. We had this trait from the very beginning but never used it. Now, if the trait is specified, `YogaLayoutableShadowNode` will set the measure function for the node and dirty it during cloning.
Previously, we used (and still use) a dedicated method for setting up the measure function - `YogaLayoutableShadowNode::enableMeasurement()`. The problem with it is that to make it work we have to dirty the Yoga node every time we clone it. And the only proper way to do this in the `YogaLayoutableShadowNode` constructor because if we do it later ancestor nodes could not observe this and react to this. Therefore we have to have a trait for it.
The plan is to use it for TextInput first to fix a crash (see the next diff). After we confirm it works fine, we will replace all the usages of `enableMeasurement` with the new trait.
This diff also renames the other two yoga-related traits (to make them less verbose and look unified), adds more comments, and asserts.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25937711
fbshipit-source-id: fafbd5d62537ac09e02ffbfd56adab6d629d791d
Summary:
Android has some optimizations around view allocation and pre-allocation that, in the case of View Unflattening, can cause "Create" mutations to be skipped.
To make sure that doesn't happen, we add a flag to ShadowViewMutation (in the core) that any platform can consume, that indicates if the mutation is a "recreation" mutation.
It is still a bit unclear why this is needed, in the sense that I would expect props revision to increment if a view is unflattened. However, there is at least one documented reproduction where that is *not* the case. So for now, we'll have a hack pending further investigation.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25935785
fbshipit-source-id: 6fb4f0a6dedba0fe46ba3cd558ac1daa70f671f5
Summary:
CommitMode allows customizing the side-effects of commit operations. In `Suspended` mode, the results of commit operations will not be passed down to a MountingCoordinator which will result in skipping the mounting phase completely.
This is one of the core elements of the Pre-rendering infrastructure.
Changelog: [Internal] Fabric-specific internal change.
Differential Revision: D24290773
fbshipit-source-id: c10ec20d13f3131fc632352ef22f4465c9dfb3c2
Summary:
allow-large-files
Changelog: [iOS] Remove iOS10/tvOS10 suppport
Similar to D19265731 (https://github.com/facebook/react-native/commit/674b591809cd1275b5f1c4d203c2f0ec52303396) for iOS9.
I just ran this command:
`find . -type f -exec sed -i '' 's/{ :ios => "10.0" }/{ :ios => "11.0" }/' {} +`
and then updated pods
Reviewed By: fkgozali
Differential Revision: D25693227
fbshipit-source-id: 0073d57ecbb268c52d21962cef202316857bcbd2
Summary:
The purpose of this diff is to ensure that visibility changes are handled correctly when the value of "display" for a View changes from 'flex' to 'none'.
RNTester is nesting several Views with different kind of visibilities. When the user tap on an item there's a state update that changes the visibility styles for some of these views. Fabric does not reflect the right changes of visibility on the screen.
changelog: internal
Reviewed By: shergin
Differential Revision: D25841763
fbshipit-source-id: 769b97afb72939d346a4c6f2669ff938b35596bc
Summary:
Changelog: [internal]
Making "layout" event asynchronous unbatched will bring the behaviour closer to Paper.
Paper puts "layout" event in the event queue from ShadowQueue and schedules a flush of event queue on JavaScript queue.
Before this, Fabric puts "layout" event in the event queue from JavaScript queue, waits until main run loop is about to go to sleep and then schedules a flush of event queue on JavaScript thread.
Now Fabric no longer waits for main run loop to go to sleep but induces a flush of event queue on JavaScript thread right away.
Reviewed By: JoshuaGross, shergin
Differential Revision: D25849468
fbshipit-source-id: 366e99364507f7bc1d09325c04a604bcb2043e3d
Summary:
This is the core (Cxx) Fabric implementation of sendAccessibilityEvent. No platform support is added in this diff (Android and iOS do not build yet).
See following diffs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25852412
fbshipit-source-id: 88b7d8e2e251183dfe7fb377a4cffbac8f458656
Summary:
While pulling in additional react-native code into react-native-windows to support fabric, I hit some bugs with the MSVC compiler. These minor changes work around those bugs and shouldn't have any functional effect on the code
## Changelog
[Internal] [Fixed] - Minor code tweaks to work around a compiler bug in MSVC.
Pull Request resolved: https://github.com/facebook/react-native/pull/30696
Test Plan: Code compiles in MSVC and clang.
Reviewed By: shergin
Differential Revision: D25830710
Pulled By: appden
fbshipit-source-id: 796bd8191ea62fe62e09dd16cc56b8edc092297f
Summary:
Changelog: [internal]
EventQueue is used as a virtual class, this diff makes it one.
Reviewed By: JoshuaGross, shergin
Differential Revision: D25826983
fbshipit-source-id: 60e6937514cd3b837b0ca9f61bfaa081823ffc61
Summary:
This changes the way we throttle `onLayout` events in Fabric.
The approach we used before has several issues:
* Every event-dispatching action initiated a lambda scheduled on JavaScript thread (which is a bit inefficient).
* If an event had {0,0,0,0} frame, it might be skipped because this is the default frame value.
* An event was always delivered by the exact block scheduled at the moment of the event initiation (even though some other blocks might be called before). In case of events being initiated rapidly, it can delay actual event delivery and maybe even overwhelm the JavaScript thread.
The new implementation uses a different approach: we maintain the shared storage with recent frame value and use the very first opportunity to deliver it. Alse see comments in the code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25676336
fbshipit-source-id: 275b08990f7c5cf1f05a8f954ebc795a14e10ec2
Summary:
The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly.
In this PR we remove this unnecessary include.
It is required for the https://github.com/microsoft/react-native-windows/pull/6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h added in https://github.com/microsoft/react-native-windows/pull/6804.
## Changelog
[Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h
Pull Request resolved: https://github.com/facebook/react-native/pull/30672
Test Plan:
The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly.
I had run the iOS tests and they passed:
```
yarn
pod install in packages\rn-tester
./scripts/objc-test.sh test
```
Reviewed By: mdvacca
Differential Revision: D25758927
Pulled By: fkgozali
fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
Summary:
Changelog: [internal]
Old event coalescing isn't used anymore and there haven't been any problems with the new one.
Reviewed By: shergin
Differential Revision: D25701311
fbshipit-source-id: 359f0361edffa22130cfa8322038acdbe26fd599
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary:
To ensure that we're not sending old eventEmitters or State objects to the mounting layer, or potentially out-of-date Props objects, base
animated interpolations on the final ShadowNode instead of the initial.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25727481
fbshipit-source-id: 560ae8d25c7cec4c2137e70b4571b762f461edff
Summary:
In Android, only changed prop values are sent to the mounting layer via folly::dynamic maps. In the LayoutAnimation system, before this, we only sent that
map at the /end/ of the animation for any non-interpolated values (for example, image source is not interpolated so it was not updated until the end of the animation).
However, what we probably expect is that all non-interpolated values change immediately, and interpolated values smoothly transition. This diff makes that change on Android
by using the final RawProps as the /initial/ value that interpolations are stacked on.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25727483
fbshipit-source-id: e692d37b9965fedcdf429a81d60b7cb7f0c6abe1
Summary:
This diff extracts the measure() Android function into an utility method.
As part of this diff I'm also refactoring one of the usages of this method (Text)
Additional refactors will be done as part of other diffs
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D25721046
fbshipit-source-id: 76cc6a8088607aaae5055c675076a0c18fc322ec
Summary:
This replaces the internal core implementation of `setState` with the new `updateStateWithAutorepeat` which is now the only option.
In short, `updateStateWithAutorepeat` works as `setState` with the following features:
* The state update might be performed several times until it succeeds.
* The callback is being called on every retry with actual previous data provided (can be different on every call).
* In case of a static value is provided (simple case, not lambda, the only case on Android for now), the same *new*/provided value will be used for all state updates. In this case, the state update cannot fail.
* If a callback is provided, the update operation can be canceled via returning `nullptr` from the callback.
This diff removes all mentions of the previous state update approach from the core; some other leftovers will be removed separatly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25695600
fbshipit-source-id: 14b3d4bad7ee69e024a9b0b9fc018f7d58bf060c
Summary:
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687692
fbshipit-source-id: a89d0a4d63b9c97775a312afa3df43f26b5ecc08
Summary:
Changelog: [internal]
Previous implementation of "measure" in UIManagerBinding returned 0, 0 for x and y coordinates.
Reviewed By: shergin
Differential Revision: D25681586
fbshipit-source-id: fa69b6d4803f083a8299e00cae8bb59932c8bf78
Summary:
Changelog: [internal]
The loop inside `UIManager::getNewestCloneOfShadowNode` is unnecessary as ancestorList already has index of the children.
Reviewed By: shergin
Differential Revision: D25681296
fbshipit-source-id: e8fab6c6d945064b0a7e63b6fd22697054fb7ea2
Summary:
Original PR contents:
This pull request updates the Podspecs and associated build scripts, and some source files so they build on OSS. RNTester now compiles with `fabric_enabled` again.
The following changes have been made:
* Various spots that were pointing to the old `ReactCommon/fabric` location have now been updated to `ReactCommon/react/renderer`
* Files that were attempting to use internal FB header `FBRCTFabricComponentsPlugins.h` were changed to use `RCTFabricComponentsPlugins.h`
* `RCTFabricComponentsPlugins` in OSS was updated to include the `Image` fabric component (thanks tsapeta)
* Replaced old `generate-rncore.sh` build script with new `generate-rncore.js` script which does not require `flow-node` and uses the `react-native-codegen` API directly, so there is no longer any need for an interim `schema-rncore.json` file.
* Updated Yoga podspec which wasn't fully synced with changes from the main Yoga repo
* Updated Fabric podspec with additional needed subspecs
Additions to PR by hramos:
* Replaced use of generate-rncore scripts with the original generate-native-modules-specs.sh script, which is now generate-specs.sh and supports both codegen for Native Modules and Components now (TurboModules/Fabric).
* Codegen now runs at build time as part of the Xcode build pipeline instead of as part of `pod install`. The build script is injected by the FBReactNativeSpec pod, as the pod is part of both Fabric and non-Fabric builds.
## Changelog
[General] [Fixed] - RNTester compiles with `fabric_enabled` again
Pull Request resolved: https://github.com/facebook/react-native/pull/29810
Test Plan:
RNTester now compiles and runs in the simulator again when `fabric_enabled` is set to `true`.
```
cd xplat/js/react-native-github/packages/rn-tester
USE_FABRIC=1 pod install
open RNTesterPods.xcworkspace
# Build and run
```
Reviewed By: fkgozali
Differential Revision: D24058507
Pulled By: hramos
fbshipit-source-id: 8b2ea3694e6cb9aa23f83f087e2995fd4320e2bb
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
This diff adds another complexity level for Stacking Context and zIndex tests: Now we test not only "noting-to-something" cases but also cases where we apply changes to an already non-empty tree, validating our assumption of each step.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25623176
fbshipit-source-id: 29a447d93522a2a4e7912351f907c46ac7b218bb
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:
After we create the RCTSurfacePresenter in Venice, we use it to create an RCTBridgelessComponentViewProvider, and pass it over to the RCTTurboModuleManager. In Venice, this allows all TurboModules to query components' UIViews given their reactTag.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25643261
fbshipit-source-id: 31da07c490d249534f700b7c8430e9cb43b5b0db
Summary:
Now, TurboModules that synthesize RCTModuleRegistry will have it available at runtime.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25643260
fbshipit-source-id: e9915f3da8412de823ae3d3e17849979c5cbd465
Summary:
The new UIManagerCommitHook can be used to implement commit-atering features without modifying the core.
E.g. State Reconciation seems can be implemented as a coomit hook but first we will use it for a new feature called Timeline (see the coming diffs).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25221312
fbshipit-source-id: dbe41b475bc8b36e1780d81447ab43b32758bdff
Summary:
With the change, a new delegate method allows a receiver to alter a new (proposed) shadow tree with another tree by returning the altered tree.
We will it use in future diffs to implement Commit Hooks.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25221313
fbshipit-source-id: 9f83577d862b713fff71fa365ce660cc1de87c84
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:
## Context
The legacy NativeModule infra implements promise methods using [async NativeModule method calls](https://fburl.com/diffusion/tpkff6vg). In the TurboModule infra, promise methods [treat as sync methods](https://fburl.com/diffusion/yde7xw71), and executed directly on the JavaScript thread. This experiment makes TurboModule promise methods async, and dispatches them to the NativeModules thread, when they're executed from JavaScript.
Reviewed By: fkgozali
Differential Revision: D25623192
fbshipit-source-id: 2b50d771c5272af3b6edf150054bb3e80cab0040
Summary:
Previously, we'd throw std::runtime_error objects when we invoked RCTPromiseResolveBlock and RCTPromiseRejectBlock. This would crash the app. Now, we'll just show RedBoxes. The RedBoxes also contain the name of the NativeModule, along with the method.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25549149
fbshipit-source-id: 33d5fc4480a577a1c17961c856ac42a9363b35f6
Summary:
After fixing `calculateShadowViewMutationsForNewTree` I realized that it will be even better to test Stacking Context and mutation instructions infra using both functions: `calculateShadowViewMutationsForNewTree` (used for testing) and the Differentiator itself. This diff implements it.
Now we have two similarly working functions with different implementations that we can use for testing Differentiator and other parts of the infra.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25576922
fbshipit-source-id: 7922e9ebfb9d6ef1792566554ba0c4a14f835ae2
Summary:
Working on zIndex tests I found that calculateShadowViewMutationsForNewTree (that we use for testing) does not take zIndex into account. This fixes it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25576923
fbshipit-source-id: a71b3a4630430488c783cd5010c0fbb7273bdaa5
Summary:
The test covers most props that must generate views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25576921
fbshipit-source-id: df5bedb8f6d409b5142e472ca2edcb1953bee4e1
Summary:
During cleanup, RCTNativeAnimatedModule [requires the RCTEventDispatcher](https://fburl.com/diffusion/0bnln893) to remove itself from the dispatcher a dispatch observer.
When the bridge is invalidated, if RCTEventDispatcher is has been cleaned up by then, we don't warn when this lookup fails: https://fburl.com/diffusion/rfioe5ay. This diff replicates that behaviour in the TurboModule infra.
Notes:
- In the legacy NativeModule infra, we can still query NativeModules post invalidation - we just won't create them. In the TurboModule infra, all requests for TurboModules from the TurboModuleManager start returning nil. Therefore, I simply did an early return inside TurboModuleManager moduleForName in the case that we're already invalidated. In addition to not displaying the warning, we just don't request/create the TurboModule in the first place.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25560228
fbshipit-source-id: 102dcc147bab6121daacdb39890bad48c0e60894
Joshua Gross
Valentin Shergin
Ramanpreet Nara
Peter Argany
David Vacca
Samuel Susla
Andres Suarez
Andrew Coates
Vladimir Morozov
Rubén Norte
empyrical
Kevin Gozali
Ron Edelstein