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
In frameworks like Ember the following pattern would be very common:
import*asEmberfrom'ember';const{ computed, get }=Ember;interfacemyComponent{myProp: Ember.ComputedProperty<number>;someMethodThatWouldUseMyProp(): any;}varmyComponent={myProp: computed.readOnly<number>('someDep'),someMethodThatWouldUseMyProp(){constmyPropValue=get<myComponent,'myProp'>(this,'myProp');}};
Having a declaration file for Ember like the following:
declarenamespaceEmber{classComputedProperty<T>{get(keyName: string): T;/* some more props omitted */}namespacecomputed{interfacereadOnly{<T>(dependentKey: string): ComputedProperty<T>;}functionreadOnly<T>(dependentKey: string): ComputedProperty<T>;}interfaceget{<T,KextendskeyofT>(obj: T,keyName: K): T[K];}functionget<T,KextendskeyofT>(obj: T,keyName: K): T[K];}export=Ember;
would result in const myPropValue = get<myComponent, 'myProp'>(this, 'myProp'); inferring a type as Ember.ComputedProperty<number> which is not what we really want as the way get method works is not just T[K] but : T[K] and then if the inferred type is Ember.ComputedProperty<F> it would actually return those F like so:
and then redefining the Ember.ComputedProperty declaration in a such way that we would be able to infer type value from it:
classComputedProperty<T>{get(keyName: string): T;_value: T;/* some more props omitted */}
we then would be sure that when we have const myPropValue: F = get<myComponent, 'myProp', '_value'>(this, 'myProp'); we would end up with the correct type for myPropValue. Now however this way of defining and using get function would throw: TS2344 Type '_value' does not satisfy the constraint 'never'
Another even better option would be able to have our get method declaration like the following:
This would allow for even more clean code: const myPropValue: F = get<myComponent, 'myProp'>(this, 'myProp');. Now it throws either TS2339 Property '_value' does not exist on type T[K]. Such approach would also allow for multiple level deep computed properties that are supported in Ember:
Ideally if we have #12342 we wouldn't have to define the _value in ComputedProperty in the declaration files and use the result of the get method instead:
classComputedProperty<T>{get(keyName: string): T;/* some more props omitted */}interfaceget{<T,KextendskeyofT,FextendskeyofT[K]>(obj: T,keyName: K): ReturnType<T[K][F]["get"]>;}functionget<T,KextendskeyofT,FextendskeyofT[K]>(obj: T,keyName: K): ReturnType<T[K][F]["get"]>;
The text was updated successfully, but these errors were encountered:
canufeel
changed the title
Feature request: Static types for dynamically named properties work only one level deep.
Feature request: Multiple level deep Static types for dynamically named properties.
Nov 21, 2016
Uh oh!
There was an error while loading. Please reload this page.
Background
In frameworks like Ember the following pattern would be very common:
Having a declaration file for Ember like the following:
would result in
const myPropValue = get<myComponent, 'myProp'>(this, 'myProp');
inferring a type asEmber.ComputedProperty<number>
which is not what we really want as the wayget
method works is not justT[K]
but :T[K]
and thenif
the inferred type isEmber.ComputedProperty<F>
it would actually return thoseF
like so:Proposal
The simplest way to achieve proper behaviour at least as it seems would be to allow using nesting with static types for dynamically named properties:
and then redefining the
Ember.ComputedProperty
declaration in a such way that we would be able to infer type value from it:we then would be sure that when we have
const myPropValue: F = get<myComponent, 'myProp', '_value'>(this, 'myProp');
we would end up with the correct type formyPropValue
. Now however this way of defining and usingget
function would throw:TS2344 Type '_value' does not satisfy the constraint 'never'
Another even better option would be able to have our
get
method declaration like the following:This would allow for even more clean code:
const myPropValue: F = get<myComponent, 'myProp'>(this, 'myProp');
. Now it throws eitherTS2339 Property '_value' does not exist on type T[K]
. Such approach would also allow for multiple level deep computed properties that are supported in Ember:Ideally if we have #12342 we wouldn't have to define the
_value
in ComputedProperty in the declaration files and use the result of theget
method instead:Related:
#11929
#12342
The text was updated successfully, but these errors were encountered: