Fix a problem with NodeRefs and vtags, ref #2206 #2279
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes #2206
This is in some sense a very poor-mans local fix. It works and has a test case - good.
There is something deeper to fix: every
NodeRef
should be owned by exactly one rendered vnode. If that invariant is violated, this could lead to unexpected results - like here: Complicating the situation is that during rendering, new nodes are mounted and refs are set immediately, while another part of nodes might get detached later during the same render - "owning" the same ref - leading to a time window where aNodeRef
is "owned" by two nodes.There might be other, similar bugs lying dormant until a bigger effort is spent on developing a conceptual understanding of the above and adding some more debug assertions to check for the implicit invariant. Note that for example, there are currently no checks for the user reusing the same
NodeRef
multiple times:Which of those divs is expected to be in
some_ref
? Imo, somedebug_assertion
should trigger and inform the user not to do this in debug builds.Checklist
cargo make pr-flow