A class definition showcasing an abstract class with a restricted constructor access

Question

A class definition showcasing an abstract class with a restricted constructor access

Within my codebase, there is a simple function that checks if an object is an instance of a specific class. The function takes both the object and the class as arguments.

To better illustrate the issue, here is a simplified example without delving into the intricate details of the actual code:

function verifyType<T>(instance: unknown, classType:new () => T):instance is T {
    if (!(instance instanceof classType)) throw(`Expecting instance of ${classType.name}`);

    return true;
}

(class Foo { constructor() { } } const foo:unknown = new Foo(); verifyType(foo, Foo); // OK

However, issues arise when working with classes that have private constructors.

I comprehend the underlying logic behind these compiler errors. A private constructor implies that external code cannot construct the class, which makes perfect sense.

Despite this understanding, I am struggling to find an alternative approach that allows me to continue utilizing instanceof:

class Bar {
    private constructor() {
    }
    static create() {
        return new Bar();
    }
}
const bar:unknown = Bar.create();
verifyType(bar, Foo);
// OK
verifyType(bar, Bar);
// Argument of type 'typeof Bar' is not assignable to parameter of type 'new () => Bar'.
//  Cannot assign a 'private' constructor type to a 'public' constructor type.

Experimenting with `T extends typeof Object`

I came across a solution proposed in How to refer to a class with private constructor in a function with generic type parameters?

Based on the advice from the above link, I attempted the following:

function verifyType<T extends typeof Object>(instance: unknown, classType:T):instance is InstanceType<T>

Unfortunately, this approach raised errors due to the numerous static methods within Object:

const foo = new Foo();
verifyType(foo, Foo);
// Argument of type 'typeof Foo' is not assignable to parameter of type 'ObjectConstructor'.
//   Type 'typeof Foo' is missing the following properties from type 'ObjectConstructor': getPrototypeOf, getOwnPropertyDescriptor, getOwnPropertyNames, create, and 16 more.

Exploring Unconventional Solutions

I experimented with various iterations of typeof Object in an attempt to satisfy TypeScript while maintaining runtime accuracy, such as:

function verifyType<T extends Function & Pick<typeof Object, "prototype">>(instance: unknown, classType:T):instance is InstanceType<T>

Although this resolved the compile-time issues, it introduced runtime errors by allowing invalid types, which is unacceptable:

verifyType(bar, ()=>{});
// No compile-time errors
// Runtime Error: Function has non-object prototype 'undefined' in instanceof check

Seeking Assistance from `// @ts-expect-error`

In conclusion, I might need to accept that this particular scenario is too specialized, and proper support may be lacking for the foreseeable future. As a result, I may need to provide exemptions in my code accordingly.

// @ts-expect-error Unfortunately, TS has no type representing a generic class with a private constructor
verifyType(bar, Bar);

typescript private-constructor

Answer 1

Answer №1

My proposed method involves conducting inference on the prototype attribute of the classType parameter, as demonstrated below:

function validateType<T extends object>(
    instance: unknown,
    classType: Function & { prototype: T }
): asserts instance is T {
    if (!classType.prototype) throw ( 
      `Hold on, ${classType.name || "that"} is not a class constructor`);
    if (!(instance instanceof classType)) throw (
      `Expecting an instance of ${classType.name}`);
}

In TypeScript, you can use x instanceof y with y being a function type, hence the need for Function &. We utilize the generic type parameter T to represent the instance type of classType by linking it to the type of the prototype property.

Alongside Function & {protoype: T}, I've incorporated several changes from your original script:

The function validateType() now acts as an assertion function, returning asserts instance is T rather than functioning as a type guard function that returns instance is T. Assertion functions ensure narrowness without returning any value, unlike type guard functions which aid in control flow analysis.
I included an explicit check within the implementation to verify if classType.prototype exists. This addresses TypeScript's allocation of the prototype property for Function as the any type instead of the preferable unknown type, making it challenging to spot potential runtime errors related to non-constructors like ()=>{}. To tackle this limitation at the design level, the code attempts to fortify validateType() against such exceptions. You may consider incorporating additional logic like
```
(!classType.prototype || typeof classType.prototype !== "object")
```
based on your requirements.

Let's put it to the test:

class Foo {
    constructor() {
    }
    a = 1;
}
const foo: unknown = new Foo();
foo.a // error! Object is of type unknown
validateType(foo, Foo);
foo.a // acceptable
console.log(foo.a.toFixed(1)) // "1.0"

The compiler correctly recognizes that foo is a Foo post the invocation of validateType(foo, Foo).

class Bar {
    private constructor() {
    }
    static create() {
        return new Bar();
    }
    b = "z"
}
const bar: unknown = Bar.create();
validateType(bar, Bar);
console.log(bar.b.toUpperCase()); // "Z"

This scenario also validates well. The compiler approves verifyType(bar, Bar) due to Bar exhibiting a prototype property linked to type Bar, facilitating the subsequent access to the b property despite the presence of a private constructor within Bar.

Lastly:

const baz: unknown = new Date();
validateType(baz, () => { }); // 💥 Hold on, that is not a class constructor
baz // any

Although we couldn't catch validateType(baz, ()=>{}) during compilation, a meaningful runtime error ensues ensuring that the transition of baz from unknown to any doesn't negatively impact us.

Link to code on TypeScript Playground

Answer 2

My proposed method involves conducting inference on the prototype attribute of the classType parameter, as demonstrated below:

function validateType<T extends object>(
    instance: unknown,
    classType: Function & { prototype: T }
): asserts instance is T {
    if (!classType.prototype) throw ( 
      `Hold on, ${classType.name || "that"} is not a class constructor`);
    if (!(instance instanceof classType)) throw (
      `Expecting an instance of ${classType.name}`);
}

In TypeScript, you can use x instanceof y with y being a function type, hence the need for Function &. We utilize the generic type parameter T to represent the instance type of classType by linking it to the type of the prototype property.

Alongside Function & {protoype: T}, I've incorporated several changes from your original script:

The function validateType() now acts as an assertion function, returning asserts instance is T rather than functioning as a type guard function that returns instance is T. Assertion functions ensure narrowness without returning any value, unlike type guard functions which aid in control flow analysis.
I included an explicit check within the implementation to verify if classType.prototype exists. This addresses TypeScript's allocation of the prototype property for Function as the any type instead of the preferable unknown type, making it challenging to spot potential runtime errors related to non-constructors like ()=>{}. To tackle this limitation at the design level, the code attempts to fortify validateType() against such exceptions. You may consider incorporating additional logic like
```
(!classType.prototype || typeof classType.prototype !== "object")
```
based on your requirements.

Let's put it to the test:

class Foo {
    constructor() {
    }
    a = 1;
}
const foo: unknown = new Foo();
foo.a // error! Object is of type unknown
validateType(foo, Foo);
foo.a // acceptable
console.log(foo.a.toFixed(1)) // "1.0"

The compiler correctly recognizes that foo is a Foo post the invocation of validateType(foo, Foo).

class Bar {
    private constructor() {
    }
    static create() {
        return new Bar();
    }
    b = "z"
}
const bar: unknown = Bar.create();
validateType(bar, Bar);
console.log(bar.b.toUpperCase()); // "Z"

This scenario also validates well. The compiler approves verifyType(bar, Bar) due to Bar exhibiting a prototype property linked to type Bar, facilitating the subsequent access to the b property despite the presence of a private constructor within Bar.

Lastly:

const baz: unknown = new Date();
validateType(baz, () => { }); // 💥 Hold on, that is not a class constructor
baz // any

Although we couldn't catch validateType(baz, ()=>{}) during compilation, a meaningful runtime error ensues ensuring that the transition of baz from unknown to any doesn't negatively impact us.

Link to code on TypeScript Playground

Answer 3

Answer №2

To achieve this, you can modify the function to accept classes with a generate method as follows:

function validateClass<C extends (Function & { generate(...args: any[]): unknown }) | (new (...args: any[]) => unknown)>(
  object: unknown,
  classType: C
): object is C extends { generate(...args: any[]): infer T } ? T : C extends new (...args: any[]) => unknown ? InstanceType<C> : never {
  if (!(object instanceof classType)) throw `Expected object of type ${classType.name}`;

  return true;
}

While this approach does work, it may not be ideal if you have multiple classes with differently named generator methods, requiring you to update the function signature accordingly.

Interactive Demo

Additionally, for async factory methods, simply replace generate(): T with generate(): T | Promise<T>.

Answer 4

To achieve this, you can modify the function to accept classes with a generate method as follows:

function validateClass<C extends (Function & { generate(...args: any[]): unknown }) | (new (...args: any[]) => unknown)>(
  object: unknown,
  classType: C
): object is C extends { generate(...args: any[]): infer T } ? T : C extends new (...args: any[]) => unknown ? InstanceType<C> : never {
  if (!(object instanceof classType)) throw `Expected object of type ${classType.name}`;

  return true;
}

While this approach does work, it may not be ideal if you have multiple classes with differently named generator methods, requiring you to update the function signature accordingly.

Interactive Demo

Additionally, for async factory methods, simply replace generate(): T with generate(): T | Promise<T>.

Answer 5

Answer №3

Fortunately, a clever solution is available

I encountered a similar issue some time back. The use of the built-in InstanceType<TClass> seems to be effective in resolving the instance type, but it comes with the constraint of requiring a public constructor:

type InstanceType<T extends abstract new (...args: any) => any> = ....

However, the limitation of needing a public constructor for InstanceType<TClass> is quite restrictive. It's suitable for obtaining runtime results, but inadequate for creating open generic types (TS Conditional Types tend to mix run-time and compile-time type results in a confusing manner!)

Thankfully, we can leverage how the compiler resolves types to find the best matching signature and overlook the accessibility modifier to allow private / protected constructors as follows:

type InstanceTypeSpy<TClass> = InstanceType<{ new(): never } & TClass>;

This method works because technically, new(): never does meet the expectations of InstanceType<>, even though the compiler chooses not to match against new(): never when possible to avoid resulting in never - thus providing us with the actual type (or defaulting to never if there truly isn't any constructor on TClass).

Fun Fact

To clarify the distinction between runtime and compile-time types, consider the recently introduced Awaited<T> - which gives us the runtime type when awaiting an instance of T. Now, imagine developing a generic library that needs to handle async / T = Promise<U> where the precise type T is unknown at compile time due to the unknown value of U.

This scenario represents an "open" generic type - once the value of U is known, it transforms into a "closed" generic type.

In such instances, we require the compile-time type; for example, if T = Promise<U>, then we need to access U.

The usage of Awaited<T> won't suffice since it may not align with U. If you attempt to assign a value of type U to something that expects Awaited<T>, a compile error will arise stating they are not assignable.

It's important to realize that await is recursive in nature. Consider a scenario where at runtime, U has a type of Promise<V>; this would result in our T being of type Promise<Promise<V>>. Upon awaiting an instance of type T, we receive a result of type V, significantly differing from a result of type Promise<V>. Thus, for an unknown T, the correctness of such library code cannot be guaranteed by the compiler.

For reference, below is an example of Awaited made non-recursive:

/**
 * Non-recursive version of Awaited<T>, offering the compile-time type necessary for generics.
 */
export type PromiseResolveType<T> =
  T extends null | undefined ? T :
  T extends object & { then(onfulfilled: infer F): any } ?
    F extends ((value: infer V, ...args: any) => any) ? V :
    never :
  T;

Answer 6

Fortunately, a clever solution is available

I encountered a similar issue some time back. The use of the built-in InstanceType<TClass> seems to be effective in resolving the instance type, but it comes with the constraint of requiring a public constructor:

type InstanceType<T extends abstract new (...args: any) => any> = ....

However, the limitation of needing a public constructor for InstanceType<TClass> is quite restrictive. It's suitable for obtaining runtime results, but inadequate for creating open generic types (TS Conditional Types tend to mix run-time and compile-time type results in a confusing manner!)

Thankfully, we can leverage how the compiler resolves types to find the best matching signature and overlook the accessibility modifier to allow private / protected constructors as follows:

type InstanceTypeSpy<TClass> = InstanceType<{ new(): never } & TClass>;

This method works because technically, new(): never does meet the expectations of InstanceType<>, even though the compiler chooses not to match against new(): never when possible to avoid resulting in never - thus providing us with the actual type (or defaulting to never if there truly isn't any constructor on TClass).

Fun Fact

To clarify the distinction between runtime and compile-time types, consider the recently introduced Awaited<T> - which gives us the runtime type when awaiting an instance of T. Now, imagine developing a generic library that needs to handle async / T = Promise<U> where the precise type T is unknown at compile time due to the unknown value of U.

This scenario represents an "open" generic type - once the value of U is known, it transforms into a "closed" generic type.

In such instances, we require the compile-time type; for example, if T = Promise<U>, then we need to access U.

The usage of Awaited<T> won't suffice since it may not align with U. If you attempt to assign a value of type U to something that expects Awaited<T>, a compile error will arise stating they are not assignable.

It's important to realize that await is recursive in nature. Consider a scenario where at runtime, U has a type of Promise<V>; this would result in our T being of type Promise<Promise<V>>. Upon awaiting an instance of type T, we receive a result of type V, significantly differing from a result of type Promise<V>. Thus, for an unknown T, the correctness of such library code cannot be guaranteed by the compiler.

For reference, below is an example of Awaited made non-recursive:

/**
 * Non-recursive version of Awaited<T>, offering the compile-time type necessary for generics.
 */
export type PromiseResolveType<T> =
  T extends null | undefined ? T :
  T extends object & { then(onfulfilled: infer F): any } ?
    F extends ((value: infer V, ...args: any) => any) ? V :
    never :
  T;

A class definition showcasing an abstract class with a restricted constructor access

Experimenting with `T extends typeof Object`

Exploring Unconventional Solutions

Seeking Assistance from `// @ts-expect-error`

Answer №1

Answer №2

Answer №3

Fortunately, a clever solution is available

Fun Fact

Similar questions

Tips for transferring data when clicking in Angular 5 from the parent component to the child component

Dynamic tag names can be utilized with ref in TypeScript

The issue with npm modules not appearing in EMCA2015 JS imports persists

Ways to Resolve the "TS2533: Object May Be Either 'Null' or 'Undefined'" Error on a Dynamic Object

Having trouble implementing the Material UI time picker because it does not meet the required DateTime format

"Benefit from precise TypeScript error messages for maintaining a streamlined and organized architecture in your

React-snap causing trouble with Firebase

Bug in auto compilation in Typescript within the Visual Studios 2015

Using createStackNavigator along with createBottomTabNavigator in React Navigation version 5

Why is the value always left unused?

The parameter type 'typeof LogoAvatar' cannot be assigned to the argument type 'ComponentType<LogoProps & Partial<WithTheme>'

Is there a counterpart to ES6 "Sets" in TypeScript?

Compilation of various Typescript files into a single, encapsulated JavaScript bundle

Unable to refresh the context following a successful API call

Tips for optimizing the performance of nested for loops

Update gulp configuration to integrate TypeScript into the build process

Steps for creating a TypeScript project with React Native

Error in TypeScript: The property 'data' is not found within type '{ children?: ReactNode; }'. (ts2339)

In Angular, dynamically updating ApexCharts series daily for real-time data visualization

What could be causing the rapid breakage of the socket in Ionic 3's Bluetooth Serial after just a short period

A class definition showcasing an abstract class with a restricted constructor access

Experimenting with T extends typeof Object

Exploring Unconventional Solutions

Seeking Assistance from // @ts-expect-error

Answer №1

Answer №2

Answer №3

Fortunately, a clever solution is available

Fun Fact

Similar questions

Tips for transferring data when clicking in Angular 5 from the parent component to the child component

Dynamic tag names can be utilized with ref in TypeScript

The issue with npm modules not appearing in EMCA2015 JS imports persists

Ways to Resolve the "TS2533: Object May Be Either 'Null' or 'Undefined'" Error on a Dynamic Object

Having trouble implementing the Material UI time picker because it does not meet the required DateTime format

"Benefit from precise TypeScript error messages for maintaining a streamlined and organized architecture in your

React-snap causing trouble with Firebase

Bug in auto compilation in Typescript within the Visual Studios 2015

Using createStackNavigator along with createBottomTabNavigator in React Navigation version 5

Why is the value always left unused?

The parameter type 'typeof LogoAvatar' cannot be assigned to the argument type 'ComponentType<LogoProps & Partial<WithTheme>'

Is there a counterpart to ES6 "Sets" in TypeScript?

Compilation of various Typescript files into a single, encapsulated JavaScript bundle

Unable to refresh the context following a successful API call

Tips for optimizing the performance of nested for loops

Update gulp configuration to integrate TypeScript into the build process

Steps for creating a TypeScript project with React Native

Error in TypeScript: The property 'data' is not found within type '{ children?: ReactNode; }'. (ts2339)

In Angular, dynamically updating ApexCharts series daily for real-time data visualization

What could be causing the rapid breakage of the socket in Ionic 3's Bluetooth Serial after just a short period

Experimenting with `T extends typeof Object`

Seeking Assistance from `// @ts-expect-error`