mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Joshua Gross
1e4d8d902d
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
89 lines
2.1 KiB
C++
89 lines
2.1 KiB
C++
/*
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
|
*
|
|
* This source code is licensed under the MIT license found in the
|
|
* LICENSE file in the root directory of this source tree.
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#include <vector>
|
|
|
|
#include <react/renderer/mounting/ShadowView.h>
|
|
|
|
namespace facebook {
|
|
namespace react {
|
|
|
|
/*
|
|
* Describes a single native view tree mutation which may contain
|
|
* pointers to an old shadow view, a new shadow view, a parent shadow view and
|
|
* final index of inserted or updated view.
|
|
* Use static methods to instantiate mutations of different types.
|
|
*/
|
|
struct ShadowViewMutation final {
|
|
using List = std::vector<ShadowViewMutation>;
|
|
|
|
#pragma mark - Designated Initializers
|
|
|
|
/*
|
|
* Creates and returns an `Create` mutation.
|
|
*/
|
|
static ShadowViewMutation CreateMutation(ShadowView shadowView);
|
|
|
|
/*
|
|
* Creates and returns an `Delete` mutation.
|
|
*/
|
|
static ShadowViewMutation DeleteMutation(ShadowView shadowView);
|
|
|
|
/*
|
|
* Creates and returns an `Insert` mutation.
|
|
*/
|
|
static ShadowViewMutation InsertMutation(
|
|
ShadowView parentShadowView,
|
|
ShadowView childShadowView,
|
|
int index);
|
|
|
|
/*
|
|
* Creates and returns a `Remove` mutation.
|
|
*/
|
|
static ShadowViewMutation RemoveMutation(
|
|
ShadowView parentShadowView,
|
|
ShadowView childShadowView,
|
|
int index);
|
|
|
|
/*
|
|
* Creates and returns an `Update` mutation.
|
|
*/
|
|
static ShadowViewMutation UpdateMutation(
|
|
ShadowView parentShadowView,
|
|
ShadowView oldChildShadowView,
|
|
ShadowView newChildShadowView,
|
|
int index);
|
|
|
|
#pragma mark - Type
|
|
|
|
enum Type { Create = 1, Delete = 2, Insert = 4, Remove = 8, Update = 16 };
|
|
|
|
#pragma mark - Fields
|
|
|
|
Type type = {Create};
|
|
ShadowView parentShadowView = {};
|
|
ShadowView oldChildShadowView = {};
|
|
ShadowView newChildShadowView = {};
|
|
int index = {};
|
|
};
|
|
|
|
using ShadowViewMutationList = std::vector<ShadowViewMutation>;
|
|
|
|
#if RN_DEBUG_STRING_CONVERTIBLE
|
|
|
|
std::string getDebugName(ShadowViewMutation const &object);
|
|
std::vector<DebugStringConvertibleObject> getDebugProps(
|
|
ShadowViewMutation const &object,
|
|
DebugStringConvertibleOptions options);
|
|
|
|
#endif
|
|
|
|
} // namespace react
|
|
} // namespace facebook
|