The mentioned 2 classes have been combined since it is no longer required to have a separate `SharedStylesHost` for SSR. This changes also reduces the memory usage footprint as remove 1 Map that stores the CSS strings.
PR Close#49424
This reverts commit 1a6ca68154.
This breaks tests in google3 which might be depending on private APIs. We
need to update these tests before we can land this PR.
PR Close#49449
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
The below error is displayed during some tests
```js
ERROR: 'Unhandled Promise rejection:', 'Cannot read properties of null (reading 'markForCheck')', '; Zone:', 'ProxyZone', '; Task:', 'Promise.then', '; Value:', TypeError: Cannot read properties of null (reading 'markForCheck')
TypeError: Cannot read properties of null (reading 'markForCheck')
at AsyncPipe2._updateLatestValue (http://angular-ci.local:9876/base/dist/legacy-test-bundle.spec.js?49174f830d8743d5c8a9551b77550b859b934291:51947:19)
```
This is caused by the fact that `ref` in `AsyncPipe` is initialized with a value of `null` which causes `_updateLatestValue` to fail since it is not expected to be `null`.
This change ensures that a `ref` is always provided and that all subscriptions are disposed off after each test.
PR Close#49433
Prior to this change, a random application ID was generated each time which forced users using server rendering to provide an application ID themselves. This was needed to handle rare cases when multiple Angular applications are rendered on the same page.
With this change the application ID is no longer generated randomly and instead it is hard coded.
BREAKING CHANGE:
The `APP_ID` token value is no longer randomly generated. If you are bootstrapping multiple application on the same page you will need to set to provide the `APP_ID` yourself.
```ts
bootstrapApplication(ComponentA, {
providers: [
{ provide: APP_ID, useValue: 'app-a' },
// ... other providers ...
]
});
```
PR Close#49422
This commit deprecated ` BrowserModule.withServerTransition` instead `APP_ID` should be used instead to configure the app id.
DEPRECATED: `BrowserModule.withServerTransition` has been deprecated. `APP_ID` should be used instead to set the application ID.
NB: Unless, you render multiple Angular applications on the same page, setting an application ID is not necessary.
Before:
```ts
imports: [
BrowserModule.withServerTransition({ appId: 'serverApp' }),
...
]
```
After:
```ts
imports: [
BrowserModule,
{ provide: APP_ID, useValue: 'serverApp' },
...
],
```
PR Close#49422
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49304
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
BREAKING CHANGE:
`ComponentFactoryResolver` has been removed from Router APIs.
Component factories are not required to create an instance of a component
dynamically. Passing a factory resolver via resolver argument is no longer needed
and code can instead use `ViewContainerRef.createComponent` without the
factory resolver.
PR Close#49239
With the introduction of `EnvironmentInjector`, we added an operation to run
a function with access to `inject` tokens from that injector. This operation
only worked for `EnvironmentInjector`s and not for element/node injectors.
This commit deprecates `EnvironmentInjector.runInContext` in favor of a
standalone API `runInInjectionContext`, which supports any type of injector.
DEPRECATED: `EnvironmentInjector.runInContext` is now deprecated, with
`runInInjectionContext` functioning as a direct replacement:
```typescript
// Previous method version (deprecated):
envInjector.runInContext(fn);
// New standalone function:
runInInjectionContext(envInjector, fn);
```
PR Close#49396
This commit adds the `provideServerSupport()` function that returns the `EnvironmentProviders` needed to setup server rendering without NgModules.
PR Close#49380
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