The type of Object.values() is not determined by a union or Records

Question

The type of Object.values() is not determined by a union or Records

When utilizing TypeScript, the Object.values() function encounters issues in deducing the accurate type from a union of Records:

type A = Record<string, number>;
type B = Record<string, boolean>;

function func(value: A | B) {
    const properties = Object.values(value); // any[]
}

TS Playground

I anticipate properties to be either number[] or boolean[], yet it is indeed any[].

Is there a method to properly determine the type from Object.values()?

typescript

Answer 1

Answer №1

When the Object.values(v) function is called, the compiler attempts to match the variable v against a type of {[k: string]: T} for a generic argument T that it automatically infers (as per this call signature).

If v has a type like {[k: string]: Z}, then the compiler will infer T as

Z</code, leading to successful compilation. However, if <code>v

is a union of records such as

{[k: string]: X} | {[k: string]: Y}

, the inference process differs. The algorithm does not directly synthesize X | Y as the inferred type

T</code. Instead, it selects one candidate - let's say, <code>X

- and raises an error if

Record<string, X> | Record<string, Y>

cannot be assigned to Record<string, X>.

This intentional avoidance of synthesizing union types aims to prevent situations where every call would succeed, causing potential issues with mismatched types.

In your scenario, however, you desire this union inference. An open feature request at microsoft/TypeScript#44312 proposes a method to facilitate this inference, although it is not yet incorporated into the language.

Hence, relying on the compiler to directly infer the desired union type is not feasible.

Instead, we can explicitly specify the union type when calling Object.values(), like so: Object.values<X | Y>(v). This means in your case, you could use

Object.values<number | boolean>(value)

and achieve the desired outcome.

However, hardcoding the type argument may not be ideal as you want it to dynamically adapt based on the type of value. To compute the type X | Y from a value such as

{[k: string]: X} | {[k: string]: Y}

, we can utilize the typeof type query operator paired with indexed access types.

For example:

Object.values<typeof value[string]>(value); // okay

To summarize using a general example:

function foo() {
    type A = Record<string, X>;
    type B = Record;
    function func(value: A | B) {
        return Object.values(value);        
    }
    // func(value: Record<string, X> | Record<string, Y>): (X | Y)[]
}

Within foo(), the func() function accepts a value of type A | B and returns a value typed as (X | Y)[], without requiring manual specification of X | Y. By employing typeof value[string], the compiler effectively calculates and utilizes the appropriate inferred union type.

Playground link to code

Answer 2

When the Object.values(v) function is called, the compiler attempts to match the variable v against a type of {[k: string]: T} for a generic argument T that it automatically infers (as per this call signature).

If v has a type like {[k: string]: Z}, then the compiler will infer T as

Z</code, leading to successful compilation. However, if <code>v

is a union of records such as

{[k: string]: X} | {[k: string]: Y}

, the inference process differs. The algorithm does not directly synthesize X | Y as the inferred type

T</code. Instead, it selects one candidate - let's say, <code>X

- and raises an error if

Record<string, X> | Record<string, Y>

cannot be assigned to Record<string, X>.

This intentional avoidance of synthesizing union types aims to prevent situations where every call would succeed, causing potential issues with mismatched types.

In your scenario, however, you desire this union inference. An open feature request at microsoft/TypeScript#44312 proposes a method to facilitate this inference, although it is not yet incorporated into the language.

Hence, relying on the compiler to directly infer the desired union type is not feasible.

Instead, we can explicitly specify the union type when calling Object.values(), like so: Object.values<X | Y>(v). This means in your case, you could use

Object.values<number | boolean>(value)

and achieve the desired outcome.

However, hardcoding the type argument may not be ideal as you want it to dynamically adapt based on the type of value. To compute the type X | Y from a value such as

{[k: string]: X} | {[k: string]: Y}

, we can utilize the typeof type query operator paired with indexed access types.

For example:

Object.values<typeof value[string]>(value); // okay

To summarize using a general example:

function foo() {
    type A = Record<string, X>;
    type B = Record;
    function func(value: A | B) {
        return Object.values(value);        
    }
    // func(value: Record<string, X> | Record<string, Y>): (X | Y)[]
}

Within foo(), the func() function accepts a value of type A | B and returns a value typed as (X | Y)[], without requiring manual specification of X | Y. By employing typeof value[string], the compiler effectively calculates and utilizes the appropriate inferred union type.

Playground link to code

Answer 3

Answer №2

Here is an example of how you can create the interface for a custom object construct called ObjectConstructorAlt.

