At first, Typescript generics make an inference but are ultimately specified

Question

At first, Typescript generics make an inference but are ultimately specified

In my TypeScript code, I have defined a custom Logger class with specific options. The DefaultLevel type is created as a union of 'info' and 'error'. The LoggerOptions interface includes two generics, CustomLevels and Level, where CustomLevels allows for custom log levels and Level extends either the custom levels or the default ones. When initializing the Logger class with certain options, including custom levels and a default level, an issue arises in the log function. Attempting to log a message at a different level than the specified default results in a type error. My question pertains to why the LoggerOptions interface can accept a wider range of level types (such as 'debug' or 'trace'), but the variables specified as Level are restricted to a smaller set within the code itself. Although I recognize that I could modify the log method to accept a broader range of level types, utilizing the more defined Level type would offer a cleaner solution.

typescript generics

Answer 1

Answer №1

It appears that the intention is not to make Logger generic in relation to the type of Level at all. The type of Level can be inferred from the level property, which is likely to be more specific than just CustomLevels | DefaultLevel. If you want Level to specifically be CustomLevels | DefaultLevel, then directly specify that type instead of attempting to assign it to another type parameter.

Seemingly, the addition of this as a type parameter was intended to stop the inference of CustomLevels from the level property. The goal is for

new Logger({ customLevels: { a: 1, b: 2 }, level: "c" });

to result in an error rather than inferring CustomLevels as

"a" | "b" | "c"

. While an additional type parameter can achieve this, the better tool for the job is using the intrinsic NoInfer<T> utility type:

interface LoggerOptions<C extends string> {
  customLevels?: Record<C, number>
  level: NoInfer<C>
}

Now, Logger needs to only be generic in one type parameter:

class Logger<C extends string> {
  constructor(options?: LoggerOptions<C>) { }
  log(level: C | DefaultLevel, message: string) { }
}

This results in the desired error:

new Logger({ customLevels: { a: 1, b: 2 }, level: "c" }) // error

Additionally, the log() function behaves correctly:

const logger = new Logger({
  customLevels: {
    debug: 1,
    trace: 2,
  },
  level: 'debug'
});        

logger.log('trace', ''); // okay

Playground link to code

Answer 2

It appears that the intention is not to make Logger generic in relation to the type of Level at all. The type of Level can be inferred from the level property, which is likely to be more specific than just CustomLevels | DefaultLevel. If you want Level to specifically be CustomLevels | DefaultLevel, then directly specify that type instead of attempting to assign it to another type parameter.

Seemingly, the addition of this as a type parameter was intended to stop the inference of CustomLevels from the level property. The goal is for

new Logger({ customLevels: { a: 1, b: 2 }, level: "c" });

to result in an error rather than inferring CustomLevels as

"a" | "b" | "c"

. While an additional type parameter can achieve this, the better tool for the job is using the intrinsic NoInfer<T> utility type:

interface LoggerOptions<C extends string> {
  customLevels?: Record<C, number>
  level: NoInfer<C>
}

Now, Logger needs to only be generic in one type parameter:

class Logger<C extends string> {
  constructor(options?: LoggerOptions<C>) { }
  log(level: C | DefaultLevel, message: string) { }
}

This results in the desired error:

new Logger({ customLevels: { a: 1, b: 2 }, level: "c" }) // error

Additionally, the log() function behaves correctly:

const logger = new Logger({
  customLevels: {
    debug: 1,
    trace: 2,
  },
  level: 'debug'
});        

logger.log('trace', ''); // okay

Playground link to code

At first, Typescript generics make an inference but are ultimately specified

Answer №1

Similar questions

Setting up ESLint for TypeScript with JSX configuration

How can I assign a true or false value to an input variable in HTML using AngularTS?

The parameter of type 'void' cannot be assigned to the parameter of type 'PathParams'

Looking to develop a dynamic password verification form control?

Troubleshooting the NullInjectorError in Angular - Service Provider Missing?

Having trouble compiling my Angular application with success

Implementing TypeScript with styled components using the 'as' prop

Exploring the Angular TypeScript Method for Rendering Nested Objects in an Array

Is there a way for me to access the names of the controls in my form directly from the .html file?

Obtain the data from onTouchTap action

There seems to be an issue with the Typescript version compatibility in the node_modules folder for the Angular Material table cell component

Differences Between JavaScript and TypeScript Classes

Trouble with modifying a cell in a TypeScript office script

Unable to retrieve data following a promise in Ionic 3

Utilizing Angular 11's HostListener to capture click events and retrieve the value of an object

What is the process to activate a function within a component once a service method has been run?

What is the best way to decouple api and async request logic from React components while incorporating Recoil?

What is the best way to link labels with input fields located separately in Angular?

How can a button click function be triggered in another component?

Guide for adding an OnClick event to a MatTable row: