Changing the types of arguments in a function, and the difference in behavior between Mapped types (functioning) and Recursive types (not functioning)

Question

Changing the types of arguments in a function, and the difference in behavior between Mapped types (functioning) and Recursive types (not functioning)

After experimenting with transforming arguments of a function using a recursive type, I encountered an issue trying to make the type work. To illustrate the problem, I created a simplified example along with examples using a mapped type (for this particular toy example, a mapped type would suffice): Playground

Initially, I created Transform functions using both mapped types and recursive types, with test data and tests to verify that they return the same result.

type TestItems = [string, number, string, boolean]

export type MappedTransform<UnionWith, Items extends any[]> 
  = { [I in keyof Items]: Items[I] | UnionWith }

type RecursiveTransform<UnionWith, Items extends any[]> 
  = Items extends [infer Head, ...infer Tail]
  ? [Head | UnionWith, ...RecursiveTransform<UnionWith, Tail>]
  : [];

type mappedTypes = MappedTransform<undefined, TestItems>

type recursiveTypes = RecursiveTransform<undefined, TestItems>

Then, I implemented a function that utilizes the transform via a mapped type. I assumed that the UnionWith type would be passed as the first type argument, while the second argument would be filled with a tuple type containing the types of the function's arguments. This setup generates the correct type.

export const fnWithMappedType = <UnionWith extends any, Args extends any[]>
  (data: UnionWith, ...args: MappedTransform<UnionWith, Args>) => {}

fnWithMappedType(undefined, "first", 42, true)

However, when I tried plugging the types into the recursive type transformer in the same way as above, the resulting type behaved differently in isolation compared to the test examples. It led to an empty tuple, causing the function to accept only the very first parameter instead of all four like in the previous example.

export const fnWithRecursiveType = <UnionWith extends any, Args extends any[]>
  (data: UnionWith, ...args: RecursiveTransform<UnionWith, Args>) => {}

fnWithRecursiveType(undefined, "first", 42, true)

I'm wondering if there is some hidden caveat or if I missed something. Is there a way to solve this issue so that arguments can be transformed by the recursive type?

typescript

Answer 1

Answer №1

By and large, TypeScript struggles to automatically deduce generic type arguments from type functions associated with the relevant type parameter. For instance, if you have a generic function structured like this:

declare function fn<T>(u: F<T>): T;

where F<T> represents some sort of type function such as type F<T> = ⋯, and you invoke that function with an argument of type U like so:

declare const u: U;
const t = fn(u);

You are essentially requesting TypeScript to reverse engineer F<T>. In other words, you want TypeScript to calculate something like type F⁻¹ = ⋯, in a way that F<F⁻¹> resolves to

U</code regardless of the value of <code>U

.

Nevertheless, this proves to be quite challenging for TypeScript in most cases. The tool can only successfully invert specific types of type functions it is familiar with. Even when disregarding scenarios where inversion is inherently unfeasible (e.g., type F<T> = string which isn't reliant on

T</code), type functions can be extremely complex and reversing them poses a significant challenge. This complexity is amplified when these type functions incorporate conditional types. Consider, for example:</p>
<pre><code>type F<T extends string, A extends string = ""> =
  T extends `${infer L}.${infer R}` ? F<R, `${L}${A}${L}`> : `${T}${A}${T}`

Determining type F⁻¹ based on a given U like "zzzazazazazzazzzza" isn't straightforward. While there may be various potential solutions, pinpointing the exact value of

T</code is not a task we can anticipate TypeScript to effortlessly accomplish.</p>
<hr />
<p>An exception to this rule is when <code>F<T>

embodies a homomorphic mapped type structure of the form

type F<T> = {[K in keyof T]: ⋯T[K]⋯}

. This procedure, acknowledged as "inference from mapped types," was formerly outlined in version 1 of the TypeScript Handbook but seems to have been omitted from recent revisions. Nonetheless, this process aligns seamlessly with the compiler's ability to infer T from

F<T></code by drawing insights from the properties within <code>F<T>

. Given that mapped types facilitate transformations for tuples into new tuples, TypeScript can deduce T based on

F<T></code at an element-specific level. Consequently, MappedTransform instances perform effectively.</p>
<p>Conversely, RecursiveTransform operations do not yield similar results since they demand TypeScript to iteratively trace back through a recursive conditional type—something TypeScript won't attempt due to its intrinsic limitations. Resultantly, the inference fails, leading to the observed behavior. To resolve this, one option entails manually devising an inverted type function beginning with:</p>
<pre><code>declare const fnWithRecursiveType:
  <U extends any, A extends any[]>(data: U, ...args: RecursiveTransform<U, A>) => A

This configuration could be modified to:

type InvertedRecursiveTransform<U, V> = ⋯

declare const fnWithRecursiveType:
  <U extends any, V extends any[]>(data: U, ...args: V) => InvertedRecursiveTransform<U, V>

