add support of fromEntries

[Kingwl]

Fixes #25999

[mhegazy]

either Record<string, any> or object. {} is the wrong type here.

[mhegazy]

consider using Record<string, T> instead.

[mhegazy]

@RyanCavanaugh the new file will need to be added to the setup of the VS SDK. you will need to run VS\scripts\distributeLibFiles.bat to update the setup.

[Jessidhia]

Would be nice to support tuple types but not sure the compiler is clever enough to deal with that without having to define 200 overloads

fromEntries<K1 extends string, V1>(entries: [[K1, V1]]): { [K1]: V1 }
fromEntries<K1 extends string, V1, K2 extends string, V2>(entries: [[K1, V1], [K2, V2]]): { [K1]: V1; [K2]: V2 }
// ...

[Bnaya]

It was nice if typescript had any way to declare types mapping from tuple to object

[alangpierce]

Is there a real use case for Object.fromEntries with a fixed number of entries? Seems like almost always you can just use object literal syntax in a case like that.

[Bnaya]

I have a use case for that :)
im doing a-lot of these manipulations.
and if i had a generic way to express it, that would be awesome

[alangpierce]

@Bnaya can you share a realistic code snippet where object literal syntax doesn't work but fixed-length fromEntries does?

[alangpierce]

I want to call out a usability issue I've seen when working with this API: tuple types aren't inferred from array literals in typical situations for the "object comprehension" use case.

For example, this snippet doesn't typecheck:

const thingsById = Object.fromEntries(things.map((thing) => [thing.id, thing]));

The underlying error is Type '(string | Thing)[]' is not assignable to type '[string, Thing]'., which happens because [thing.id, thing] is treated as an array of string | Thing rather than a tuple type.

As one workaround, I can make my own function entry that forces the type to be a tuple:

function entry<T>(key: string, value: T): [string, T] { return [key, value]; }
const thingsById = Object.fromEntries(things.map((thing) => entry(thing.id, thing)));

but certainly that's not ideal since it's not in the JS standard library.

Maybe the typechecker could be smarter here and either try both variants (array and tuple) or see from context that we prefer a tuple return type from the arrow function rather than an array type?

[Jessidhia]

This can already be encountered today when mapping data for passing to a Map constructor, this will just be another place where it happens.

Tangentially related, I encounter this more commonly now in my codebase when writing custom React hooks.

As a really simple custom hook, take:

function useLoggedState<T>(initialValue: T | (() => T) {
  const [value, setValue] = React.useState(initialValue)
  useEffect(() => {
    console.log('value is', value)
  }, [value])
  return [value, setValue]
}

Letting typescript infer the return type produces (T | React.Dispatch<React.SetStateAction<T>>)[] which is not useful at all to users of the hook.

I've been fixing it with return [value, setValue] as [typeof value, typeof setValue]. This is probably the cleanest way to deal with it until we have some way to tell typescript that it's ok to infer a tuple from an array literal.

[aboyton]

It would be great if Object.fromEntries(Object.entries(foo)) returned something of the same type as foo where possible.

When foo is of type { [key: string]: T } this should be easy but it would be nice if this could also support { [key in Values]: T } and { [key in Values]?: number } as well.

enum Values {
  a = 'a',
  b = 'b',
  c = 'c',
}

const foo: { [key in Values]: number } = { a: 1, b: 2, c: 3 };
const bar = Object.fromEntries(Object.entries(foo));

[saschanaz]

tc39/ecma262#1274

fromEntries only accepts iterable object so probably we should remove ArrayLike here. The Firefox implementation also throws for array-like object.

(Edit: Or replace it with ReadonlyArray if we want it to be ES5 compatible.)

[saschanaz]

@Kingwl Object.fromEntries just hit stage 4 as (yet incomplete) ES2019 standard. Would you fix this PR to use es2019.object instead?

[Kingwl]

@saschanaz sure, after a few moments later

[bakkot]

Drive-by comment: fromEntries allows Symbol keys, not just strings.

[Jessidhia]

😸

The more comprehensive version is:

1. The first argument must be an Iterable. The algorithm literally calls @@iterator. Can't get away with ArrayLikes here.
2. The iterable must yield an object of the shape { 0?: string | number | symbol | null | { valueOf(): string | number } | { toString(): string }; 1?: any }. This is probably not very useful for the actual type definition, and is incomplete as the valueOf may just be any other coercible value; but the point is that the Iterable's value needs not be an array or ArrayLike.
   2a) The "0" key / first element of tuple just needs to be something that can be cast into an object key, and that includes undefined. undefined becomes "undefined" and null becomes "null". Pretty much the only thing I found that "doesn't work" is Object.create(null).
   2b) The "1" key / second element of tuple is the value associated with the key.
   2c) Any of those keys may be getters or just missing entirely. They may even be write-only setters.
3. Duplicates overwrite each other in iteration order. The last value wins.

---

Current TypeScript treats tuples as assignable to objects with numeric literal keys. Using <K extends keyof any, T> as the generic argument and Iterable<{ 0: K, 1: T }> should work for most cases; with maybe a few more overloads for index signatures and a catch-all for mixed tuples.

[ljharb]

This proposal is now stage 4, in ES2019.

Is there any possibility of making the types for this function take an iterable of entries, where an Entry is a tuple-2 of "K extends PropertyKey, V extends unknown", and returns an object consisting of all the K: V pairs in entries? It seems a shame if the type needs to end up being something less magical.

[Jessidhia]

<K extends keyof any, T>(entries: Iterable<{ 0: K, 1: T }>): Record<K, T> will do, but unfortunately typescript can't represent an iterable that yields different types over time. Another overload would be needed if the 1 is optional ({ 0: K, 1?: T }, which would have T | undefined as the resulting value type.

It's possible to do something like <K0 extends keyof any, T0, K1 extends keyof any, T1, ...>(entries: [{ 0: K0, 1: T0 }, { 0: K1, 1: T1 }, ...]): {[K in K0 | K1 | ...]: K extends K0 ? T0 : K extends K1 ? T1 : ...}, or otherwise use intersection types, but you basically need an extra overload for each arity, and you have to use tuple types instead of iterable types.

[bakkot]

It seems reasonable to me that the return type is no more precise than Record<K, T>. That's consistent (ish) with the inverse function, anyway.

[RyanCavanaugh]

I think we'll pick this up at #30934. It would be great if people could write up concise example testcases they think should pass / should fail for the definition WIP