Skip to content

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

Open
@Jonathan002

Description

@Jonathan002

πŸ” 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions