What sets apart extending and intersecting interfaces in TypeScript?

Question

What sets apart extending and intersecting interfaces in TypeScript?

If we have the following type defined:

interface Shape {
  color: string;
}

Now, let's explore two different methods to add extra properties to this type:

Using Extension

interface Square extends Shape {
  sideLength: number;
}

Using Intersection

type Square = Shape & {
  sideLength: number;
}

What sets apart these two approaches?

And just to ensure we cover all bases and satisfy our curiosity, are there other ways to achieve similar results?

typescript types intersection extends

Answer 1

Answer №1

Indeed, there exist differences that may or may not be applicable to your specific situation.

One of the most notable disparities lies in how members with identical property keys are managed when present in both types.

Take for example:

interface NumberToStringConverter {
  convert: (value: number) => string;
}

interface BidirectionalStringNumberConverter extends NumberToStringConverter {
  convert: (value: string) => number;
}

The extends keyword here triggers an error due to the fact that the inheriting interface declares a property with the same key as one in the parent interface but with incompatible signatures.

error TS2430: Interface 'BidirectionalStringNumberConverter' incorrectly extends interface 'NumberToStringConverter'.

  Types of property 'convert' are incompatible.
      Type '(value: string) => number' is not assignable to type '(value: number) => string'.
          Types of parameters 'value' and 'value' are incompatible.
              Type 'number' is not assignable to type 'string'.

However, by utilizing intersection types:

type NumberToStringConverter = {
  convert: (value: number) => string;
}

type BidirectionalStringNumberConverter = NumberToStringConverter & {
  convert: (value: string) => number;
}

No errors occur in this scenario. Furthermore, this approach is advantageous as it allows for easy conceptualization of a value adhering to this particular intersection type.

const converter: BidirectionalStringNumberConverter = {
    convert: (value: string | number) => {
        return (
          typeof value === 'string'
            ? Number(value)
            : String(value)
          ) as string & number; // type assertion is an unfortunately necessary hack.
    }
}

It's important to note that while the implementation of the intersection involves some cumbersome types and assertions, these are simply implementation details that do not impact the type of the converter object determined solely by the

BidirectionalStringNumberConverter

type annotation used on the converter object literal.

const s: string = converter.convert(0); // `convert`'s call signature comes from `NumberToStringConverter`

const n: number = converter.convert('a'); // `convert`'s call signature comes from `BidirectionalStringNumberConverter`

Playground Link

Another significant distinction is that interface declarations are open-ended. Additional members can be added anywhere because multiple interface declarations with the same name in the same declaration space are merged. This differs from the type expression created by &, which generates an anonymous expression that can be assigned to an alias for reuse but cannot be extended through merging.

Here's a common example demonstrating the merging behavior:

lib.d.ts

interface Array<T> {
  // map, filter, etc.
}

array-flat-map-polyfill.ts

interface Array<T> {
  flatMap<R>(f: (x: T) => R[]): R[];
}

if (typeof Array.prototype.flatMap !== 'function') {
  Array.prototype.flatMap = function (f) { 
    // Implementation simplified for exposition. 
    return this.map(f).reduce((xs, ys) => [...xs, ...ys], []);
  }
}

Notice the absence of an extends clause. Despite being specified in separate files, the interfaces reside in the global scope and are merged by name into a unified logical interface declaration containing both sets of members. (Similar merging can be achieved for module-scoped declarations with slight syntax adjustments)

In contrast, intersection types stored within a type declaration are closed and not subject to merging.

There are numerous distinctions between the two approaches. For further information, you can refer to the TypeScript Handbook. The sections on Object Types and Creating Types from Types offer valuable insights.

Answer 2

Indeed, there exist differences that may or may not be applicable to your specific situation.

One of the most notable disparities lies in how members with identical property keys are managed when present in both types.

Take for example:

interface NumberToStringConverter {
  convert: (value: number) => string;
}

interface BidirectionalStringNumberConverter extends NumberToStringConverter {
  convert: (value: string) => number;
}

The extends keyword here triggers an error due to the fact that the inheriting interface declares a property with the same key as one in the parent interface but with incompatible signatures.

error TS2430: Interface 'BidirectionalStringNumberConverter' incorrectly extends interface 'NumberToStringConverter'.

  Types of property 'convert' are incompatible.
      Type '(value: string) => number' is not assignable to type '(value: number) => string'.
          Types of parameters 'value' and 'value' are incompatible.
              Type 'number' is not assignable to type 'string'.

