elements: no coalescing of change detection invocations across instances

[gkalpak]

🐞 bug report

Affected Package

The issue is caused by package @angular/elements.

Is this a regression?

No.

Description

While Angular custom elements do coalesce change detection invocations per element instance (see scheduleDetectChanges()), there is no coalescing across other instances of the same element or other elements (even for those on the same injector or component tree.

This results in too many CDs on pages/routes with many custom elements and can negatively affect performance. (This is the case for example in https://angular.io/guide/router, which has ~200 custom elements.)

Anything else relevant?

Related issues: #23813, #33059

EDIT:
Similar issue with useful context (closed in favor of this one): #23813
PR (that would at least cover some usecases): #23885

[pkozlowski-opensource]

This is a confirmed issues with elements <-> change detection interaction. On the mentioned page we are getting the following picture under the profiler (the highlighted task of ~400ms is showing the issue):

[gkalpak]

Similar issue with useful context (closed in favor of this one): #23813
PR (that would at least cover some usecases): #23885

[dbaranovsky97]

We also faced this problem. The components initialization time grows in a parabola along with the growth of the number of components:

Here is a testbed where you can see it - https://stackblitz.com/edit/angular-nn5ec8
I also wrote a custom strategy there - https://stackblitz.com/edit/angular-nn5ec8?file=src/element-strategy/component-factory-custom-strategy.ts . There I redesigned the scheduler so that it runs all tasks in one requestAnimationFrame. This greatly improved performance (although it is still worse than in regular angular components):

Perhaps you should use the same approach in the default strategy? If it's ok, I can make a pull request.