domFor: always get generation from delayedRemoval instead of parameter

[kfule]

Description

The generation of domFor is no longer passed as a parameter.
This allows domFor to work well in onbeforeremove and onremove and reduces the amount of code.

Motivation and Context

#3005 did not properly take into account that domFor is public API.
This PR fixes these problems (#3005 (comment)):

• The domFor in onremove() does not work well during delayed removal. (flems)
• When there is onbeforeremove() in both vnode.state and vnode.attrs, domFor in onbeforeremove() in the latter vnode.attrs does not work well (since 3005.) (flems)

How Has This Been Tested?

npm run test including new tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My change requires a documentation update, and I've opened a pull request to update it already:
• I have read https://mithril.js.org/contributing.html.

[dead-claudia]

I'd like to see tests confirming multiple generations are tracked correctly, for completeness.

Given you do this:

• Render vnode A with onbeforeremove and DOM nodes A1 and A2
• Remove vnode A, do not resolve onbeforeremove
• Render vnode B with onbeforeremove and DOM nodes B1 and B2
• Remove vnode B, do not resolve onbeforeremove
• Render vnode C with onbeforeremove and DOM nodes C1 and C2
• Remove vnode C, do not resolve onbeforeremove

I'd like to see confirmation of this (6 possible removal sequences in total):

• m.domFor(A) returns [A1, A2] consistently before A's onbeforeremove resolves, even if B's and/or C's resolves first
• m.domFor(B) returns [B1, B2] consistently before B's onbeforeremove resolves, even if A's and/or C's resolves first
• m.domFor(C) returns [C1, C2] consistently before C's onbeforeremove resolves, even if B's and/or C's resolves first

[kfule]

@dead-claudia Thanks for your review comments.
I have added the following tests as you commented.

• m.domFor(A) returns [A1, A2] consistently before A's onbeforeremove resolves, even if B's resolves first
• m.domFor(A) returns [A1, A2] consistently before A's onbeforeremove resolves, even if B's and C's resolves first
• m.domFor(B) returns [B1, B2] consistently before B's onbeforeremove resolves, even if C's resolves first
• m.domFor(B) returns [B1, B2] consistently before B's onbeforeremove resolves, even if C's and A's resolves first
• m.domFor(C) returns [C1, C2] consistently before C's onbeforeremove resolves, even if A's resolves first
• m.domFor(C) returns [C1, C2] consistently before C's onbeforeremove resolves, even if A's and B's resolves first
  • (Other patterns should have been implemented in the above test cases.)

I am a little sorry that the test codes are somewhat verbose.
It seems that the test codes could be more aggregated, but I did not want to make it too complicated.

[dead-claudia]

I am a little sorry that the test codes are somewhat verbose.
It seems that the test codes could be more aggregated, but I did not want to make it too complicated.

@kfule Oh, I expected it to be messy. Don't worry.

[dead-claudia]

You got these orders:

• BCA
• CAB
• ABC

I also wanted to see the other three:

• ACB
• BAC
• CBA

[kfule]

@dead-claudia
I have added the test as you commented (ACB, BAC and CBA.)
I also removed the generation parameter of removeDOM() that I forgot to remove.