Enhance your TypeScript code using decorators with inheritance

Question

Enhance your TypeScript code using decorators with inheritance

Exploring the realm of Typescript decorators has led me to discover their intriguing behavior when combined with class inheritance.

Consider the following scenario:

class A {
    @f()
    propA;
}

class B extends A {
    @f()
    propB;
}

class C extends A {
    @f()
    propC;
}

function f() {
    return (target, key) => {
        if (!target.test) target.test = [];
        target.test.push(key);
    };
}

let b = new B();
let c = new C();

console.log(b['test'], c['test']);

The current output is:

[ 'propA', 'propB', 'propC' ] [ 'propA', 'propB', 'propC' ]

However, the expected output would be:

[ 'propA', 'propB' ] [ 'propA', 'propC' ]

This suggests that target.test is shared among classes A, B, and C. Here's my analysis:

When instantiating new B(), it triggers initialization of class A first, invoking the evaluation of f for A. As target.test is undefined, it gets initialized.
Subsequently, f is called for class B after extending from A. At this point, target.test in class B references the same instance as class A, resulting in the accumulation of properties propA and propB. So far, so good.
A similar process occurs with class C inheriting from A. Despite my anticipation of a distinct test object for C, the shared log proves otherwise.

I am seeking insights on why this behavior persists and how I can modify f to grant separate test properties for A and B. Could this involve creating an "instance specific" decorator?

typescript inheritance decorator

Answer 1

Answer №1

After dedicating some time to experimenting and researching online, I managed to create a functional version. Although I'm unsure of the reasoning behind its success, I hope you can overlook the absence of an explanation.

The crucial point lies in utilizing

Object.getOwnPropertyDescriptor(target, 'test') == null

instead of !target.test for checking the existence of the test property.

If you implement:

function f() {
    return (target, key) => {
        if (Object.getOwnPropertyDescriptor(target, 'test') == null) target.test = [];
        target.test.push(key);
    };
}

the following will be displayed on the console:

[ 'propB' ] [ 'propC' ]

This outcome is close to my desired result. Nonetheless, the array is now unique to each instance. Consequently, 'propA' is absent from the array as it is defined in A. Therefore, we must access the parent target and retrieve the property from there. After some trial and error, I discovered that this can be achieved using Object.getPrototypeOf(target).

The finalized solution consists of:

function f() {
    return (target, key) => {
        if (Object.getOwnPropertyDescriptor(target, 'test') == null) target.test = [];
        target.test.push(key);

        /*
         * Now that the target is specific, include properties defined in the parent.
         */
        let parentTarget = Object.getPrototypeOf(target);
        let parentData = parentTarget.test;
        if (parentData) {
            parentData.forEach(val => {
                if (target.test.find(v => v == val) == null) target.test.push(val);
            });
        }
    };
}

The resulting output is:

[ 'propB', 'propA' ] [ 'propC', 'propA' ]

I would appreciate any insight from those who comprehend why this approach succeeds where the previous one falls short.

Answer 2

After dedicating some time to experimenting and researching online, I managed to create a functional version. Although I'm unsure of the reasoning behind its success, I hope you can overlook the absence of an explanation.

The crucial point lies in utilizing

Object.getOwnPropertyDescriptor(target, 'test') == null

instead of !target.test for checking the existence of the test property.

If you implement:

function f() {
    return (target, key) => {
        if (Object.getOwnPropertyDescriptor(target, 'test') == null) target.test = [];
        target.test.push(key);
    };
}

the following will be displayed on the console:

[ 'propB' ] [ 'propC' ]

This outcome is close to my desired result. Nonetheless, the array is now unique to each instance. Consequently, 'propA' is absent from the array as it is defined in A. Therefore, we must access the parent target and retrieve the property from there. After some trial and error, I discovered that this can be achieved using Object.getPrototypeOf(target).

The finalized solution consists of:

function f() {
    return (target, key) => {
        if (Object.getOwnPropertyDescriptor(target, 'test') == null) target.test = [];
        target.test.push(key);

        /*
         * Now that the target is specific, include properties defined in the parent.
         */
        let parentTarget = Object.getPrototypeOf(target);
        let parentData = parentTarget.test;
        if (parentData) {
            parentData.forEach(val => {
                if (target.test.find(v => v == val) == null) target.test.push(val);
            });
        }
    };
}

The resulting output is:

[ 'propB', 'propA' ] [ 'propC', 'propA' ]

