Encountering an error due to an invalid type union when creating a new instance of a

Question

Encountering an error due to an invalid type union when creating a new instance of a

My TypeScript code includes a Logger class that has an optional options parameter in its constructor. The options parameter includes a class generic C which represents custom levels. These custom levels are used within the class for methods like log(level: Level<C>). Now, I need to implement an updateConfig method that will return a new instance of the Logger class with the C parameter being a union of the original custom levels and those specified in the new options object.

Here's the code snippet:

type DefaultLevel = 'info' | 'error'; // Default log levels

type Level<C extends string> = DefaultLevel | C
type LevelWithSilence<C extends string> = Level<C> | 'silence'

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

interface UpdatedLoggerOptions<C extends string, L extends string> {
  customLevels?: Record<L, number>
  level: LevelWithSilence<NoInfer<C | L >>
}

class Logger<C extends string = ''> {

  options?: LoggerOptions<C>

  constructor(options?: LoggerOptions<C>) {
    this.options = options
  }

  log(level: Level<C>, message: string) {
    // Log message
  }

  updateConfig<L extends string = never>(options?: UpdatedLoggerOptions<C, L>) {
    
    if(!this.options) return new Logger (options as LoggerOptions<C>)

    if(!options) return this

    return new Logger<C | L>({
      customLevels: {
        ...this.options.customLevels as Record<C, number>,
        ...options.customLevels as Record<L, number>
      },
      level: options.level
    } as LoggerOptions<C | L>)
  }
}

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

logger.log('debug', '')

const newLogger = logger.updateConfig({
  customLevels: {
    test: 3,
  },
  level: 'test'
})

newLogger.log('debug', '') // Works
newLogger.log('test', '') // Should work

Although everything seems to be typesafe, there is an issue with the log method. While newLogger.log('debug', '') works fine and extracts the father's custom levels correctly, attempting newLogger.log('test', '') results in the error:

Argument of type '"test"' is not assignable to parameter of type 'Level<"debug" | "trace">'.

It seems to have trouble extrapolating the custom levels from the options object.

Moreover, the type for the logger object is shown as:

const logger: Logger<"debug" | "trace">

, while for newLogger it is:

const newLogger: Logger<"debug" | "trace"> | Logger<"debug" | "trace" | "test">

.

How can I achieve the desired behavior?

typescript typescript-generics

Answer 1

Answer №1

After reviewing the question at hand, the main issue lies in the return type specification for the updateConfig function. It is crucial to define the return type as Logger<C | L> in order to accommodate values from both C and L:

updateConfig<L extends string = never>(
  options?: UpdatedLoggerOptions<C, L>
): Logger<C | L> { ⋯ }

For the implementation to work smoothly, there is a need for type assertions, or similar techniques, to convince the compiler that the return type indeed conforms to Logger<C | L>. This is due to the complexity involved in generic case analysis, where assumptions need to be verified by assertions:

updateConfig<L extends string = never>(options?: UpdatedLoggerOptions<C, L>): Logger<C | L> {

  if (!this.options) return new Logger(options as LoggerOptions<C | L>)
  // ----------------------------------------> ^^^^^^^^^^^^^^^^^^^^^^^

  if (!options) return this as Logger<C | L>
  // ---------------------> ^^^^^^^^^^^^^^^^

  return new Logger({
    customLevels: {
      ...this.options.customLevels as Record<C, number>,
      // ------------------------> ^^^^^^^^^^^^^^^^^^^^
      ...options.customLevels as Record<L, number>
      // -------------------> ^^^^^^^^^^^^^^^^^^^^
    },
    level: options.level
  })
}

By adding these assertions, the code compiles without errors. It is essential to test the functionality to ensure it works as intended:

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

logger.log('debug', '')

const newLogger = logger.updateConfig({
  customLevels: {
    test: 3,
  },
  level: 'test'
})

newLogger.log('debug', '') // Functions correctly
newLogger.log('test', '') // Functions correctly

Upon testing, the code performs as expected.

Link to code on Playground

Answer 2

