Conversation
JoostK
force-pushed
the
ngtsc-template-guards
branch
2 times, most recently
from
May 3, 2019 19:08
7c743c1 to
5cf51bf
Compare
alxhub
approved these changes
May 15, 2019
Member
A structural directive can specify a template guard for an input, such that
the type of that input's binding can be narrowed based on the guard's return
type. Previously, such template guards could only be methods, of which an
invocation would be inserted into the type-check block (TCB). For `NgIf`,
the template guard narrowed the type of its expression to be `NonNullable`
using the following declaration:
```typescript
export declare class NgIf {
static ngTemplateGuard_ngIf<E>(dir: NgIf, expr: E): expr is NonNullable<E>
}
```
This works fine for usages such as `*ngIf="person"` but starts to introduce
false-positives when e.g. an explicit non-null check like
`*ngIf="person !== null"` is used, as the method invocation in the TCB
would not have the desired effect of narrowing `person` to become
non-nullable:
```typescript
if (NgIf.ngTemplateGuard_ngIf(directive, ctx.person !== null)) {
// Usages of `ctx.person` within this block would
// not have been narrowed to be non-nullable.
}
```
This commit introduces a new strategy for template guards to allow for the
binding expression itself to be used as template guard in the TCB. Now,
the TCB generated for `*ngIf="person !== null"` would look as follows:
```typescript
if (ctx.person !== null) {
// This time `ctx.person` will successfully have
// been narrowed to be non-nullable.
}
```
This strategy can be activated by declaring the template guard as a
property declaration with `'binding'` as literal return type.
See angular#30235 for an example where this led to a false positive.
alxhub
force-pushed
the
ngtsc-template-guards
branch
from
May 15, 2019 22:16
5cf51bf to
80e5412
Compare
Member
Member
|
Caretaker: the public API change in this PR is Ivy-only and not user facing. |
BioPhoton
pushed a commit
to BioPhoton/angular
that referenced
this pull request
May 21, 2019
…#30248) A structural directive can specify a template guard for an input, such that the type of that input's binding can be narrowed based on the guard's return type. Previously, such template guards could only be methods, of which an invocation would be inserted into the type-check block (TCB). For `NgIf`, the template guard narrowed the type of its expression to be `NonNullable` using the following declaration: ```typescript export declare class NgIf { static ngTemplateGuard_ngIf<E>(dir: NgIf, expr: E): expr is NonNullable<E> } ``` This works fine for usages such as `*ngIf="person"` but starts to introduce false-positives when e.g. an explicit non-null check like `*ngIf="person !== null"` is used, as the method invocation in the TCB would not have the desired effect of narrowing `person` to become non-nullable: ```typescript if (NgIf.ngTemplateGuard_ngIf(directive, ctx.person !== null)) { // Usages of `ctx.person` within this block would // not have been narrowed to be non-nullable. } ``` This commit introduces a new strategy for template guards to allow for the binding expression itself to be used as template guard in the TCB. Now, the TCB generated for `*ngIf="person !== null"` would look as follows: ```typescript if (ctx.person !== null) { // This time `ctx.person` will successfully have // been narrowed to be non-nullable. } ``` This strategy can be activated by declaring the template guard as a property declaration with `'binding'` as literal return type. See angular#30235 for an example where this led to a false positive. PR Close angular#30248
4 of 14 tasks
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


A structural directive can specify a template guard for an input, such that
the type of that input's binding can be narrowed based on the guard's return
type. Previously, such template guards could only be methods, of which an
invocation would be inserted into the type-check block (TCB). For
NgIf,the template guard narrowed the type of its expression to be
NonNullableusing the following declaration:
This works fine for usages such as
*ngIf="person"but starts to introducefalse-positives when e.g. an explicit non-null check like
*ngIf="person !== null"is used, as the method invocation in the TCBwould not have the desired effect of narrowing
personto becomenon-nullable:
This commit introduces a new strategy for template guards to allow for the
binding expression itself to be used as template guard in the TCB. Now,
the TCB generated for
*ngIf="person !== null"would look as follows:This strategy can be activated by declaring the template guard as a
property declaration with
'binding'as literal return type.See #30235 for an example where this led to a false positive.