I would appreciate any insight from those who comprehend why this approach succeeds where the previous one falls short.

Answer 3

Answer №2

The reason for the behavior in your code is due to the fact that your decorated field is an instance member, and the target you receive is the prototype of the class. As the execution begins, the class A is loaded first since it is the parent class. Consequently, the test array is set on the prototype of class A, which is shared by all Child Classes B/C. This explains why you see 3 elements in the test array.

Instead of utilizing getOwnPropertyDescriptor(), one alternative approach is to store the metadata on the target.constructor itself, which represents the class. Each class will then have its own metadata stored, making it easier to gather all decorated fields by searching up the prototype chain (with assistance from the standard relect-metadata).

function f() {
  return (target, key) => {
    if (!Reflect.hasOwnMetadata('MySpecialKey', target.constructor)) {
      // add field list to the class.
      Reflect.defineMetadata('MySpecialKey', [], target.constructor);
    }
    Reflect.getOwnMetadata('MySpecialKey', target.constructor).push(key);
  };
}

/**
 * @param clz the class/constructor
 * @returns the fields decorated with @f throughout the prototype chain.
 */
static getAllFields(clz: Record<string, any>): string[] {
if(!clz) return [];
const fields: string[] | undefined = Reflect.getMetadata('MySpecialKey', clz);
// retrieve `__proto__` and (recursively) all parent classes
const rs = new Set([...(fields || []), ...this.getAllFields(Object.getPrototypeOf(clz))]);
return Array.from(rs);
}

Alternatively, you can consider following the class-validator approach which involves a global metadata storage containing decorator-related information. During the logic execution, check if the target constructor is an instance of the registered target. If so, include the field in the validation process.

Answer 4

The reason for the behavior in your code is due to the fact that your decorated field is an instance member, and the target you receive is the prototype of the class. As the execution begins, the class A is loaded first since it is the parent class. Consequently, the test array is set on the prototype of class A, which is shared by all Child Classes B/C. This explains why you see 3 elements in the test array.

Instead of utilizing getOwnPropertyDescriptor(), one alternative approach is to store the metadata on the target.constructor itself, which represents the class. Each class will then have its own metadata stored, making it easier to gather all decorated fields by searching up the prototype chain (with assistance from the standard relect-metadata).

function f() {
  return (target, key) => {
    if (!Reflect.hasOwnMetadata('MySpecialKey', target.constructor)) {
      // add field list to the class.
      Reflect.defineMetadata('MySpecialKey', [], target.constructor);
    }
    Reflect.getOwnMetadata('MySpecialKey', target.constructor).push(key);
  };
}

/**
 * @param clz the class/constructor
 * @returns the fields decorated with @f throughout the prototype chain.
 */
static getAllFields(clz: Record<string, any>): string[] {
if(!clz) return [];
const fields: string[] | undefined = Reflect.getMetadata('MySpecialKey', clz);
// retrieve `__proto__` and (recursively) all parent classes
const rs = new Set([...(fields || []), ...this.getAllFields(Object.getPrototypeOf(clz))]);
return Array.from(rs);
}

Alternatively, you can consider following the class-validator approach which involves a global metadata storage containing decorator-related information. During the logic execution, check if the target constructor is an instance of the registered target. If so, include the field in the validation process.

Answer 5

Answer №3

One possible explanation is that when class B is created, the prototype of A is duplicated along with all its unique properties (as references).

I decided to implement a slightly modified solution which seems to address the issue of duplicates more effectively, especially if class C does not contain any decorators.

I am still uncertain if this approach is the most efficient way to handle such scenarios:


    function foo(target, key) {
        let
            ctor = target.constructor;

        if (!Object.getOwnPropertyDescriptor(ctor, "props")) {
            if (ctor.props)
                ctor.props = [...ctor.props];
            else
                ctor.props = [];
        }

        ctor.props.push(key);
    }

    abstract class A {
        @foo
        propA = 0;
    }

    class B extends A {
        @foo
        propB = 0;
    }

    class C extends A {
        @foo
        propC = 0;
    }

Answer 6

One possible explanation is that when class B is created, the prototype of A is duplicated along with all its unique properties (as references).

I decided to implement a slightly modified solution which seems to address the issue of duplicates more effectively, especially if class C does not contain any decorators.

