Utilizing TypeScript's conditional return type with an object as a parameter, and incorporating default values

Question

Utilizing TypeScript's conditional return type with an object as a parameter, and incorporating default values

Is it possible to create a function where the return type is determined by a string, with some additional complexities involved? I'm looking to achieve the following:

The parameter is contained within an object
The parameter is optional
The object itself is also optional

I want to know if this can be achieved. Here's a simplified version of what I have in mind:

interface NumberWrapper {
  type: "my_number";
  value: number;
}

const x1: number        = fn(1, { returnType: "bare" });
const x2: NumberWrapper = fn(1, { returnType: "wrapped" });
const x3: void          = fn(1, { returnType: "none" });
const x4: number        = fn(1, {});
const x5: number        = fn(1);

In the examples above, different ways are shown on how I intend to call my function fn() and have TypeScript correctly deduce the return type.

For x1, x2, x3, the function is called with a specified value for returnType.

For x4, no value is provided for returnType, and I aim for it to default to "bare". Similarly, for x5, when no object is supplied at all, it should act as if returnType is "bare".

(You might be questioning why I'm placing returnType in an object when it's just one parameter. In my real-world scenario, there are other parameters in the object.)

So far, I've managed to make x1, x2, and x3 work, but not x4 or x5. This is what I currently have:

type ReturnMap<T extends "bare" | "wrapped" | "none"> = T extends "bare"
  ? number
  : T extends "wrapped"
  ? NumberWrapper
  : void;

function fn<T extends "bare" | "wrapped" | "none">(
  x: number,
  { returnType }: { returnType: T }
): ReturnMap<T> {
  if (returnType === "bare") {
    return x as ReturnMap<T>;
  } else if (returnType === "wrapped") {
    return { type: "my_number", value: x } as ReturnMap<T>;
  } else {
    return undefined as ReturnMap<T>;
  }
}

An issue I am facing is that each return statement ends with return x as ReturnMap<T>. I would prefer to avoid this as the as may compromise some type safety.

However, the main challenge lies in making this work for x4 and x5. I have attempted various approaches using default values, but have not succeeded so far.

typescript

Answer 1

Answer №1

One way to quickly resolve the issue is by setting the generic type to encompass the entire argument rather than just the returnType attribute. This approach involves a longer chain of conditional operators to achieve the desired types, although it still necessitates the use of unsightly as assertions.

type Argument = undefined | { returnType?: "bare" | "wrapped" | "none" };
type ReturnTypeMap<T extends Argument> =
  T extends { returnType: 'wrapped' }
    ? NumberWrapper
    : T extends { returnType: 'none' }
      ? void
      : number;

function customFunction<T extends Argument>(
  value: number,
  argument?: T
): ReturnTypeMap<T> {
  if (!argument || !('returnType' in argument) || argument.returnType === 'bare') {
    return value as ReturnTypeMap<T>;
  } else if (argument.returnType === 'wrapped') {
    return { type: "my_number", value: value } as ReturnTypeMap<T>;
  } else {
    return undefined as ReturnTypeMap<T>;
  }
}

const result1: number = customFunction(1, { returnType: "bare" });
const result2: NumberWrapper = customFunction(1, { returnType: "wrapped" });
const result3: void = customFunction(1, { returnType: "none" });
const result4: number = customFunction(1, {});
const result5: number = customFunction(1);

Answer 2

One way to quickly resolve the issue is by setting the generic type to encompass the entire argument rather than just the returnType attribute. This approach involves a longer chain of conditional operators to achieve the desired types, although it still necessitates the use of unsightly as assertions.

type Argument = undefined | { returnType?: "bare" | "wrapped" | "none" };
type ReturnTypeMap<T extends Argument> =
  T extends { returnType: 'wrapped' }
    ? NumberWrapper
    : T extends { returnType: 'none' }
      ? void
      : number;

