[3.17.2] WillDestroy is called at a wrong time for components inside {{each}}

[seidelman]

If a component is rendered in {{each}} block for items added to the list after initial rendering then
for those components willDestroy() is called only after {{each}} block is removed.

This issue is very similar to #18797 and it may be a result of the fix for that issue.

Why is this a problem

Our application uses Ember Leaflet to display a map with markers. Markers are displayed using {{each}} block with Ember Leaflet <Marker> components inside. The component relies on life-cycle hooks to actually add and remove markers using leaflet.js library.

Not calling willDestroy results in markers staying on a map after they were removed from a list.

Reproduction Scenario

I have created an Ember Twiddle to illustrate the problem:
https://ember-twiddle.com/db073f2618c1f191f75ce249f89cb639

It creates a list with 2 elements and have buttons to add and remove elements. It removes whole {{each}} block if the list is empty. It also logs component construction and willDestroy() calls.

• Start with items 1 and 2 in the list
• Add item 3
• Remove item 1: willDestroy(1) is called
• Remove item 3: PROBLEM: willDestroy(3) is not called.
• Remove item 2: willDestroy(list) is called followed by willDestroy(1) and ** willDestroy(3) (delayed)**
• Add item 4: the list get rendered again
• Add item 5:
• Remove item 5: PROBLEM: willDestroy(5) is not called.
• Remove item 4: willDestroy(list) is called followed by willDestroy(4) and ** willDestroy(5 (delayed))**

If the Twiddle is configured for Ember 3.17.0, then those problematic willDestroy() are not called at all. Issue #18797

If the Twiddle is configured for Ember 3.16.2, then those problematic willDestroy() are called as expected right after element removal from the list

[scottmessinger]

I just ran into this same issue today where I had an array of ObjectProxy rendered with {{#each}}. Just like @seidelman notes, willRemove is called for the original items but isn't called for anything added to the list (e.g. willRemove(3) in his example.

Great job @seidelman pinning this down!

[pzuraq]

Looks like there's an extra updating Opcode that we missed which needs the destructor hooked up to it. I should be able to look in the next week or so, the fix should be similar to the one for #18797

[mehulkar]

Would this affect the will-destroy modifier also? Ran into an issue with Ember Basic Dropdown that might be worth looking into as well: cibernox/ember-basic-dropdown#540

[seidelman]

Look like {{will-destroy}} modifier execution is delayed the same way calls to {{willDestroy()}} are.

I have modified the Twiddle to demonstrate that as well.

[MatthewPringle]

I am seeing an issue where willDestroy on a route I'm transitioning from fires after {{did-insert}} on the new route.

As my components register with a service this means the new component registers with the service before the old component has unregistered.

[waissbluth]

i am facing the same (or maybe a similar?) issue that i have not been able to pin down or consistently reproduce. have you found a workaround for this? @pzuraq did you get a chance to take a look?

[pzuraq]

I haven't had time just yet, but it's next on my todo list! Very much a high priority

[whatthewhat]

We've hit this issue, but with willDestroyElement in our app, otherwise same scenario as the original post. Tested on 3.17, 3.18 and the 3.19 beta (3.16 and below works).

[pzuraq]

Bugfix submitted to the VM, going to be downstreaming soon