Leave natural this in the decorator functions

[pabloalmunia]

Currently

In the specification, the decorator functions have a call that sets the value undefined to this.

 Call(decorator, undefined, « value, context »).

Curiously, in the current implementation of Babel this is true in all cases except for class decorators, in which this is the decorator function (the natural behavior):

function decorator(value, context) {
  console.log('decorator call');
  console.log('this', this);
  console.log('value', value);
  console.log('context', context);
}

@decorator
class C {
  @decorator
  m() {}
}

The output for the method decorator is:

decorator call
this undefined
value [Function: m]
context {
  kind: 'method',
  name: 'm',
  isStatic: false,
  isPrivate: false,
  addInitializer: [Function (anonymous)],
  getMetadata: [Function: getMetadata],
  setMetadata: [Function: setMetadata]
}

The output for the class decorator is:

decorator call
this [ [Function: decorator] ]
value [class C]
context {
  kind: 'class',
  name: 'C',
  addInitializer: [Function (anonymous)],
  getMetadata: [Function: getMetadata],
  setMetadata: [Function: setMetadata]
}

Why is this undefined?

In some discussions, it was suggested that this could be the decorated element, but this option brought a lot of problems and side effects. Probably, the solution was made to assign the value undefined to this to avoid these problems.

In my humble opinion, forcing the undefined value in this is an over-specification, and it would be correct to let the decorator function have the natural this that it has.

Advantages of leaving this of the decorating function in a natural way

A class could be considered a decorator factory, where when we create an instance, we generate a reference that can use for all calls to a method as a decorator.

An example of this behavior can be seen here: JavaScript metaprogramming with the 2022-03 decorators API (2ality.com)

As I understand it, if Babel followed the specification, this example would not be possible. Please correct me if I am wrong.

Proposal of update

Remove the assignment of this with the undefined value in the decorator function call. It's a minor change but essential.

[trusktr]

That 2ality arrow-function example will always work regardless what the spec chooses to do, because the arrow function always captures (or "closes over") this from the scope where it is used.

---

Are you suggesting that @some.method should be treated similarly to some.method() and automatically use some as this when it calls method?

That would be interesting!

Whereas @(some.method) would be as if we wrote (some.method)() and would lose this because some.method is being used as an expression.

This would simply work:

class Foo {
  decorate() {
    console.log(this instanceof Foo) // true
  }
}

const foo = new Foo()

@foo.decorate
class A {}

// Outputted "true" to console.

That's nice!

It is not too late to change this part of the design because no JS runtime has implemented decorators yet.

[nicolo-ribaudo]

Note that (some.method)() doesn't loose this.

[pabloalmunia]

Allow me to summarize what I have understood up to this point.

Current specification

class Decorator {
  name = "Decorator factory";
  check(value, context) {
    console.log('decorator call');
    console.log('this', this);
    console.log('value', value);
    console.log('context', context);
  }
}

const decorator = new Decorator;

@decorator.check
class C {
  @decorator.check
  m() {}
}

1. In this simple example, this must be undefined in the check method-decorator.

2. The current implementation in Babel has a minor error and the class method-decorator don't have undefined in this, but is a mistake. Is it true @nicolo-ribaudo?

Workarround: arrow function

class Decorator {
  name = "Decorator factory";
  check = (value, context) => {
    console.log('decorator call');
    console.log('this', this);
    console.log('value', value);
    console.log('context', context);
  }
}

const decorator = new Decorator;

@decorator.check
class C {
  @decorator.check
  m() {}
}

3. If we use a arrow function into a member of Decorator class the this is the object instance.

Workarround: the method return the decorator

class Decorator {
  name = "Decorator factory";
  check() {
    const _this = this;
    return function(value, context) {
      console.log('decorator call');
      console.log('this', this);
      console.log('_this', _this);
      console.log('value', value);
      console.log('context', context);
    }
  }
}

const decorator = new Decorator;

@(decorator.check)()
class C {
  @(decorator.check)()
  m() {}
}

4.- With a method that returns the decorator we can keep the original by closure, but the method call must be as a expression.

Question

@pzuraq, why is it not possible to keep the natural this in decorators and avoid these workarrounds?

[pzuraq]

I think this may have been a mistake in the spec, I can't think of a reason that we would have wanted to change this. I'll update it.

[Jamesernator]

I think this may have been a mistake in the spec, I can't think of a reason that we would have wanted to change this. I'll update it.

Is this change still planned? I've been playing around with decorators in TS 5.0's support and I was wanting to have some decorators as methods of a class.

(As far as I can tell in the current spec it just calls the decorator unconditionally with this as undefined)

[pzuraq]

This is still planned, yes. However as a normative change now it will need to go through committee first.

[pzuraq]

This has been resolved, natural this is used for decorator functions when called.