Alternatively, if your recursive transform is redundant when A is valid (i.e., if

A extends RecursiveTransform<U, A>

for correct A values), you can leverage intersection strategies like this:

declare const fnWithRecursiveType:
  <U extends any, A extends any[]>(data: U, ...args: A & RecursiveTransform<U, A>) => A;

For a visual representation, you can check out this Playground link to code.

Answer 2

By and large, TypeScript struggles to automatically deduce generic type arguments from type functions associated with the relevant type parameter. For instance, if you have a generic function structured like this:

declare function fn<T>(u: F<T>): T;

where F<T> represents some sort of type function such as type F<T> = ⋯, and you invoke that function with an argument of type U like so:

declare const u: U;
const t = fn(u);

You are essentially requesting TypeScript to reverse engineer F<T>. In other words, you want TypeScript to calculate something like type F⁻¹ = ⋯, in a way that F<F⁻¹> resolves to

U</code regardless of the value of <code>U

.

Nevertheless, this proves to be quite challenging for TypeScript in most cases. The tool can only successfully invert specific types of type functions it is familiar with. Even when disregarding scenarios where inversion is inherently unfeasible (e.g., type F<T> = string which isn't reliant on

T</code), type functions can be extremely complex and reversing them poses a significant challenge. This complexity is amplified when these type functions incorporate conditional types. Consider, for example:</p>
<pre><code>type F<T extends string, A extends string = ""> =
  T extends `${infer L}.${infer R}` ? F<R, `${L}${A}${L}`> : `${T}${A}${T}`

Determining type F⁻¹ based on a given U like "zzzazazazazzazzzza" isn't straightforward. While there may be various potential solutions, pinpointing the exact value of

T</code is not a task we can anticipate TypeScript to effortlessly accomplish.</p>
<hr />
<p>An exception to this rule is when <code>F<T>

embodies a homomorphic mapped type structure of the form

type F<T> = {[K in keyof T]: ⋯T[K]⋯}

. This procedure, acknowledged as "inference from mapped types," was formerly outlined in version 1 of the TypeScript Handbook but seems to have been omitted from recent revisions. Nonetheless, this process aligns seamlessly with the compiler's ability to infer T from

F<T></code by drawing insights from the properties within <code>F<T>

. Given that mapped types facilitate transformations for tuples into new tuples, TypeScript can deduce T based on

F<T></code at an element-specific level. Consequently, MappedTransform instances perform effectively.</p>
<p>Conversely, RecursiveTransform operations do not yield similar results since they demand TypeScript to iteratively trace back through a recursive conditional type—something TypeScript won't attempt due to its intrinsic limitations. Resultantly, the inference fails, leading to the observed behavior. To resolve this, one option entails manually devising an inverted type function beginning with:</p>
<pre><code>declare const fnWithRecursiveType:
  <U extends any, A extends any[]>(data: U, ...args: RecursiveTransform<U, A>) => A

This configuration could be modified to:

type InvertedRecursiveTransform<U, V> = ⋯

declare const fnWithRecursiveType:
  <U extends any, V extends any[]>(data: U, ...args: V) => InvertedRecursiveTransform<U, V>

Alternatively, if your recursive transform is redundant when A is valid (i.e., if

A extends RecursiveTransform<U, A>

for correct A values), you can leverage intersection strategies like this:

declare const fnWithRecursiveType:
  <U extends any, A extends any[]>(data: U, ...args: A & RecursiveTransform<U, A>) => A;

For a visual representation, you can check out this Playground link to code.

Changing the types of arguments in a function, and the difference in behavior between Mapped types (functioning) and Recursive types (not functioning)

Answer №1

Similar questions

Can TypeScript ascertain the object's type dynamically based on the key of its proxy name?

Verify that the Angular service has been properly initialized

Is it possible for me to create an If statement that can verify the current index within a Map?

Determine if a condition is met in Firebase Observable using scan() and return the

What is the best way to customize the hover-over label appearance for a time series in ChartJS?

Ways to implement logging in an NPM package without the need for a specific logging library

Utilizing Angular service in a separate file outside of components

Error in TypeScript: The type 'Color' cannot be assigned to the type '"default" | "primary" | "secondary"'

correct usage of getServerSideProps with Typescript in a next.js project using i18n

Issue encountered during node execution related to firebase; however, the application continues to run smoothly, including firebase integration with angular-universal

Typescript is unable to access the global variables of Node.js

Tips for capturing an error generated by a child component's setter?

Although VSCode is functioning properly, there seems to be a discrepancy between the VSCode and the TS compiler, resulting in an

What is the trick to maintaining the chiplist autocomplete suggestions visible even after inserting or deleting a chip?

Issue: "Stumbled upon an unknown provider! This often implies the presence of circular dependencies"

Outputting a JS file per component using Rollup and Typescript

How do you add a line break ( ) to a string in TypeScript?

How can I combine multiple styles using Material-UI themes in TypeScript?

Creating a parameterized default route in Angular 2

Limiting the assignment of type solely based on its own type, without considering the components of the type