Is there a way to use decorator with setters?

[UserAbuser228]

I would like to use decorator, that would control property's setter. Here's what I tried.

const MyDecorator = <T>(): PropertyDecorator => () => {
    let value: T;
    return {
        configurable: true,
        get: () => value,
        set: val => {
            value = val;
        },
    };
};

class MyClass {
    @MyDecorator()
    field = 1;

    constructor() {
        makeAutoObservable(this);
        reaction(() => this.field, () => console.log('reacted'));
    }
}

const myClass = new MyClass();
console.log(myClass.field++);
console.log(myClass.field++);
console.log(myClass.field++);

In the case above, both my @MyDecorator and makeAutoObservable don't work. They do work separatly. Without makeAutoObservable the value is increasing as it should be. Without @MyDecorator it's increasing and runs the callback for reaction. Both of them do not actually change the value, it always equal to 1.

I tried several ways, even with older versions and @observable decorators, but none of my tries were successfull.

So, could you please tell is there a way to create a decorator with setter?

[urugator]

The getter(+setter) fields are transformed to computed. You need the underlying value being observable. No promises, but you can try:

const MyDecorator = <T>(): PropertyDecorator => () => {
    const value = observable.box();
    return {
        configurable: true,
        get: () => value.get(),
        set: val => value.set(val)
    };
};

[urugator]

Anyway why do you need getter/setter, can't you just return { value: someFunc(token) } from decorator?

[UserAbuser228]

Because that will make the field readonly

[urugator]

Ok, I thought it's obvious, but: { value: someFunc(token), writable: true, enumerable: true, configurable: true }.
Or do you mean that you want to make the field readonly?

[UserAbuser228]

Excuse me, not obvious for me. That is still not what I need. This way I can set initial value, but what about reacting on the value's change?
I just wander can my idea of decorator

@Decorator('token')
@observable field = initialValue; // works only if (someFunc('token') === null);

can exists.

[urugator]

but what about reacting on the value's change?

Just make the field observable as usual: @observable + makeObservable(this) or makeObservable(this, { field: observable }). makeObservable should use the updated descriptor instead of the original one.
You can check if the decorator was applied correctly - in constructor, before calling makeObservable - console.log(Object.getOwnPropertyDescriptor(this, "field")) - you should see the descriptor returned from your decorator.

[mweststrate]

Depends on how decorators are transpiled, the semantics of Babel are close but different to TS

…

On Sun, 21 Feb 2021, 10:48 urugator, ***@***.***> wrote: That's wierd https://www.typescriptlang.org/docs/handbook/decorators.html#property-decorators : *A Property Descriptor is not provided as an argument to a property decorator due to how property decorators are initialized in TypeScript. This is because there is currently no mechanism to describe an instance property when defining members of a prototype, and no way to observe or modify the initializer for a property. The return value is ignored too. As such, a property decorator can only be used to observe that a property of a specific name has been declared for a class.* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2820 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBFH65H4VNYRJR6U2FTTADQGHANCNFSM4X46KJVA> .

[UserAbuser228]

Could you please tell me if such a decorator is even possible?

[mweststrate]

I strongly recommend against writing your own decorators. There are currently 3 different proposals / implementations you will have to deal with, they compose badly and without further standardization the effort will probably not outweigh the risk. If you want to know more about how to write decorators, please use StackOverflow or something similar, this is not a general JavaScript helpdesk :)

If I might give my 2 cents on the design of your decorator, I wouldn't introduce it: @decorator('token') isn't statically analysable and will break whenever you name or move 'token' without any language assistance. I'd keep it explicit and just setup the observe or reaction in the constructor.

[UserAbuser228]

I would not need static analysis, and the token would always be written in Latin, which would allow me not to think about language support. I just thought that this decorator will allow to solve the DRY problem. There are quite a few places in my project where I do essentially the same thing, and replacing this routine with a single decorator call seemed like a good idea to me.

Well, I guess I was wrong in my reasoning. Thank you for your answer.