Support known possible keys in Object.entries and Object.fromEntries

[wucdbm]

Search Terms

Object.entries, Object.fromEntries

Suggestion

Add

entries<E extends PropertyKey, T>(o: { [K in E]: T } | ArrayLike<T>): [E, T][]; to Object.entries in lib.es2017.object.d.ts see #12253 (comment)

and

fromEntries<K extends PropertyKey, T = any>(entries: Iterable<readonly [K, T]>): { [k in K]: T }; to Object.fromEntries in lib.es2019.object.d.ts
OR
fromEntries<K extends string, T = any>(entries: Iterable<readonly [K, T]>): { [k in K]: T }; extends string for now until #31393 is resolved in terms of the "keyofStringsOnly": true compiler option, which would disallow number and symbol.

#31393 is a related issue that suggests the same addition @ fromEntries
Any other research lead me to #12253 (comment)

Use Cases

Basically, I'd like to map an object with known finite number of fields to an object with the same keys, but where the values are of different type (in the example below - the values are transformed from an object containing label: string and rating: number to number)

Examples

Example repository at https://github.com/wucdbm/typescript-object-entries-key-type
Commenting out the two suggested additions in src/types/es.d.ts leads to two errors in index.ts (Please have a look at the types in src/types/rating.d.ts)

const requestData: BackendRatingRequest = {
    stars: Object.fromEntries(
        Object.entries(rating.stars).map((v: [RatingFields, RatingWithLabel]) => {
            return [v[0], v[1].rating]
        })
    ),
    feedback: rating.feedback
};

