What exactly does bivarianceHack aim to achieve within TypeScript type systems?

Question

What exactly does bivarianceHack aim to achieve within TypeScript type systems?

As I went through the TypeScript types for React, I noticed a unique pattern involving a function declaration called bivarianceHack():

_{@types/react/index.d.ts}

type EventHandler<E extends SyntheticEvent<any>> = { bivarianceHack(event: E): void }["bivarianceHack"];

I searched but couldn't find any documentation explaining why this specific pattern was chosen. However, I did come across other instances of using this pattern, indicating it's not exclusive to React.

What is the reason behind using this pattern instead of (event: E) => void?

typescript types

Answer 1

Answer №1

This issue revolves around the concept of function compatibility when using the strictfunctionTypes option in TypeScript. Essentially, under this setting, passing an argument of a derived type to a function that expects a base class argument is not allowed. An example to illustrate this:

class Animal { private x: undefined }
class Dog extends Animal { private d: undefined }

type EventHandler<E extends Animal> = (event: E) => void

let o: EventHandler<Animal> = (o: Dog) => { } // triggers an error under strictFunctionTypes

However, there is a specific exception mentioned regarding method or constructor declarations in the PR:

The stricter checking applies to all function types, except those originating in method or constructor declarations. This exclusion ensures that generic classes and interfaces like Array<T> still maintain covariance relationships. The decision not to strictly check methods was made to prevent a significant breaking change where many generic types would become invariant (although further exploration into a stricter mode may be considered).

Important emphasis on the above statement.

Therefore, a workaround has been introduced to preserve the bivariant behavior of the EventHandler even with strictFunctionTypes enabled. Since the event handler's signature originates from a method declaration, it remains exempt from the stricter function checks.

type BivariantEventHandler<E extends Animal> = { bivarianceHack(event: E): void }["bivarianceHack"];
let o2: BivariantEventHandler<Animal> = (o: Dog) => { } // continues to work with strictFunctionTypes

You can also test this scenario in the TypeScript Playground here.

Answer 2

This issue revolves around the concept of function compatibility when using the strictfunctionTypes option in TypeScript. Essentially, under this setting, passing an argument of a derived type to a function that expects a base class argument is not allowed. An example to illustrate this:

class Animal { private x: undefined }
class Dog extends Animal { private d: undefined }

type EventHandler<E extends Animal> = (event: E) => void

let o: EventHandler<Animal> = (o: Dog) => { } // triggers an error under strictFunctionTypes

However, there is a specific exception mentioned regarding method or constructor declarations in the PR:

The stricter checking applies to all function types, except those originating in method or constructor declarations. This exclusion ensures that generic classes and interfaces like Array<T> still maintain covariance relationships. The decision not to strictly check methods was made to prevent a significant breaking change where many generic types would become invariant (although further exploration into a stricter mode may be considered).

Important emphasis on the above statement.

Therefore, a workaround has been introduced to preserve the bivariant behavior of the EventHandler even with strictFunctionTypes enabled. Since the event handler's signature originates from a method declaration, it remains exempt from the stricter function checks.

type BivariantEventHandler<E extends Animal> = { bivarianceHack(event: E): void }["bivarianceHack"];
let o2: BivariantEventHandler<Animal> = (o: Dog) => { } // continues to work with strictFunctionTypes

You can also test this scenario in the TypeScript Playground here.

Answer 3

Answer №2

In order to address the --strictFunctionTypes issue that impacts how a function's type is assigned to its parameters, it was mentioned earlier.

I felt it was important to provide further illustration of this point.

Illustrative Example

Interactive Playground

https://i.sstatic.net/2DFBB.png

Clarification

'foo' | 'bar' is considered a subtype of string, or in TypeScript terms, you could express it as 'foo' | 'bar' extends string.

When utilized as parameters for function F, the assignability behaves differently.

The equation

F<string> extends F<'foo' | 'bar'>

showcases contravariance within the type parameter.

In the example above, there are two tests conducted for the function independently and then with the bivariance workaround implemented. The first test explores contravariance, while the second examines covariance.

In absence of the workaround, the function displays contravariant behavior exclusively. However, after applying the hack, it exhibits both contravariant and covariant characteristics, making it bivariant.

An informative article on this specific concept in TypeScript can be found here.

Answer 4

In order to address the --strictFunctionTypes issue that impacts how a function's type is assigned to its parameters, it was mentioned earlier.

I felt it was important to provide further illustration of this point.

Illustrative Example

Interactive Playground

https://i.sstatic.net/2DFBB.png

Clarification

'foo' | 'bar' is considered a subtype of string, or in TypeScript terms, you could express it as 'foo' | 'bar' extends string.

When utilized as parameters for function F, the assignability behaves differently.

The equation

F<string> extends F<'foo' | 'bar'>

showcases contravariance within the type parameter.

In the example above, there are two tests conducted for the function independently and then with the bivariance workaround implemented. The first test explores contravariance, while the second examines covariance.

In absence of the workaround, the function displays contravariant behavior exclusively. However, after applying the hack, it exhibits both contravariant and covariant characteristics, making it bivariant.

An informative article on this specific concept in TypeScript can be found here.

What exactly does bivarianceHack aim to achieve within TypeScript type systems?

Answer №1

Answer №2

Illustrative Example

Clarification

Similar questions

Having trouble getting Tailwind CSS utility classes to work with TypeScript in create-react-app

Encountering a compiler error due to lack of patience for a promise?

Issue TS2365: The operation of addition cannot be performed between an array of numbers and the value -1000

Retrieving information from a .json file using TypeScript

Drizzle-ORM provides the count of items in a findMany query result

Angular is not programmed to automatically reflect updates made to my string array

Change a TypeScript alias within the @types namespace

Ensure that Angular resolver holds off until all images are loaded

The names of properties in Typescript are determined by the values of the outer type properties

Using ternary operator to set multiple variables in setState

Directly retrieve the result from http service (observable) without the need to return Observable from the function

The interface does not allow properties to be assigned as string indexes

Setting up NextJs in Visual Studio Code with Yarn

The production build encountered an error after upgrading Angular due to a problem with document.documentElement.setAttribute not being recognized

Guidelines for utilizing NgFor with Observable and Async Pipe to create Child Component once the data has been loaded

Jest snapshot tests are not passing due to consistent output caused by ANSI escape codes

Oops! The system encountered a problem: the property 'modalStack' is not recognized on the type 'NgxSmartModalService'. Maybe you meant to use '_modalStack' instead?

Steps for combining a sequence of subsequent subscriptions in RxJS

Ways to extract information from a database using a parameter

Can you explain the significance of the additional pipeline in the type declaration in TypeScript?