Tips on effectively setting limitations on TypeScript generics

Question

Tips on effectively setting limitations on TypeScript generics

In the process of developing this class, found at this playground link:

export class CascadeStrategies<
  T extends Record<any, (...args: any[]) => unknown>
> {
  private strategies: T = {} as T;

  constructor(strategyMap: T) {
    this.registerStrategies(strategyMap);
  }

  private registerStrategies(strategyMap: T) {
    this.strategies = strategyMap;
  }

  use(
    strategies: (keyof T)[],
    ...args: Parameters<T[keyof T]>
  ): ReturnType<T[keyof T]> {
    return this.strategies[strategies[0]](...args);
  }
}

The intended functionality of this class should be

const myMap = {
  test: (arg1: number, arg2: string) => arg1,
  otherTest: (arg1: number, arg2: string) => arg2,
  thirdTest: (arg1: number, arg2: string) => null
}
const cascadeStrats = new CascadeStrategies(myMap);
const shouldBeNumber = cascadeStrats.use(["test"], 0, "");
const shouldBeString = cascadeStrats.use(["otherTest"], 0, "");
const shouldBeNull = cascadeStrats.use(["thirdTest"], 0, "");

The goal is to have T represent an object where each entry is a function that can accept the same parameters and return a string. This is achieved by using

T extends Record<any, (...args: unknown[]) => string

. However, there is an issue with the typing, as

this.strategies[strategies[0]](...args)

results in type unknown, which does not match the expected ReturnType<T[keyof T]>.

If the type of strategies is changed from T to Record<any, any>, then

this.strategies[strategies[0]](...args)

will have the correct type and be inferred correctly when used. Although strategies is only an internal variable and does not impact user experience when using the class, it raises the question of what needs to be adjusted to achieve the desired outcome:

Accurate inference while utilizing the user-defined strategyMap (an object with functions that share the same parameters and return string).
strategies not having a type of Record<any, any>.
When the user employs cascadeStrats.use, they receive accurate inferences regarding the function's arguments and return type.

typescript typescript-generics type-inference

Answer 1

Answer №1

To simplify this, it is best to divide your generic type parameter into two separate components. Have A, representing the common parameter list type for all strategies, and T, denoting the mapping from strategy keys to their corresponding return types. With these distinctions, the type of strategies would be as follows:

type Strategies<A extends any[], T> =
  { [K in keyof T]: (...args: A) => T[K] }

This forms a mapped type that transforms each member of T into a function returning that member's value.

Here's how I would modify CascadeStrategies:

class CascadeStrategies<A extends any[], T extends object> {
  private strategies!: Strategies<A, T>

  constructor(strategyMap:
    Record<string, (...args: A) => any> &
    Strategies<A, T>
  ) {
    this.registerStrategies(strategyMap);
  }

  private registerStrategies(strategyMap: Strategies<A, T>) {
    this.strategies = strategyMap;
  }

  use<K extends keyof T>(
    strategies: K[],
    ...args: A
  ) {
    return this.strategies[strategies[0]](...args); // works fine
  }
}

This snippet compiles error-free. The crucial aspect here lies within the use() functionality. This function becomes generic based on K, a key in T. The inferred return type of use() becomes T[K], aligning with expectations.

For this setup to succeed, TypeScript needs to infer both A and

T</code when initializing <code>new CascadeStrategies(myMap)

. Inference can be intricate. My strategy was to define the constructor parameter type as

Record<string, (...args: A) => any> & Strategies<A, T>

. It utilizes an intersection, allowing each part to aid in inferring a distinct type argument. The

Record<string, (...args: A) => any>

type aids A's inference early on before TypeScript gathers details about T. Then, Strategies<A, T> helps in deducing T from the method return types. Simplifying the intersection down to just strategyMap being treated as type Strategies<A, T> enhances clarity.

Let's put it to the test:

const myMap = {
  test: (arg1: number, arg2: string) => arg1,
  otherTest: (arg1: number, arg2: string) => arg2,
  thirdTest: (arg1: number, arg2: string) => null
}
const cascadeStrats = new CascadeStrategies(myMap);
/*    ^? const cascadeStrats: CascadeStrategies<
    [arg1: number, arg2: string], 
    { test: number; otherTest: string; thirdTest: null; }
    >
*/
const shouldBeNumber = cascadeStrats.use(["test"], 0, "");
//    ^? const shouldBeNumber: number
const shouldBeString = cascadeStrats.use(["otherTest"], 0, "");
//    ^? const shouldBeString: string
const shouldBeNull = cascadeStrats.use(["thirdTest"], 0, "");
//    ^? const shouldBeNull: null
const shouldBeStringOrNumber = cascadeStrats.use(["test", "otherTest"], 0, "")
//    ^? const shouldBeStringOrNumber: string | number

