Which @angular/* package(s) are the source of the bug? router

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

viewTransition not working with eventCoalescing about angular HOT 2 OPEN

kkachniarz220 commented on May 9, 2024

viewTransition not working with eventCoalescing

from angular.

Comments (2)

atscott commented on May 9, 2024 3

@garrettld That's exactly correct. Coalescing isn't compatible at the moment as a result.

Similar to #44314, there are situations where the current implementation of event coalescing falls over (because it's solely reliant on requestAnimationFrame). In our zoneless scheduler, we take the approach of racing setTimeout and rAF:

angular/packages/core/src/change_detection/scheduling/zoneless_scheduling_impl.ts

Lines 30 to 54 in e9246f7

    
             /** 
        
              * Run change detection after the first of setTimeout and requestAnimationFrame resolves. 
        
              * 
        
              * - `requestAnimationFrame` ensures that change detection runs ahead of a browser repaint. 
        
              * This ensures that the create and update passes of a change detection always happen 
        
              * in the same frame. 
        
              * - When the browser is resource-starved, `rAF` can execute _before_ a `setTimeout` because 
        
              * rendering is a very high priority process. This means that `setTimeout` cannot guarantee 
        
              * same-frame create and update pass, when `setTimeout` is used to schedule the update phase. 
        
              * - While `rAF` gives us the desirable same-frame updates, it has two limitations that 
        
              * prevent it from being used alone. First, it does not run in background tabs, which would 
        
              * prevent Angular from initializing an application when opened in a new tab (for example). 
        
              * Second, repeated calls to requestAnimationFrame will execute at the refresh rate of the 
        
              * hardware (~16ms for a 60Hz display). This would cause significant slowdown of tests that 
        
              * are written with several updates and asserts in the form of "update; await stable; assert;". 
        
              * - Both `setTimeout` and `rAF` are able to "coalesce" several events from a single user 
        
              * interaction into a single change detection. Importantly, this reduces view tree traversals when 
        
              * compared to an alternative timing mechanism like `queueMicrotask`, where change detection would 
        
              * then be interleaves between each event. 
        
              * 
        
              * By running change detection after the first of `setTimeout` and `rAF` to execute, we get the 
        
              * best of both worlds. 
        
              */ 
        
             private async raceTimeoutAndRequestAnimationFrame() { 
        
               const timeout = new Promise<void>(resolve => setTimeout(resolve));

. We do plan to do the same thing in zone coalescing.

from angular.

garrettld commented on May 9, 2024

It appears these 2 features together create a sort of deadlock, where CD is waiting on the next animation frame (via requestAnimationFrame), and the view transition (which blocks the next animation frame) is waiting on CD to occur (via afterNextRender). Eventually the view transition times out, the requestAnimationFrame callback runs, and the deadlock is resolved.

I also noticed that this behavior isn't triggered by just any event. I think it's determined by whether there are events that are emitted asynchronously, and their timing relative to the router's work. As an example, the StackBlitz linked below shows an input element that reproduces the bug with NgModel but doesn't reproduce it when you leave off the NgModel. I think this is because NgModel triggers additional CD passes asynchronously that aren't being triggered by the version without NgModel. This isn't an NgModel bug, it's just that NgModel happens to do some stuff asynchronously.

https://stackblitz.com/edit/stackblitz-starters-zz3qp5?file=src%2Froutes.ts

Here's a non-Angular repro that approximates what's happening under the hood: https://stackblitz.com/edit/rxjs-fzehee?devtoolsheight=60&file=index.ts

from angular.

viewTransition not working with eventCoalescing about angular HOT 2 OPEN

Comments (2)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	/**
	* Run change detection after the first of setTimeout and requestAnimationFrame resolves.
	*
	* - `requestAnimationFrame` ensures that change detection runs ahead of a browser repaint.
	* This ensures that the create and update passes of a change detection always happen
	* in the same frame.
	* - When the browser is resource-starved, `rAF` can execute _before_ a `setTimeout` because
	* rendering is a very high priority process. This means that `setTimeout` cannot guarantee
	* same-frame create and update pass, when `setTimeout` is used to schedule the update phase.
	* - While `rAF` gives us the desirable same-frame updates, it has two limitations that
	* prevent it from being used alone. First, it does not run in background tabs, which would
	* prevent Angular from initializing an application when opened in a new tab (for example).
	* Second, repeated calls to requestAnimationFrame will execute at the refresh rate of the
	* hardware (~16ms for a 60Hz display). This would cause significant slowdown of tests that
	* are written with several updates and asserts in the form of "update; await stable; assert;".
	* - Both `setTimeout` and `rAF` are able to "coalesce" several events from a single user
	* interaction into a single change detection. Importantly, this reduces view tree traversals when
	* compared to an alternative timing mechanism like `queueMicrotask`, where change detection would
	* then be interleaves between each event.
	*
	* By running change detection after the first of `setTimeout` and `rAF` to execute, we get the
	* best of both worlds.
	*/
	private async raceTimeoutAndRequestAnimationFrame() {
	const timeout = new Promise<void>(resolve => setTimeout(resolve));