However, by utilizing intersection types:

type NumberToStringConverter = {
  convert: (value: number) => string;
}

type BidirectionalStringNumberConverter = NumberToStringConverter & {
  convert: (value: string) => number;
}

No errors occur in this scenario. Furthermore, this approach is advantageous as it allows for easy conceptualization of a value adhering to this particular intersection type.

const converter: BidirectionalStringNumberConverter = {
    convert: (value: string | number) => {
        return (
          typeof value === 'string'
            ? Number(value)
            : String(value)
          ) as string & number; // type assertion is an unfortunately necessary hack.
    }
}

It's important to note that while the implementation of the intersection involves some cumbersome types and assertions, these are simply implementation details that do not impact the type of the converter object determined solely by the

BidirectionalStringNumberConverter

type annotation used on the converter object literal.

const s: string = converter.convert(0); // `convert`'s call signature comes from `NumberToStringConverter`

const n: number = converter.convert('a'); // `convert`'s call signature comes from `BidirectionalStringNumberConverter`

Playground Link

Another significant distinction is that interface declarations are open-ended. Additional members can be added anywhere because multiple interface declarations with the same name in the same declaration space are merged. This differs from the type expression created by &, which generates an anonymous expression that can be assigned to an alias for reuse but cannot be extended through merging.

Here's a common example demonstrating the merging behavior:

lib.d.ts

interface Array<T> {
  // map, filter, etc.
}

array-flat-map-polyfill.ts

interface Array<T> {
  flatMap<R>(f: (x: T) => R[]): R[];
}

if (typeof Array.prototype.flatMap !== 'function') {
  Array.prototype.flatMap = function (f) { 
    // Implementation simplified for exposition. 
    return this.map(f).reduce((xs, ys) => [...xs, ...ys], []);
  }
}

Notice the absence of an extends clause. Despite being specified in separate files, the interfaces reside in the global scope and are merged by name into a unified logical interface declaration containing both sets of members. (Similar merging can be achieved for module-scoped declarations with slight syntax adjustments)

In contrast, intersection types stored within a type declaration are closed and not subject to merging.

There are numerous distinctions between the two approaches. For further information, you can refer to the TypeScript Handbook. The sections on Object Types and Creating Types from Types offer valuable insights.

Answer 3

Answer №2

Check out the updated documentation from Typescript that delves into this particular scenario!

https://www.typescriptlang.org/docs/handbook/2/objects.html#interfaces-vs-intersections

"The key distinction between interfaces and intersections lies in how conflicts are managed, and this is often a deciding factor when choosing between the two for defining an object type."

Answer 4

Check out the updated documentation from Typescript that delves into this particular scenario!

https://www.typescriptlang.org/docs/handbook/2/objects.html#interfaces-vs-intersections

"The key distinction between interfaces and intersections lies in how conflicts are managed, and this is often a deciding factor when choosing between the two for defining an object type."

What sets apart extending and intersecting interfaces in TypeScript?

Answer №1

Answer №2

Similar questions

Troub3leshooting Circular Dependency with Typescript, CommonJS & Browserify

Compelled to utilize unfamiliar types in TypeScript generics

What is the best way to combine async/await with a custom Promise class implementation?

Using forEach in React to simultaneously set multiple properties and return destructured output within the setState function

What is the best way to interpret the data from forkjoin map?

How to access nested JSON elements in Javascript without relying on the eval function

An error is triggered when an HttpClient post does not return any data

Capable of retrieving response data, however, the label remains invisible in the dropdown menu

What is the best way to export a default object containing imported types in TypeScript?

Issues with functionality of React/NextJS audio player buttons arise following implementation of a state

Looping Through RxJS to Generate Observables

Error encountered in Jest mockImplementation: Incompatible types - 'string[]' cannot be assigned to 'Cat[]' type

Is it possible to import both type and value on the same line when isolatedModules=true?

What could be causing MongoDB to not delete documents on a 30-second cycle?

Encountered an error while trying to update information in Angular

How can we avoid excessive re-rendering of a child component in React when making changes to the parent's state?

Step-by-step guide on building a mat-table with nested attributes as individual rows

Create a collection of values and assign it to a form control in Ionic 2

Volar and vue-tsc are producing conflicting TypeScript error messages

Is there a way for me to program the back button to navigate to the previous step?