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
Summary:
This is to address a UBN blocking FBiOSv300 rollout. A TM is attempting to invoke a promise more than once and crashing. We can't find the TM, so downgrading this to a warning to unblock the release.
Plan going forward:
- Replace this with some better logging to try and identify the culprit module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25539676
fbshipit-source-id: 5b75b71110eaa393378049de6e0d9a77e6328831
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:
Changelog: [internal]
Cloning of `LegacyViewManagerInteropViewProps` causes loss of `sourceProps.otherProps` if the cloning happens before shadow node is mounted. This was happening in WebView and callback `onLoadEnd` was dropped because of this.
Reviewed By: JoshuaGross
Differential Revision: D25474581
fbshipit-source-id: 74d7c5cd32b7318bb99306c82bc8b5e5eab63db2
Summary:
This is a followup to the issue described in D25477044, basically the TM cache can get messed up if `TurboModuleManager` is asked for "RCTNetworking" vs "Networking". This solves that issue globally.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25480624
fbshipit-source-id: 2024560eadbcf58cdc3d7d5675b4120aa2fa2582
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:
This fix is still a little hypothetical. We have a few different JS errors that we're seeing with bridgeless mode that seem to be caused by Fabric trying to access `__fbBatchedBridge` from C++. I think what's happening is:
1. User encounters an unrelated JS error very early in rendering a new surface (possibly while the bundle is still loading?)
2. In release builds, BridgelessReactFragment handles the error by stopping the surface and rendering a retry button (actually, the surface is stopped in a bunch of places in BaseFbReactFragment, which might be why this is popping up now - I recently refactored that class to share more of its logic in bridgeless mode)
3. Fabric stops the surface by first checking to see if the custom binding `RN$stopSurface` exists; if not, it falls back to calling the registered callable module `ReactFabric`.
I think #3 is where things are going wrong for bridgeless mode; if you call stopSurface before `RN$stopSurface` is installed (which happens when ReactFabric shim is required) then you'll fall back to the bridge version.
My solution here is to instead rely on a flag set in C++ to determine whether we're in bridgeless mode, and then check to see if the stopSurface binding has been installed. If not, we just noop - if the ReactFabric shim hasn't been required, we probably don't actually have a React surface that needs to be stopped.
At least, that's my current theory. We'll see if this actually works.
Changelog: [Fixed][iOS] Fix an issue calling stopSurface in bridgeless mode before surface is started
Reviewed By: mdvacca
Differential Revision: D25453696
fbshipit-source-id: bff76675c43989101d0ba5ae0aba60089db230bf
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce
Summary:
The `index` parameter for UpdateMutation is optional, and is normally just -1. It's not useful, so remove it. `parentShadowView` is also not relevant and is not used; in some existing use-cases the actual parent view of the updated view is available, and in some contexts the parent view is not set.
The function now will always set the index to -1 for UpdateMutations, and `{}` for ParentShadowView.
This should have no impact on iOS or Android, as this parameter is not used. It could theoretically have an impact on lifetimes of objects retained (now not retained) by not passing parentShadowView into the mutation. For example, any shared props or state associated with the parent will not be retained in the Update mutation now.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25342943
fbshipit-source-id: 0ddbef76a6e2eefc2629c9729f721d8674d7737e
Summary:
If a ShadowNode is being animated from opacity 0 to 1, and that animation is interrupted by another update to the same ShadowNode, we stop the animation and send the original "final" ShadowView
to the mounting layer. On iOS, this is enough to make the Mounting layer consistent with the Shadow layer. However, on Android, since only prop deltas are passed to the mounting layer and not the
entire props bag, this will NOT be enough because the opacity will not be updated in that final step.
Therefore, in those cases where we've detected a conflict and we're cleaning up after an interrupted animation, we must send two updates to the mounting layer: one to force the opacity to 1,
and another to make the ShadowTree consistent with the Mounting layer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D25324942
fbshipit-source-id: 5d9666128feaae87d7530c394ef05db580aa5a75
Summary:
In very marginal cases, it was possible to set up an animation of the following diffing instructions:
```
REMOVE X from parent Y
DELETE X
```
If your LayoutAnimation configuration had no "delete" config, the DELETE would be executed immediately; the REMOVE was erroneously being categorized as an "update" (now fixed)
which caused the REMOVE to be delayed, but then executed very shortly thereafter. So the order of instructions would become:
```
DELETE X
REMOVE X from parent Y
```
which would crash (or at least fail an assertion) when the REMOVE instruction was processed.
This fixes the issue by ensuring that REMOVEs have a corresponding "delete" config, or they are also executed immediately; unless followed by an INSERT (and any combination of `REMOVE, DELETE, INSERT` in the same frame is not possible).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D25292560
fbshipit-source-id: 7ffdd6cbcb43126de07a70c197dfaf1ebff83555
Summary:
The "reparenting differ" has been the default differ for several months; ship it by removing config and the old differ.
Some functions can't be deleted yet because unit testing relies on it heavily; this can be refactored in the future if we care a lot.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25257205
fbshipit-source-id: 6f1dcc490bb1efe3d12506addf5f0843ca48c5c6
Summary:
Changelog: [internal]
Touch events should be of a type PressEvent. Fabric only provided touches, changedTouches and targetTouches and leaves out force, identifier, locationX, locationY, pageX, pageY and timestamp.
Reviewed By: shergin
Differential Revision: D25243347
fbshipit-source-id: e824558bd43f51c0c6dcca62bfc98318aa61678e
Summary:
Changelog: [internal]
This is already defined in Touch.h
Reviewed By: shergin
Differential Revision: D25242843
fbshipit-source-id: 23bac2a60f3d995e34d342c3a189760875f4bc77
Summary:
Changelog: [internal]
Return value from `LayoutAnimationKeyFrameManager::getAndEraseConflictingAnimations` was a tuple with 3 elements. Two of them are not being used so let's get rid of them.
Reviewed By: JoshuaGross
Differential Revision: D25220601
fbshipit-source-id: 35781e735b6a2e518337fdeaf956c18bb370993b
Summary:
Changelog: [internal]
The assert is still firing, let's disable it until we can investigate why layout animations creates two delete mount instructions.
Reviewed By: majak
Differential Revision: D25216794
fbshipit-source-id: 6328a2afb5eaf7fceebdc05bc75804f2eb44ddd2
Summary:
These configs are never actually empty, so they shouldn't be optionals.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D25129254
fbshipit-source-id: 626119fefad0440732541c680286ebbbfab6aeba
Summary:
Changelog: [internal]
`currentAnimation_` is accessed on multiple threads and has dedicated mutex, but it was not acquiring the mutex in `LayoutAnimationKeyFrameManager::shouldAnimateFrame`
Reviewed By: JoshuaGross
Differential Revision: D25121654
fbshipit-source-id: 38b1c82eaabab283beab18dc210ea21379edbe93
Summary:
Changelog: [Internal]
Contents of `callComplete_` are accessed from JavaScript thread and main thread and there is possible race condition. This diff changes `bool` to `atomic_bool` to prevent the race.
Reviewed By: JoshuaGross
Differential Revision: D25094907
fbshipit-source-id: 6a2c6e33ab5ba0c6ab728e175f2e5c11fdd0a579
Summary:
Changelog: [Internal]
General improvements. Behaviour should be exactly the same.
Reviewed By: JoshuaGross
Differential Revision: D25092505
fbshipit-source-id: 584640ece3e02d468f6bcb84577d7a6c899cc253
Summary:
Imagine the scenario in which there's an ongoing UPDATE animation; a REMOVE+INSERT (move) is queued up for the same tag, but there's no
new corresponding UPDATE - so maybe the indices of the view have changed, but the layout stays the same. Under the old model, the previous animation would be canceled and the node would jump to the final position. In theory, if there's no new UPDATE, we should continue animating the node to its final position.
I'm much happier with this - conflicting animations transition into each other super seamlessly now, and I think the logic is more straightforward as well.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D25071664
fbshipit-source-id: fcefc4619dc34cdafdc4d8e8e730b935e5528290
Summary:
This is noisy when enabled, and not very useful.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25071584
fbshipit-source-id: 7205b5fa39622feccaf315ccebb181dbdac4281d
Summary:
See comments, hopefully they explain this situation. This fixes the last remaining case that I have repro'd where StubViewTree asserts fire.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D25062135
fbshipit-source-id: a28afba21f4094200aa0502b1e085dcbc10f9835
Summary:
The current implementation of LayoutAnimations assumed that the "previous/old" ShadowView passed into the diff mutation didn't matter except for purposes of diffing.
As it turns out, iOS components could possibly use the "old" version of props, state, etc - so we should try to keep track of the current value in the tree as much as possible.
This diff accomplishes that by keeping track of the "previous" view, which the AnimationDriver will update over time. This also allows us to simplify logic around conflicting animations.
I'm also adding a few additional asserts to assist in debugging.
This doesn't totally eliminate all asserts hit on iOS, yet, but it does reduce the number of times the asserts are hit in StubViewTree.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D25048644
fbshipit-source-id: d00aeece5af04624d8193063be453c7ce4a6e565
Valentin Shergin
Samuel Susla
empyrical
Kevin Gozali
Ramanpreet Nara
Ron Edelstein
Peter Argany
Aditya Kumar
Emily Janzer
Joshua Gross