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 often needed (and I think others do) to get type of element of collection, especially when dealing with collections of complex type. As a workaround I introduce new dummy variable which is assigned with a value of collection element in order to get its type further through the typeof. Here is a sample with simple collection of type number[]
functiontest(a: number[]){vardummy=a[0]returna.map(mapper)functionmapper(v: typeofdummy){// some code}}
A bad things about this approach is need to introduce new dummy variable, and some unclarified declarations function mapper(v: typeof dummy)
So my proposal is to provide some kind of metadata (which is common for C++ STL, boost) in form of exported type properties like <...container type...>.ElementType.
Here is not a final syntax, but at least it looks more clear
functiontest(a: number[]){returna.map(mapper)functionmapper(v: (typeofa).ElementType){// some code}}
It'd be good to understand what kind of things are showing up in your code other than number that make introducing new syntax preferable to just writing function mapper(v: number).
One alternative approach would be to allow indexing expressions with numeric literals in typeof positions. This would allow you to write:
Ryan Cavanaugh (@RyanCavanaugh) While the original example has an array of a known type, the syntax would also be useful in the case where the array type is anonymous, e.g. from a .map() call:
@ander-nz why? Since TS can derive type for data as {raw: number, square: number}[] then it will be able to derive a type for expression typeof data[0] as {raw: number, square: number}
Activity
RyanCavanaugh commentedon Jul 6, 2015
It'd be good to understand what kind of things are showing up in your code other than
numberthat make introducing new syntax preferable to just writingfunction mapper(v: number).One alternative approach would be to allow indexing expressions with numeric literals in
typeofpositions. This would allow you to write:lazdmx commentedon Jul 22, 2015
Ryan Cavanaugh (@RyanCavanaugh) I think that allowing indexing expression with numeric literals in would be concise and good solution.
Andael commentedon Aug 8, 2015
Ryan Cavanaugh (@RyanCavanaugh) While the original example has an array of a known type, the syntax would also be useful in the case where the array type is anonymous, e.g. from a
.map()call:lazdmx commentedon Aug 8, 2015
@ander-nz why? Since TS can derive type for
dataas{raw: number, square: number}[]then it will be able to derive a type for expressiontypeof data[0]as{raw: number, square: number}Andael commentedon Aug 8, 2015
lazutkin Sorry, my post was unclear, so I've updated it. (I meant that the type was unknown to the developer, so
typeofwould be useful)RyanCavanaugh commentedon Oct 5, 2015
Approved + accepting PRs: allow
typeof expr['str']andtypeof expr[42]in type positions.yortus commentedon Jan 25, 2016
I submitted a proposal + implementation that covers this: #6606
However the proposal goes beyond what's suggested here so is more aligned with #4233, with this issue covered as a special case.
simonbuchan commentedon Aug 8, 2017
Ryan Cavanaugh (@RyanCavanaugh) looks like this can be closed now?
mhegazy commentedon Nov 20, 2017
with indexed types,
typeof a[number]should work. see it on the playground