Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript doesn't understand fromEntries #43332

Closed
vdegenne opened this issue Mar 21, 2021 · 5 comments
Closed

TypeScript doesn't understand fromEntries #43332

vdegenne opened this issue Mar 21, 2021 · 5 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@vdegenne
Copy link

vdegenne commented Mar 21, 2021

Look at this example

const exchanges = {
  kraken: new Object,
  binance: new Object,
  others: new Object
}

declare type AvailableExchanges = keyof typeof exchanges;

declare type WalletsData = {
  [key in AvailableExchanges]: []
}

let wallets: WalletsData
wallets = Object.fromEntries(Object.keys(exchanges).map(exchange => {
  return [exchange, []]
}))

I have an initial object exchanges (key: name of the exchange, value: Object).
Then I declare a type to have all the exchange names in a string literal type.
I declare another object representing a wallet for each exchange in a separator data structure.

Finally I create wallets object based on this last structure. I expect no error since I am only creating a structure similar in keys of the first one only a different value type that map take care to create.
But wallets variable is having an error saying :

Type '{ [k: string]: []; }' is missing the following properties from type 'WalletsData': kraken, binance, others

@RyanCavanaugh RyanCavanaugh added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Mar 22, 2021
@RyanCavanaugh
Copy link
Member

We don't have any type constructors that could do this, so the definition is written as well as it can be.

@nmain
Copy link

nmain commented Mar 23, 2021

If you refactor the Object.fromEntries(Object.keys(..... code into a helper function that takes a value selector predicate, you can usually put a type on the helper function that lets you have strong typing when calling that function using mapped types. The types for lodash may have some inspiration in them.

@lmmarsano
Copy link

lmmarsano commented Mar 21, 2022

The type system is powerful enough to do better than this.
I often override the built-in type definitions if it's bad enough.

type UnionToIntersection<Union>
  = (
    Union extends unknown
    ? (distributedUnion: Union) => void
    : never
  ) extends ((mergedIntersection: infer Intersection) => void)
  ? Intersection
  : never
type Entry<T, K = keyof T>
  = K extends keyof T
  ? [K, T[K]]
  : never
type _FromEntry<T extends readonly [PropertyKey, unknown]>
  = T extends unknown
  ? { [k in T[0]]: T[1] }
  : never
type FromEntry<T extends readonly [PropertyKey, unknown]> = UnionToIntersection<_FromEntry<T>>

interface ObjectConstructor {
  entries<T>(o: T): Entry<T>[]
  fromEntries<T extends readonly [PropertyKey, unknown]>(entries: Iterable<T>): FromEntry<T>
  keys<T>(o: T): (keyof T)[]
}

Some type definitions at first glance seem unnecessary: they're written that way to take advantage of distributive conditional types.
Distributivity in Entry produces a union of ordered-pairs instead of a single ordered-pair of unions.
UnionToIntersection takes advantage of covariance in function parameters & distributivity to infer an intersection.
FromEntry distributively maps each ordered-pair of a union to a singleton key/value mapping, then intersects that union to merge all those mappings.

With these definitions, your code (lightly modified to explicitly type ordered pairs) passes type check.

@mxdvl
Copy link

mxdvl commented Jul 6, 2022

I believe this is a duplicate of #35745. As mentioned there:

It's not correct to use the input type to determine the output type, because knowing what might be in an array is not the same as knowing what's actually in it. This program is legal per the above definitions but unsound:

const arr: Array<["A", 1] | ["B", 2]> = [];
let o = fromEntries(arr);
let m: number = o.A;

RyanCavanaugh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

6 participants