function customFunction<T extends Argument>(
  value: number,
  argument?: T
): ReturnTypeMap<T> {
  if (!argument || !('returnType' in argument) || argument.returnType === 'bare') {
    return value as ReturnTypeMap<T>;
  } else if (argument.returnType === 'wrapped') {
    return { type: "my_number", value: value } as ReturnTypeMap<T>;
  } else {
    return undefined as ReturnTypeMap<T>;
  }
}

const result1: number = customFunction(1, { returnType: "bare" });
const result2: NumberWrapper = customFunction(1, { returnType: "wrapped" });
const result3: void = customFunction(1, { returnType: "none" });
const result4: number = customFunction(1, {});
const result5: number = customFunction(1);

Answer 3

Answer №2

Allow me to share with you an alternative approach for writing your fn() function:

interface ReturnMap {
  bare: number,
  wrapped: NumberWrapper,
  none: void
}

function fn<K extends keyof ReturnMap = "bare">(
  x: number,
  { returnType = "bare" as K }: { returnType?: K } = { returnType: "bare" as K }
): ReturnMap[K] {
  return {
    get bare() { return x },
    get wrapped() { return { type: "my_number" as const, value: x } },
    get none() { return undefined }
  }[returnType]

}

Below are a few explanations:

The issue with your "as ReturnMap<T>" statement arises from the fact that the compiler struggles to determine if your implementation aligns with the return type. The type ReturnMap<T> is a conditional type hinging on a generic type parameter T. In such scenarios, the compiler encounters uncertainty due to its inability to interpret T, resulting in it not comprehending which ReturnMap<T> version to use. While your implementation assesses arg, the compiler cannot utilize these assessments to narrow down the type parameter T. This is a recognized limitation of TypeScript; refer to microsoft/TypeScript#33912 for additional details.

I would suggest restructuring the code into a format that the compiler can grasp, such as leveraging object indexing with a generic key.

This is why ReturnMap serves as an authentic mapping type containing keys corresponding to your returnType values, and whose property values indicate the respective return types. Consequently, fn() can be flexible through K extends keyof ReturnMap, enabling you to retrieve ReturnMap[K] by accessing the returnType property within an object of type ReturnMap.

Note that I've opted for utilizing getter methods to elude the necessity for pre-computing outcomes for every feasible input within the ReturnMap object.

In addressing the default concerns associated with the x4 and x5 cases, the desired behavior can be replicated utilizing JavaScript by combining both a function parameter default and a destructuring assignment default:

function fn(x, {returnType = "bare"} = {returnType: "bare"}) {}

This setup yields the exact runtime behavior you desire. However, when applying typings, you may need to incorporate certain type assertions to convince the compiler to accept them. This requirement stems from the less-than-seamless interaction between generics and default parameters in TypeScript. Refer to this question or this one for further insights.

To manage defaults, we assign K a default type of "bare"; hence, in instances where K isn't inferred by the compiler during a call to fn(), it defaults back to "bare". Similarly, we establish the returnType variable's default as "bare" within the implementation via JavaScript's destructuring assignment default and function parameter default...

...yet, the compiler fails to anticipate this duo of defaults. This necessitates the utilization of type assertions. With the declaration "bare" as K, I signify that, in scenarios employing the default for returnType , the default for K will also apply. It remains plausible for someone to craft fn< "none">(1), leading to potential disruptions. Nonetheless, given the low likelihood of this occurrence, we can confidently assume that K equates to "bare" when defaults come into play.

In summary, this method generates the intended outcomes:

const x1: number = fn(1, { returnType: "bare" });
const x2: NumberWrapper = fn(1, { returnType: "wrapped" });
const x3: void = fn(1, { returnType:& quot;"none" });
const x4: number = fn(1, {});
const x5: number = fn(1);

Access the Playground link to code

Answer 4

Allow me to share with you an alternative approach for writing your fn() function:

interface ReturnMap {
  bare: number,
  wrapped: NumberWrapper,
  none: void
}

function fn<K extends keyof ReturnMap = "bare">(
  x: number,
  { returnType = "bare" as K }: { returnType?: K } = { returnType: "bare" as K }
): ReturnMap[K] {
  return {
    get bare() { return x },
    get wrapped() { return { type: "my_number" as const, value: x } },
    get none() { return undefined }
  }[returnType]

}

