This patch introduces the `printTable()` and `printSources()`
methods to `DebugStylingContext` which can be used via the
`window.ng.getDebugNode` helpers when debugging an application.
PR Close#32753
This patch enables a styling debug instance (which is apart of the
`debugNode.styles` or `debugNode.classes` data structures) to expose
its context value so that it can be easily debugged.
PR Close#32753
Prior to this patch the `window.ng.getDebugNode` method would fail to
return the debug information for an element that is a host element to
a component.
PR Close#32780
Remove MockData from the constructor parameters of MockTypescriptHost
since the entire Tour of Heroes (TOH) project is now loaded from disk.
Added a new method `reset()` to MockTypescriptHost that is necessary to
reset the state of the project before each spec if run to make sure
previous overrides are cleared.
PR Close#32752
Language service uses a canonical "Tour of Heroes" project to test
various features, but the files are all contained in test_data.ts which
is hard to read and often contains errors that are difficult to catch
without proper IDE syntax highlighting. The directory structure is also
not clear from first glance.
This PR refactors the test project into standalone files in the proper
format.
Next up:
[ ] Update the interface of MockTypeScript to only accept scriptNames.
[ ] Remove test_data.ts
PR Close#32653
This sets up the Language Service to support #32565.
This PR exposes a `getDirectiveModule` method on `TypeScriptServiceHost`
that returns the NgModule owning a Directive given the Directive's
TypeScript node or its Angular `StaticSymbol`. Both types are supported
to reduce extraneous helper methods.
PR Close#32710
Before this refactoring native node `classList` / `style` properties were
read even if not used. The reason for this was desire to avoid code duplication
between procedural and non-procedural renderers. Unfortunatelly for the case
which will be used by most users (a procedura renderer) the `classList` / `style`
properties were read twice, making the `setStyle` \ `setClass` functions the
most expensive ones (self time) in several benchmarks (large table, expanding
rows).
This refactoring adds a bit of code duplication in order to get better
runtime performance. The code duplication will be removed when we drop
checks for a procedural renderer.
PR Close#32716
Currently the expressions used in a template string are automatically named
`PH_1`, `PH_2`, etc. Whereas interpolations used in i18n templates generate
placeholders automatically named `INTERPOLATION`, `INTERPOLATION_1`, etc.
This commit aligns the behaviors by starting the generated placeholder
names for expressions at `PH`, then `PH_1`, etc.
It also documents this behavior in the documentation of `$localize` as
it was not mentioned before.
PR Close#32493
Prior to this patch if any backwards-compatible Angular code was using
Ivy then the built-in `window.ng` debug utilies would not be exposed.
PR Close#32725
Now that the `$localize` translations are `MessageId` based the
compiler must render `MessageId`s in its generated `$localize` code.
This is because the `MessageId` used by the compiler is computed
from information that does not get passed through to the `$localize`
tagged string.
For example, the generated code for the following template
```html
<div id="static" i18n-title="m|d" title="introduction"></div>
```
will contain these localization statements
```ts
if (ngI18nClosureMode) {
/**
* @desc d
* @meaning m
*/
const MSG_EXTERNAL_8809028065680254561$$APP_SPEC_TS_1 = goog.getMsg("introduction");
I18N_1 = MSG_EXTERNAL_8809028065680254561$$APP_SPEC_TS_1;
}
else {
I18N_1 = $localize \`:m|d@@8809028065680254561:introduction\`;
}
```
Since `$localize` is not able to accurately regenerate the source-message
(and so the `MessageId`) from the generated code, it must rely upon the
`MessageId` being provided explicitly in the generated code.
The compiler now prepends all localized messages with a "metadata block"
containing the id (and the meaning and description if defined).
Note that this metadata block will also allow translation file extraction
from the compiled code - rather than relying on the legacy ViewEngine
extraction code. (This will be implemented post-v9).
Although these metadata blocks add to the initial code size, compile-time
inlining will completely remove these strings and so will not impact on
production bundle size.
PR Close#32594
As discussed in https://hackmd.io/33M5Wb-JT7-0fneA0JuHPA `SourceMessage`
strings are not sufficient for matching translations.
This commit updates `@angular/localize` to use `MessageId`s for translation
matching instead.
Also the run-time translation will now log a warning to the console if a
translation is missing.
BREAKING CHANGE:
Translations (loaded via the `loadTranslations()` function) must now use
`MessageId` for the translation key rather than the previous `SourceMessage`
string.
PR Close#32594
Previously the translation key used for translations was the `SourceMessage`
but it turns out that this is insufficient because "meaning" and "custom-id"
metadata affect the translation key.
Now run-time translation is keyed off the `MessageId`.
PR Close#32594
This commit documents and extends the basic `$localize`
implementation to support adding a metadata block to the
start of a tagged message.
All the "pass-though" version does is to strip this block out,
similar to what it does to placeholder name blocks.
PR Close#32594
The `packages/localize/test/utils` folder was not being
included in the unit tests because the glob for the spec
files was only looking in the top level folder.
PR Close#32594
Previously we were looking for a global factory call that looks like:
```ts
(factory((global.ng = global.ng || {}, global.ng.common = {}), global.ng.core))"
```
but in some cases it looks like:
```ts
(global = global || self, factory((global.ng = global.ng || {}, global.ng.common = {}), global.ng.core))"
```
Note the `global = global || self` at the start of the statement.
This commit makes the test when finding the global factory
function call resilient to being in a comma list.
PR Close#32709
Removes the selection strategies for `AngularTemplateCompile` and `TypeScriptCompile` causing
them to use the automatic selection strategies instead.
PR Close#32678
Prior to this patch, each time `advance()` would run (or when a
templateFn or hostBindings code exits) then the core change detection
code would check to see whether the styling data needs to be reset. This
patch removes that functionality and places everything inside of the
scheduled styling exit function. This means that each time one or more
styling bindings run (even if the value hasn't changed) then an exit
function will be scheduled and that will do all the cleanup.
PR Close#32591
This patch is a final major refactor in styling Angular.
This PR includes three main fixes:
All temporary state taht is persisted between template style/class application
and style/class application in host bindings is now removed.
Removes the styling() and stylingApply() instructions.
Introduces a "direct apply" mode that is used apply prop-based
style/class in the event that there are no map-based bindings as
well as property collisions.
PR Close#32259
PR Close#32591
Currently all property instructions eventually call into `elementPropertyInternal` which in turn calls to `getLView`, however all of the instructions already have access to the LView. These changes switch to passing in the LView as a parameter.
PR Close#32681
Within an Angular package, it can happen that there are
entry-points which do not contain features that belong into
an `@NgModule` or need metadata files to be generated.
For example: the `cdk`, `cdk/testing` and `cdk/coercion`
entry-points. Besides other entry-points in the `cdk`
package, those entry-points do not need metadata to
be generated and no not use the `ng_module` rule.
Currently the "ng_package" rule properly picks up such
entry-points and builds bundles, does downleveling etc.
The only thing it misses is that no `package.json` files
are generated for the entry-point. This means that consumers
will not be able to use these entry-points built with "ts_library"
(except accessing the individual bundlings explicitly).
The "ng_package" rule should follow the full APF specification
for such entry-points. Partially building bundles and doing the
downleveling is confusing and a breaking issue.
The motifivation of supporting this (besides making the
rule behavior consistent; the incomplete output is not
acceptable), is that using the "ng_module" rule does
not make sense to be used for non-Angular entry-points.
Especially since it depends on Angular packages to
be specified as Bazel action inputs just to compile
vanilla TypeScript with `@angular/compiler-cli`.
PR Close#32610
Matias Niemelä
Judy Bogart
Kapunahele Wong
Keen Yee Liau
ayazhafiz
Andrew Kushnir
Jason Bedard
Pawel Kozlowski
Joey Perrott
cexbrayat
Aristeidis Bampakos
Pete Bacon Darwin
crisbeto
Misko Hevery
cran-cg
Paul Gschwendtner