Summary:
changelog: [internal]
`useLayoutEffect` has two guarantees which React Native breaks:
- Layout metrics are ready.
- Updates triggered inside `useLayoutEffect` are applied before paint. State between first commit and update is not shown on the screen.
React Native breaks the first guarantee because it uses Background Executor. Background executor moves Yoga layout to another thread. If user core reads layout metrics in `useLayoutEffect` hook, it is a race. The information might be there, or it might not. They can even read partially update information. This diff does not affect this. We already have a way to turn off Background Executor. We haven't done this because it introduces regressions on one screen but we have a solution for that.
React Native breaks the second guarantee. After Fabric's commit phase, Fabric moves to mounting the changes right away. In this diff, we queue the mounting phase and give React a chance to change what is committed to the screen. To do that, we schedule a task with user blocking priority in `RuntimeScheduler`. React, if there is an update in `useLayoutEffect`, schedules a task in the scheduler with higher priority and stops the mounting phase.
We are not delaying mounting, this just gives React a chance to interrupt it.
Fabric commit phase may be triggered by different mechanisms. C++ state update, surface tear down, template update (not used atm), setNativeProps, to name a few. Fabric only needs to block paint if commit originates from React. Otherwise the scheduling is wrong and we will get into undefined behaviour land.
Rollout:
This change is gated behind `react_fabric:block_paint_for_use_layout_effect` and will be rolled out incrementally.
Reviewed By: javache
Differential Revision: D43083051
fbshipit-source-id: bb494cf56a11763e38dce7ba0093c4dafdd8bf43
Summary:
changelog: [internal]
Passing MountingCoordinator argument by value instead of reference. Using reference does not make sense since we eventually take ownership of shared_ptr anyway. This better communicates the intent.
Reviewed By: christophpurrer
Differential Revision: D43082955
fbshipit-source-id: 29e20abb9824c10a5f0d5e0ba1049ff6d67cee98
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
This is a two step (1/2) fix to a race that could caused a `DELETE`...`CREATE` mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ, yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This race condition could cause a view to get deleted at the end of one UI frame, yet the mount instructions generated from animation in the next frame still need to access the deleted view and caused crashes like T112157805. Note that even though such crash is recorded as `RetryableMountingLayerException` and is a soft crash (which only gets logged but not crash in production), the out-of-order mount instructions could lead to illegal view state and make the surface unusable, like what's shown here:
{F820669000}
The diff fixes this issue by removing the `DELETE` [conflict animation](https://fburl.com/code/5ctckvz3) keyframe, as well as the `CREATE` [immediate mutations](https://fburl.com/code/txyomytd) from the layout animation. The Fabric mounting layer assumes no combination of `DELETE...CREATE` in the same frame from differ + [layout animation overrides](https://fburl.com/code/zn17uqch).
Reviewed By: sammy-SC
Differential Revision: D41895427
fbshipit-source-id: d6df02663ba707af6db4a63a325ac776ca54d18e
Summary:
changelog: Introduce setNativeProps to Fabric
Add support for `setNativeProps` in Fabric for backwards compatibility. It is still recommended to move away from `setNativeProps` because the API will not work with future features.
We can make step [Migrating off setNativeProps](https://reactnative.dev/docs/new-architecture-library-intro#migrating-off-setnativeprops) in migration guide optional.
Reviewed By: yungsters, mdvacca
Differential Revision: D41521523
fbshipit-source-id: 4d9bbd6304b8c5ee24a36b33039ed33ae1fc21f8
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:
Minimal set of changes to intercept events in external modules. Current intended use-case is for Reanimated to handle events for the Animated properties.
Changelog: [Added] Add listeners to allow intercepting events in C++ core.
Reviewed By: cipolleschi
Differential Revision: D35312534
fbshipit-source-id: ec924b57fd0c0dabf7be7b886dbef23bf3170d6c
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
Applies suggestions from default preset that make sense in our codebase
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33010231
fbshipit-source-id: 6bc9edf01fd9bd9938d211e3494dd1a127b24eaa
Summary:
The IDE warning suggests that passing folly::dynamic by value will create a copy on each call.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D32978154
fbshipit-source-id: a47a60c332a9d299eb2110d3537dfab0bc2398b6
Summary:
changelog: [internal]
This is a pre-condition to get rid of `shared_ptr` from `EventEmitterWrapper`. Also saves us a few copies of shared_ptr, this is negligible though.
Reviewed By: mdvacca
Differential Revision: D31307048
fbshipit-source-id: b84654bed2359b66faf3995795e135e88fe51cb6
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
This diff exposes a new API in FabricUIManager called getInspectorDataForInstance. The goal of this method is to return React metadata for a Native view.
This data will be used from partner teams to build tools that uses React metadata in RN
Data returned from React: P429701924
changelog: [internal] internal
allow-large-files
Reviewed By: JoshuaGross
Differential Revision: D29747864
fbshipit-source-id: 8cb55573be08cb530f7e3c83eed8b4fcf43e7781
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
The new C++ Differ has been validated on Android and iOS. Delete the old code path.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28904330
fbshipit-source-id: 2e0d8682f6b2a79f9758ed8b7b92809060835815
Summary:
Changes in following diffs will be gated by this feature flag.
The differ in the new file is copied from the current stable implementation and will not be modified until it's deleted.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D27775698
fbshipit-source-id: 03d9518ffd2b1f25712386c56a38bd2b4d839fc2
Summary:
The non-Fabric API has a `blockNativeResponder` param in setJSResponder. Make sure to pass that along in Fabric.
On Android this allows us to respect the flag and do the same thing non-Fabric was doing if `blockNativeResponder` is false. It's not clear yet what the impact is on iOS.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27058806
fbshipit-source-id: aa5074fa46191d78f5292a93d9040ab4bb58ca66
Summary:
This is a Fabric-compliant implementation of `JSResponder` feature. To make it work e2e we also need to update FabricRenderer in React repository. But before we can do this, we need to ship the native changes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D24630027
fbshipit-source-id: 70c30e1250b554d83862956b536714704093072f
Summary:
The diff implements a way to use `SurfaceHandler` without using `SurfaceHandler` directly for testing and transitioning purposes. If a boolean flag is enabled all calls related to surface management will be redirected to an appropriate `SurfaceHandler` via `SurfaceManager`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26125955
fbshipit-source-id: 8760c237d486897ea0c32867c921d445a7f24edc
Summary:
This implements `SurfaceHandler`, a new primitive for controlling the Surface life-cycle that ensures ownership, preserves state, maintains internal invariants, and simplifies surface manipulation from the application side.
For now, all this is an unused code. The coming diff will introduce an experiment that will route all surfaceId-based APIs to SurfaceHandler-based ones.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290777
fbshipit-source-id: f2ff2b58e6d46e971a548f9f02113a1c783c4940
Summary:
Before this change, `mountingOverrideDelegate` was proxied via `Scheduler::startSurface` and `ShadowTree::ShadowTree` constructor down to `MountingCordinator`. Now we set it on the `MountingCoordinator` directly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26049076
fbshipit-source-id: 7f1ecf2c8b6f264a7e59d19881464fe529c53d30
Summary:
This diff simplifies `ShadowTree` constructor by removing `rootComponentDescriptor` argument. It was previously stored and supplied by `Scheduler`; now `ShadowTree` class allocates one instance of it for all instances of `ShadowTree`. The `RootComponentDescriptor` instance of it is only needed to clone a `RootShadowNode` instance; it cannot issue events, state updates, or anything like that because it does not have React counterpart.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D26048466
fbshipit-source-id: ec02b1b4bcc917efe17cef58112fa870b341c85f
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:
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:
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:
# Summary
In previous diffs earlier in 2020, we made changes to detect and optimize reordering of views when the order of views changed underneath the same parent.
However, until now we have ignored reparenting and there's evidence of issues because of that. Because Fabric flattens views more aggressively, reparenting is also marginally more likely to happen.
This diff introduces a very general Reparenting detection. It will work with view flattening/unflattening, as well as tree grafting - subtrees moved to entirely different parts of the tree, not just a single
parent disappearing or reappearing because of flattening/unflattening.
There is also another consideration: previously, we were generating strictly too many Create+Delete operations that were redundant and could cause consistency issues, crashes, or bugs on platforms that do not handle that gracefully -
especially since the ordering of the Create+Delete is not guaranteed (a reparented view could be created "first" and then the differ could later issue a "delete" for the same view).
Intuition behind how it works: we know the cases where we can detect reparenting: it's when nodes are *not* matched up with another node from the other tree, and we're either trying to delete an entire subtree, or create an entire subtree. For perf reasons, we generate whatever set of operations comes first (say, we generate all the Delete and Remove instructions) and take note in the `ReparentingMetadata` data-structure that Delete and/or Remove have been performed for each tag (if ordering is different, we do the same for Create+Insert if those come first). Then if we later detect a corresponding subtree creation/deletion, we don't generate those mutations and we mark the previous mutations for deletion. This incurs some map lookup cost, but this is only wasteful for commits where a large tree is deleted and a large tree is created, without reparenting.
We may be able to improve perf further for certain edge-cases in the future.
# Why can't we solve this in JS?
Two things:
1. We certainly can avoid reparenting situations in JS, but it's trickier than before because of Fabric's view flattening logic - product engineers would have to think much harder about how to prevent reparenting in the general case.
2. In the case of specific views like BottomSheet that may crash if they're reparented, the solution is to make sure that the BottomSheet and the first child of the BottomSheet is never memoized, so that lifecycle functions and render are called more often; and that in every render, the BottomSheet manually clones its child, so that when the Views are recreated, the child of the BottomSheet has a tag and is an entirely different instance. This is certainly possible to do but feels like an onerous requirement for product teams, and it could be challenging to track down every specific BottomSheet that is memoized and/or hoist them higher in the view hierarchy so they're not reparented as often.
Reviewed By: shergin
Differential Revision: D23123575
fbshipit-source-id: 2fa7e1f026f87b6f0c60cad469a3ba85cdc234de
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Samuel Susla
Xin Chen
Samuel Susla
Nicola Corti
Andres Suarez
Kevin Gozali
Andrei Shikov
Joshua Gross
David Vacca
Valentin Shergin
Stephy Ma