Sending a generalized data type as a parameter for a type

Question

Sending a generalized data type as a parameter for a type

In the process of developing a utility function to merge two TypeScript lists, I encountered the following challenge:

type TupleCombine<L extends unknown[], R extends unknown[]> =
    L extends [infer LH, ...infer LT]
    ? R extends [infer RH, ...infer RT]
    ? [LH & RH, ...TupleCombine<LT, RT>] // Merging tuples with 1+ elements
    : [LH & R[number], ...TupleCombine<LT, R>] // Merging tuple with list
    : R extends [infer RH, ...infer RT]
    ? [RH & L[number], ...TupleCombine<L, RT>] // Merging list with tuple
    : L extends []
    ? R extends []
    ? [] // Merging empty tuples
    : R[number] // Merging empty tuple with list 
    : R extends []
    ? L[number] // Merging empty list with tuple
    : (L[number] & R[number])[]; // Merging list types

I am now seeking a way to generalize this utility function so that I can avoid repeating similar cases for scenarios like "tuple unions" and other combinations involving tuple types.

My initial idea for this generalized version is as follows:

type TupleMerge<L extends unknown[], R extends unknown[], Combinator, Default> =
    L extends [infer LH, ...infer LT]
    ? R extends [infer RH, ...infer RT]
    ? [Combinator<LH, RH>, ...TupleMerge<LT, RT, Combinator, Default>]
    : [Combinator<LH, R[number]>, ...TupleMerge<LT, R, Combinator, Default>]
    : R extends [infer RH, ...infer RT]
    ? [Combinator<L[number], R>, ...TupleMerge<L, RT, Combinator, Default>]
    : L extends []
    ? R extends []
    ? []
    : [Combinator<Default, R[number]>]
    : R extends []
    ? [Combinator<L[number], Default>]
    : Combinator<L[number], R[number]>[];

Theoretically, I would specify a Combinator generic type in the following manner:

type Intersect<L, R> = L & R;
type TupleIntersect<L extends unknown[], R extends unknown[]> = TupleMerge<L, R, Intersect, unknown>;

type Union<L, R> = L | R;
type TupleIntersect<L extends unknown[], R extends unknown[]> = TupleMerge<L, R, Union, never>;

However, the TypeScript compiler does not permit this due to the restriction that "type parameters aren't generic types."

Is there a legitimate approach to achieving my objective using TypeScript? Or have I delved too deep into comparing TypeScript generic types with C++ template metaprogramming and template templates?

typescript generics types typescript-generics

Answer 1

Answer №1

One way to achieve your goal is by utilizing free-types library

import { Lift, $Intersect, $Unionize } from 'free-types';

type Foo = { a: 1 };
type Bar = { b: 2 };
type Baz = { c: 3 };
type Qux = { d: 4 };

type I = Lift<$Intersect, [[Foo, Bar], [Baz, Qux]]>
// type I = [Foo & Baz, Bar & Qux]

type U = Lift<$Unionize, [[Foo, Bar], [Baz, Qux]]>
// type U = [Foo | Baz, Bar | Qux]

playground

An update on jcalz' answer: the declaration merging method is no longer in extensive use. A notable package still applying this pattern is fp-ts, with gradual changes in the new version fp-ts/core.

The prevalent approach involves intersecting an interface with an object so that the this keyword within the interface references the members of the intersected object. This diminishes the need for registering types in numerous interfaces for various type parameter variants or implementing convoluted methods like using strings as parameters, keyof operations, and more.

A straightforward implementation:

type Type = { [k: number]: unknown, type: unknown }
type apply<$T extends Type, Args> = ($T & Args)['type'];

interface $Union extends Type { type: this[0] | this[1] }
interface $Intersection extends Type { type: this[0] & this[1] }

type A = { a: 1 };
type B = { b: 2 };

type UnionAB = apply<$Union, [A, B]> // { a: 1 } | { b: 2 }
type IntersectionAB = apply<$Intersection, [A, B]> // { a: 1 } & { b: 2 }

