Constructor caching leading to the error message: "The property '...' does not have an initializer and is not definitely assigned in the constructor."

Question

Constructor caching leading to the error message: "The property '...' does not have an initializer and is not definitely assigned in the constructor."

Whenever I work on projects, I tend to create classes with constructors that cache the objects they generate. This way, if the constructor is called with the same parameters multiple times, it will return the same instance rather than creating redundant instances.

Let's take a look at a simple example:

class X {
    private static __cache: Record<string, X> = Object.create(null);

    readonly name: string; // A compilation error occurs here.

    constructor(name: string) {
        const cached = X.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        this.name = name;
        X.__cache[name] = this;
    }
}

This code used to work flawlessly in TypeScript until I upgraded to version 2.7 and enabled strictPropertyInitialization. Now, an error pops up on readonly name: string; stating:

Property 'name' has no initializer and is not definitely assigned in the constructor.

I have several classes in my projects following this pattern, so I need to come up with some general solutions to eliminate the error.

Two solutions I am not keen on:

Disabling strictPropertyInitialization. Although useful, I prefer not to turn it off as it revealed areas needing improvement and forced me to update definitions in some cases.
Adding a definite assignment assertion to name, like readonly name!: string;. While this bypasses the error, it also weakens compiler checks. If I accidentally miss the assignment this.name = name, TypeScript won't flag it as an error - which is risky for catching mistakes early.

The example provided was minimal, but in actual applications, classes may have numerous fields or involve complex computations rather than simple parameter assignments.

typescript constructor

Answer 1

Answer №1

When dealing with cases where calculating the object's fields is a resource-intensive task, my preferred solution involves marking the constructor as private (although protected might be appropriate in certain scenarios) and defining a factory function as a static member within the class. Here's an example:

class X2 {
    private static __cache: Record<string, X2> = Object.create(null);

    readonly name: string;

    private constructor(nameSource: string) {
        this.name = expensiveComputation(nameSource);
    }

    // Instead of directly using `new X2`, we utilize this factory function to instantiate new objects.
    static make(name: string): X2 {
        const cached = X2.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        return X2.__cache[name] = new X2(name);
    }    
}

Since the constructor consistently assigns values to all fields, TypeScript no longer encounters any issues. This approach necessitates that when working with the class, the factory function must be employed for creating new instances instead of directly invoking the constructor.

Answer 2

When dealing with cases where calculating the object's fields is a resource-intensive task, my preferred solution involves marking the constructor as private (although protected might be appropriate in certain scenarios) and defining a factory function as a static member within the class. Here's an example:

class X2 {
    private static __cache: Record<string, X2> = Object.create(null);

    readonly name: string;

    private constructor(nameSource: string) {
        this.name = expensiveComputation(nameSource);
    }

    // Instead of directly using `new X2`, we utilize this factory function to instantiate new objects.
    static make(name: string): X2 {
        const cached = X2.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        return X2.__cache[name] = new X2(name);
    }    
}

Since the constructor consistently assigns values to all fields, TypeScript no longer encounters any issues. This approach necessitates that when working with the class, the factory function must be employed for creating new instances instead of directly invoking the constructor.

Answer 3

Answer №2

In scenarios where my constructor simply assigns parameters to fields without extensive computation, I have found a different solution. I prefer flipping the logic in the constructor to first perform field assignments before checking if an instance already exists. Although this may result in unnecessary field assignments if an instance is already present, I only address this concern if profiling indicates it poses a significant issue in a practical application.

The revised approach looks like this:

class X {
    private static __cache: Record<string, X> = Object.create(null);

    readonly name: string;

    constructor(name: string) {
        // Assigning the fields first...
        this.name = name;

        // Then determining if an instance exists for return.
        const cached = X.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        X.__cache[name] = this;
    }
}

If utilizing parameter properties, the code can be further simplified to:

class X {
    private static __cache: Record<string, X> = Object.create(null);

    // The constructor parameter doubles as the property definition on X instances.
    constructor(readonly name: string) {

        // Determining if an instance is available for return.
        const cached = X.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        X.__cache[name] = this;
    }
}

Answer 4

In scenarios where my constructor simply assigns parameters to fields without extensive computation, I have found a different solution. I prefer flipping the logic in the constructor to first perform field assignments before checking if an instance already exists. Although this may result in unnecessary field assignments if an instance is already present, I only address this concern if profiling indicates it poses a significant issue in a practical application.

The revised approach looks like this:

class X {
    private static __cache: Record<string, X> = Object.create(null);

    readonly name: string;

    constructor(name: string) {
        // Assigning the fields first...
        this.name = name;

        // Then determining if an instance exists for return.
        const cached = X.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        X.__cache[name] = this;
    }
}

If utilizing parameter properties, the code can be further simplified to:

class X {
    private static __cache: Record<string, X> = Object.create(null);

    // The constructor parameter doubles as the property definition on X instances.
    constructor(readonly name: string) {

        // Determining if an instance is available for return.
        const cached = X.__cache[name];
        if (cached !== undefined) {
            return cached;
        }

        X.__cache[name] = this;
    }
}

Answer 5

Answer №3

Visit this link to learn how to fix the TypeScript error in Visual Studio 2017

When facing issues within our own code, it is important to manually add the definite assignment assertion modifier as mentioned in the provided link. By placing a few ! in the right places, we can effectively resolve any problems in our project.

Answer 6

Visit this link to learn how to fix the TypeScript error in Visual Studio 2017

When facing issues within our own code, it is important to manually add the definite assignment assertion modifier as mentioned in the provided link. By placing a few ! in the right places, we can effectively resolve any problems in our project.

Constructor caching leading to the error message: "The property '...' does not have an initializer and is not definitely assigned in the constructor."

Answer №1

Answer №2

Answer №3

Similar questions

Chai expect() in Typescript to Validate a Specific Type

Running a function before triggering a refresh in Angular 2/4

The Error message "Property 'data' is not present in Type <void> | AxiosHttpResponse<any>" is indicating that the data property is missing on

Is there a deeper philosophical rationale behind choosing to use (or not use) enums in TypeScript, along with string union types?

Error encountered while compiling an Asp.Net Core project due to exceeding the maximum allowable path length in the

Is it possible for TypeScript to manage a dynamic return type that is not determined by a function parameter?

Leveraging Typescript Definitions Files from Definitely Typed with an Outdated Typescript Version

The specified JSX element type (whether it be from react-konva or not) does not contain any defined constructors or callable signatures

Received corrupted file during blob download in Angular 7

Tips for specifying a clear type in TypeGraphQL when dealing with key-value pair objects

CORS policy blocked Axios React GET request

Typescript array iteration using dual parameters

Ways to efficiently update the API_BASE_URL in a TypeScript Angular client generated by NSwag

Why does the property of {{hero.name}} function properly in a <h> tag but not in an <img> tag?

Updating parent components through child components in ReactWould you like another unique

Saving large amounts of data in bulk to PostgreSQL using TypeORM

Create a Jest mock for a namespace and a function that have the same name

Enhance Material UI with custom properties

Suggestions for efficiently filtering nested objects with multiple levels in RXJS within an Angular environment?

Organizing data in TypeScript