Recursive template with @defer about angular

[JoostK]

This happens because the IntersectionObserver used to implement the on viewport trigger is asynchronous, so each level introduces its own microtick delay and therefore an additional round of change detection.

The documentation also states that the on viewport trigger is driven by IntersectionObserver, confirming its asynchronous behavior, so this isn't a bug per se. That said, I can see how a "preflight" viewport test might help avoid the additional microtick latency and its associated change detection cycle.

[JoostK]

Even that isn't great really, as it would result in a forced layout.

[olegdunkan]

I reopen the issue because I need some clarification from angular team.
Is it ok to execute template expressions O(n^2) times in the case of defered recursive template?

[alxhub]

I'm going to close this as working-as-intended.

In general, using @defer recursively this way will do N change detections as it's truly a waterfall of rendering:

1. A @defer block is rendered and creates the placeholder element in the first change detection.
2. IntersectionObserver asynchronously observes the placeholder in the layout and fires an event.
3. That event triggers the @defer block, and the next round of change detection runs, creating the next @defer block (goto 1)

It's not feasible for Angular to synchronously evaluate the on viewport condition as that would require reflowing the page in the middle of rendering, which could have a significantly negative performance impact on the rest of the application.

Each template expression will be executed O(N) times - once for each step in the waterfall.

You observe your logging statement being called O(N^2) times because each instance of the template has its own logging binding, so you end up with N instances * O(N) calls per instance.

[olegdunkan]

In general, using @defer recursively this way will do N change detections as it's truly a waterfall of rendering

@alxhub May I conclude that using recursive template is anti-pattern in angular?

[alxhub]

Recursive templates aren't really related to this issue. They don't by themselves cause waterfalls, and it's easy to rewrite the example into a waterfall without recursive templates at all.

[olegdunkan]

@alxhub now I see, the problem is we can't render all ng-template embedded views in one changes detection round because IntersectionObserver triggers that, other rounds. But if use recursive ng-template without @defer angular renders it with help of only one changes detection round.
Unfortunately we can't prevent execution of template expressions previously created (by IntersectionObserver's changes detection rounds) embedded views because there is no way to control changes detection strategy per embedded view.
As I know, signals will be able to mark view for check and we will be able to avoid situation like above. Is that related to embedded view also or it is related only to component level view?