After reviewing the question at hand, the main issue lies in the return type specification for the updateConfig function. It is crucial to define the return type as Logger<C | L> in order to accommodate values from both C and L:

updateConfig<L extends string = never>(
  options?: UpdatedLoggerOptions<C, L>
): Logger<C | L> { ⋯ }

For the implementation to work smoothly, there is a need for type assertions, or similar techniques, to convince the compiler that the return type indeed conforms to Logger<C | L>. This is due to the complexity involved in generic case analysis, where assumptions need to be verified by assertions:

updateConfig<L extends string = never>(options?: UpdatedLoggerOptions<C, L>): Logger<C | L> {

  if (!this.options) return new Logger(options as LoggerOptions<C | L>)
  // ----------------------------------------> ^^^^^^^^^^^^^^^^^^^^^^^

  if (!options) return this as Logger<C | L>
  // ---------------------> ^^^^^^^^^^^^^^^^

  return new Logger({
    customLevels: {
      ...this.options.customLevels as Record<C, number>,
      // ------------------------> ^^^^^^^^^^^^^^^^^^^^
      ...options.customLevels as Record<L, number>
      // -------------------> ^^^^^^^^^^^^^^^^^^^^
    },
    level: options.level
  })
}

By adding these assertions, the code compiles without errors. It is essential to test the functionality to ensure it works as intended:

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

logger.log('debug', '')

const newLogger = logger.updateConfig({
  customLevels: {
    test: 3,
  },
  level: 'test'
})

newLogger.log('debug', '') // Functions correctly
newLogger.log('test', '') // Functions correctly

Upon testing, the code performs as expected.

Link to code on Playground

Answer 3

Answer №2

In a world where constructors hold privilege in the realm of Object-Oriented Programming, an interesting phenomenon occurs. When a constructor is invoked, a class is not truly instantiated. For example:

    class Foo<T extends string = '', V extends string = ''> {
       constructor(opts?: T) {}
    }
    
    // No instance of `Foo` exists, types are inferred from non-existent entity
    
    const foo = new Foo('abc');
    
    // Constructor infers type of T, but not V due to lack of information

Implementing otherwise would jeopardize type-safety, as illustrated here:


    type DefaultLevel = 'info' | 'error';
    
    type Level<C extends string> = DefaultLevel | C
    type LevelWithSilence<C extends string> = Level<C> | 'silence'
    
    interface LoggerOptions<C extends string> {
      customLevels?: Record<C, number>
      level: LevelWithSilence<NoInfer<C>>
    } 
    
    class Logger<C extends string = '', V extends string = ''> {
    
      constructor(options?: LoggerOptions<C>) { // Setting V without specified value
        // Initialization based on options
      }
    
      log(level: Level<C>, message: string) {
        // Log message
      }
    
      setPrimaryConfig(config: LoggerOptions<C>) {}
    
      setSecondaryConfig(config: LoggerOptions<V>) {}

}

Why is setPrimaryConfig restricted from mutating C, while V is not? Both are identical functions. Ensuring type-safety is essential to prevent type mutations in instantiated objects. Attempting to mutate generic type V on Foo<T..., V...> after construction introduces instability.

Consider this scenario:

    class Foo<T extends string = '', V extends string = ''> {
        constructor(opts?: T) {}
        private secondaryOpts?: V;
        setSecondary(opts: V) {
           this.secondaryOpts = opts;
        }
    
        get secondaryOptsOrFalse (): V extends '' ? false : V {
            return this.secondaryOpts ?? false;
        }
    
    }
    
    const foo = new Foo('abc');
    const firstForSecondaryOpts = foo.secondaryOpts // type false;
    foo.setSecondary('def');
    const secondForSecondaryOpts = foo.secondaryOpts // type 'def';

Attempting to compare the types:

    firstForSecondaryOpts === secondForSecondaryOpts

Yields a contradiction due to the disparity in types.

Furthermore, the constructor's purpose is to construct based on a predefined blueprint. Allowing other methods to override the constructor's blueprint would undermine the integrity of types in TypeScript.

