Add zoneless scheduler to the ApplicationRef.isStable indicator

[atscott]

Commit 1:
test(core): Add scheduler in tests to tie into ApplicationRef.isStable

This commit updates the test scheduler implementation to contribute to
ApplicationRef stableness.

Commit 2
refactor(core): Move change detection scheduler implementation to core

This commit moves the implementation of the change detection scheduler
used for testing to angular/core along with a (private export) provider function.

Note: Naming of the provider function is absolutely not final (and not
public API). I would prefer one that did not mention "zones"
but the easiest thing for now is to have a "Zone" and "Zoneless" naming
scheme.

[eneajaho]

Hi
Regarding naming, I was thinking of having something like we do in http client (provideHttpClient(withFetch())).

provideChangeDetection(withZone());

The only issue with that is that a required migration would be needed to migrate every app to use it.

And then have it removed for default zoneless change detection.

[JeanMeche]

Hi Regarding naming, I was thinking of having something like we do in http client (provideHttpClient(withFetch())).

provideChangeDetection(withZone());

The only issue with that is that a required migration would be needed to migrate every app to use it.

And then have it removed for default zoneless change detection.

Then probably the default could be zonefull, and the api could be provideChangeDetection(withoutZone());

[eneajaho]

Hi Regarding naming, I was thinking of having something like we do in http client (provideHttpClient(withFetch())).

provideChangeDetection(withZone());

The only issue with that is that a required migration would be needed to migrate every app to use it.
And then have it removed for default zoneless change detection.

Then probably the default could be zonefull, and the api could be provideChangeDetection(withoutZone());

Yeah that's the point, because the default would be without zone, it wouldn't be necessary to write it at all.

[atscott]

We already have the provideZoneChangeDetection provider function. When zoneless becomes the default, we can deprecate this function and have a migration to remove it entirely. Naming of this function is still an open question but this does not add it to the public API yet so we aren't really at the bikeshedding stage

edit - Excerpt from the design doc:

We have an existing API that is provideZoneChangeDetection that allows developers to configure how ZoneJS behaves and drives change detection scheduling [...] A tempting name might be something like provideZonelessChangeDetection as the other option. With zoneless being our ideal future, it would be nice to avoid the “Zone” name in the API, for example provideChangeDetectionScheduler(). On the flipside, if zoneless is the future, then ideally we deprecate this provider and have it the new default instead of provideZoneChangeDetection, which is currently built into both TestBed and application bootstrap. In that respect, provideZonelessChangeDetection might be a good name while the default is zones.

[atscott]

This PR was merged into the repository by commit 5978b3d.

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