Roll out the red carpet for Zoneless Angular by providing custom ChangeDetectionStrategy

[yjaaidi]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

In order to implement zoneless Angular apps, developers must either trigger change detection manually or use libraries like RxAngular and custom pipes (e.g. PushPipe) & directives.

In order to provide a seamless way of migrating to zoneless Angular, without necessarily switching to signal-based components (which are not here yet), it would be nice if apps that are not heavily relying on Zone.js (i.e. using Signals or RxJS + AsyncPipe) could provide a custom change detection strategy.

This strategy would allow developers to decide when to schedule change detection for a view when it is marked dirty.

This could be combined with #49882

Warning: We need a default built-in zoneless strategy

The main problem with this approach is that the most naive implementation would simply trigger change detection whenever a view is marked for check. This could cause worse performance than zoneful apps and would break if Signals are used as Signals would be read during write phase (because views are marked dirty during this phase)

That is why, this should be provided with a default zoneless strategy with a generally efficient scheduling + coalescing strategy.

Proposed solution

This is how the ChangeDetectionStrategy interface could look:

interface ChangeDetectionStrategy {
  handleMarkDirty(changeDetectorRef: ChangeDetectorRef): void
}

and it could be provided at the app level:

bootstrapApplication(RootCmp, {
  providers: [
    {provide: ChangeDetectionStrategy, useClass: ZonelessChangeDetectionStrategy},
    {provide: NgZone, useClass: NoopNgZone},
  ]
})

Alternatives considered

Use RxAngular

[atscott]

Hi @yjaaidi, we're absolutely working on what the APIs will be around scheduling in a zoneless application. Angular today does not provide any real support for this. Since one of the goals of the signals project is to make Angular zoneless by default, more seamless support for zoneless is a requirement.

I'm going to close this issue since it really falls under the zoneless/signals project that's already tracked on the roadmap. Rather than going straight to a solution, we'll be evaluating the problem space as a whole.

[yjaaidi]

Thanks @atscott for your feedback.
I understand that this is part of the roadmap and it should be handled with care as there are lots of different considerations to take into account... and that I am probably missing.

On other hand, the two issues are different, while this one involves more changes, the other one #49882 is less intrusive IMO.
Also, such APIs wouldn't go against thinking of a better solution in the future. As a matter of fact, providing such an API would allow creative teams in the community (e.g. RxAngular) to explore further grounds and help design the best fit.

[atscott]

Also, such APIs wouldn't go against thinking of a better solution in the future.

Since we don't yet know what zoneless looks like, how can you know if this proposal would even work well together with that? Regardless, this is also a proposed solution based on current APIs that were never designed to work well in a zoneless application. Let's wait until we have real APIs for zoneless applications before jumping the gun on new features built on top of the existing classes. This proposal might look entirely different at that point.

[yjaaidi]

I see your point Andrew.

TL;DR: providing such APIs would allow more zoneless exploration and help cleaning up zone.js coupling + provide more input to the Angular team for the future zoneless APIs

Today, we don't know how Angular's native zoneless support will be but we know how current zoneless apps look like mainly thanks to @BioPhoton's & RxAngular's team work.
While most large zoneless apps are in private repos, there are few open-source examples like https://github.com/tastejs/angular-movies or https://marmicode.io (https://github.com/marmicode/marmicode)

Of course, as you mentioned, current APIs were not designed to work zoneless, and more importantly the whole ecosystem is not zoneless ready meaning that there are some rough edges (e.g. using Angular Material).
But, providing such APIs to allow more zoneless exploration, could allow the community to help clean up the zone.js coupling. (e.g. #48198)

[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.}