Skip to content

Support for type of input and output #25545

New issue
New issue
Closed
Closed
Support for type of input and output#25545
Assignees
kyliau
Labels
P4A relatively minor issue that is not relevant to core functionsarea: language-serviceIssues related to Angular's VS Code language servicefeatureLabel used to distinguish feature request from other issuesfreq3: high
Milestone
Backlog

Description

@probert94
probert94
opened on Aug 17, 2018

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

If I have an Output defined as new EventEmitter<number>, I can assign the corresponding $event to a variable of type string (or any other type), without getting an error or a warning.
The same goes for Input-bindings, I can assign a number to an Input of type string.
Also, I don't get any type informations for the Input, the Output or the $event inside the HTML.

Expected behavior

It would be cool, if the language service is able to check the type of the Inputs and Outputs and show the same errors as TypeScript does.

Minimal reproduction of the problem with instructions

https://stackblitz.com/edit/angular-gitter-mtojsc

AppComponent assigns a variable of type string to an Input of type number.
The component OtherComponent has an Output of type object, which is bound to the variable of type string.
Both should show an error.

What is the motivation / use case for changing the behavior?

If you are using third-party-components, the code-completion shows you possible Inputs and Outputs. However, the types of them are missing and you have to use go to definition or search a documentation online. If the language service would provide type informations the API of those thrid-party-components would often be clear and no other documentaiton would be needed.

Environment


Angular version: 6.1.2
 
For Tooling issues:
- Node version: 8.10.0
- Platform:  Windows
- IDE/Editor: Visual Studio Code Insider (1.27.0)

Others:
I am using the vscode plugin `Angular Language Service` which is still using @angular/language-service@5.2.2. So I am not sure if the newer language service versions give type informations.

Activity

  1. jasonaden
    added
    area: language-serviceIssues related to Angular's VS Code language service
    on Aug 17, 2018
  2. ngbot
    added this to the needsTriage milestone on Aug 17, 2018
  3. kyliau
    self-assigned this
    on Sep 5, 2018

  4. trotyl commented on Oct 4, 2018

    @trotyl
    trotyl
    on Oct 4, 2018
    Contributor

    Duplicate of #17483

  5. gkalpak commented on Oct 4, 2018

    @gkalpak
    gkalpak
    on Oct 4, 2018
    Member

    I don't think they are duplicates. #17483 is about the properties/property names. This one is about their values.
    (Sure both issues could be merged into one, but as they stand they don't look like duplicates to me.)

  6. trotyl commented on Oct 5, 2018

    @trotyl
    trotyl
    on Oct 5, 2018
    Contributor

    @gkalpak My bad, wasn't accurate enough, this is exact duplicate of #21204, but which was closed.

    Technically speaking, type-checking for inputs is a regression tracked by #20600, type-checking for outputs is a feature request at #16952, they're mostly unrelated (the former should be fixed in Ivy soon), so seems all the aspects has already been tracked somehow.

  7. probert94 commented on Oct 5, 2018

    @probert94
    probert94
    on Oct 5, 2018
    Author

    @trotyl Isn't #20600 about AOT? This Issue is about the Language Service, which should give an error, if you are binding a wrong input type to an @Input.

    Example:

    // test.component.ts (app-test)
@Input
num: number;

<app-test [num]="'String is not valid'"></app-test>

    Note the striked text, which should be the reported error (something like "string cannot be assigned to number").

    For outputs I would like to get type informations of the $event. In vscode for example, I get variable $event, if I hover over it in the html. It would be cool, if it could show something like variable $event: number and again, it should show an error if I call a function which expects another type.
    Example:

    // test.component.ts (app-test)
@Output
num: EventEmitter;

// app.component.html
<app-test (num)="printString($event)"></app-test>

// app.component.ts
public printString(value: string) {
}

    Again, the striked text is the reported error.

    So, I don't think the Issues you referenced are the same, but they are probably related.
    So if you think, this Issue can be closed, in favor of the others, then feel free to close it.

    Thanks :)

  8. trotyl commented on Oct 5, 2018

    @trotyl
    trotyl
    on Oct 5, 2018
    Contributor

    Isn't #20600 about AOT? This Issue is about the Language Service, which should give an error, if you are binding a wrong input type to an @Input.

    #20600 is about type-checking, which is shared between compiler and language service, which is normally just mentioned as compiler stuff.

    For outputs I would like to get type informations of the $event

    It's about infer the type of $event variable, which is currently always any by design, so it's can always pass the type-checking even when type-checking works well.

    In vscode for example, I get variable $event, if I hover over it in the html.

    It's a orthogonal feature request at https://github.com/angular/angular/issues/26155 unrelated to the type-checking. But require feature request of smart $event type declaration being completed first.

    So if you think, this Issue can be closed, in favor of the others, then feel free to close it.

    I don't have right to do that, but can only help to link issues.

  9. mina-skunk commented on Oct 30, 2018

    @mina-skunk
    mina-skunk
    on Oct 30, 2018

    While type checking inputs and output would ultimately be nicer, if mistyped inputs become a design/build time error then should all existing components stop using coercion on inputs? Basically if this feature gets fulfilled all of the existing components that gracefully handle mistypes will have dead code.

  10. kyliau
    added
    featureLabel used to distinguish feature request from other issues
    freq3: high
    severity2: inconvenient
    on Dec 6, 2018
  11. ngbot
    modified the milestones: needsTriage, Backlog on Dec 6, 2018

  12. mohammedzamakhan commented on Jan 29, 2019

    @mohammedzamakhan
    mohammedzamakhan
    on Jan 29, 2019

    This is one thing that I love in using TypeScript with React. I think this will help lot of projects. Rather than checking types using if else, we can just get help from TypeScript. Here is an example for Types helping in the value of props

    types

  13. sod commented on Apr 9, 2019

    @sod
    sod
    on Apr 9, 2019
    Contributor

    IntelliJ / WebStorm now does this. I guess they just started to work around the language service. But still no way to check it from ci.

    image

    Also the | async as ... syntax, for angular thats just any, is checked in that IDE

    image

    They tried to contribute in #25983, but it didn't land in master.

  14. jelbourn
    added
    P4A relatively minor issue that is not relevant to core functions
    and removed
    severity2: inconvenient
    on Oct 1, 2020

  15. JoostK commented on May 13, 2021

    @JoostK
    JoostK
    on May 13, 2021
    Member

    With the Ivy language service now using the compiler type checking infrastructure, this now works for inputs and output events provided that strictTemplates is enabled.

  16. JoostK
    closed this as completedon May 13, 2021

  17. angular-automatic-lock-bot commented on Jun 13, 2021

    @angular-automatic-lock-bot
    angular-automatic-lock-botBot
    on Jun 13, 2021

    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.

  18. angular-automatic-lock-bot
    locked and limited conversation to collaborators on Jun 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P4A relatively minor issue that is not relevant to core functionsarea: language-serviceIssues related to Angular's VS Code language servicefeatureLabel used to distinguish feature request from other issuesfreq3: high

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions