Adds new abstraction `Compiler` with methods
`compileComponentAsync` and `compileComponentSync`.
This is in preparation of deprecating `ComponentResolver`.
`compileComponentSync` is able to compile components
synchronously given all components either have an inline
template or they have been compiled before.
Also changes `TestComponentBuilder.createSync` to
take a `Type` and use the new `compileComponentSync` method.
Also supports overriding the component metadata even if
the component has already been compiled.
Also fixes#7084 in a better way.
BREAKING CHANGE:
`TestComponentBuilder.createSync` now takes a component type
and throws if not all templates are either inlined
are compiled before via `createAsync`.
Closes#9594
This fix prevented waiting for child components even if the cycle was only introduced via the `directives` array, i.e. without actually having a cycle. This easily causes issues for applications that have one shared list of directives for all components.
This reverts commit 3d5bb23184.
Closes#9647
E.g. in the following scenario,
`some-directive` should not be able to inject
any view provider that `my-comp-with-view-providers`
declares.
```
<my-comp-with-view-providers>
<div some-directive></div>
</my-comp-with-view-providers>
```
Fixes#7315
BREAKING CHANGES:
Previously multiple template bindings on one element
(ex. `<div *ngIf='..' *ngFor='...'>`) were allowed but most of the time
were leading to undesired result. It is possible that a small number
of applications will see template parse errors that shuld be fixed by
nesting elements or using `<template>` tags explicitly.
Closes#9462
Fix how the compiler checks for recursive components by also considering
component descendants. Previously, it only checked if the current
component was evaluated previously. This failed in certain cases of
mutually recursive components, causing `createAsync` in tests to not
resolve.
closes [7084](https://github.com/angular/angular/issues/7084)
After splitting the facades into multiple modules,
enabling prod mode for code had no effect for the compiler.
Also in a change between RC1 and RC2 we created the `CompilerConfig`
via a provider with `useValue` and not via a `useFactory`, which reads
the prod mode too early.
Closes#9318Closes#8508Closes#9318
`<ng-container>` is a logical container that can be used to group nodes but is not rendered in the DOM tree as a node.
`<ng-container>` is rendered as an HTML comment.
* feat(I18nExtractor): Add file paths to error messages
relates to #9071
* feat(i18n): allow i18n start comments without meaning
* refactor(i18n): cleanup
* test(HtmlParser): Add depth to expansion forms
This aligns the configuration of platform pipes / directives with offline compilation.
BREAKING CHANGE:
- `PLATFORM_PIPES` and `PLATFORM_DIRECTIVES` now are fields on `CompilerConfig`.
Instead of providing a binding to these tokens, provide a binding for `CompilerConfig` instead.
It is now possible to set a fallback state that will apply its
styling when the destination state is not detected.
```ts
state("*", style({ ... }))
```
Closes#9013
This is needed to have a true replacement of the previous
`DynamicComponentLoader.loadNextToLocation`, so that components
can be loaded into the view before change detection runs.
Closes#9040
There is no need to expose this additional method inside of the Renderer
API. The functionality can be restored by looping and calling
`setElementStyle` instead.
Note that this change is changing code that was was introduced after
the last release therefore this fix is not a breaking change.
Closes#9000Closes#9009
This addresses several oversights in assigning security contexts to DOM schema
elements found by our security reviewers (thanks!).
This also adds some more precise unit tests for the interaction between
(Dom)ElementSchemaRegistry and the TemplateParser, and extracts the security
specific parts into dom_security_schema.ts.
Comparison of (potentially) dangerous property names is done case insensitive,
to avoid issues like formAction vs formaction.
Part of issue #8511.
* fix(compiler): throw an error if variable with the same name is already defined. Closes#6492
* fix(compiler): Clean up formatting for issue #6492
* fix(compiler): throw an error if reference with the same name is already defined.
Closes#6492
<!-- xxxx ------->
The issue came from a lack of support for backtracking on string
matching.
The way it is done, if the "end pattern" for consumeRawText starts with
twice the same character, you end up having problem when your string
being parsed has 3 times this char
Example
End string: xxyz
string to parse: aaaaaaxxxyz
calling consumeRawText(false, 'x', attemptParseStr('xyz')) would fail
Closes#7119
Summary:
This adds basic security hooks to Angular 2.
* `SecurityContext` is a private API between core, compiler, and
platform-browser. `SecurityContext` communicates what context a value is used
in across template parser, compiler, and sanitization at runtime.
* `SanitizationService` is the bare bones interface to sanitize values for a
particular context.
* `SchemaElementRegistry.securityContext(tagName, attributeOrPropertyName)`
determines the security context for an attribute or property (it turns out
attributes and properties match for the purposes of sanitization).
Based on these hooks:
* `DomSchemaElementRegistry` decides what sanitization applies in a particular
context.
* `DomSanitizationService` implements `SanitizationService` and adds *Safe
Value*s, i.e. the ability to mark a value as safe and not requiring further
sanitization.
* `url_sanitizer` and `style_sanitizer` sanitize URLs and Styles, respectively
(surprise!).
`DomSanitizationService` is the default implementation bound for browser
applications, in the three contexts (browser rendering, web worker rendering,
server side rendering).
BREAKING CHANGES:
*** SECURITY WARNING ***
Angular 2 Release Candidates do not implement proper contextual escaping yet.
Make sure to correctly escape all values that go into the DOM.
*** SECURITY WARNING ***
Reviewers: IgorMinar
Differential Revision: https://reviews.angular.io/D103
Impure pipes need to live on the view
that used them and need a new instance for
each call site.
Impure pipes need to live on the component view, cached across all child views,
and need a new pure proxy for each for
each call site that lives on the view
of the call site.
Fixes#8408
This bug was introduced not long ago by 152a117d5c
Tobias Bosch
Miško Hevery
Naomi Black
Victor Berchet
vsavkin
Matias Niemelä
Pawel Kozlowski
ScottSWu
tycho01
Rob Wormald
Wassim Chegham
Alex Eagle
ScottSWu
Martin Probst
Alex Eagle
laco0416
Suguru Inatomi
Andrii Nechytailov
Igor Minar
Wesley Cho
Grégory Bataille
Tero Parviainen
alexcastillo
Igor Minar