Support type-checking of computed properties for constants and Symbols

[IgorMinar]

On Angular we are considering using ES6 computed prototype methods as part of Angular’s component api but we realized that typescript doesn’t allow us to express this in a type-safe way.

I’m wondering if this is a feature that could be added to typescript or if there is a fundamental issue that would prevent typescript from supporting this. Example:

{Component, onInit, OnInit} from ‘angular2/core';

@Component({
 selector: 'my-component'
})
class MyComponent implements OnInit {
 [onInit](param1, param2){ return something; }
}

Where onInit is a const string or ES Symbol, and OnInit is an interface with the signature of the [onInit] method. onInit is a an optional life-cycle hook that Angular will call if the component has this property name.

The reason why we find this api style attractive is that it removes the possibility of name-collisions, which means that we are free to add support for more hooks in the future without affecting any existing components.

PS: ES Observables are already using Symbols to define the observable interface, so this feature would allow creation of Observable interface. I expect more libs will want to take advantage of this api style as computed property and Symbol support becomes better.

Related issue: #4653

[mhegazy]

#4653 is much simpler to do. in fact Vladimir Matveev (@vladima) has a change out for this one.

Using non-literals is a different issue. there is a more elaborate discussion here: #2012

[ahejlsberg]

Igor Minar (@IgorMinar) The tricky issue here is that during the binding phase of compilation we need to know the spelling of every symbol (so we can build symbol tables). However, we can't know the actual spelling of the string or symbol that onInit references without resolving that expression, which requires binding information, which is what we're in the process of collecting. So, to support full checking of user defined symbols we'd have to introducing some sort of iterative partial binding which would be a fairly disruptive change. It currently works for built-in symbols only because we specially recognize symbols of the form [System.XXX], but it isn't clear that we could do something similar for libraries in general.

[benlesh]

This seems directly related to an issue I have here: #8099

[benlesh]

Anders Hejlsberg (@ahejlsberg) would it be possible to type this with an annotation like [Symbol.for('xyz')]? Since Symbol.for() creates and returns a single static reference, this could be "type checked" so to speak.

I think there's an obvious problem with dealing with [randomSymbol] properties, in that Symbol('foo') === Symbol('foo') is false.

A weirder problem exists around the polyfilling of symbols with "@@mysymbol"... which depending on the platform is interchanged with a symbol as a property key. so { ["@@mysymbol"]: () => {} } should match { [Symbol.for('mysymbol')]: () => void }.

[DanielRosenwasser]

If there was something like a generic primitive type, symbol<"xyz"> would be an interesting possibility. Default type arguments could also make symbol equivalent to symbol<any>. I dunno, just an idea.

[kitsonk]

Coming in with something related... Anders Hejlsberg (@ahejlsberg) you say that the compiler has a bit of a challenge with resolving the types that aren't on the global Symbol. Even though clearly I don't know the inner working, I wonder if that is strictly still true. For Dojo 2 we produced a Symbol shim which doesn't modify the global scope if there is no Symbol present (though it does fill in missing "well knowns"). Then other modules, instead of relying upon the global Symbol reference the module (therefore minimising issues other code running in the same environment).

When we target es5 everything works perfectly fine. The compiler handles everything and is even aware of the primitive type of symbol. It is only when targeting es6 does the error 'Symbol' reference does not refer to the global Symbol constructor object. present itself.

[mhegazy]

The way it works today is by checking the text of the name to identify the property, that is exactelly "Symbol.iterator". if you change any thing about this it is not found. this is why it is important to know that you are using the global "Symbol" and not a local Symbol. in --t es5, the definition of Symbol does not exist, so the check does not happen. but that does not mean it "works". for instance, see:

import sym from './Symbol';
var i: Iterable<string>;
i[sym.iterator] // not the same as Symbol.iterator.

import Symbol from `./Symbol`;
const iteratorSymbol = Symbol.iterator;
i[sym.iterator] // still not the same as Symbol.iterator.

This issue tracks making it work, ideally by knowing the "identity" of a symbol and use that to define and access properties.

there is more relevant discussion on why it works this way and what is missing in #2012

[benlesh]

the global "Symbol" and not a local Symbol

It's probably worth disambiguating this a bit:

1. Symbol('description'): A local symbol with a description, always a different reference.
2. Symbol.for('name'): A global symbol looked up by name and created if it doesn't exist
3. Symbol.iterable, Symbol.toStringTag, et al: Global symbols that should always be present.
4. "@@whatever": A string property name used as a place holder, generally for number 2 above, in environments where Symbol doesn't exist (legacy browsers, etc).

I don't think we can track the first type there. The rest, though, should be doable.

[kitsonk]

Ok, I understand now. I guess though, it is a but "surprising" that unlike most features in TypeScript which have some sort of the "trust me, I know what I am doing" flag. This particular one doesn't seem to have such an option.