Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ngtsc: acceptance coercion members should be inherited #33830

Closed
devversion opened this issue Nov 14, 2019 · 1 comment
Closed

ngtsc: acceptance coercion members should be inherited #33830

devversion opened this issue Nov 14, 2019 · 1 comment

Comments

@devversion
Copy link
Member

@devversion devversion commented Nov 14, 2019

For ngtsc, the concept of acceptance coercion members has been introduced:

export class MatSelect {
  @Input()
  get disabled(): boolean {..}
  set disabled(val: boolean) { this._disabled = coerceToBoolean(val); }

  // this allows consumers to use <select disabled="">
  static ngAcceptInputType_disabled = boolean | string;
}

Unfortunately it's currently not intuitive that those acceptance members are not inherited. This means that consumers of the component, or library authors who share logic in base classes need to copy the acceptance members manually to derived classes. e.g.

export class CustomSelect extends MatSelect {
  // PROBLEM: this needs to be re-created.. even though we extend from MatSelect.
  static ngAcceptInputType_disabled = typeof MatSelect.ngAcceptInputType_disabled;
}

The acceptance members are technically inherited (at runtime) in the CustomSelect but just need to be properly picked up by ngtsc. This would match the mental model where the actual inputs are inherited too.

Just an idea of how it could work:

export declare class Test {
  test: boolean;
  static ngTypeCtor(init: {test: boolean|string}): Test;
}

export declare class Test2 extends Test {
  static ngTypeCtor(init: Parameters<typeof Test.ngTypeCtor>[0]): Test2;
}

Test2.ngTypeCtor({test: 'a'})
@devversion devversion added this to the v9-candidates milestone Nov 14, 2019
@kara kara removed this from the v9-candidates milestone Nov 18, 2019
@ngbot ngbot bot added this to the needsTriage milestone Nov 18, 2019
@kara kara modified the milestones: needsTriage, v9-blockers Nov 18, 2019
JoostK added a commit to JoostK/angular that referenced this issue Dec 7, 2019
For Ivy's template type checker it is possible to let a directive
specify static members to allow a wider type for some input:

```typescript
export class MatSelect {
  @input() disabled: boolean;

  static ngAcceptInputType_disabled: boolean | string;
}
```

This allows a binding to the `MatSelect.disabled` input to be of type
boolean or string, whereas the `disabled` property itself is only of
type boolean.

Up until now, any static `ngAcceptInputType_*` property was not
inherited for subclasses of a directive class. This is cumbersome, as
the directive's inputs are inherited, so any acceptance member should as
well. To resolve this limitation, this commit extends the flattening of
directive metadata to include the acceptance members.

Fixes angular#33830
Resolves FW-1759
@JoostK JoostK assigned JoostK and unassigned alxhub Dec 7, 2019
@JoostK JoostK added the state: has PR label Dec 7, 2019
AndrewKushnir added a commit that referenced this issue Dec 11, 2019
For Ivy's template type checker it is possible to let a directive
specify static members to allow a wider type for some input:

```typescript
export class MatSelect {
  @input() disabled: boolean;

  static ngAcceptInputType_disabled: boolean | string;
}
```

This allows a binding to the `MatSelect.disabled` input to be of type
boolean or string, whereas the `disabled` property itself is only of
type boolean.

Up until now, any static `ngAcceptInputType_*` property was not
inherited for subclasses of a directive class. This is cumbersome, as
the directive's inputs are inherited, so any acceptance member should as
well. To resolve this limitation, this commit extends the flattening of
directive metadata to include the acceptance members.

Fixes #33830
Resolves FW-1759

PR Close #34296
@angular-automatic-lock-bot

This comment has been minimized.

Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Jan 11, 2020

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jan 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.