This updates tests and examples only to prepare for zoneless by default.
These changes were identified and made as part of #63382. Anything that
failed gets `provideZoneChangeDetection` unless the fixes were easily
and quickly determined.
It also adds the zoneless provider to the `initTestEnvironment` calls
for tests in this repo to prevent regressions before #63382 is merged.
PR Close#63668
Previously Elements was assuming that every output was an RxJS `Subject` and
supports `.pipe()`. This is not true for `output()`-based outputs which
have `.subscribe()` but not `.pipe()`. This commit fixes such outputs by
using a `new Observable` instead of `map` to forward outputs.
PR Close#57535
The custom element implementation previously used a custom code path for
setting inputs, which contained bespoke code for writing input properties,
detecting whether inputs actually change, marking the component dirty,
scheduling and running CD, invoking `ngOnChanges`, etc. This custom logic
had several downsides:
* Its behavior different from how Angular components behave in a normal
template.
For example, inputs setters were invoked in `NgZone.run`, which (when
called from outside the zone) would trigger synchronous CD in the
component, _without_ calling `ngOnChanges`. Only when the custom rAF-
scheduled `detectChanges()` call triggered would `ngOnChanges` be called.
* CD always ran multiple times, because of the above. `NgZone.run` would
trigger CD, and then separately the scheduler would trigger CD.
* Signal inputs were not supported, since inputs were set via direct
property writes.
This change refactors the custom element implementation with two changes:
1. `ComponentRef.setInput` is used instead of a custom code path for
writing inputs.
This allows us to drop all the custom logic related to managing
`ngOnChanges`, since `setInput` does that under the hood. `ngOnChanges`
behavior now matches how the component would behave when _not_ rendered
as a custom element.
2. The custom rAF-based CD scheduler is removed in favor of the main Angular
scheduler, which now handles custom elements as necessary.
Running `NgZone.run` is sufficient to trigger CD when zones are used, and
the hybrid zoneless scheduler now ensures CD is scheduled when `setInput` is
called even with no ZoneJS enabled. As a result, the dedicated elements
scheduler is now only used when Angular's built-in scheduler is disabled.
As a concession to backwards compatibility, the element's view is also
marked for refresh when an input changes. Doing this allows CD to revisit
the element even if it becomes dirty during CD, mimicking how it would be
detected by the former elements scheduler unconditionally refreshing the
view a second time.
As a part of this change, the elements tests have been significantly
refactored. Previously all of Angular was faked/spied, which had a number
of downsides. For example, there were tests which asserted that change
detection only happens once when setting multiple inputs. This wasn't
actually the case (because of `NgZone.run` - see logic above) but the test
didn't catch the issue because it was only spying on `detectChanges()` which
isn't called from `ApplicationRef.tick()`. Even the components were fake.
Now, the tests use real Angular components and factories. They've also been
updated to not use `fakeAsync`.
A number of tests have been disabled, which were previously asserting
behavior that wasn't matching what was actually happening (as above). Other
tests were disabled due to real differences with `ngOnChanges` behavior,
where the current behavior could be seen as a bug.
Fixes#53981
BREAKING CHANGE: as part of switching away from custom CD behavior to the
hybrid scheduler, timing of change detection around custom elements has
changed subtly. These changes make elements more efficient, but can cause
tests which encoded assumptions about how or when elements would be checked
to require updating.
PR Close#56728
This commit starts exposing `isSignal` for inputs in the
`ComponentMirror`. We initially had this as a draft when rolling out
signal inputs, but there were no good use-cases, so we skipped it.
Now, inside G3, for the testing infrastructure and rolling out
advancements for signal inputs, having this information is necessary and
allows identifying signal inputs without "accessing fields" on the class
that may cause side-effects (like triggering setters).
PR Close#56402
In combination with the TS `noImplicitOverride` compatibility changes,
we also want to follow the best-practice of adding `override` to
members which are implemented as part of abstract classes. This
commit fixes all instances which will be flagged as part of the
custom `no-implicit-override-abstract` TSLint rule.
PR Close#42512
`ComponentNgElementStrategy` is supposed to call `ngOnChanges()` on the
underlying component instance if available, but not fail if the
component does not have an `ngOnChanges()` method. This works as
expected. However, the test used to verify that was invalid; i.e. the
test would pass even if `ComponentNgElementStrategy` would try to call
`ngOnChanges()` on a component without such a method.
This commit replaces the invalid test with a new one that correctly
verifies that `ComponentNgElementStrategy` does not try to call
`ngOnChanges()`.
PR Close#39452
Previously, the `componentRef` property of `FakeComponentFactory` used
in `elements` tests was initialy set to a spy object with all mock
properties defined as spied methods. Later, the properties where
overwritten to the actual mock values.
This commit simplifies the creation of `componentRef` by correctly using
the arguments of [jasmine.createSpyObj()][1] to specify the desired
shape of the spy object (separating spied properties from methods and
directly providing the mock values).
[1]: https://jasmine.github.io/api/3.5/jasmine.html#.createSpyObj
PR Close#39452
Default change detection fails in some cases for @angular/elements where
component events are called from the wrong zone.
This fixes the issue by running all ComponentNgElementStrategy methods
in the same zone it was created in.
Fixes#24181
PR Close#37814
Previously, when an input property was initially set to `undefined` it
would not be correctly recognized as a change (and trigger
`ngOnChanges()`).
This commit ensures that explicitly setting an input to `undefined` is
correctly handled the same as setting the property to any other value.
This aligns the behavior of Angular custom elements with that of the
corresponding components when used directly (not as custom elements).
PR Close#36140
Previously, when an input property was set on an `NgElement` before
instantiating the underlying component, the `SimpleChange` object passed
to `ngOnChanges()` would have `firstChange` set to false, even if this
was the first change (as far as the component instance was concerned).
This commit fixes this by ensuring `SimpleChange#firstChange` is set to
true on first change, regardless if the property was set before or after
instantiating the component. This alignthe behavior of Angular custom
elements with that of the corresponding components when used directly
(not as custom elements).
Jira issue: [FW-2007](https://angular-team.atlassian.net/browse/FW-2007)
Fixes#36130
PR Close#36140
Kristiyan Kostadinov