Prior to this commit, `TestBed` would require tests call `flushEffects`
or `fixture.detectChanges` in order to execute effects. In general, we
want to discourage authoring tests like this because it makes the timing
of change detection and effects differ from what happens in the
application. Instead, developers should perform actions and `await` (or
`flush`/`tick` when using `fakeAsync`) some `Promise` so that Angular
can react to the changes in the same way that it does in the
application.
Note that this still _allows_ developers to flush effects synchronously
with `flushEffects` and `detectChanges` but also enables the <action>,
`await` pattern described above.
PR Close#53843
Previously effects were queued as they became dirty, and this queue was
flushed at various checkpoints during the change detection cycle. The result
was that change detection _was_ the effect runner, and without executing CD,
effects would not execute. This leads a particular tradeoff:
* effects are subject to unidirectional data flow (bad for dx)
* effects don't cause a new round of CD (good/bad depending on use case)
* effects can be used to implement control flow efficiently (desirable)
This commit changes the scheduling mechanism. Effects are now scheduled via
the microtask queue. This changes the tradeoffs:
* effects are no longer limited by unidirectional data flow (easy dx)
* effects registered in the Angular zone will trigger CD after they run
(same as `Promise.resolve` really)
* the public `effect()` type of effect probably isn't a good building block
for our built-in control flow, and we'll need a new internal abstraction.
As `effect()` is in developer preview, changing the execution timing is not
considered breaking even though it may impact current users.
PR Close#51049
This commit adds a provider function that allows developers to configure
the `NgZone` instance for the application. In the future, this provider
will be used for applications to specifically opt-in to change detection
powered by ZoneJS rather than it being provided by default.
This API does _not_ specifically provide support for developers to define their own
`NgZone` implementation or opt in to `NoopNgZone` directly. Both of
these are possible today, but are effectively unsupported (applications
that use these are left to their own devices to run change detection at
the appropriate times). That said, developers can still use DI in
`bootstrapApplication` to provide an `NgZone` implementation instead,
it's just not specifically available in the
`provideZoneChangeDetection` function.
PR Close#49557
This commit moves the providers for `NgZone`-based change detection to a
single provider function. This function is currently called by default
in all places where `NgZone` was provided
(`bootstrapApplication`, `bootstrapModule`, and `TestBed`).
When we want to make Angular applications zoneless by default, we
can make a public provider method that has to be used in order to enable
the zone change detection features. When this method is not called,
Angular would use `NoopNgZone` by default and not initialize any
subscriptions to the `NgZone` stability events.
Side note: There are actually two places that `NgZone` is provided for `TestBed`
(providers in `compileTestModule` and `BrowserTestingModule`). This
likely doesn't need to be in both locations.
PR Close#49373
Tests sometimes do not mock out the `PlatformLocation` and end up
affecting real browser state. This can mean changing the real URL of the
browser during a test, updating the History state object, or any number
of other stateful operations. This can result in a test unintentionally affecting
other tests in the suite because the browser state does not usually get
reset before the next test runs. Providing `MockPlatformLocation` by
default prevents these types of accidental test leakages.
In addition, not providing `MockPlatformLocation` by default led to
developers needing to add `RouterTestingModule` to their test suite to
avoid the problems above. This module has spy `Location` providers which
prevent those issues. This commit now makes `RouterTestingModule`
obsolete. Developers can now just use `RouterModule.forRoot` or
`provideRouter` directly in tests _without_ needing to learn to import
additional test providers or modules.
With this, we should consider deprecating `RouterTestingModule` altogether and
migrating developers to `RouterModule.forRoot` or `provideRouter` instead. There
are some small differences between `SpyLocation` and
`MockPlatformLocation` that might cause tests to fail after the
migration (`MockPlatformLocation` is actually more correct in its
behaviors). If this happens, we can advise developers to also add
`provideLocationMocks()` to their test providers, which would re-provide
the `SpyLocation` like before and should make the tests pass again.
BREAKING CHANGE: `MockPlatformLocation` is now provided by default in tests.
Existing tests may have behaviors which rely on
`BrowserPlatformLocation` instead. For example, direct access to the
`window.history` in either the test or the component rather than going
through the Angular APIs (`Location.getState()`). The quickest fix is to
update the providers in the test suite to override the provider again
`TestBed.configureTestingModule({providers: [{provide: PlatformLocation, useClass: BrowserPlatformLocation}]})`.
The ideal fix would be to update the code to instead be compatible with
`MockPlatformLocation` instead.
PR Close#49137
This commit prepares the code of the `BrowserTestingModule` to include the `MockPlatformLocation` by deafult in the future. With this change, the set of providers to add the `MockPlatformLocation` would be disabled by a flag, which will be switched in v16.
PR Close#48651
This change allows ReflectiveInjector to be tree shaken resulting
in not needed Reflect polyfil and smaller bundles.
Code savings for HelloWorld using Closure:
Reflective: bundle.js: 105,864(34,190 gzip)
Static: bundle.js: 154,889(33,555 gzip)
645( 2%)
BREAKING CHANGE:
`platformXXXX()` no longer accepts providers which depend on reflection.
Specifically the method signature when from `Provider[]` to
`StaticProvider[]`.
Example:
Before:
```
[
MyClass,
{provide: ClassA, useClass: SubClassA}
]
```
After:
```
[
{provide: MyClass, deps: [Dep1,...]},
{provide: ClassA, useClass: SubClassA, deps: [Dep1,...]}
]
```
NOTE: This only applies to platform creation and providers for the JIT
compiler. It does not apply to `@Compotent` or `@NgModule` provides
declarations.
Benchpress note: Previously Benchpress also supported reflective
provides, which now require static providers.
DEPRECATION:
- `ReflectiveInjector` is now deprecated as it will be remove. Use
`Injector.create` as a replacement.
closes#18496
Andrew Scott