From fc2153cc4351a4416610e4c6bfd149e0dca895c0 Mon Sep 17 00:00:00 2001 From: Joshua Gross Date: Wed, 2 Jun 2021 12:48:42 -0700 Subject: [PATCH] Remove mounting-layer hack Summary: This hack should not be necessary. It should be fixed at Differ or LayoutAnimations level if there are existing issues there. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D28810021 fbshipit-source-id: 98b8d2ae9991ad527a3b3e90943d75063b2a4496 --- .../com/facebook/react/fabric/jni/Binding.cpp | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp b/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp index 8cb2ebc858c..2945893c05d 100644 --- a/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp +++ b/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp @@ -677,24 +677,6 @@ void Binding::schedulerDidFinishTransaction( newChildShadowView.props->revision > 1) { cppCommonMountItems.push_back( CppMountItem::CreateMountItem(newChildShadowView)); - - // Generally, DELETE operations can always safely execute at the end - // of a MountItem batch. The usual expected order would be REMOVE and - // then DELETE, for instance. However... in specific cases with - // LayoutAnimations especially, a DELETE and CREATE may happen for a - // View - in that order. The inverse is NOT possible - for example, we - // do not expect a CREATE...DELETE in the same batch. That would - // contradict itself - a node cannot be in the tree (CREATE) and - // removed from the tree (DELETE) at the same time. - cppDeleteMountItems.erase( - std::remove_if( - cppDeleteMountItems.begin(), - cppDeleteMountItems.end(), - [&](const CppMountItem &mountItem) { - return mountItem.oldChildShadowView.tag == - newChildShadowView.tag; - }), - cppDeleteMountItems.end()); } break; }