Distinguishing TypeScript between the source object and the spread object

Question

Distinguishing TypeScript between the source object and the spread object

I'm struggling with a riddle related to Typescript:

const randomFn = (arg: Record<string, unknown>): string => 'kappa'

export type Values = {
    key: string;
};
const values: Values = {
    key: 'kappa'
}

const { ...spread } = values;

randomFn(values)
randomFn(spread) // produce Index signature for type 'string' is missing in type '{ transaction: string; }'.(2345)

Why does Typescript generate errors for the spread object when they should have the same typing in my opinion? When examining the object in the playground, it appears to be identical for the TS compiler. Both the original and the spreaded object.

Typescript version 4.5.4. Reproduction in Type Script Playground

EDIT: also doing double spread to make it work again .

randomFn({...spread}) // NO error

typescript typescript-typings

Answer 1

Answer №1

When spreading, the type is lost because there is no guarantee that the spread object is of the same type. Take this example:

const { excluded, ...rest } = object;

It is clear that rest cannot have the same type as object since a key is missing!

Another way to look at it is:

const [excluded, ...rest] = array;

This is why the spread operation does not maintain the type of Values.

Answer 2

When spreading, the type is lost because there is no guarantee that the spread object is of the same type. Take this example:

const { excluded, ...rest } = object;

It is clear that rest cannot have the same type as object since a key is missing!

Another way to look at it is:

const [excluded, ...rest] = array;

This is why the spread operation does not maintain the type of Values.

Answer 3

Answer №2

The limitations within TypeScript lead to this outcome, as detailed in microsoft/TypeScript#42021. When employing a rest element in an object destructuring assignment, TypeScript fails to replicate an index signature in the type of the newly created variable. It also does not support the inclusion of an implicit index signature (the reason for which is unclear, as mentioned in this comment).

The Values type alias can include an implicit index signature (although it would not be permissible if it were defined as an interface, as discussed in microsoft/TypeScript#15300). Thus, it can be considered as assignable to Record<string, unknown> (equivalent to {[k: string]: unknown}, featuring a string index signature). However, spread, acting as a rest-destructured variable, does not meet this criteria and hence results in failure.

It has been observed that performing a second rest destructuring does yield the desired outcome, indicating potential irregularities in how object types are designated to allow or disallow implicit index signatures. This anomaly is also acknowledged in microsoft/TypeScript#42021, albeit lacking an explanation.

Presently, there isn't a fully satisfactory resolution unless there is further progress in microsoft/TypeScript#42021.

Answer 4

The limitations within TypeScript lead to this outcome, as detailed in microsoft/TypeScript#42021. When employing a rest element in an object destructuring assignment, TypeScript fails to replicate an index signature in the type of the newly created variable. It also does not support the inclusion of an implicit index signature (the reason for which is unclear, as mentioned in this comment).

The Values type alias can include an implicit index signature (although it would not be permissible if it were defined as an interface, as discussed in microsoft/TypeScript#15300). Thus, it can be considered as assignable to Record<string, unknown> (equivalent to {[k: string]: unknown}, featuring a string index signature). However, spread, acting as a rest-destructured variable, does not meet this criteria and hence results in failure.

It has been observed that performing a second rest destructuring does yield the desired outcome, indicating potential irregularities in how object types are designated to allow or disallow implicit index signatures. This anomaly is also acknowledged in microsoft/TypeScript#42021, albeit lacking an explanation.

Presently, there isn't a fully satisfactory resolution unless there is further progress in microsoft/TypeScript#42021.

Distinguishing TypeScript between the source object and the spread object

Answer №1

Answer №2

Similar questions

Can TypeScript support promise chaining in a functional way?

Styling of Bootstrap HTML element not appearing as expected

Unable to navigate to a page called "meeting" in NextJS 13 due to issues with router.push not functioning correctly

Retrieve input from text field and showcase in angular 6 with material design components

Tips for inserting a property into an array of objects when it matches the specified ID

Invoking a function from a collection of mixed data types

Transforming JavaScript into TypeScript within an Angular 4 component class

how to implement dynamic water fill effects using SVG in an Angular application

Tips on excluding node_modules from typescript in Next.js 13

When using a Redux action type with an optional payload property, TypeScript may raise complaints within the reducer

I am currently working on an Angular 8 project and experiencing difficulties with displaying a specific value from a JSON object in my template using an ngFor loop

What is the best way to incorporate an external .css file into my Angular project by referencing its URL?

Angular: Refresh Mat-Table data following any changes

Include an external JavaScript file within a component to display pictures in a web browser using Angular 2

Steps for modifying the look of a button to display an arrow upon being clicked with CSS

Sending data between components in Angular can be achieved by using various methods. One common approach is to utilize

Conflicting events arising between the onMouseUp and onClick functions

Rotate object within HTML table

Steps to resolve the Angular observable error

Unable to attach eventName and callback to addEventListener due to the error message stating 'No overload matches this call'