Typed Object.entries/Object.fromEntries - Or Type Utility to infer Unions with matching length so that a new type safe object can be made

[Jonathan002]

🔍 Search Terms

"Typed Object.entries", "Typed Object.fromEntries", "Object.fromEntries", "Object.entries", "Infer Union Types"

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I have an issue where I'm trying to Match Two Union Types together to make Object.entries and map() back to a transformed Object.fromEntries(). I believe I almost can do it, but may lack the typescript tool to do a correct inference to make sure two unions with the same length and match up properly.

I would like to refer to this stack overflow question I have asked: https://stackoverflow.com/questions/79310390/i-need-help-strongly-typing-typescript-object-entries?noredirect=1#comment139855755_79310390

I think Object.entries() and adding transformations to the Value is a common operation. It would be amazing if typescript had implicitly made it easy for it to correctly become a typed object with Object.fromEntries().

Preferable Feature:
The feature suggestion hopes that either native es Object.fromEntries( Object.entries().map(([key, val]) => [key, () => val]) ) can infer value transformations and match a key automatically.

---

Alternative Feature:
Type utilities to make the above possible if the user has to create their own types. Currently I find it difficult to work with generic unions that match the same length and match them to map back to an object. You can view my code question: https://stackoverflow.com/questions/79310390/i-need-help-strongly-typing-typescript-object-entries?noredirect=1#comment139855755_79310390 and notice that I'm trying to Extract<Val, Val> in the case it comes back as a union. The code already feels complex. It would be great if additional type tools can help with Entry Types or Unions with the same length. Maybe a syntax to declaratively state EntryUnion<UnionOne, UnionTwo, FallbackValue> which would do its best to match each union index accordingly if the lengths fit or go to a fallback value if UnionTwo does not fit UnionOne length.

// Note: The union matching to create a working Object.fromEntries() works if we incorrectly use infer _V.
// ------------------------------------------------------------
// Context:
// Entry: ["fruitName", "apple"] | ["description", string] | ["weight", number] | ["isFresh", boolean]
  // infer K: "fruitName" | "description" | "weight" | "isFresh"
  // infer _V: "apple" | string | number | boolean
// Val: 
  // - Example 1: 123 - number
  // - Example 2: entry[1] - "apple" | string | number | boolean - Same union as infer _V but does not key match with infer K
  // - Example 3: () => entry[1] - () => string | number | boolean
  // - Example 4: { test: entry[1] } - { test: string | number | boolean }
type TransformEntry<Entry, Val> = Entry extends [infer K, infer _V] ? [K, Extract<Val, Val>] : never;

📃 Motivating Example

Please refer to this stack overflow question and view the examples: https://stackoverflow.com/questions/79310390/i-need-help-strongly-typing-typescript-object-entries?noredirect=1#comment139855755_79310390

JS has a large api that deal with the concept of entries that work with Object.fromEntries() that will eventually become an object. If we can parse these patterns as special, it would be more type safe rather than doing type assertions to correct the output.

• Object.entries
• new Map().entries()
• new Set().entries()
• Array.entries()

---

• Object.fromEntries()

💻 Use Cases

1. What do you want to use this for?

• I would use this with everyday Object transformation of values. It would be amaizing to just iterate objects and tap into a value update with seemless type inference.

2. What shortcomings exist with current approaches?
   The current approach is more tedious and less type safe. Most consumers apparently just use type assertion when doing Object.fromEntries(Object.entries()) which can be prone to human error.

3. What workarounds are you using in the meantime?
   This example in the stack overflow question is what I use: https://stackoverflow.com/questions/79310390/i-need-help-strongly-typing-typescript-object-entries?noredirect=1#comment139855755_79310390 or sometimes my own type assertion.

[jcalz]

It's not just matching length, it's that each entry key might correspond to a different value type. Lengths can be handled, arbitrary type mappings cannot. If TS gets higher kinded types like #1213, or maybe call types like #40179, then I think map() could be rewritten to handle what you're doing, but without that, I don't see it.

[MartinJohns]

It's also important to mention that the actual values returned by Object.entries() can contain keys not present on the type, because objects are not sealed in TypeScript. For this alone I can't really see any improvements to the typings of Object.entries().