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
I think that #29179 has broken this anyway since IdentityCandidate extends DataTypeKey = DataType[IdentityCandidate] references itself in its default. Can you confirm Anders Hejlsberg (@ahejlsberg)?
I think in my tinkering I've come up with variants that don't rely on such, so -- if there's a suitable alternative to make the example a bit more robust, let me know. 😄
I should add -- without a circular reference, I'm not sure what other kind of syntax I'd have to come up with to express what I want here. The type is effectively justifying itself, or bailing out.
I think that #29179 has broken this anyway since IdentityCandidate extends DataTypeKey = DataType[IdentityCandidate] references itself in its default. Can you confirm Anders Hejlsberg (@ahejlsberg)?
Yes, the code above now errors on the circular reference to IdentityCandidate in its own default (which is a good thing, since it doesn't make sense to reference a type parameter for which no type argument was specified).
I'm no fan of circular references, so I'm onboard there -- but I need a way to check if that type, when used as a key, retrieves a string. In this case, I'm not entirely convinced this is a circular reference, at least in intent.
However, it looks to me like the IdentityCandidate type parameter is never supposed to be specified and is just intended as an alias for the default value. That's definitely an anti-pattern, and I would suggest inlining it instead:
So, I think overall the advice here worked, but there's one thing that could possibly be improved:
constkey=item[this.props.identityProperty];
When I do the above, the value key, doesn't want to be a string. Even though this.props.identityProperty is required to be a key that resolves to a string value.
Conversion of type 'ItemType[NonNullable<ItemType[Extract<keyof ItemType, string>] extends string ? Extract<keyof ItemType, string> : never>]' to type 'string' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
I can do that, but I feel like the compiler has enough information here to know that the value I get when using this key will have to be a string?
This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.
Activity
DanielRosenwasser commentedon Dec 31, 2018
I think that #29179 has broken this anyway since
IdentityCandidate extends DataTypeKey = DataType[IdentityCandidate]references itself in its default. Can you confirm Anders Hejlsberg (@ahejlsberg)?atrauzzi commentedon Dec 31, 2018
I think in my tinkering I've come up with variants that don't rely on such, so -- if there's a suitable alternative to make the example a bit more robust, let me know. 😄
I should add -- without a circular reference, I'm not sure what other kind of syntax I'd have to come up with to express what I want here. The type is effectively justifying itself, or bailing out.
ahejlsberg commentedon Dec 31, 2018
Yes, the code above now errors on the circular reference to
IdentityCandidatein its own default (which is a good thing, since it doesn't make sense to reference a type parameter for which no type argument was specified).atrauzzi commentedon Dec 31, 2018
Anders Hejlsberg (@ahejlsberg) - If that's the case, is there an alternate way for me to express:
I'm no fan of circular references, so I'm onboard there -- but I need a way to check if that type, when used as a key, retrieves a string. In this case, I'm not entirely convinced this is a circular reference, at least in intent.
ahejlsberg commentedon Dec 31, 2018
Not entirely clear on what you're trying to do, but I think you could write it like this:
However, it looks to me like the
IdentityCandidatetype parameter is never supposed to be specified and is just intended as an alias for the default value. That's definitely an anti-pattern, and I would suggest inlining it instead:Hope that helps.
atrauzzi commentedon Jan 5, 2019
So, I think overall the advice here worked, but there's one thing that could possibly be improved:
When I do the above, the value
key, doesn't want to be a string. Even thoughthis.props.identityPropertyis required to be a key that resolves to a string value.If I do this:
I get:
I can do that, but I feel like the compiler has enough information here to know that the value I get when using this key will have to be a string?
typescript-bot commentedon Jul 13, 2019
This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.