microsoft / microsoft/TypeScript

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

Open
#60,859 4 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Awaiting More Feedback Suggestion
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

🔍 Search Terms

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

✅ Viability Checklist
⭐ 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.
  1. 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.

  2. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the linked Stack Overflow examples and the proposed Object.entries/Object.fromEntries transformations, including the alternative union-matching utility. Determine whether the request is a feasible language-service or standard-library typing change and define the required inference behavior; done requires an agreed design and corresponding type-checking tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.