Prior to this change `this.isStable.pipe(first((isStable) => isStable)).toPromise()` had to be done in multiple places across the framework and the Angular CLI see https://github.com/angular/angular-cli/pull/25856#discussion_r1328158846. In the majority of cases an Observable based `isStable` API is not needed. This also removes the need for RXJS operator imports.
PR Close#51807
This commit updates hydration runtime code to avoid creating an empty array when we can avoid it. Instead, we just check whether the field is `null` directly (without using nullish coalescing).
PR Close#51917
This commit updates the runtime implementation of defer blocks to avoid their triggering on the server. This behavior was described in the RFC (https://github.com/angular/angular/discussions/50716, see "Server Side Rendering Behavior" section): only a placeholder is rendered on the server at this moment. This commit also updates the logic to make sure that the placeholder content is hydrated after SSR.
PR Close#51530
This commit fixes an issue where serialization of a view container fails in case it uses a component host as an anchor. This fix is similar to the fix from #51247, but for cases when we insert a component (that acts as a host for a view container) deeper in a hierarchy.
Resolves#51318.
PR Close#51456
For cases when a root component also acts as an anchor node for a ViewContainerRef (for example, when ViewContainerRef is injected in a root component), there is a need to serialize information about the component itself, as well as an LContainer that represents this ViewContainerRef. Effectively, we need to serialize 2 pieces of info: (1) hydration info for the root component itself and (2) hydration info for the ViewContainerRef instance (an LContainer). Each piece of information is included into the hydration data (in the TransferState object) separately, thus we end up with 2 ids. Since we only have 1 root element, we encode both bits of info into a single string: ids are separated by the `|` char (e.g. `10|25`, where `10` is the ngh for a component view and 25 is the `ngh` for a root view which holds LContainer).
Previously, we were only including component-related information, thus all the views in the view container remained dehydrated and duplicated (client-rendered from scratch) on the client.
Resolves#51157.
PR Close#51247
non-destructive hydration expects the DOM tree to have the same structure in both places.
With this commit, the app will throw an error if comments are stripped out by the http server (eg by some CDNs).
fixes#51160
PR Close#51170
This commit updates an internal hydration logic to make sure that the content of components with i18n blocks is cleaned up before we start rendering it.
Resolves#50627.
PR Close#50644
This commit updates the `ApplicationRef.isStable` API to account for
pending rendering task. This is needed as once a pending rendering task
is done, new macrotask and microtask could be created which previously caused these not
to be intercepted and thus ignored when doing SSR.
PR Close#50425
Hydration requires a stable App to run some logic.
With this warning developers will be informed about potential issues encountered when running an unstable app.
Fixes#50285
PR Close#50295
This commit updates hydration logic to support a scenario where a view container that was hydrated and later on projected to a component that skips hydration. Currently, such projected content is extracted from the DOM (since a component that skips hydration needs to be re-created), but never added back, since the current logic treats such content as "already inserted".
Closes#50175.
PR Close#50199
This commit fixes an issue where a root component with an injected ViewContainerRef (for ex. `inject(ViewContainerRef)`) was triggering a certain code path during hydration which didn't handle this case correctly.
Resolves#50133.
PR Close#50136
This adds context to the error message in the case that a DOM node is not found during the hydration process. It outputs the expected DOM structure based on the lView and tNode rather than an unhelpful text message.
PR Close#49977
This commit updates hydration logic to handle cases when there are projection slots present in a template inside of an `<ng-container>` and when there are regular elements follow an <ng-content> slot (see tests for additional information). With this combination, the logic that annotates regular element locations should fallback to calculating a path from a reference node to that node. In case of an <ng-container>, the comment node is located *after* the node that needs an annotation. An existing logic was mistakenly returning an empty path, which was represented as a pointer to teh reference node. This commit fixes that and triggers a fallback to using a component host node as a reference in this case.
Resolves#49918.
PR Close#49920
Empty text nodes are not present in the server-rendered HTML output, thus we inject a special marker
at a text node location to later restore an empty text node at the client. Currently, we treat text nodes with spaces as "empty" as well, however those spaces are present in the HTML and text nodes are created in a browser. Adding extra annotation in this case results in extra text nodes created on the client and may trigger hydration issues. This commit updates the code to avoid treating text nodes with spaces as "empty".
PR Close#49877
This commit updates the code to log hydration setup warning in dev mode only. Previously, the warning was retained in the code even after optimization, thus making it into production bundles. The warning is meant to let developers know that hydration was enabled, but wasn't activated, so it's safe to tree-shake it away from production bundles.
PR Close#49876
This commit renames an internal token to better align it with the naming of the function (to highlight the fact that it's responsible for DOM part of the hydration).
PR Close#49800
This commit updates the logic that adds the "ng-server-context" attribute to the root elements to also include information about SSR feature enabled got an application.
PR Close#49773
This commit updates the logic to avoid enabling hydration in case server response doesn't contain hydration-related info serialized. It can happen when `provideClientHydration()` call only happens on the client, but not on the server.
PR Close#49750
This commit updates the logic to detect a situation when hydration support was enabled only on the client. If that happens, Angular produces a warning in a console with a link to the error guide.
PR Close#49743
The Domino DOM emulation library doesn't support shadow DOM. For such components we can not guarantee that client and server representations would match perfectly. To avoid hydration mismatch errors, such components are opted out of hydration.
PR Close#49722
Currently, non-destructive hydration for i18n blocks is not supported (but support is coming!).
This commit updates the serialization logic from throwing an error when it comes across an i18n
block to annotating a component with a skip hydration flag.
PR Close#49722
This commit adds the `provideClientHydration` function to the public API. This function can be used to enable the non-destructive Angular hydration.
Important note: the non-destructive hydration feature is in Developer Preview mode, learn more about it at https://angular.io/guide/releases#developer-preview.
Before you can get started with hydration, you must have a server side rendered (SSR) application. Follow the [Angular Universal Guide](https://angular.io/guide/universal) to enable server side rendering first. Once you have SSR working with your application, you can enable hydration by visiting your main app component or module and importing `provideClientHydration` from `@angular/platform-browser`. You'll then add that provider to your app's bootstrapping providers list.
```typescript
import {
bootstrapApplication,
provideClientHydration,
} from '@angular/platform-browser';
// ...
bootstrapApplication(RootCmp, {
providers: [provideClientHydration()]
});
```
Alternatively if you are using NgModules, you would add `provideClientHydration` to your root app module's provider list.
```typescript
import {provideClientHydration} from '@angular/platform-browser';
import {NgModule} from '@angular/core';
@NgModule({
declarations: [RootCmp],
exports: [RootCmp],
bootstrap: [RootCmp],
providers: [provideClientHydration()],
})
export class AppModule {}
```
You can confirm hydration is enabled by opening Developer Tools in your browser and viewing the console. You should see a message that includes hydration-related stats, such as the number of components and nodes hydrated.
Co-authored-by: jessicajaniuk <72768744+jessicajaniuk@users.noreply.github.com>
Co-authored-by: alan-agius4 <17563226+alan-agius4@users.noreply.github.com>
PR Close#49666
This commit updates the logic to handle a case when the `ngSkipHydration` attribute is applied to the root node of an app. In this case, the hydration info should not be serialized and the contents of the app on the client should be cleared up before initial rendering.
PR Close#49675
This commit adds a logic to output basic hydration stats into a console. This is also helpful to ensure that hydration is enabled and works.
PR Close#49617
This fixes two cases where DOM node navigation during hydration would be broken. It also fixes an infinite loop on clearing DOM during skip hydration blocks
PR Close#49615
This commit implements a simple tracker of the pending tasks during initial rendering. The class allows adding and removing tasks from the set. The class also exposes a promise that gets resolved once the last task is removed.
This tracker is needed to keep track of ongoing processes like Router navigation (and potentially HTTP requests) and acts as a signaling mechanism to SSR and hydration that the application is in the "stable" state and a serialization can be performed.
This class would also act as a future replacement for the `ApplicationRef.isStable` for zoneless applications.
PR Close#49576
This commit updates the serialization logic to avoid serializing a path for a node that was content projected (based on template information), but is not present in the DOM. This can happen if a <ng-content> is used with the *ngIf="false", for example: `<ng-content *ngIf="false" />`.
PR Close#49590
Previously, we've annotated all disconnected DOM nodes, even if they are not used in content projection. However, this situation is only possible in content projection and if it happens in other cases (for example, when a node was removed using direct DOM manipulations), this should be a mismatch error.
PR Close#49549
This adds user friendly error messages outlining exactly where hydration
mismatches occur and what was expected with easy to read stringified
DOM. It also includes a pointer to exactly where the mismatch happened
and lets the user know what was expected.
PR Close#49502
This commit updates the hydration logic to handle situations where DOM nodes might end up
being disconnected from the DOM tree. We serialize ids of those nodes into the hydration
state transfer data and use the information to switch from hydration to the regular "creation
mode" at runtime.
This situation may happen during the content projection, when some nodes don't make it
into one of the content projection slots (for example, when there is no default
<ng-content /> slot in projector component's template).
Note: we leverage the fact that we have this information available in the DOM emulation
layer (in Domino) for now. Longer-term solution should not rely on the DOM emulation and
only use internal data structures and state to compute this information.
PR Close#49471
This commit updates the serialization logic to detect a situation when i18n was used for a template and throw an error to indicate that hydration for i18n blocks is not yet supported.
Hydration for i18n blocks will be added in follow up versions.
PR Close#49497
Angular Hydration uses Components as a hydration boundary, i.e. you can enable/disable hydration on per-component basis. This commit enforces that the `ngSkipHydration` can only be applied on component host nodes (an error if thrown otherwise).
PR Close#49500
This commit updates the serialization logic to recognized similar repeated views and instead of including the same info over and over again, a special field is added to the serialized view object with a number of repetitions. The hydration logic also recognizes the flag and creates the necessary number of dehydrated views in a container.
This optimization should help minimize the amount of extra annotations required for cases like *ngFor with large number of items.
PR Close#49475
This commit adds a logic to remove all views that were not cleaimed during the hydration. The process is started once the ApplicationRef becomes stable on the client (which matches the timing of serialization on the server).
PR Close#49455
This commit adds serialization and hydration logic for content projection.
While hydration for regular elements relies on their location in the TNode tree, the content projection may move elements around, so in order to hydrate them correcty, the runtime needs some extra information. This commit adds a serialization logic that adds element locations (instructions on how to navigate to a particular element from another known location of other element) into the hydration state for the following cases:
- when a TNode is a first element in projection segment (other nodes are linked from that node)
- when a TNode's next sibling is different before and after projection (we serialize extra info about the template-based sibling)
- when a TNode's previous sibling was a content projection (i.e. `<ng-content>` slot), because we can not rely on the previous element in this case (projection happens at a later point)
PR Close#49454
This commit adds serialization and hydration logic for content projection.
While hydration for regular elements relies on their location in the TNode tree, the content projection may move elements around, so in order to hydrate them correcty, the runtime needs some extra information. This commit adds a serialization logic that adds element locations (instructions on how to navigate to a particular element from another known location of other element) into the hydration state for the following cases:
- when a TNode is a first element in projection segment (other nodes are linked from that node)
- when a TNode's next sibling is different before and after projection (we serialize extra info about the template-based sibling)
- when a TNode's previous sibling was a content projection (i.e. `<ng-content>` slot), because we can not rely on the previous element in this case (projection happens at a later point)
PR Close#49454
This restores the separation between adjacent text nodes that is lost during server serialization when parsed by the browser. It adds a special comment node just prior to the serialization process that is then restored as a separated node during hydration.
PR Close#49419
During DOM serialization, empty text nodes are lost when the client parses the DOM. To solve this problem comment nodes are added where the empty nodes are located right before serialization. Those comments then get replaced during hydration with the proper empty text nodes.
PR Close#49419
This commit implements hydration support for view containers, which should make `*ngIf`, `*ngFor` and other structural directive work with hydration.
The logic also respects the `ngSkipHydration` flag and skips hydration in such cases.
PR Close#49382
This commit updates the serialization logic to include information about views from view containers (based on underlying LContainer info). The information is needed during hydration to pick a correct instance of dehydrated view (this logic will be implemented in a followup commit).
PR Close#49382
This commit updates the serialization logic to include information about templates that were used to create embedded views. The information is needed during hydration to pick a correct instance of dehydrated view (this logic will be implemented in a followup commit).
PR Close#49382
