Tslint: no-unused-variable function called from the view Angular 2.

Created on 8 Jun 2016  ·  11Comments  ·  Source: palantir/tslint

Bug Report? Question

  • TSLint version: 3.10.2
  • TypeScript version: 1.8.10
  • Running TSLint via: gulp task

    TypeScript code being linted


@Component({
    templateUrl: /someComponent.html",
})
export class SomeComponent {
    private cancel(): void {
        console.log("CANCEL!");
    }
}
<button type="button" (click)="cancel()" >Avbryt</button>

with tslint.json configuration:

    "no-unused-variable": [
      true,
      "check-parameters",
      { "ignore-pattern": "fdescribe|xdescribe|fit|xit|on*|/g" }
    ],

Actual behavior

reported as an unused variable

Expected behavior

Could it check specified view file?
solved by prefixin with on but seems like there should be some better solution but have no Idea what....

Question

Most helpful comment

For anyone else reading this you can mark the methods as "protected" and the error goes away, but you're not exposing the method outside the class :+1:

All 11 comments

Checking a template file for references feels out-of-scope for TSLint because we rely on TypeScript's Language Service APIs for finding occurrences of values. I don't think TSLint will do this unless the LS does static analysis of templates (there is _some_ hope for this; see https://github.com/Microsoft/TypeScript/issues/3003 and https://github.com/Microsoft/TypeScript/issues/5151).

In the meantime, your workarounds are to use the ignore-pattern option or make those methods public.

Thats what I suspected, but wanted to make sure. Also relates to Microsoft/Typescript#5470 .

Thanks!

Going to close this because it's not actionable on the TSLint side of things. As always, more discussion is always welcome and if thing change in the future on the TS side of things we can see what we can do in TSLint as well

I think private modifier won't work anyway, because Angular 2 template compiler will produce .ts files when run as a build step, which will import the class and call the method. This won't typecheck unless you open up the visibility.

@alexeagle this still true?!
Currently in RC5 I'm using a lot of private methods from within the template. Would you advise me to change that?

Thank you...

Still true. The template is not part of the class, with AoT compilation it is a separate class. So they can't be private.

This is still not working with Angular2 Final and latest tslint (3.15.1). We have private template variables. Should we now make them all public ?

Having tslint look into Angular templates is complex. To do it right, we really need to use Angular's template expression parser to get 100% compatibility, then hook Angular as an extension in TypeScript language service. We are close to a first version of VSCode support for angular templates. I'd like to figure out the linting story soon after.

For anyone else reading this you can mark the methods as "protected" and the error goes away, but you're not exposing the method outside the class :+1:

I don't see why protected is helpful, you'll still get a type-check error
from the generated .ngfactory.ts file right?

On Tue, Jan 31, 2017 at 1:59 AM franz notifications@github.com wrote:

For anyone else reading this you can mark the methods as "protected" and
the error goes away, but you're not exposing the method outside the class
👍


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/palantir/tslint/issues/1295#issuecomment-276321769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5IxoPQbJmhHUaCVU4Ow8BoQzVSl9Hks5rXwYZgaJpZM4Iw1J3
.

I couldn't say @alexeagle - to be honest I'm using the ionic2 CLI which was giving the same issue. I would imagine it would solve the same issue .. it's all TypeScript under the hood.

I'm figuring tslint thinks the class may be inherited elsewhere (like a public modifier) and therefore doesn't flag it?

In essence making my methods (that are referenced in the template) no longer error when they're protected :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

denkomanceski picture denkomanceski  ·  3Comments

zewa666 picture zewa666  ·  3Comments

adidahiya picture adidahiya  ·  3Comments

avanderhoorn picture avanderhoorn  ·  3Comments

CSchulz picture CSchulz  ·  3Comments