You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Private members used only via [] notation trigger --noUnusedLocals error #14137
classPhoneBook{privatesally: number=123;// error TS6133: 'sally' is declared but never used.privatesam: number=456;// error TS6133: 'sam' is declared but never used.getNumber(who: 'sally'|'wendy'): number{returnthis[who];// tsc is able to correctly deduce that this is a number}}constphoneBook=newPhoneBook();console.log(phoneBook.getNumber('sally'));
Expected behavior:
Using a private member via [] notation should not trigger --noUnusedLocals errors.
Actual behavior:
A private member used only via [] triggers --noUnusedLocals errors.
It could reasonably be argued that this is not an obvious or perhaps common use case. And indeed, this can be worked around. Obviously, this example is contrived in the extreme. And yet, I would maintain that in some cases it may be a reasonable use case which obeys (I believe) all the rules of the language, and ought not trigger a compiler error.
I have encountered this issue. In my case, I use state property for dynamic dispatching.
Can I avoid those errors and keep dynamic dispatching?
typeParserState="A_STATE"|"B_STATE"|"Z_STATE"classParser{privatestate: ParserStateconstructor(){this.state="A_STATE"}parse(){while(this.state!=="Z_STATE"){this.state=this[this.state]()}}privateA_STATE(): ParserState{/* .... */}// 'A_STATE' declared but never used.privateB_STATE(): ParserState{/* .... */}// 'B_STATE' declared but never used.privateZ_STATE(): ParserState{/* .... */}// 'Z_STATE' declared but never used.}
However, getting forced to remove some intentional unused locals like specific imports, I decided to use tslint till tsc supports warning messages. Besides that I just agree with alexeagle who said in issue #15953 :
So I believe TypeScript should avoid non-fatal diagnostics (and unused variable was a mistake).
To overcome the need of activated type info for tslint core rule no-unused-variable I came up with ajafff's tslint-consistent-codestyle custom rule no-unused which workes quiet fine (without type info) for many cases, just class members are ignored for now, but it's a brand new rule, so let's wait and see.
I opt for improving this as well, because the the dynamic dispatching (as named by Toru Nagashima (@mysticatea)) is a very efficient way of implementing the strategy pattern in TypeScript that I use a lot, as it removes the necessity of an extra object only existing to map a string to a certain function.
Here is an example of a class converting a JSON schema into a valid elasticsearch mapping, that only serves the purpose of demonstration, in a real world, I wouldn't actually implement it as a class.
This is actually nice and concise. However, the compiler does not understand, that the -ToEsMap methods are actually used and throws an error.
Which forces me to either extract them into a separate module, which violates the separation of concerns principle and considerable augments the number of arguments the methods would have to take, or, to "manually" create an additional map property to hold these methods:
Activity
studds commentedon Feb 17, 2017
It could reasonably be argued that this is not an obvious or perhaps common use case. And indeed, this can be worked around. Obviously, this example is contrived in the extreme. And yet, I would maintain that in some cases it may be a reasonable use case which obeys (I believe) all the rules of the language, and ought not trigger a compiler error.
kemsky commentedon Mar 29, 2017
It does not work in a more simple case like
object["property"].mysticatea commentedon May 21, 2017
I have encountered this issue. In my case, I use
stateproperty for dynamic dispatching.Can I avoid those errors and keep dynamic dispatching?
Manusan42 commentedon Jul 1, 2017
I have a similar problem like mysticatea...
However, getting forced to remove some intentional unused locals like specific imports, I decided to use
tslinttilltscsupports warning messages. Besides that I just agree with alexeagle who said in issue #15953 :To overcome the need of activated type info for
tslintcore ruleno-unused-variableI came up with ajafff'stslint-consistent-codestylecustom ruleno-unusedwhich workes quiet fine (without type info) for many cases, just class members are ignored for now, but it's a brand new rule, so let's wait and see.Dervol03 commentedon May 17, 2018
+1
I opt for improving this as well, because the the
dynamic dispatching(as named by Toru Nagashima (@mysticatea)) is a very efficient way of implementing the strategy pattern in TypeScript that I use a lot, as it removes the necessity of an extra object only existing to map a string to a certain function.Here is an example of a class converting a JSON schema into a valid elasticsearch mapping, that only serves the purpose of demonstration, in a real world, I wouldn't actually implement it as a class.
Example:
This is actually nice and concise. However, the compiler does not understand, that the
-ToEsMapmethods are actually used and throws an error.Which forces me to either extract them into a separate module, which violates the separation of concerns principle and considerable augments the number of arguments the methods would have to take, or, to "manually" create an additional map property to hold these methods:
Which doesn't really help. Or worse, move everything to static methods, which creates the same problems as the ones with a separate module