cascadeStrats.use(["test"], "oops", "abc"); // triggers error!
// -----------------------> ~~~~~~
// Argument of type 'string' is not assignable to parameter of type 'number'.

The results appear satisfactory. T gets appropriately inferred, making shouldBeXXX match expected types, while A also receives accurate inferences, pinpointing any incorrect parameter types passed (as demonstrated in the last line).

Playground link to code

Answer 2

To simplify this, it is best to divide your generic type parameter into two separate components. Have A, representing the common parameter list type for all strategies, and T, denoting the mapping from strategy keys to their corresponding return types. With these distinctions, the type of strategies would be as follows:

type Strategies<A extends any[], T> =
  { [K in keyof T]: (...args: A) => T[K] }

This forms a mapped type that transforms each member of T into a function returning that member's value.

Here's how I would modify CascadeStrategies:

class CascadeStrategies<A extends any[], T extends object> {
  private strategies!: Strategies<A, T>

  constructor(strategyMap:
    Record<string, (...args: A) => any> &
    Strategies<A, T>
  ) {
    this.registerStrategies(strategyMap);
  }

  private registerStrategies(strategyMap: Strategies<A, T>) {
    this.strategies = strategyMap;
  }

  use<K extends keyof T>(
    strategies: K[],
    ...args: A
  ) {
    return this.strategies[strategies[0]](...args); // works fine
  }
}

This snippet compiles error-free. The crucial aspect here lies within the use() functionality. This function becomes generic based on K, a key in T. The inferred return type of use() becomes T[K], aligning with expectations.

For this setup to succeed, TypeScript needs to infer both A and

T</code when initializing <code>new CascadeStrategies(myMap)

. Inference can be intricate. My strategy was to define the constructor parameter type as

Record<string, (...args: A) => any> & Strategies<A, T>

. It utilizes an intersection, allowing each part to aid in inferring a distinct type argument. The

Record<string, (...args: A) => any>

type aids A's inference early on before TypeScript gathers details about T. Then, Strategies<A, T> helps in deducing T from the method return types. Simplifying the intersection down to just strategyMap being treated as type Strategies<A, T> enhances clarity.

Let's put it to the test:

const myMap = {
  test: (arg1: number, arg2: string) => arg1,
  otherTest: (arg1: number, arg2: string) => arg2,
  thirdTest: (arg1: number, arg2: string) => null
}
const cascadeStrats = new CascadeStrategies(myMap);
/*    ^? const cascadeStrats: CascadeStrategies<
    [arg1: number, arg2: string], 
    { test: number; otherTest: string; thirdTest: null; }
    >
*/
const shouldBeNumber = cascadeStrats.use(["test"], 0, "");
//    ^? const shouldBeNumber: number
const shouldBeString = cascadeStrats.use(["otherTest"], 0, "");
//    ^? const shouldBeString: string
const shouldBeNull = cascadeStrats.use(["thirdTest"], 0, "");
//    ^? const shouldBeNull: null
const shouldBeStringOrNumber = cascadeStrats.use(["test", "otherTest"], 0, "")
//    ^? const shouldBeStringOrNumber: string | number

cascadeStrats.use(["test"], "oops", "abc"); // triggers error!
// -----------------------> ~~~~~~
// Argument of type 'string' is not assignable to parameter of type 'number'.

The results appear satisfactory. T gets appropriately inferred, making shouldBeXXX match expected types, while A also receives accurate inferences, pinpointing any incorrect parameter types passed (as demonstrated in the last line).

Playground link to code

Tips on effectively setting limitations on TypeScript generics

Answer №1

Similar questions

Enhancing the getDate function in JavaScript with additional days

Error in Angular compiler-cli: The namespace 'ts' does not contain the exported member 'ResolutionMode'

What is the best way to encrypt the JWT decode token payload using Angular 8 on the client-side?

NGXS no longer functions properly when upgrading to Angular 9 and enabling Ivy

tips for accessing the output of a function within an object using TypeScript

What are some effective strategies for incorporating React states with input variables?

"Experiencing sluggish performance with VSCode while using TypeScript and Styled Components

Encountering TS 2694 Error while running the ng serve command

Is there a way to send both a file and JSON data in a single HTTP request?

"Defining the structure of object parameters in a function using type

Using nodemailer to send an email with a dynamic variable that holds the HTML content

Entering a series of predetermined value types into an array

Change the country name to all lowercase letters

Error 404 Encountered During Azure Functions GET Request

Could the repeated utilization of BehaviorSubject within Angular services indicate a cause for concern?

Module augmentations do not allow for exports or export assignments

Tips for adding text to a file in a VSCode Extension

Transferring information from ag-Grid to a different user interface

Tips for fixing: "Object may be null" error in Angular routing

Error: The specified property 'Body' is not found within the type '{}'