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
This commit updates the Injector.create function to accept the `Provider` type in addition to the `StaticProvider` type. This should make it easier to work with the Injector.create function and have less type casts if you have a list of `Provider`s available.
PR Close#49587
Host property bindings beginning with `attr.` should have `Attribute` binding kind, and result in an `attribute` instruction.
This should really be handled in the parser in the future.
PR Close#51188
Templates may contain special `svg` and `math` elements, as well as logical descendants of those elements (e.g. `svg` may contain `g`). These will be parsed with a special colon-prefixed *namespace identifier*, such as `:svg:svg`, or `:svg:g`, or `:math:infinity`.
The template pipeline now considers these namespace prefixes, and stores them specially on the Element and Template data structures, ultimately generating the appropriate runtime instructions to change namespaces when needed.
PR Close#51188
When a container-like element has the `ngNonBindable` special attribute, bindings are disabled for it and its descendants. This requires emitting the `disableBindings` and `enableBindings` instructions when nested content exists.
PR Close#51188
Previously we refactored the compilation to use the concepts of "jobs" and "units." However, old type aliases were provided to avoid changing all call-sites in bulk. Here, those aliases are deleted, and call sited updated:
1. `ComponentCompilation` becomes `ComponentCompilationJob`.
2. `ViewCompilation` becomes `ViewCompilationUnit`.
PR Close#50899
Interestingly, host bindings are parsed quite differently from template functions. For example, bindings such as `[style.foo]: 3px` would be parsed into a value, unit, and type when bound to a template, but will not be parsed as such when used in a host binding.
In this commit, we remedy this shortcoming by adding support for bindings in host binding functions to the template pipeline. In particular, we create a phase to process these bindings, and transform them into the correct output binding kind.
Additionally, we fix some other minor bugs and omissions.
Finally, we enable compilation of host bindings with the template pipeline, which requires us to turn off a number of failing tests.
PR Close#50899
Alter the compiler code to ingest and process host bindings, using the newly updated compilation passes.
This is currently switched off in the outer compiler layer, but lays the foundation for actually generating the host binding functions using template pipeline.
PR Close#50899
Today, bindings on templates are ingested in highly distinct ways, depending on the parsed binding kind, as well as special cases for `style` and `class`. This makes it very difficult to also ingest them for host bindings without duplicating all this subtle logic.
To solve this, we introduce two major related refactors:
1. Move all processing of attributes into phases. This dramatically reduces the amount of code in `ingest.ts`, which is now only responsible for ingesting an abstract `BindingOp`. The later phases replace each `BindingOp` with more specific ops for each binding kind. For example, `binding_specialization.ts` transforms each abstract `BindingOp` into a concrete `PropertyOp`, `AttributeOp`, etc. Likewise, `style_binding_specialization.ts` performs special-case transformations for style and class bindings. This approach has the additional advantage of separating the creation of attribute and property bindings from other special cases.
2. Eliminate all interpolation ops. Instead, allow the expression inside of an op to be of a new `Interpolation` type. The reify code will then emit the appropriate instruction variant (interpolated or unary).
3. Separate some concerns that were previously mixed in, such as empty bindings and listeners on templates.
These refactors cause major downstream code changes across the system, especially to attribute extraction and variable counting.
PR Close#50899
Modify most of the remaining necessary phases to accept generic `CompilationJobs`. This includes `phasePureLiteralStructures`, `phaseNullishCoalescing`, `phaseExpandSafeReads`, `phaseVariableOptimization`, `phaseNaming`, and `phasePureFunctionExtraction`.
PR Close#50899
Refactor `compilation.ts` by introducing two new concepts:
1. A compilation unit, which has create and update ops. Compilations of individual views are compilation units, as are individual host bindings.
2. Aa compilation job, which has several compilation units. For example, a whole component is a compilation job, because it can have many view compilation units. A host binding compilation is a job in addition to a unit, because each host binding unit is always a singleton.
Then, we begin modifying phases to accept general compilation jobs instead of component compilations specifically, which will allow us to run them on host bindings. In particular, we update the following phases: `phaseReify`, and `phaseChaining`.
PR Close#50899
Add a compatibility setting to the component compilation. Accordingly, remove all the custom compatibility flags passed to each phase, and use the main setting instead.
PR Close#50899
Begin producing source maps for the template pipeline, for a couple fundamental kinds of instructions, including elements, templates, properties, text, and interpolations.
PR Close#50899
Previously, `$event` was interpreted as a lexical read on the enclosing context. Now, a new pass converts such reads into simple output AST reads of `$event`, so they are not processed by the context resolution or naming phases. Additionally, the same pass sets a field on the enclosing listener op, so that the reify phase does not have to search for reads of `$event`.
PR Close#50899
`$any(...)` casts should be dropped, except when they are an explicit call on `this.$any(...)`. Fix a bug in which we were transforming `ThisReceiver` into an implicit receiver.
PR Close#50899
Currently the label showing the component name is always positioned from the bottom/right edge of the element which may be outside of the viewport. These changes add some logic to fall back to a different position so that the label is always visible.
I've also cleaned the `highlighter.ts` file up a bit.
Fixes#48479.
PR Close#50656
Summary of changes:
* change 'notice that' -> note that
* break large sentence to smaller ones to improve readability
* use future tense & modal verbs to indicate future events
PR Close#49578
aanchal