With free-types, which provides support for type constraints to some extent, reimplementing TupleZip, $Unionize, and $Intersect can be done as follows:

...

Some benefits of this strategy over interface merging and module augmentation include:

Bypassing the use of magic strings which can confuse users. By directly passing a type constructor, it aligns more with higher-order functions, making it easier to understand and work with.
A contract can specify an explicit return type, unlike interfacing indexing which only considers the legality at the point of usage. The user has control over their free type's contract, allowing for inverted dependencies.
In cross-package scenarios, when utilizing interface merging, there may be issues with checking external packages loaded into the IDE workspace. Using a contract allows for comprehensive type-checking at the definition site of the free type, regardless of external factors.

Answer 2

One way to achieve your goal is by utilizing free-types library

import { Lift, $Intersect, $Unionize } from 'free-types';

type Foo = { a: 1 };
type Bar = { b: 2 };
type Baz = { c: 3 };
type Qux = { d: 4 };

type I = Lift<$Intersect, [[Foo, Bar], [Baz, Qux]]>
// type I = [Foo & Baz, Bar & Qux]

type U = Lift<$Unionize, [[Foo, Bar], [Baz, Qux]]>
// type U = [Foo | Baz, Bar | Qux]

playground

An update on jcalz' answer: the declaration merging method is no longer in extensive use. A notable package still applying this pattern is fp-ts, with gradual changes in the new version fp-ts/core.

The prevalent approach involves intersecting an interface with an object so that the this keyword within the interface references the members of the intersected object. This diminishes the need for registering types in numerous interfaces for various type parameter variants or implementing convoluted methods like using strings as parameters, keyof operations, and more.

A straightforward implementation:

type Type = { [k: number]: unknown, type: unknown }
type apply<$T extends Type, Args> = ($T & Args)['type'];

interface $Union extends Type { type: this[0] | this[1] }
interface $Intersection extends Type { type: this[0] & this[1] }

type A = { a: 1 };
type B = { b: 2 };

type UnionAB = apply<$Union, [A, B]> // { a: 1 } | { b: 2 }
type IntersectionAB = apply<$Intersection, [A, B]> // { a: 1 } & { b: 2 }

With free-types, which provides support for type constraints to some extent, reimplementing TupleZip, $Unionize, and $Intersect can be done as follows:

...

Some benefits of this strategy over interface merging and module augmentation include:

Bypassing the use of magic strings which can confuse users. By directly passing a type constructor, it aligns more with higher-order functions, making it easier to understand and work with.
A contract can specify an explicit return type, unlike interfacing indexing which only considers the legality at the point of usage. The user has control over their free type's contract, allowing for inverted dependencies.
In cross-package scenarios, when utilizing interface merging, there may be issues with checking external packages loaded into the IDE workspace. Using a contract allows for comprehensive type-checking at the definition site of the free type, regardless of external factors.

Answer 3

Answer №2

One of the missing features in TypeScript is direct support for higher kinded types, where generic type parameters can themselves be generic. While there has been a long-standing request for this at microsoft/TypeScript#1213, it has not yet been implemented.

To work around this issue, one approach mentioned is to create a "registry" interface where higher kinded types can be placed and accessed using specific keys instead of names. Instead of defining types like:

type Intersect<L, R> = L & R;
type TupleIntersect<L extends unknown[], R extends unknown[]> =
  TupleZip<L, R, Intersect, unknown>;

type Union<L, R> = L | R;
type TupleIntersect<L extends unknown[], R extends unknown[]> =
  TupleZip<L, R, Union, never>;

You can use an interface and key referencing method like below:

interface Combinator<L, R> {
  Intersect: L & R;
}
type TupleIntersect<L extends unknown[], R extends unknown[]> =
  TupleZip<L, R, "Intersect", unknown>;
    
interface Combinator<L, R> {
  Union: L | R
}
type TupleUnion<L extends unknown[], R extends unknown[]> = 
  TupleZip<L, R, "Union", never>;