I am still uncertain if this approach is the most efficient way to handle such scenarios:


    function foo(target, key) {
        let
            ctor = target.constructor;

        if (!Object.getOwnPropertyDescriptor(ctor, "props")) {
            if (ctor.props)
                ctor.props = [...ctor.props];
            else
                ctor.props = [];
        }

        ctor.props.push(key);
    }

    abstract class A {
        @foo
        propA = 0;
    }

    class B extends A {
        @foo
        propB = 0;
    }

    class C extends A {
        @foo
        propC = 0;
    }

Answer 7

Answer №4

@user5365075 I encountered a similar issue while using method decorators, but your solution proved to be effective.

Below is an example of a decorator I implemented in one of my projects, utilizing an object instead of an array:

export function property(options) {
    return (target, name) => {
        // This workaround addresses a bug discussed here:
        // https://stackoverflow.com/questions/43912168/typescript-decorators-with-inheritance

        if (!Object.getOwnPropertyDescriptor(target, '_sqtMetadata')) {
            target._sqtMetadata = {}
        }

        if (target._sqtMetadata.properties) {
            target._sqtMetadata.properties[name] = options.type
        } else {
            target._sqtMetadata.properties = { [name]: options.type }
        }

        const parentTarget = Object.getPrototypeOf(target)
        const parentData = parentTarget._sqtMetadata

        if (parentData) {
            if (parentData.properties) {
                Object.keys(parentData.properties).forEach((key) => {
                    if (!target._sqtMetadata.properties[key]) {
                        target._sqtMetadata.properties[key] = parentData.properties[key]
                    }
                })
            }
        }
    }
}

I can attest that the behavior described also applies to class decorators.

Answer 8

@user5365075 I encountered a similar issue while using method decorators, but your solution proved to be effective.

Below is an example of a decorator I implemented in one of my projects, utilizing an object instead of an array:

export function property(options) {
    return (target, name) => {
        // This workaround addresses a bug discussed here:
        // https://stackoverflow.com/questions/43912168/typescript-decorators-with-inheritance

        if (!Object.getOwnPropertyDescriptor(target, '_sqtMetadata')) {
            target._sqtMetadata = {}
        }

        if (target._sqtMetadata.properties) {
            target._sqtMetadata.properties[name] = options.type
        } else {
            target._sqtMetadata.properties = { [name]: options.type }
        }

        const parentTarget = Object.getPrototypeOf(target)
        const parentData = parentTarget._sqtMetadata

        if (parentData) {
            if (parentData.properties) {
                Object.keys(parentData.properties).forEach((key) => {
                    if (!target._sqtMetadata.properties[key]) {
                        target._sqtMetadata.properties[key] = parentData.properties[key]
                    }
                })
            }
        }
    }
}

I can attest that the behavior described also applies to class decorators.

Enhance your TypeScript code using decorators with inheritance

Answer №1

Answer №2

Answer №3

Answer №4

Similar questions

TypeScript fails to acknowledge an exported enum

Exploring the Behavior of Typescript Modules

js TouchEvent: When performing a pinch gesture with two fingers and lifting one of them up, how can you determine which finger was lifted?

The attribute 'data' is not found in the type 'IntrinsicAttributes & IProps'. Error code: ts(2322)

The Gulp task is stuck in an endless cycle

I need to compile a comprehensive inventory of all the publicly accessible attributes belonging to a Class/Interface

The noUnusedLocal rule in the Typescript tsconfig is not being followed as expected

Is it possible to leverage ES6 modules within a Node.js application while also debugging it using Visual Studio?

Obtain the value of a template variable in Angular 2

What is the significance of utilizing an empty value `[]` for a typed array interface instead of using an empty `{}` for a typed object interface?

Error encountered in Angular NGRX while accessing the store: Trying to read property 'map' of an undefined variable

Error message: Typescript and Styled-Component conflict: GlobalStylesProps does not share any properties with type { theme?: DefaultTheme | undefined; }

When utilizing makeStyles in @mui, an error may occur stating that property '' does not exist on type 'string'

The module 'node:fs' could not be located. Stack required:

Angular 6 Checkbox Selector - Filtering Made Easy

Tips for sending a function as a value within React Context while employing Typescript

A step-by-step guide to customizing the Material UI Chips delete SVG icon to appear in white color through

There was an error in parsing the module: an unexpected token was encountered during the rendering

What is the best approach for managing Create/Edit pages in Next.js - should I fetch the product data in ServerSideProps or directly in the component?

What is the best way to incorporate a WYSIWYG Text Area into a TypeScript/Angular2/Bootstrap project?