[BREAKING CHANGE] BrowserAnimationsModule makes removal of non-animated elements asynchronous

[youdz]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Currently, importing the BrowserAnimationsModule in in an app makes the removal of all embedded views asynchronous, even if they are not animated. One of the main problems is that it happens even if the module declaring them does not import the BrowserAnimationsModule, just the app importing it seems to override the Renderer for everyone.
It also produces strange situations since addition is also synchronous: with a simple *ngFor, when updating the array given to it, any code happening AfterViewChecked can see both the newly added items and the removed ones lingering around.

Expected behavior

Removal should become asynchronous only if animated elements are found inside of the removed component (including itself). If this is not possible, at the very least offer a solution to force synchronous removal. I tried using @.disabled, but the removal is still asynchronous. Maybe force synchronicity only when @.disabled is used? That should be the safest solution.

Minimal reproduction of the problem with instructions

1. Here is an example of the behavior I was mentioning for *ngFor: https://plnkr.co/edit/vEBwyVgQdjaAPZmjrGG4?p=preview
   If you open the console, you will see that changing the items from [1, 2, 3, 4, 5] to [4, 5, 6] prints 1 2 3 4 5 6 in ngAfterViewChecked().
   Here is the exact same plunker without the BrowserAnimationsModule import: https://plnkr.co/edit/kb8RGLkLBtPx7SR6nFRj?p=preview
   This time, ngAfterViewChecked() prints 4 5 6 as expected.
2. Here is an example showing that this is an issue even if doing some kind of "manual" *ngFor (with a naive implementation for the sake of clarity) in a module that does not import BrowserAnimationsModule: https://plnkr.co/edit/kEzzULZHJpusciWSbQix?p=preview
   Once again, if you open the console, you'll see that additions happen immediately, but removals happen asynchronously. It still logs the removed items after removing them.
   If you try removing the BrowserAnimationsModule import from the app, you'll see removal becomes synchronous again.

What is the motivation / use case for changing the behavior?

Some components need the DOM to be updated after view modifications, typically to access their dynamic height or width for rendering purposes. Wrapping all these in setTimeout() affects performance negatively, and is sometime not possible when the view modifications happen in a loop and the DOM needs to be updated at each step.

Environment

Angular version: 4.3.6


Browser:
- All
 
Others:

[youdz]

We started noticing a lot more things breaking in our project because of this issue. Things that were working fine before.

So I investigated a bit more, and it turns out this was a breaking change introduced in 4.2.0 without notification. See https://plnkr.co/edit/IEksw5ywbSkw6trFneQc?p=preview for the exact same plunker as posted above, but on a 4.1.3 version.

I updated the title of the issue accordingly.

The fact that non-animated components changed behavior because of an non disclaimed breaking change in the animations module is pretty bad, honestly. Having one setTimeout() as a single workaround was kind of reasonable, but we're starting to need many more timeouts in our library, which might severely impact the performance of all applications using it.

[matsko]

@youdz looking into it.

[youdz]

Any news on this? We're really stuck on this, the fact that for a single change detection, both elements removed in that pass and elements freshly created coexist in the DOM is raising a lot of problems when trying to do advanced rendering features.

If you can't solve it quickly and since it's a real regression, any reason you didn't roll it back while investigating?

[matsko]

Landed as 46aa0a1

Next week's release will have the fix in it.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}