This requires updating your TupleZip definition to reflect these changes. You could also create utility types like ApplyCombinator to simplify things further:

type ApplyCombinator<K extends keyof Combinator<any, any>, L, R> =
  Combinator<L, R>[K];

type Demo = ApplyCombinator<"Intersect", Foo, Bar>
// type Demo = Foo & Bar

With that in place, you can test it out with examples like:

type I = TupleIntersect<[Foo, Bar], [Baz, Qux]>;
// type I = [Foo & Baz, Bar & Qux]
type U = TupleUnion<[Foo, Bar], [Baz, Qux]>;
// type U = [Foo | Baz, Bar | Qux]

All seems well!

Playground link to code

Answer 4

One of the missing features in TypeScript is direct support for higher kinded types, where generic type parameters can themselves be generic. While there has been a long-standing request for this at microsoft/TypeScript#1213, it has not yet been implemented.

To work around this issue, one approach mentioned is to create a "registry" interface where higher kinded types can be placed and accessed using specific keys instead of names. Instead of defining types like:

type Intersect<L, R> = L & R;
type TupleIntersect<L extends unknown[], R extends unknown[]> =
  TupleZip<L, R, Intersect, unknown>;

type Union<L, R> = L | R;
type TupleIntersect<L extends unknown[], R extends unknown[]> =
  TupleZip<L, R, Union, never>;

You can use an interface and key referencing method like below:

interface Combinator<L, R> {
  Intersect: L & R;
}
type TupleIntersect<L extends unknown[], R extends unknown[]> =
  TupleZip<L, R, "Intersect", unknown>;
    
interface Combinator<L, R> {
  Union: L | R
}
type TupleUnion<L extends unknown[], R extends unknown[]> = 
  TupleZip<L, R, "Union", never>;

This requires updating your TupleZip definition to reflect these changes. You could also create utility types like ApplyCombinator to simplify things further:

type ApplyCombinator<K extends keyof Combinator<any, any>, L, R> =
  Combinator<L, R>[K];

type Demo = ApplyCombinator<"Intersect", Foo, Bar>
// type Demo = Foo & Bar

With that in place, you can test it out with examples like:

type I = TupleIntersect<[Foo, Bar], [Baz, Qux]>;
// type I = [Foo & Baz, Bar & Qux]
type U = TupleUnion<[Foo, Bar], [Baz, Qux]>;
// type U = [Foo | Baz, Bar | Qux]

All seems well!

Playground link to code

Sending a generalized data type as a parameter for a type

Answer №1

Answer №2

Similar questions

Undefined 'require' error in Angular 2.0

Leverage the app.component function within an Ionic 2 page

Using TypeScript: Applying constraints to generic types with primitive datatypes

What is the best way to implement asynchronous guarding for users?

Struggling with data interpolation issues in Angular2+ while using Angular material table

Is there a way to set a default value for an Angular service provider?

A method to simultaneously retrieve all emitted values from multiple EventEmitters in Angular 7

Create generic functions that prioritize overloading with the first generic type that is not included in the parameters

Upon completion of a promise in an express middleware and breaking out of a loop, a 404 error is returned

The type 'typeof globalThis' does not have an index signature, therefore the element is implicitly of type 'any'. Error code: ts(7017) in TypeScript

Enable Ace Editor's read-only mode

Turn off the warning message that says 'Type of property circularly references itself in mapped type' or find a solution to bypass it

Issue encountered while setting up a socket server using socket.io in a TypeScript environment

How can I enhance the mongoose Query class using Typescript?

I encountered numerous type errors while working on a React Native project that utilizes TypeScript

Guide on utilizing the main development dependencies in Vue 3 Mono Repo

The express-validator library raises errors for fields that contain valid data

Experiencing trouble accessing a property in TypeScript

Decorators: A Handy Tool for Renaming Instance Keys

What's Going on with My Angular Dropdown Menu?