1. Object.entries(rating.stars).map((v: [RatingFields, RatingWithLabel]) => { RatingFields has no sufficient overlap with string, where because of rating.stars's index signature, the key can only be one of the values of RatingFields

2. Object.fromEntries complains that the keys of RatingFields are missing. But in this case, the first element of the returned array can only be of type RatingFields

I'm leaving the first checklist option unticked. I am unsure whether this wouldn't be a breaking change for TypeScript code in some situations. I personally haven't encountered one, and have had the same es.d.ts file, found in the example repo, in our project, in order to prevent build errors.

Would be nice if someone with more experience in TS's internals had a look at this. Particularly if it woul lead to any regressions.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[MicahZoltu]

The case of Object.fromEntries I believe this is different from the Object.keys and Object.entries problem. In the Object.keys and Object.entries case, it would be incorrect for TypeScript to assume that the only keys on the object are limited to those on the type. In the case of Object.fromEntries however, TypeScript can guarantee that the Object it returns will at least have the set of keys it knows about on the incoming tuple array.

@wucdbm I recommend removing the Object.entries case from this request as that cannot change without breaking TypeScript type safety (see the issue about Object.keys you linked). I think Object.fromEntries can be fixed though.

[dragomirtitian]

Personal stab at typing it, it gets kind of complex, not sure if there is a simpler approach 😕

type UnionToIntersection<T> = (T extends T ? (p: T) => void : never) extends (p: infer U) => void ? U : never
type FromEntries<T extends readonly [PropertyKey, any]> = T extends T ? Record<T[0], T[1]> : never;
type Flatten<T> = {} & {
  [P in keyof T]: T[P]
}

function fromEntries<V extends PropertyKey, T extends [readonly [V, any]] | Array<readonly [V, any]>>(entries: T): Flatten<UnionToIntersection<FromEntries<T[number]>>> {
  return null!;
}

let o = fromEntries([["A", 1], ["B", "1"], [1, true]])
// let o: {
//     A: number;
//     B: string;
//     1: boolean;
// }

Playground Link

Or without any helper types (can't wait for the SO questions as to what this does 😂):

function fromEntries<V extends PropertyKey, T extends [readonly [V, any]] | Array<readonly [V, any]>>(entries: T):
  (((T[number] extends infer Tuple ? Tuple extends [PropertyKey, any] ? Record<Tuple[0], Tuple[1]> : never : never) extends
    infer FE ? (FE extends FE ? ((p: FE) => void) : never) extends (p: infer U) => void ? U : never : never) extends 
    infer R ? { [P in keyof R] : R[P] }: never)
    
  {
  
  return null!;
}

let o = fromEntries([["A", 1], ["B", "1"], [1, true]])
// let o: {
//     A: number;
//     B: string;
//     1: boolean;
// }

Playground Link

[wucdbm]

@MicahZoltu Fair enough.

In that case, I guess the Object.entries problem could be solved by a 3rd-party library that implements runtime extraction based on a type/interface, simply for the sake of not writing these functions by hand.

For example,

import {entries} from 'some-lib';

const someTypeEntriesOnly = entries<SomeType>(object);

would generate (once per type) a function that takes an object and returns the fields of SomeType only by calling Object.entries(object) and then calling .filter to only return the subset contained in SomeType. Or something like that. Assuming the Object.fromEntries proposal is accepted, this would work perfectly well for us, although in our particular case we wouldn't need the .filter overhead from such a library as the values passed around in our app never satisfy two separate types. At least so far.
But then again, this seems to fall outside of the intended use of TypeScript itself.

I stumbled upon https://www.npmjs.com/package/typescript-is and #14419 today. Could use its source code as a starting point if 14419 is accepted and its easy to plug into TS for code generation.

WDYT?

[MicahZoltu]

Something similar to typescript-is could work for generating code that "loops over all of the keys known at compile time, but not over all of the keys on the object".

[wucdbm]

Original comment updated.

Furthermore, due to #31393 imo it makes sense to go with K extends string rather than K extends PropertyKey for the time being, as that shouldn't hurt anybody, until #31393 is resolved.

fromEntries<K extends string, T = any>(entries: Iterable<readonly [K, T]>): { [k in K]: T };

[Wenzil]

What is the status on this? fromEntries seems like it would only benefit from @wucdbm's type signature above.

[MicahZoltu]

Often you can achieve the desired result with a pattern like this:

const fruits = [ 'apple', 'banana', 'cherry' ] as const
type Fruits = (typeof fruits)[number]
type FruitBasket = Record<Fruits, number>

function countFruits(fruitBasket: FruitBasket) {
    let totalFruits = 0
    for (const fruit of fruits) {
        totalFruits += fruitBasket[fruit]
    }
    return totalFruits
}

countFruits({ apple: 5, banana: 7, cherry: 3 }) // returns: 15

const produceBasket = { apple: 5, banana: 2, cherry: 1, asparagus: 7 }
countFruits(produceBasket) // returns: 8; note it didn't count the asperagus

[wucdbm]

@MicahZoltu Good point. That could come in handy in several of the use-cases the .entries typing proposal was trying to solve.

Does anybody know a use-case where fromEntries<K extends string, T = any>(entries: Iterable<readonly [K, T]>): { [k in K]: T }; will be wrong or interfere with other features or break existing code?

[alamothe]

Can TypeScript at least provide a type-safe version of Object.entries for Record<K, V>?

Here keys are known to be of K, but the current signature treats them as strings.

[sdegutis]

Just now I was thinking:

type A = {
    Message: string;
    Detail: string;
    code: string;
}

Object.entries(a) // should return B

type B = [
    ["Message", string],
    ["Detail", string],
    ["code", string],
];

Is that the same feature that this issue is requesting? I was about to make a feature request issue for this use-case.

[flying-sheep]

Hi, I was just bitten by this. I very much expected this to work:

type Foo = 'a' | 'b' | 'c'
const foos: Foo[] = ['a', 'b', 'c']
const recs: Record<Foo, number> = Object.fromEntries(foos.map((foo, i) => [foo, i]))

[CarterLi]

At least this should work:

let obj = { a: 1, b: 2 };
obj = Object.fromEntries(Object.entries(obj));

Its pattern is generally used as a quick implementation of mapValues. Please fix it.

[wucdbm]

Do const obj = {...another} then, should be good
This is pretty important when mapping the values to something else

[CarterLi]

Ok. Then lets make this work

let obj = { a: 1, b: 2 };
obj = Object.fromEntries(Object.entries(obj).map(([key, value]) => [key, value + 1]));

[simPod]

@wucdbm ?

[wucdbm]

@simPod It has been too long and there are several objections against this, and I've already forgotten whether anything could be done on this matter. I know for sure I made a custom type on one of my projects and that's been long forgotten.

If you have the capacity to carry on, please review and open a new discussion about the part that could be implemented, and check if there aren't any objections against it.

To be fair, given the time span and the fact that JS isn't my primary strength, I can't judge what makes sense at this point, and I don't really have the time or will to get into it.

This has been further fortified by several rejections of contributions towards improving terrible (to say the least) design of (otherwise great) OS libraries, so my will to help anywhere is nowhere to be found these days, sorry.

[flying-sheep]

Are there any reasons against making a PR with @dragomirtitian’s types in #35745 (comment)?

[RyanCavanaugh]

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;

[niieani]

@RyanCavanaugh this is true for writeable arrays, but not for const tuples.
Const tuples by definition must include all the the members, and thus guarantee their contents.
Here's a PR with a fix: #50203.

[GravlLift]

So I get the hesitancy to use const property keys here. However, I don't understand why the return type is {k: string]: T}. Given the input type of Iterable<readonly [PropertyKey, T]>, I would expect a return type of {[k: PropertyKey]: T}, no?

After all, Object.fromEntries([[0, "test"]]) spits out {0: "test"}.

[niieani]

Just FYI for anyone following, since my PR with strict typing wasn't accepted due to "too complex", I've finally gotten around to publishing an NPM package with the strict Object.fromEntries typings. It doesn't suffer from any unsoundness as far as I can tell and is fully compatible with the regular Object.fromEntries.

See nesity-types.

[wucdbm]

The radash library has mapEntries in case anyone stumbles upon this.

[adroste]

@wucdbm Neither radash nor lodash nor remeda offer proper type inference (for const values with custom keys).
The only working solutions I've found so far (for both directions entries and fromEntries) is from StackOverflow https://stackoverflow.com/a/69019874/6292230
Quick reminder: code from SO is licensed CC BY-SA (copyleft/viral)