Below are a few explanations:

The issue with your "as ReturnMap<T>" statement arises from the fact that the compiler struggles to determine if your implementation aligns with the return type. The type ReturnMap<T> is a conditional type hinging on a generic type parameter T. In such scenarios, the compiler encounters uncertainty due to its inability to interpret T, resulting in it not comprehending which ReturnMap<T> version to use. While your implementation assesses arg, the compiler cannot utilize these assessments to narrow down the type parameter T. This is a recognized limitation of TypeScript; refer to microsoft/TypeScript#33912 for additional details.

I would suggest restructuring the code into a format that the compiler can grasp, such as leveraging object indexing with a generic key.

This is why ReturnMap serves as an authentic mapping type containing keys corresponding to your returnType values, and whose property values indicate the respective return types. Consequently, fn() can be flexible through K extends keyof ReturnMap, enabling you to retrieve ReturnMap[K] by accessing the returnType property within an object of type ReturnMap.

Note that I've opted for utilizing getter methods to elude the necessity for pre-computing outcomes for every feasible input within the ReturnMap object.

In addressing the default concerns associated with the x4 and x5 cases, the desired behavior can be replicated utilizing JavaScript by combining both a function parameter default and a destructuring assignment default:

function fn(x, {returnType = "bare"} = {returnType: "bare"}) {}

This setup yields the exact runtime behavior you desire. However, when applying typings, you may need to incorporate certain type assertions to convince the compiler to accept them. This requirement stems from the less-than-seamless interaction between generics and default parameters in TypeScript. Refer to this question or this one for further insights.

To manage defaults, we assign K a default type of "bare"; hence, in instances where K isn't inferred by the compiler during a call to fn(), it defaults back to "bare". Similarly, we establish the returnType variable's default as "bare" within the implementation via JavaScript's destructuring assignment default and function parameter default...

...yet, the compiler fails to anticipate this duo of defaults. This necessitates the utilization of type assertions. With the declaration "bare" as K, I signify that, in scenarios employing the default for returnType , the default for K will also apply. It remains plausible for someone to craft fn< "none">(1), leading to potential disruptions. Nonetheless, given the low likelihood of this occurrence, we can confidently assume that K equates to "bare" when defaults come into play.

In summary, this method generates the intended outcomes:

const x1: number = fn(1, { returnType: "bare" });
const x2: NumberWrapper = fn(1, { returnType: "wrapped" });
const x3: void = fn(1, { returnType:& quot;"none" });
const x4: number = fn(1, {});
const x5: number = fn(1);

Access the Playground link to code

Utilizing TypeScript's conditional return type with an object as a parameter, and incorporating default values

Answer №1

Answer №2

Similar questions

I am attempting to gather user input for an array while also ensuring that duplicate values are being checked

Using GraphQL in React to access a specific field

Experimenting with a Collection of Items - Jest

Performing optimized searches in Redis

Typescript defines types for parameters used in callbacks for an event bus

The observable did not trigger the next() callback

Utilize the global theme feature within React Material-UI to create a cohesive

Module lazily loaded fails to load in Internet Explorer 11

The presence of 'eventually' in the Chai Mocha test Promise Property is undefined

Why is my custom Vuelidate validator not receiving the value from the component where it is being called?

Angular time-based polling with conditions

The React component fails to load due to the discrepancies in the data retrieved from various asynchronous requests

How can we use tsyringe (a dependency injection library) to resolve classes with dependencies?

The TypeScript datatype 'string | null' cannot be assigned to the datatype 'string'

Obtaining Input Field Value in Angular Using Code

Change the background color of a span element dynamically

Issue with the drag functionality of Framer Motion carousel causing malfunction

reusable angular elements

"What is the significance of the .default property in scss modules when used with typescript

Learn how to implement React Redux using React Hooks and correctly use the useDispatch function while ensuring type-checking