This issue is driving me crazy for a couple of days now. I have analyzed this behavior a lot and I found out that it isn’t only a problem with *ngIf but also with *ngFor (where I faced this issue too) and I guess that it is also a problem with *ngSwitchCase (not tested). I think in general you can say: If you have a parent element which has child elements inside it with animation triggers and the parent element gets removed (e. g. by *ngFor or *ngIf) before the child elements get removed, the child elements with animation triggers attached are causing a DOM leak (in case of *ngFor with a huge list - a massive one).

I guess it doesn’t even matter if the parent element itself has an animation trigger attached to it.

For example (the scenario where I faced this issue):

I have a multidimensional array, where each entry of the array is another array. Like:

let arr = [
    ["test01", "test02", "test03"],
    ["test11", "test12", "test13"],
    ["test21", "test22", "test23"],
    ["test31", "test32", "test33"],
]

In my template I use a nested *ngFor to visualize this. Each array is a own div and inside that div each entry of the array is a paragraph. The paragraphs have animation triggers attached to them to animate them at application runtime.

For example:

<div *ngFor="let list of arr"">
    <p [@exampleAnimation]="exampleState *ngFor="let entry of list>{{entry}}</p>
</div

Now, when you do arr.length = 0 to clear the array, all parapgraphs are leaked as Detached DOM elements. If you remove the animation trigger and do the same, that doesn’t happen.

This also doesn’t happen with an one dimensional array and a single *ngFor.

A workaround that I found out:

First clear all array entries inside the main array, then run change detection and let angular destroy all elements from the inner *ngFor (the paragraphs), then clear the main array and run change detection again so angular can now destroy all elements from the outer *ngFor (the divs). If you do it like that, everything gets cleaned up as expected.

But this workaround feels really hacky so I don’t think that it is a good option.

I also had a similar issue with *ngIf, where the parent container with the *ngIf attached had a child element with an animation trigger. This also caused a memory leak (of the whole component template). There I used the same workaround as above: First removed the child element itself with an *ngIf, then run change detection and let angular update the template, and then remove the parent container with the original *ngIf. This also fixed the issue.

But as I said, this workaround isn’t a solution because it is really dirty and feels hacky. So I hope this will get fixed soon, because it makes the @angular/animations package almost unusable for large applications with much animations.

also ran into this… especially annoying in our case because that loop with the animation is run through on a timer (it’s kind of a slideshow situation) which also is endless… which means this is guaranteed to crash the browser-tab given enough time 🧨

Still an issue in Angular 10 as far as I can see. A simple <*ngFor @withAnimation> causes un-GC’d detached DOM nodes. I don’t work for Google, but I’d question the P3 prioritization of any (easily reproducible) performance bug – just my 2 cents.

Closing based on Dario’s comment above. Please open a new issue (and include a repro) if the problem still exists in the most recent version of Angular. Thank you.

Could somebody take a look at this? @dario-piotrowicz maybe?

@JoostK I see. Can we please bump this up from P3? This issue is easily reproducible and will quickly destroy apps with any moderate-to-heavy use of animations.