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
This refactor extracts the `NgZone` microtask subscription to a new
"ChangeDetectionScheduler". With this change, `ApplicationRef` not
longer injects `NgZone` directly. In the future, we can update the
providers that depend on `NgZone` to not use zones by default but
instead require a specific-opt in.
PR Close#49373
This extracts the zone-based error handling in `ApplicationRef` to a new
token. This works towards removing `NgZone` as a dependency in
`ApplicationRef`.
PR Close#49373
`ApplicationRef.isStable` is entirely powered by the state of `NgZone`.
The implementation should be part of `NgZone` code rather than built in
to `ApplicationRef`. In the future, `ApplicationRef.isStable` should
likely be removed in favor of the API living on the `NgZone`
class/interface instead.
PR Close#49373
add function `provideServiceWorker` to register a service worker in standalone applications without using `ServiceWorkerModule.register()`
PR Close#48247
Prior to this change component styles generated on the server where removed prior to the client side component being rendered and attached it's own styles. In some cases this caused flickering. To mitigate this `initialNavigation: enabledBlocking'` was introduced which allowed the remove of server styles to be defer to a latter stage when the application has finished initialization.
This commit changes the need for this, by not removing the server generated component styles and reuse them for client side rendering.
PR Close#48253
Prior to this change the component IDs where generated based on a counter. This is problematic as there is no guarantee that a component will get the same ID that was assigned on the server when generated on the client side.
This is paramount to be able to re-use the component styles generated on the server.
PR Close#48253
Before this change `ɵɵdefineDirective` called `ɵɵdefineComponent` under the hood. This is problematic for the consistent component id generation as it could result in hash collisions for certain directives. Directives however do not require an id.
This changes moves common definition generation logic into a separate function that is re-used in `ɵɵdefineDirective` and `ɵɵdefineComponent`.
PR Close#49350
The decorator downlevel transform is never used for actual class
decorators because Angular class decorators rely on immediate execution
for JIT. Initially we also supported downleveling of class decorators
for View Engine library output, but libraries are shipped using partial
compilation output and are not using this transform anymore.
The transform is exclusively used for JIT processing, commonly for
test files to help ease temporal dead-zone/forward-ref issues. We can
remove the class decorator downlevel logic to remove technical debt.
PR Close#49351
The private util `isObservable` was actually just testing the same thing as`isSubscribable()`. As the implementation is closer to the function's name, let's only keep ``isSubscribable`.
PR Close#49295
This adds the ngSkipHydration annotation, which allows users to
opt hydration boundaries out of hydration. This enables incremental
adoption of hydration by letting users skip hydration on components
that have implementation issues that conflict with hydration.
co-authored-by: AndrewKushnir <akushnir@google.com>
PR Close#49345
This commit incrementally builds on top of #49285 and adds the logic to hydrate <ng-container>s and their contents. This implementation supports simple <ng-container>s that don't have any Angular features (like *ngIf/*ngFor, etc) and are not content-projected.
The subsequent commits will extend the logic further to support more complex scenarios.
PR Close#49303
This commit incrementally builds on top of https://github.com/angular/angular/pull/49271 and adds the logic to hydrate elements and text nodes that don't have any Angular features (like *ngIf/*ngFor, etc) and are not content-projected.
The subsequent commits will extend the logic further to support more complex scenarios.
Co-authored-by: Jessica Janiuk <jessicajaniuk@google.com>
Co-authored-by: Andrew Kushnir <akushnir@google.com>
PR Close#49285
Close#45698
KeyEventsPlugin now has different behavior with EventsPlugin, it will
always run inside ngZone with ngZone.runGuarded() no matter the
component is initialized inside or outside of NgZone, this PR
make sure KeyEventsPlugin bahave the same with other events.
PR Close#49330
Previously (at the early days of Ivy) a TNode used to keep an array of TViews, but the logic was changed since that time, but the `tViews` field remained on TNode interface (+ corresponding typings).
This commit renames TNode.tViews to TNode.tView and cleans up typings.
PR Close#49313
**Important note**: this is a first commit in a series of commits that will be needed
to support non-destructive hydration. Stay tuned for further updates!
This commit lays the foundation on top of which more hydration logic will be
added in follow up PRs. This PR includes:
* Initial serialization of hydration data
* Data transfer of hydration annotations from server side to client
* Accessing hydration info and populating internal data structures
* Initial APIs (currently private) that enable hydration (in a tree-shakable manner)
* Cleanup of annotations post hydration
* Initial test infrastructure and basic test cases
This commit does **not** expose any public APIs. They'll be exposed later, when
more hydration logic is implemented to a state when it can cover most common
use-cases.
Co-authored-by: Jessica Janiuk <jessicajaniuk@google.com>
Co-authored-by: Andrew Kushnir <akushnir@google.com>
PR Close#49271
