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).
PR Close#51276
This refactoring adds utility functions to add / remove LView from LContainer.
Those utils are preparation for the control flow and defer work.
Existing code was refactored to use the new utility functions and avoid
any code duplication.
PR Close#51191
This commit updates the logic to drop regular imports when all symbols that it brings can be defer-loaded.
The change ensures that there is no mix of regular and dynamic imports present in a source file.
PR Close#51171
Updates the template pipeline's temporary variables phase to reuse
temporary variables within an expression. The algorithm implemented here
reuses variables more aggressively than TemplateDefinitionBuilder. This
change in behavior is acceptable, as it is unlikely to cause any
failures, and implementing the exact behavior observed in
TemplateDefinitionBuilder would be difficult.
PR Close#51100
In some cases it is not feasible to have the template pipeline produce
the exact same compiled output as the TemplateDefinitionBuilder. This
commit adds support to the testing infrastructure to have different
expected output files for each. This option should be used sparingly, as
we want the output to be as close as possible.
PR Close#51100
Updates the TemplateDefinitionBuilder class to generate the `defer` instruction for `{#defer}` blocks. Also generates dependency function that would be invoked at runtime (with dynamic imports inside).
PR Close#51162
This commit brings the logic to calculate teh set of dependencies for each defer block. For each dependency we also identify whether it can be defer-loaded or not.
PR Close#51162
This is a minor refactoring of the ComponentHandler class logic to extract helper function and types to the top level for simplicity and reuse across other functions of the class.
PR Close#51162
This commit updates the logic of the TemplateBinder and DirectiveBinder classes to recognize defer blocks. The logic is updated to prevent Directive and Pipe matching inside the defer block. Instead, the scope for those blocks would be calculated separately.
PR Close#51162
This commit adds a new class called `DeferredSymbolTracker` to keep track of all usages of a particular symbol within a source file and allow to detect whether a symbol can be defer loaded (i.e. if there are any references to a symbol).
PR Close#51162
Creates unit tests for the following APIs
- setInjectorProfiler
- getInjectorProviders
- getInjectorResolutionPath
- getDependenciesFromInjectable
Modifies existing tests in
- packages/examples/core/di/ts/injector_spec.ts
- packages/core/test/render3/jit/declare_injectable_spec.ts
- packages/core/test/render3/jit/declare_factory_spec.ts
because they setup framework injector context manually.
Exports setInjectorProfilerContext in packages/core/src/core_private_export.ts in order for use
in the the modified tests above.
PR Close#48639
This commit introduces 3 new APIs.
getDependenciesFromInstantiation:
- Given an injector and a token that was instantiated by that injector, discover all of the things were injected in the instance of that token
- This API is meant to enable recursive inspection of dependencies. Dependencies returned by this API include which injector they were providedIn, which enables the continous use of getDependenciesFromInstantiation to determine the dependencies of dependencies
getInjectorProviders:
- Given an injector, discover all of the providers that were configured in that injector.
- This API returns information on the configured providers of an injector, including the import path that leads to the container that the provider originated from (NgModule or standalone directive). This enables fine grained inspection to determine where a specific provider comes from.
getInjectorParent:
- Given an injector, discover the parent of that injector.
- This function is meant to be used recursively to discover the entire resolution path from a starting injector to the NullInjector.
These APIs were designed to be used together. For example, getInjectorParent can be used to discover the structure of an injector hierarchy. Once that's done, getInjectorProviders can be used to determine the providers of each injector in that hierarchy.
Another example: getDependenciesFromInstantiation can be used to discover the dependencies of a specific injector constructed instance. From there, we can use getInjectorParent to discover the injector resolution path and map each dependency to a path from the starting injector to the injector that it was provided in.
PR Close#48639
walkProviderTree and processInjectorTypesWithProviders both perform some generic traversal logic of the import graph of an input NgModule or Standalone component. Currently, these functions pass around a `providersOut` array that is used to collect providers at each step of the traversal.
This PR converts those functions to accept visitor callbacks instead of the `providersOut` array. This is done to make the traversal logic of these functions reusable, while leaving it up to the visitor to determine the logic that fires for each visited node.
This refactor would allow us to reuse `walkProviderTree` for injector debugging APIs that could support some cool features in DevTools, like tracing the injector resolution path of an injected property on a component instance all the way up to the specific imported module/standalone component.
PR Close#48639
Currently, understanding dependency injection in Angular requires a lot of context and has been sited in our surveys as one of the largest points of confusion that our users have with the framework. This commit is the beginning of our approach to make debugging dependency injection in Angular easier.
This commit introduces injector profiler callbacks in parts of the framework to emit injector events. It also introduces a default handler for these events. This default handler parses the stream of events to construct some data structures that will support new injector debug APIs.
We have implemented a similar pattern in the past to minimize overhead. There is also the possiblity of making the internal `setInjectorProfiler` function a public debug API in the future, so that users can implement their own handlers to debug DI events. Lastly DI in Angular maps nicely to a stream of events.
For production applications there is no runtime overhead. For applications in dev mode there is some additional overhead from the default profiler handling injector events and holding debug data in memory.
For production applications, dead code elimination should strip all of the code used by this PR.
PR Close#48639
Adds the `ɵsetEnabledBlockTypes` utility that can be used when writing JIT tests using `defer` blocks. Intended usage:
```ts
import {ɵsetEnabledBlockTypes as setEnabledBlockTypes} from '@angular/compiler/src/jit_compiler_facade';
describe('deferred tests', () => {
beforeEach(() => setEnabledBlockTypes(['defer']));
afterEach(() => setEnabledBlockTypes([]));
it('should work', () => {
// test goes here
});
});
```
PR Close#51183
Change sourceSpan for Comment nodes to cover the whole comment
instead of just the opening token.
The primary motivation for this is the interaction between ESLint and
`@angular-eslint`. ESLint can detect unused `eslint-disable` directives
in comments and automatically remove them when running with `--fix`.
This is based on ranges computed from AST spans, and as a result
does not work inside Angular templates - right now all comments
claim to be 4 characters long so only the opening `<!--` is removed.
PR Close#50855
Andrew Kushnir