declare interface ObjectConstructorAlt {
    values<T>(o: T):
    T extends any ?
        T extends Record<string|number, infer V> ? V[] 
            : T extends (infer V)[] ? V[]
            : any
        : never       
    ;
}
type A = Record<string, number>;
type B = Record<string, boolean>;
declare const a:A;
declare const b:B;
declare const ab:A|B;

Object.values(a); // number[]
Object.values(b); // boolean[]
Object.values(ab); // any[]

// actual implementation
const ObjectAlt: ObjectConstructorAlt = {
    values<T>(x: T){ 
        return Object.values(x as object) as any; 
    }
}
ObjectAlt.values(a); // number[]
ObjectAlt.values(b); // boolean[]
ObjectAlt.values(ab); // number[] | boolean[]

Typescript

If by some miraculous chance you were able to convince the TypeScript team to replace the current ObjectConstructor

interface ObjectConstructor {
    values<T>(o: { [s: string]: T } | ArrayLike<T>): T[];
    values(o: {}): any[];
    ...
}

with something like ObjectConstructorAlt, then you wouldn't need to apply a patch on your own. However, this scenario is highly unlikely as it could lead to longer compile times and potentially break other functionalities.

update - Just for your information, I raised this issue with TypeScript as an official concern and unfortunately, the existing behavior of Object.values/entries has been deemed not faulty. There are historical reasons behind this decision, which you can read about here.

Answer 4

Here is an example of how you can create the interface for a custom object construct called ObjectConstructorAlt.

declare interface ObjectConstructorAlt {
    values<T>(o: T):
    T extends any ?
        T extends Record<string|number, infer V> ? V[] 
            : T extends (infer V)[] ? V[]
            : any
        : never       
    ;
}
type A = Record<string, number>;
type B = Record<string, boolean>;
declare const a:A;
declare const b:B;
declare const ab:A|B;

Object.values(a); // number[]
Object.values(b); // boolean[]
Object.values(ab); // any[]

// actual implementation
const ObjectAlt: ObjectConstructorAlt = {
    values<T>(x: T){ 
        return Object.values(x as object) as any; 
    }
}
ObjectAlt.values(a); // number[]
ObjectAlt.values(b); // boolean[]
ObjectAlt.values(ab); // number[] | boolean[]

Typescript

If by some miraculous chance you were able to convince the TypeScript team to replace the current ObjectConstructor

interface ObjectConstructor {
    values<T>(o: { [s: string]: T } | ArrayLike<T>): T[];
    values(o: {}): any[];
    ...
}

with something like ObjectConstructorAlt, then you wouldn't need to apply a patch on your own. However, this scenario is highly unlikely as it could lead to longer compile times and potentially break other functionalities.

update - Just for your information, I raised this issue with TypeScript as an official concern and unfortunately, the existing behavior of Object.values/entries has been deemed not faulty. There are historical reasons behind this decision, which you can read about here.

The type of Object.values() is not determined by a union or Records

Answer №1

Answer №2

Similar questions

The functionality of the KendoReact Grid for filtering and sorting is not functioning correctly when data is grouped

Fetching JSON data using Promise.all results in an empty response

The MaterialTable component is indicating that there is no property called 'tableData' on the IPerson type

Is it possible to capture and generate an AxiosPromise inside a function?

The typescript error "Cannot read properties of undefined" is encountered while trying to access the 'map' function

Problem integrating 'fs' with Angular and Electron

The Angular library files built with ng build are not automatically included in the dist folder

Sending VSCode to external functions

One way to incorporate type annotations into your onChange and onClick functions in TypeScript when working with React is by specifying the expected

The attribute 'disabled' is originally defined as a characteristic within the class 'CanColor & CanDisableRipple & HasTabIndex & MatChipBase'. However, it is replaced in the current context of 'MatChip' as an attribute

A method for modifying the key within a nested array object and then outputting the updated array object

Dynamically pass a template to a child component

Image not found in next.js

Struggling to combine interface with import and local variables - any solutions?

What is the reason behind Rxjs switchMap only emitting the final value from an of() observable source?

Error in unit testing: Trying to access property 'pipe' of an undefined variable results in a TypeError

What is the best way to set up TypeScript to utilize multiple node_modules directories in conjunction with the Webpack DLL plugin?

Monitor modifications to documents and their respective sub-collections in Firebase Cloud Functions

Ways to transfer information among Angular's services and components?

Broaden material-ui component functionality with forwardRef and typescript