[3.17] WillDestroy not called after a component is destroyed if that component was rendered from adding items to a list

[jakesjews]

If a component is rendered for each item in an each block then any components created by adding new items to the bound list will not call their willDestroy hooks. The issue affects both classic and glimmer components.

The bug is demonstrated at https://github.com/jakesjews/ember-will-destroy-bug/blob/master/tests/integration/components/test-comp-test.js. The console logs whenever each component is created or destroyed. The first test logs out two creates and two destroys which is expected but the second test logs two creates and only one destroy.

[boris-petrov]

I just hit the same issue.

@jakesjews - did you find a fix? If not, I'll have to downgrade to 3.16 because that's a major problem for us.

[jakesjews]

@boris-petrov unfortunately I have not. I downgraded our app to 3.16.

[pieter-v]

Same problem here

[manufitoussiwit]

Same problem here, too. I went crazy with this :-). I'm downgrading to 3.16.3.

[rwjblue]

Yeah, sorry about this y'all. Recent changes have this fixed and released in v3.17.2.

[seidelman]

I think I still have a problem with when willDestroy() is actually called.

My application has a list that is no longer rendered after the last element is removed:

{{#if list}}
  <div>
     {{#each list as |item|}} 
        <Component @item={{item}} {{will-destroy some-action}} /> 
     {{/each}}
  </div>
{{/if}}

There is logic outside of this template to add and remove items to the list as application runs.

In 3.16.6

willDestroy() is called immediately after an item is removed from the list. I think this is expected behavior.

In 3.17.1

willDestroy() is not called at all.

In 3.17.2

willDestroy() is called for all removed items after {{#each}}...{{/each} block itself is no longer rendered. This means that there may be a very long delay between component removal from the DOM and willDestroy().

[simonihmig]

willDestroy() is called for all removed items after {{#each}}...{{/each} block itself is no longer rendered. This means that there may be a very long delay between component removal from the DOM and willDestroy().

I can confirm the observation here, and this is still happening in Ember 3.18!

You can see this very well in the Ember inspector. See the following debugging experiment, captured from an actual app:

The field "rafters count" represents the length of the array being iterated over. The grey buttons are what is rendered in the each loop for each item. And on the right you see the matching component instances (<BsButton>), which are not properly destroyed. After reducing the array from 5 to 4 items, you can still see 9 component instances in the inspector (didn't bother to setup a proper key for the {{each}}, so there are the 5 to-be-destroyed components plus the 4 new ones)

In the actual use case where this came up, the willDestroy hook not only cleaned things up, but had to do some important side-effects. So this is not a purely aesthetic issue, but actually broke behavior.

@rwjblue sorry, but I think this needs to be reopened!

[waissbluth]

@simonihmig can you confirm that this still happens in v3.18.1, after #18941 was merged?

[rwjblue]

Ya, there is also another issue fixed WRT rerenders within an {{#each that hasn't been released just yet (was fixed in #18982).

[simonihmig]

can you confirm that this still happens in v3.18.1, after #18941 was merged?

@waissbluth Oh, great catch! I though we were already on the latest stable release 🤦‍♂️.

So yes, works as expected again! Sorry for the noise here!

[rwjblue]

Awesome, thanks for confirming that it is fixed!