Consider the implications and necessity of flexibility in types, as excessive flexibility can compromise immutability.

Answer 4

In a world where constructors hold privilege in the realm of Object-Oriented Programming, an interesting phenomenon occurs. When a constructor is invoked, a class is not truly instantiated. For example:

    class Foo<T extends string = '', V extends string = ''> {
       constructor(opts?: T) {}
    }
    
    // No instance of `Foo` exists, types are inferred from non-existent entity
    
    const foo = new Foo('abc');
    
    // Constructor infers type of T, but not V due to lack of information

Implementing otherwise would jeopardize type-safety, as illustrated here:


    type DefaultLevel = 'info' | 'error';
    
    type Level<C extends string> = DefaultLevel | C
    type LevelWithSilence<C extends string> = Level<C> | 'silence'
    
    interface LoggerOptions<C extends string> {
      customLevels?: Record<C, number>
      level: LevelWithSilence<NoInfer<C>>
    } 
    
    class Logger<C extends string = '', V extends string = ''> {
    
      constructor(options?: LoggerOptions<C>) { // Setting V without specified value
        // Initialization based on options
      }
    
      log(level: Level<C>, message: string) {
        // Log message
      }
    
      setPrimaryConfig(config: LoggerOptions<C>) {}
    
      setSecondaryConfig(config: LoggerOptions<V>) {}

}

Why is setPrimaryConfig restricted from mutating C, while V is not? Both are identical functions. Ensuring type-safety is essential to prevent type mutations in instantiated objects. Attempting to mutate generic type V on Foo<T..., V...> after construction introduces instability.

Consider this scenario:

    class Foo<T extends string = '', V extends string = ''> {
        constructor(opts?: T) {}
        private secondaryOpts?: V;
        setSecondary(opts: V) {
           this.secondaryOpts = opts;
        }
    
        get secondaryOptsOrFalse (): V extends '' ? false : V {
            return this.secondaryOpts ?? false;
        }
    
    }
    
    const foo = new Foo('abc');
    const firstForSecondaryOpts = foo.secondaryOpts // type false;
    foo.setSecondary('def');
    const secondForSecondaryOpts = foo.secondaryOpts // type 'def';

Attempting to compare the types:

    firstForSecondaryOpts === secondForSecondaryOpts

Yields a contradiction due to the disparity in types.

Furthermore, the constructor's purpose is to construct based on a predefined blueprint. Allowing other methods to override the constructor's blueprint would undermine the integrity of types in TypeScript.

Consider the implications and necessity of flexibility in types, as excessive flexibility can compromise immutability.

Encountering an error due to an invalid type union when creating a new instance of a

Answer №1

Answer №2

Similar questions

Issue encountered with the signature provided for a Safe API POST request

Unable to retrieve the third attribute of a Class using Angular2's toString method

Using TypeScript: creating functions without defining an interface

Issue with Radio Button Value Submission in Angular 6 and Laravel 5.5

What is the best way to implement a switch case with multiple payload types as parameters?

Choose only the options that are present in both arrays

I am encountering difficulties in accessing my component's property within the corresponding template while working with Angular 5

Iterating through an array with ngFor to display each item based on its index

The issue I'm facing with Angular 8 is that while the this.router.navigate() method successfully changes the URL

Exploring Vue 3: Crafting a custom plugin using the composition API and enhancing it with Typescript type augmentation

Developing an object using class and generic features in Typescript

Is it possible to use a single type predicate for multiple variables in order to achieve type inference?

Issues encountered when attempting to use Angular2 with SystemJs and typescript transpiler

Tips for accessing and manipulating an array that is defined within a Pinia store

Following the build process with the --prod flag in Ionic 3, users may encounter a situation where

What is the best method to locate an element<T> within an Array[T] when <T> is an enum?

Typescript enhances the functionality of the Express Request body

Webpack 2.7.0 throws an error: "Unexpected parameter: theme"

Steps to resolve the "ERESOLVE could not resolve" error during the deployment of Firebase functions

Piping in Angular 2 with injected dependencies