Are indexed properties constraints in Typescript only working with raw types and not with object literals?

Question

Are indexed properties constraints in Typescript only working with raw types and not with object literals?

After defining this interface:

interface Thing1 {
    [key: string]: string;
    x: number;
}

During compilation in Typescript, an error is thrown stating "TS2411: Property 'x' of type number is not assignable to string index type 'string'."

While this error seems reasonable, when using an object literal as the indexed type value like:

interface Foo {}
interface Thing2 {
    [key: string]: Foo;
    foo: number;
}

Surprisingly, there is no error reported, even though number and Foo are different types.

Do you have any insights into why this inconsistency occurs?

Note: This was tested on Typescript 2.1.5

typescript

Answer 1

Answer №1

The reason for this behavior is the way type compatibility functions in TypeScript:

Type compatibility in TypeScript relies on structural subtyping, which compares types based on their members rather than their names. This differs from nominal typing.

For example, the following code snippet is valid:

interface Foo {}
let f: Foo = 3;

This is because every property in {} has a corresponding property with the same name and type in Number.

However, the following code will result in an error:

interface Foo {}
let f: Foo = 3;
let b: number = f;

The compiler flag an issue at let b: number = f;:

Type 'Foo' cannot be assigned to type 'number';

Once again, referring to the documentation:

TypeScript's structural type system was developed to align with the typical coding practices of JavaScript. Given that JavaScript often uses anonymous objects like function expressions and object literals, it makes more sense to represent relationships found in JavaScript libraries using a structural type system as opposed to a nominal one.

Answer 2

The reason for this behavior is the way type compatibility functions in TypeScript:

Type compatibility in TypeScript relies on structural subtyping, which compares types based on their members rather than their names. This differs from nominal typing.

For example, the following code snippet is valid:

interface Foo {}
let f: Foo = 3;

This is because every property in {} has a corresponding property with the same name and type in Number.

However, the following code will result in an error:

interface Foo {}
let f: Foo = 3;
let b: number = f;

The compiler flag an issue at let b: number = f;:

Type 'Foo' cannot be assigned to type 'number';

Once again, referring to the documentation:

TypeScript's structural type system was developed to align with the typical coding practices of JavaScript. Given that JavaScript often uses anonymous objects like function expressions and object literals, it makes more sense to represent relationships found in JavaScript libraries using a structural type system as opposed to a nominal one.

Answer 3

Answer №2

When dealing with empty interfaces in Typescript, it's important to note that they are compatible with simple types such as numbers and strings. For example, you can assign a number to a variable declared as an interface like this:

let x: Bar = 5;

This means that in some cases, Typescript will still consider the interface compatible with the assigned type. However, if the interface includes an index signature (like in Thing1), all members must adhere to the specified type (in this case, string).

Answer 4

When dealing with empty interfaces in Typescript, it's important to note that they are compatible with simple types such as numbers and strings. For example, you can assign a number to a variable declared as an interface like this:

let x: Bar = 5;

This means that in some cases, Typescript will still consider the interface compatible with the assigned type. However, if the interface includes an index signature (like in Thing1), all members must adhere to the specified type (in this case, string).

Are indexed properties constraints in Typescript only working with raw types and not with object literals?

Answer №1

Answer №2

Similar questions

Encountering a Issue with Http module in Angular

Utilizing the Angular *ngFor directive to iterate through JSON data

What are some ways to access Angular's form array within HTML code?

Base class protected properties are absent following the exclusion of another property

Simplify typing in TypeScript using default generic parameters

Error encountered: `npm ERR! code E503`

The return type is not undefined but the switch covers all possibilities

Using ngIf for various types of keys within a JavaScript array

Issues arise when attempting to include the src attribute within the template tag in a Vuejs and Laravel project

What is the accurate type of control parameter in Typescript?

Issue with Nestjs and Jest: expect().toHaveReturnedWith() not returning any value

Having trouble with routerLink in your custom library while using Angular 4?

The invocation of `prisma.profile.findUnique()` is invalid due to inconsistent column data. An invalid character 'u' was found at index 0, resulting in a malformed ObjectID

What could be causing the Uncaught Error to persist even after using .catch()?

Switching from module.exports in Javascript to Typescript format

Encountering error code TS1003 while trying to access object properties using bracket notation in Typescript

Could a variable (not an element) be defined and controlled within an Angular 2 template?

Explore all user-defined properties of a specified type using the TypeScript Compiler API

eliminate any redundant use of generics

Adding the unzip feature is not within my capabilities