Summary:
When playing around with issues in debug mode but without having a debugger attached, these logs are helpful.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407772
fbshipit-source-id: 2083901094d3bd2b0b6c6799baffcf5a60cf57ae
Summary:
This impacts Android only. It's not high-impact to check the consistency of these views and they can become "inconsistent" easily in a way that is not interesting or useful to us,
since we handle "virtual" views differently on the platform.
The need for these hacks should go away in the future if/when we account for virtual views in the differ, and stop sending redundant instructions entirely.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407779
fbshipit-source-id: 01a7ea5106ed5d94b908de03a6a710cc6275018d
Summary:
On Android we have the notion of "virtual views", which are defined consistently but the logic is scattered and duplicated throughout the codebase.
The logic exists to mark nodes that exist in the ShadowTree, but not the View tree. We want to CREATE, UPDATE, and DELETE them on the platform, but not INSERT or REMOVE
them. They basically exist as EventEmitter objects.
The only issue with this is (1) duplicated code, which opened the possibility for inconsistent definition (2) StubViewTree did not account for virtualized views, which caused
assert crashes in debug mode for certain LayoutAnimations on Android.
By moving the definition to ShadowViewMutation and accounting for it in StubViewTree, asserts are correct and consistent on all platforms.
This was not caught until recently, because, until recently, no asserts actually ran on Android.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27001199
fbshipit-source-id: eb29085317037ba8a286d7813bdd57095ad4746f
Summary:
We have a custom STUB_VIEW_ASSERT that helps debugging stub view issues on platforms (like iOS) where flushing logs around assert-time isn't 100% guaranteed.
Move that logic into react_native_assert since it's generally useful.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26567218
fbshipit-source-id: 79f5ae66fc65a0af48dbcf4c7204ac8245911cb0
Summary:
See react_native_assert.{h,cpp}. Because of the BUCK+Android issue where NDEBUG is always defined, we use react_native_assert instead of assert to enable xplat asserts in debug/dev mode.
This migrates most of the codebase, but probably not 100%. The goal is to increase assertion coverage on Android, not to get to 100% (yet).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26562866
fbshipit-source-id: a7bf2055b973e1d3650ed8d68a6d02d556604af9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30988
We have a bunch of flags scattered throughout the codebase with poor hygiene and commenting. Consolidate.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26392518
fbshipit-source-id: 2823de123a5009d6b8c358e8a3f451b9fa0e05b7
Summary:
iOS and Android platform code already explicitly check this invariant: nodes cannot have parents when they're inserted into the View hierarchy.
Check this in the core so we get these checks in unit tests, and earlier in the core before platform code runs.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D26331842
fbshipit-source-id: c12bc9066d280cb85ccc9e754c9fa475927e6080
Summary:
On iOS, log lines are not entirely flushed when an assert is hit right after (or during) this mutate function. Make sure to flush log lines regularly during this function so that debugging is easier.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26291789
fbshipit-source-id: 47af109cdc3dcfc6bf08cbb41db06e9260bfaa08
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:
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
Summary:
This diff adds more enforcement for consistency of `ShadowNodeMutation`s, including:
* `Props` object for newly created or updated view must not be nullptr;
* `oldShadowView` must describe the previous state of the view for `Update` instruction;
* `ignoreDuplicateCreates` option was removed.
I suspect some of the crashes we see in Fabric are caused by a violation of one of these constraints. If one of these fails in debug builds, we will get an early signal.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D24880821
fbshipit-source-id: 8c8a3d8e205ce34f6e0335e8a2b0cf676930c284
Summary:
Index adjustment is tricky. Seems more reliable to adjust each immediate mutation, and then immediately adjust delayed mutations based on it, rinse and repeat.
Previously it was possible to construct examples where the UI would get into a weird state because index adjustment caused items to be inserted in the wrong location.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D24232926
fbshipit-source-id: f8c445213528c2d2aedacf3e0c73c5bbeb62bc3d
Summary:
1. When testing major changes to the differ, it can be useful to have more verbose logging.
2. On Android, since asserts don't fire yet, I log which asserts are failing.
Should have no impact on any builds unless you manually set the macro here, and it will have no impact on production builds regardless.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23257859
fbshipit-source-id: 94a8e74ece8023064de0f2203db6074975f8f1f0
Joshua Gross
Valentin Shergin
Samuel Susla
generatedunixname89002005287564@sandcastle995.atn2.facebook.com
David Vacca