Deduce the argument type of a class from the super call

Question

Deduce the argument type of a class from the super call

I'm currently working on a project utilizing the discord.js library. Within this project, there is an interface called ClientEvents which contains different event argument tuple types:

interface ClientEvents {
  ready: [];
  warn: [reason: string]
  message: [message: Message];
  // ...some more events
}

Alongside this, I have created an EventHandler class that accepts a specific type as an argument:

abstract class EventHandler<E extends keyof ClientEvents> {

  protected constructor(public eventName: E) {}

  abstract execute(...args: ClientEvents[E]): void;
}

However, I've encountered an issue where I am unable to extend this class using type inference for E, even when explicitly defined in the super() call:

// Error: Generic type 'EventHandler<E>' requires 1 type argument(s).
class ReadyHandler extends EventHandler {

  public constructor() {
    super('ready'); // My intention was to infer the type using this argument
  }

  public execute() {
    // Additional code goes here
  }
}

Is there a method to automatically infer class argument types based on the arguments provided in a super() call?

typescript generics

Answer 1

Answer №1

Unfortunately, inference doesn't usually work that way, so it's not easy to achieve. One option is to explicitly write out the code:

class ReadyHandler extends EventHandler<"ready"> {    
  public constructor() {  super('ready');  }    
  public execute() {}
}

If you want to avoid redundancy, you can refactor or encapsulate the EventHandler by passing an actual string of type E for inference. This approach would result in a non-generic class. Here's an example:

function SpecificHandler<E extends keyof ClientEvents>(eventName: E) {
  abstract class SpecificHandler extends EventHandler<E> {
    constructor() { super(eventName) };
  }
  return SpecificHandler;
}

class MessageHandler extends SpecificHandler("message") {
  public execute(msg: Message) {

  }
}

However, the trade-off may not be worth it.

Explore the code on TypeScript Playground

Answer 2

Unfortunately, inference doesn't usually work that way, so it's not easy to achieve. One option is to explicitly write out the code:

class ReadyHandler extends EventHandler<"ready"> {    
  public constructor() {  super('ready');  }    
  public execute() {}
}

If you want to avoid redundancy, you can refactor or encapsulate the EventHandler by passing an actual string of type E for inference. This approach would result in a non-generic class. Here's an example:

function SpecificHandler<E extends keyof ClientEvents>(eventName: E) {
  abstract class SpecificHandler extends EventHandler<E> {
    constructor() { super(eventName) };
  }
  return SpecificHandler;
}

class MessageHandler extends SpecificHandler("message") {
  public execute(msg: Message) {

  }
}

However, the trade-off may not be worth it.

Explore the code on TypeScript Playground

Answer 3

Answer №2

When creating an instance of a class, the generic type can be inferred from a constructor argument. However, when subclassing, this inference does not occur with the use of `super`. In TypeScript, the generic type needs to be included in the type definition when extending a class. This could be because TypeScript may not know if the generic type is required before `super` is called.

To work around this limitation, you can also make the subclass generic and pass the generic type to the superclass.

type EventKeys = keyof ClientEvents;

class ReadyHandler<E extends EventKeys> extends EventHandler<E> {
  constructor() {
    // A cast is necessary to prevent TS from raising an error.
    super('ready' as E);
  }
}

In this scenario, the generic type `E` is correctly inferred from the constructor of `ReadyHandler`, allowing you to call `new ReadyHandler()` without specifying the type argument.

Another approach mentioned in the other response is to explicitly specify the type as in `EventHandler<'ready'>`, which requires writing `'ready'` twice. The choice between these methods depends on your preference for convenience.

Answer 4

When creating an instance of a class, the generic type can be inferred from a constructor argument. However, when subclassing, this inference does not occur with the use of `super`. In TypeScript, the generic type needs to be included in the type definition when extending a class. This could be because TypeScript may not know if the generic type is required before `super` is called.

To work around this limitation, you can also make the subclass generic and pass the generic type to the superclass.

type EventKeys = keyof ClientEvents;

class ReadyHandler<E extends EventKeys> extends EventHandler<E> {
  constructor() {
    // A cast is necessary to prevent TS from raising an error.
    super('ready' as E);
  }
}

In this scenario, the generic type `E` is correctly inferred from the constructor of `ReadyHandler`, allowing you to call `new ReadyHandler()` without specifying the type argument.

Another approach mentioned in the other response is to explicitly specify the type as in `EventHandler<'ready'>`, which requires writing `'ready'` twice. The choice between these methods depends on your preference for convenience.

Deduce the argument type of a class from the super call

Answer №1

Answer №2

Similar questions

The resolver function in the Nextjs higher order API is not defined

The interface is incompatible with the constant material ui BoxProps['sx'] type

What are the best methods for visually designing a database using Entity Framework Core?

The numerical value of zero in React Native TypeScript is being interpreted as NaN

Creating a fresh ngx-translate pipeline (comparing pure and impure methods)

retrieve the router information from a location other than the router-outlet

"Encountering a 500 error on Chrome and Internet Explorer while trying to sign

What is the best way to add a service to a view component?

How to integrate a chips feature in Angular 4 using Typescript

Issue with Angular component inheritance where changes made in the base component are not being

Removing the final element within a nested array: a step-by-step guide

React - All subsequent variable declarations must be of the same type

Encountering a Lint No Nested Ternary Error while utilizing the ternary operator

Encountered 'DatePickerProps<unknown>' error while attempting to develop a custom component using Material-UI and react-hook-form

What is the significance of the 'this' context type void not being assignable to type rule?

Guide on setting up a route in Next.js

Mastering mapped types to replace properties in Typescript

Unable to run `create-react-app` with the `--template typescript` option

The object's key values were unexpectedly empty despite containing data

Annoying glitch when using http get in Ionic (version 3.19.0)