Commit Graph

3198 Commits

Author SHA1 Message Date
Kara Erickson eb39633823 test(ivy): re-enable ngIf protractor test (#28845)
We previously disabled this test because we did not yet have
static query support in Ivy and the planned API would be
slightly different. Now that a static query flag is available
that works in both View Engine and Ivy, the test has been
updated to use that flag and has been turned on to run in CI.

Since the test was always unrelated to queries and was intended
to test *ngIf behavior, updating the test in this instance
seems reasonable.

PR Close #28845
2019-02-19 16:23:57 -08:00
Jason Aden 71d0eeb966 feat(router): add hash-based navigation option to setUpLocationSync (#28609)
The `setUpLocationSync` function in @angular/router/upgrade didn't previously let you sync hash-based navigations. With this change, you can now pass an option to `setUpLocationSync` that will make sure location changes run in Angular in hash-based apps.

Fixes #24429 #21995

PR Close #28609
2019-02-19 16:20:35 -08:00
Olivier Combe ad6475ffac fix(ivy): re-create node links after creating/moving/removing nodes with i18n (#28827)
I18n can change the order of the nodes, or insert new dynamic nodes. When that happens it can break the existing links (`TNode.next`) or even create loops:
```
div1 → div2 → div3 → div4 → div5
```

Can become:
```
div1 → div4 → div2 → div3  div5
         🡑             │
         └─────────────┘
```

This PR fixes this issue by recreating the broken links between those nodes.
PR Close #28827
2019-02-19 15:54:33 -08:00
Kara Erickson 3c1a1620e3 fix(ivy): support static ContentChild queries (#28811)
This commit adds support for the `static: true` flag in `ContentChild`
queries. Prior to this commit, all `ContentChild` queries were resolved
after change detection ran. This is a problem for backwards
compatibility because View Engine also supported "static" queries which
would resolve before change detection.

Now if users add a `static: true` option, the query will be resolved in
creation mode (before change detection runs). For example:

```ts
@ContentChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:01 -08:00
Kara Erickson a4638d5a81 fix(ivy): support static ViewChild queries (#28811)
This commit adds support for the `static: true` flag in
`ViewChild` queries. Prior to this commit, all `ViewChild`
queries were resolved after change detection ran. This is
a problem for backwards compatibility because View Engine
also supported "static" queries which would resolve before
change detection.

Now if users add a `static: true` option, the query will be
resolved in creation mode (before change detection runs).
For example:

```ts
@ViewChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:00 -08:00
Kara Erickson 19afb791b4 feat(core): allow users to define timing of ViewChild/ContentChild queries (#28810)
Prior to this commit, the timing of `ViewChild`/`ContentChild` query
resolution depended on the results of each query. If any results
for a particular query were nested inside embedded views (e.g.
*ngIfs), that query would be resolved after change detection ran.
Otherwise, the query would be resolved as soon as nodes were created.

This inconsistency in resolution timing had the potential to cause
confusion because query results would sometimes be available in
ngOnInit, but sometimes wouldn't be available until ngAfterContentInit
or ngAfterViewInit. Code depending on a query result could suddenly
stop working as soon as an *ngIf or an *ngFor was added to the template.

With this commit, users can dictate when they want a particular
`ViewChild` or `ContentChild` query to be resolved with the `static`
flag. For example, one can mark a particular query as `static: false`
to ensure change detection always runs before its results are set:

```ts
@ContentChild('foo', {static: false}) foo !: ElementRef;
```

This means that even if there isn't a query result wrapped in an
*ngIf or an *ngFor now, adding one to the template later won't change
the timing of the query resolution and potentially break your component.

Similarly, if you know that your query needs to be resolved earlier
(e.g. you need results in an ngOnInit hook), you can mark it as
`static: true`.

```ts
@ViewChild(TemplateRef, {static: true}) foo !: TemplateRef;
```

Note: this means that your component will not support *ngIf results.

If you do not supply a `static` option when creating your `ViewChild` or
`ContentChild` query, the default query resolution timing will kick in.

Note: This new option only applies to `ViewChild` and `ContentChild`
queries, not `ViewChildren` or `ContentChildren` queries, as those types
already resolve after CD runs.

PR Close #28810
2019-02-19 12:56:25 -08:00
Trevor Karjanis 5e68e35112 docs(platform-browser): fix a grammatical error in the BrowserModule documentation (#28808)
The browser module is not included by defaults, it is included by default. Default should be singular.

There is no associated issue.
PR Close #28808
2019-02-19 12:54:52 -08:00
George Kalpakas 745c9c5ca7 build(compiler-cli): upgrade chokidar to latest version (#28797)
Fixes #28771

PR Close #28797
2019-02-19 12:54:11 -08:00
Paul Gschwendtner 4131715df5 fix(compiler-cli): incorrect bundled metadata for static class member call expressions (#28762)
Currently if developers use call expressions in their static
class members ([like we do in Angular](https://github.com/angular/angular/blob/master/packages/core/src/change_detection/differs/keyvalue_differs.ts#L121)),
the metadata that is generated for flat modules is invalid. This
is because the metadata bundler logic currently does not handle
call expressions in static class members and the symbol references
are not rewritten to avoid relative paths in the bundle.

Static class members using a call expression are not relevant for
the ViewEngine AOT compilation, but it is problematic that the
bundled metadata references modules using their original relative
path. This means that the bundled metadata is no longer encapsulated
and depends on other emitted files to be emitted in the proper place.

These incorrect relative paths can now cause issues where NGC
looks for the referenced symbols in the incorrect path. e.g.

```
src/
 | lib/
    | index.ts -> References the call expression using `../../di`
```

Now the metadata looks like that:

```
node_modules/
  | @angular/
  -- | core/
  -- -- | core.metadata.json -> Says that the call expr. is in `../../di`.
  | di/
```

Now if NGC tries to use the metadata files and create the summary files,
NGC resolves the call expression to the `node_modules/di` module. Since
the "unexpected" module does not contain the desired symbol, NGC will
error out.

We should fix this by ensuring that we don't ship corrupted metadata
to NPM which contains relative references that can cause such
failures (other imports can be affected as well; it depends on what
modules the developer has installed and how we import our call
expressions).

Fixes #28741.

PR Close #28762
2019-02-19 12:53:18 -08:00
Pawel Kozlowski 692ddfcbb5 fix(ivy): allign DebugNode.componentInstance semantics with view engine (#28756)
PR Close #28756
2019-02-19 12:51:47 -08:00
Filipe Silva 1923c2f99c feat(compiler-cli): make enableIvy ngtsc/true equivalent (#28616)
Currently setting `enableIvy` to true runs a hybrid mode of `ngc` and `ngtsc`. This is counterintuitive given the name of the flag itself.

This PR makes the `true` value equivalent to the previous `ngtsc`, and `ngtsc` becomes an alias for `true`. Effectively this removes the hybrid mode as well since there's no other way to enable it.

PR Close #28616
2019-02-19 12:28:44 -08:00
George Kalpakas 6b511a33f6 fix(ivy): fix class inheritance detection for ES5 code in `ngtsc` (#28773)
Previously, `ngtsc` detected class inheritance in a way that only worked
in TS or ES2015 code. As a result, inheritance would not be detected for
code in ES5 format, such as when running `ngtsc` through `ngcc` to
transform old-style Angular code to ivy format.

This commit fixes it by delegating class inheritance detection to the
current `ReflectionHost`, which is able to correctly interpret the used
code format.

PR Close #28773
2019-02-16 21:00:50 -08:00
Kara Erickson 911599d9a3 test(ivy): mark unknown binding test modifiedInIvy (#28740)
This commit turns off an unknown binding test that is specific
to the View Engine implementation. In Ivy, we do property validation
at runtime for jit, so this test does not apply.

PR Close #28740
2019-02-16 20:58:25 -08:00
Pawel Kozlowski c1094cf46f refactor(ivy): remove duplicated getRootView function (#28732)
PR Close #28732
2019-02-16 20:58:01 -08:00
Cody Schroeder 2e3cc45c74 build(bazel): specify tsconfig-test dependency (#28696)
PR Close #28696
2019-02-16 20:57:34 -08:00
Vani 8accc98d28 docs: incorporate review feedback (#26827)
PR Close #26827
2019-02-14 19:33:14 +00:00
Vani aa8d0809d3 docs: update HttpInterceptor API docs (#26827)
PR Close #26827
2019-02-14 19:33:14 +00:00
Kristiyan Kostadinov 80a5934af6 fix(ivy): support schemas at runtime (#28637)
Accounts for schemas in when validating properties in Ivy.

This PR resolves FW-819.

A couple of notes:
* I had to rework the test slightly, in order to have it fail when we expect it to. The one in master is passing since Ivy's validation runs during the update phase, rather than creation.
* I had to deviate from the design in FW-819 and not add an `enableSchema` instruction, because the schema is part of the `NgModule` scope, however the scope is only assigned to a component once all of the module's declarations have been resolved and some of them can be async. Instead, I opted to have the `schemas` on the component definition.

PR Close #28637
2019-02-14 19:31:51 +00:00
Paul Gschwendtner 7cbc36fdac build: remove unused rollup.config.js files (#28646)
Since we build and publish the individual packages
using Bazel and `build.sh` has been removed, we can
safely remove the `rollup.config.js` files which are no
longer needed because the `ng_package` bazel rule
automatically handles the rollup settings and globals.

PR Close #28646
2019-02-14 19:28:08 +00:00
Kristiyan Kostadinov 63e5d2787b fix(ivy): rethrow event handler errors in tests (#28707)
Currently errors thrown inside event handler in Ivy are caught and forwarded to the `ErrorHandler`, however this means that if they happen during a unit test, the test won't fail. These changes add a test-specific `ErrorHandler` that throws the error rather than logging it out.

PR Close #28707
2019-02-14 19:26:56 +00:00
Jeremy Elbourn 83fd66d1d0 fix(ivy): DebugNode should read styles from StylingContext (#28709)
Previously `DebugNode.classes` and `DebugNode.styles` mistakenly used an
object that is only *sometimes* a `StylingContext`. Also fixes a mistake
in `debug_node_spec.ts` where a test component was not declared in the
testing module.

There is still a bug here where `DebugNode` is not exposing *static*
values. This will need to be fixed in a follow up.

PR Close #28709
2019-02-14 19:24:17 +00:00
Matias Niemelä 627cecdfe2 fix(ivy): ensure host bindings and host styling works on a root component (#28664)
Prior to this fix if a root component was instantiated it create host
bindings, but never render them once update mode ran unless one or more
slot-allocated bindings were issued. Since styling in Ivy does not make
use of LView slots, the host bindings function never ran on the root
component.

This fix ensures that the `hostBindings` function does run for a root
component and also renders the schedlued styling instructions when
executed.

Jira Issue: FW-1062

PR Close #28664
2019-02-14 19:23:25 +00:00
Keen Yee Liau 65c2deacbb refactor(bazel): Fix warning about overridden tsconfig options (#28674)
Under Bazel, some compilerOptions in tsconfig.json are controlled by
downstream rules. The default tsconfig.json causes Bazel to print out
warnings about overriden settings.

This commit makes a backup of the original tsconfig.json and removes
tsconfig settings that are controlled by Bazel.

As part of this fix, JsonAst utils are refactored into separate package
and unit tests are added.

PR closes https://github.com/angular/angular/issues/28034

PR Close #28674
2019-02-13 21:24:19 -08:00
Pawel Kozlowski b0afc4c638 refactor(ivy): remove unused constructor argument (#28677)
PR Close #28677
2019-02-13 19:18:02 -08:00
Artem Lanovyy 1df3aefb81 fix(forms): mark form as pristine before emitting value and status change events (#28395)
BREAKING CHANGE

Previous to this change, when a control was reset, value and status change
events would be emitted before the control was reset to pristine. As a
result, if one were to check a control's pristine state in a valueChange
listener, it would appear that the control was still dirty after reset.

This change delays emission of value and status change events until after
controls have been marked pristine. This means the pristine state will be
reset as expected if one checks in a listener.

Theoretically, there could be applications depending on checking whether a
control *used to be dirty*, so this is marked as breaking. In these cases,
apps should cache the state on the app side before calling reset.

Fixes #28130

PR Close #28395
2019-02-13 19:17:35 -08:00
Alex Eagle 8cec4b3ff7 build: make api-extractor work in google3 (#28588)
PR Close #28588
2019-02-13 19:16:29 -08:00
Alan Agius 9e5d1357fe build: update `@microsoft/api-extractor` to `7.0.17` (#28588)
This fixes one of the problems that we reported https://github.com/Microsoft/web-build-tools/issues/1048

PR Close #28588
2019-02-13 19:16:29 -08:00
Alan Agius 3bb3d6d3e6 test: update ng_package tests to use bundle_dts (#28588)
PR Close #28588
2019-02-13 19:16:29 -08:00
Alan Agius 3d39100c85 feat(bazel): add dts bundler as action to ng_module (#28588)
This enabled dts flattening in the final distrubutable package.

Notes:
 - For the time being this is an opt-in feature via the `ng_module` attribute  `bundle_dts`, however in the near future this will be turned on by default.
 - This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029

Ref: TOOL-611

PR Close #28588
2019-02-13 19:16:29 -08:00
Marc Laval 3842dd6a6d fix(ivy): OnChanges should support updating one Input among many (#28693)
PR Close #28693
2019-02-13 19:15:44 -08:00
Alberto Garza 36df9056af docs(animations): fixed some grammar (#28708)
PR Close #28708
2019-02-13 19:14:57 -08:00
Alex Rickabaugh 423b39e216 feat(ivy): use fileNameToModuleName to emit imports when it's available (#28523)
The ultimate goal of this commit is to make use of fileNameToModuleName to
get the module specifier to use when generating an import, when that API is
available in the CompilerHost that ngtsc is created with.

As part of getting there, the way in which ngtsc tracks references and
generates import module specifiers is refactored considerably. References
are tracked with the Reference class, and previously ngtsc had several
different kinds of Reference. An AbsoluteReference represented a declaration
which needed to be imported via an absolute module specifier tracked in the
AbsoluteReference, and a RelativeReference represented a declaration from
the local program, imported via relative path or referred to directly by
identifier if possible. Thus, how to refer to a particular declaration was
encoded into the Reference type _at the time of creation of the Reference_.

This commit refactors that logic and reduces Reference to a single class
with no subclasses. A Reference represents a node being referenced, plus
context about how the node was located. This context includes a
"bestGuessOwningModule", the compiler's best guess at which absolute
module specifier has defined this reference. For example, if the compiler
arrives at the declaration of CommonModule via an import to @angular/common,
then any references obtained from CommonModule (e.g. NgIf) will also be
considered to be owned by @angular/common.

A ReferenceEmitter class and accompanying ReferenceEmitStrategy interface
are introduced. To produce an Expression referring to a given Reference'd
node, the ReferenceEmitter consults a sequence of ReferenceEmitStrategy
implementations.

Several different strategies are defined:

- LocalIdentifierStrategy: use local ts.Identifiers if available.
- AbsoluteModuleStrategy: if the Reference has a bestGuessOwningModule,
  import the node via an absolute import from that module specifier.
- LogicalProjectStrategy: if the Reference is in the logical project
  (is under the project rootDirs), import the node via a relative import.
- FileToModuleStrategy: use a FileToModuleHost to generate the module
  specifier by which to import the node.

Depending on the availability of fileNameToModuleName in the CompilerHost,
then, a different collection of these strategies is used for compilation.

PR Close #28523
2019-02-13 19:13:11 -08:00
Alex Rickabaugh a529f53031 feat(ivy): introduce concrete types for paths in ngtsc (#28523)
This commit introduces a new ngtsc sub-library, 'path', which contains
branded string types for the different kind of paths that ngtsc manipulates.
Having static types for these paths will reduce the number of path-related
bugs (especially on Windows) and will eliminate unnecessary defensive
normalizing.

See the README.md file for more detail.

PR Close #28523
2019-02-13 19:13:11 -08:00
Alex Rickabaugh 99d8582882 feat(ivy): support @Injectable on already decorated classes (#28523)
Previously, ngtsc would throw an error if two decorators were matched on
the same class simultaneously. However, @Injectable is a special case, and
it appears frequently on component, directive, and pipe classes. For pipes
in particular, it's a common pattern to treat the pipe class also as an
injectable service.

ngtsc actually lacked the capability to compile multiple matching
decorators on a class, so this commit adds support for that. Decorator
handlers (and thus the decorators they match) are classified into three
categories: PRIMARY, SHARED, and WEAK.

PRIMARY handlers compile decorators that cannot coexist with other primary
decorators. The handlers for Component, Directive, Pipe, and NgModule are
marked as PRIMARY. A class may only have one decorator from this group.

SHARED handlers compile decorators that can coexist with others. Injectable
is the only decorator in this category, meaning it's valid to put an
@Injectable decorator on a previously decorated class.

WEAK handlers behave like SHARED, but are dropped if any non-WEAK handler
matches a class. The handler which compiles ngBaseDef is WEAK, since
ngBaseDef is only needed if a class doesn't otherwise have a decorator.

Tests are added to validate that @Injectable can coexist with the other
decorators and that an error is generated when mixing the primaries.

PR Close #28523
2019-02-13 19:13:10 -08:00
Alex Rickabaugh d2742cf473 feat(ivy): compile @Injectable on classes not meant for DI (#28523)
In the past, @Injectable had no side effects and existing Angular code is
therefore littered with @Injectable usage on classes which are not intended
to be injected.

A common example is:

@Injectable()
class Foo {
  constructor(private notInjectable: string) {}
}

and somewhere else:

providers: [{provide: Foo, useFactory: ...})

Here, there is no need for Foo to be injectable - indeed, it's impossible
for the DI system to create an instance of it, as it has a non-injectable
constructor. The provider configures a factory for the DI system to be
able to create instances of Foo.

Adding @Injectable in Ivy signifies that the class's own constructor, and
not a provider, determines how the class will be created.

This commit adds logic to compile classes which are marked with @Injectable
but are otherwise not injectable, and create an ngInjectableDef field with
a factory function that throws an error. This way, existing code in the wild
continues to compile, but if someone attempts to use the injectable it will
fail with a useful error message.

In the case where strictInjectionParameters is set to true, a compile-time
error is thrown instead of the runtime error, as ngtsc has enough
information to determine when injection couldn't possibly be valid.

PR Close #28523
2019-02-13 19:13:10 -08:00
Alex Rickabaugh f8b67712bc fix(ivy): translate WriteKeyExpr expressions properly (#28523)
Translation of WriteKeyExpr expressions was not implemented in the ngtsc
expression translator. This resulted in binding expressions like
"target[key] = $event" not compiling.

This commit fixes the bug by implementing WriteKeyExpr translation.

PR Close #28523
2019-02-13 19:13:10 -08:00
Alex Rickabaugh 3477610f6d fix(ivy): resolve enum values in host bindings (#28523)
Some applications use enum values in their host bindings:

@Component({
  host: {
    '[prop]': EnumType.Key,
  }, ...
})

This commit changes the resolution of host properties to follow the enum
declaration and extract the correct value for the binding.

PR Close #28523
2019-02-13 19:13:10 -08:00
Alex Rickabaugh 09af7ea4f5 fix(compiler): fix two existing expression transformer issues (#28523)
Testing of Ivy revealed two bugs in the AstMemoryEfficientTransformer
class, a part of existing View Engine compiler infrastructure that's
reused in Ivy. These bugs cause AST expressions not to be transformed
under certain circumstances.

The fix is simple, and tests are added to ensure the specific expression
forms that trigger the issue compile properly under Ivy.

PR Close #28523
2019-02-13 19:13:10 -08:00
Greg Magolan 28bdeeef3e build(bazel): update to rules_nodejs 0.18.6 (#28699)
PR Close #28699
2019-02-13 12:13:08 -08:00
Pawel Kozlowski 6d057cc05d fix(ivy): should mark OnPush ancestor of dynamically created views as dirty (#28687)
While marking a given views tree as dirty we should go all the way to the
root of the views tree and cross boundaries of dynamically inserted views.
In other words the markForCheck functionality should consider parents of
dynamically inserted views.

PR Close #28687
2019-02-13 12:12:45 -08:00
Pawel Kozlowski 2f27a8051b test(ivy): ivy change detection doesn't descend into CD-detached view trees (#28680)
PR Close #28680
2019-02-13 12:12:26 -08:00
Trotyl Yu 77eee42963 fix(core): improve global variable detection (#28679)
Closes #16545

PR Close #28679
2019-02-13 12:05:41 -08:00
Andrew Kushnir 553f80ff46 fix(ivy): set proper implementation for module injector (#28667)
Prior to this change we used current injector implementation for module injector, which was causing problems and produces circular dependencies in case the same token is referenced (with @SkipSelf flag) in the `deps` array. The origin of the problem was that once `directiveInject` implementation becomes active, it was used for module injector as well, thus searching deps in Component/Directive DI scope. This fix sets `injectInjectorOnly` implementation for module injector to resolve the problem.

PR Close #28667
2019-02-13 12:05:13 -08:00
Andrew Kushnir 39d0311e4e refactor(ivy): combine contentQueries and contentQueriesRefresh functions (#28503)
Prior to this update we had separate contentQueries and contentQueriesRefresh functions to handle creation and update phases. This approach was inconsistent with View Queries, Host Bindings and Template functions that we generate for Component/Directive defs. Now the mentioned 2 functions are combines into one (contentQueries), creation and update logic is separated with RenderFlags (similar to what we have in other generated functions).

PR Close #28503
2019-02-13 12:01:32 -08:00
Judy Bogart 644e7a28d8 docs: add di-related api doc (#27731)
PR Close #27731
2019-02-13 11:57:37 -08:00
Keen Yee Liau 2ea030c2c5 fix(bazel): Turn on strict action env (#28675)
This commit fixes a bug whereby recompilation occurs every time `yarn ng build`
or `yarn bazel build ...` is invoked.

This is a temporary solution until # https://github.com/bazelbuild/bazel/issues/7026
is fixed.

PR Close #28675
2019-02-13 09:52:51 -08:00
Keen Yee Liau 49fb8c3cb0 fix(bazel): Install angular repo before yarn_install (#28670)
PR closes https://github.com/angular/angular/issues/28636

PR Close #28670
2019-02-13 09:52:30 -08:00
Keen Yee Liau 0c7581da89 refactor(bazel): use multi_sass_binary rule (#28669)
`multi_sass_binary` rules is reinstated in rules_sass v1.17.0
and it is a better solution than list comprehension currently used
because it handles imports correctly.

PR Close #28669
2019-02-13 09:52:10 -08:00
JoostK 06ec95f2ef fix(ivy): allow directive inheritance in strict mode (#28634)
For TypeScript compilation units that have the "strictFunctionTypes"
option enabled, an error would be produced for Ivy's definition fields
in declaration files in the case of inheritance across directives or
pipes.

This change loosens the definition types to allow for subtypes of the
defined type where necessary.

A test package that has the "strict" option enabled verifies that we
won't regress in environments where strict type checking is enabled.

Fixes #28079

PR Close #28634
2019-02-13 09:50:15 -08:00
Paul Gschwendtner 91b7152852 feat(compiler-cli): no longer re-export external symbols by default (#28633)
With #28594 we refactored the `@angular/compiler` slightly to
allow opting out from external symbol re-exports which are
enabled by default.

Since symbol re-exports only benefit projects which have a
very strict dependency enforcement, external symbols should
not be re-exported by default as this could grow the size of
factory files and cause unexpected behavior with Angular's
AOT symbol resolving (e.g. see: #25644).

Note that the common strict dependency enforcement for source
files does still work with external symbol re-exports disabled,
but there are also strict dependency checks that enforce strict
module dependencies also for _generated files_ (such as the
ngfactory files). This is how Google3 manages it's dependencies
and therefore external symbol re-exports need to be enabled within
Google3.

Also "ngtsc" also does not provide any way of using external symbol
re-exports, so this means that with this change, NGC can partially
match the behavior of "ngtsc" then (unless explicitly opted-out).

As mentioned before, internally at Google symbol re-exports need to
be still enabled, so the `ng_module` Bazel rule will enable the symbol
re-exports by default when running within Blaze.

Fixes #25644.

PR Close #28633
2019-02-13 09:49:51 -08:00