Exports and decorators

[keithamus]

Within a module, which only exports one class, the easiest syntax to use is as follows:

export default class Foo {
}

However, it seems this could be incompatible with class decorators. Would the following work?

@dec
export default class Foo {
}

Or would you have to do:

@dec
class Foo {
}
export default Foo

[nesk]

Good point, the middle code should desugar to this to allow this behaviour:

var Foo = (function () {
  class Foo {
  }

  Foo = dec(Foo) || Foo;
  return Foo;
})();
export default Foo;

[yuchi]

AFAIK this:

export default class C {}

already desugars to:

class C {}
export default C;

So this is a non-issue.

Please @sebmck check me on this.

[keithamus]

May be a bug in Babel; http://babel.sebmck.com/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=function%20foo()%20%7B%0A%20%20console.log(arguments)%3B%20%20%0A%7D%0A%0A%40foo%0Aexport%20default%20class%20Foo%20%7B%0A%7D%0A

I can file it but I'll make sure this is the case when @sebmck chimes in.

[sebmck]

I don't think the grammar specifically allows it but it should be allowed.

[sebmck]

The grammar (If I'm reading it correctly) allows you to do:

export default @decorator class Foo {}

[keithamus]

FYI @sebmck Babel's decorator transform does not allow that. Shall I raise an issue?

[sebmck]

@keithamus No it does. I just haven't pushed the latest version to that site.

[keithamus]

Sweet, many thanks @sebmck! Awesome work!

Back on point - this become a pain point for ES6? export default <thing> seems a much more common paradigm than export default\n <thing>. I would be surprised if I was the only one to trip up on this syntax.

[jayphelps]

It may or may not be worth mentioning that TypeScript's WIP branch for ES6/decorators (demo'd for Angular 2.0) supports decorators before the export declaration. This doesn't appear to be inline with the outlined spec here, but just wanted to note real-world user assumptions.

@decorator export default class Foo {}

Everything else seems the same.

[rbuckton]

For TypeScript, we've been working with the idea that export and default are modifiers of the ClassDeclaration. As with static in ES6/TypeScript and public, private, protected in TypeScript, all decorators appear before all modifiers. Generally it also looks a bit cleaner if you have decorators on multiple lines in the class declaration:

@decorator
export class C {
  @decorator
  static method() {
  }
}

As opposed to:

export
@decorator
class C {
  @decorator
  static method() {
  }
}

[wycats]

@rbuckton the problem with that syntax is that it forecloses the ability to ever decorate exports themselves, no?

[rbuckton]

@wycats Wouldn't you instead be decorating the declaration that is being exported? I'd rather look into ways of qualifying a decorator in a future proposal. Something similar to how you can disambiguate attributes in C#. An example might be:

@module: moduleDecorator // decorator for module

@export: exportDecorator // decorator for export
@constructor: classDecorator // decorator for class (default)
@classDecorator // decorator for class (default)
export class C {

  @initializer: initializerDecorator // decorator for function of initializer
  @property: propertyDecorator // decorator for property (default)
  @propertyDecorator // decorator for property (default)
  property = 1;

  @return: returnDecorator // decorator for return
  @method: methodDecorator // decorator for function of method
  @property: propertyDecorator // decorator for property (default)
  @propertyDecorator; // decorator for property (default)
  method() {
  }

  @method: methodDecorator // decorator for function of get accessor
  @propertyDecorator // decorator for property (default)
  get accessor() {}

  @method: methodDecorator // decorator for function of set accessor
  set accessor(value) {}

  method2(
    @param: parameterDecorator // decorator for parameter (default)
    @parameterDecorator // decorator for parameter
    p) {
  }
}

Parsing decorator before export doesn't restrict us from future support to decorate exports.

[keithamus]

@wycats Maybe I'm misunderstanding, but decorating exports over classes sounds a bit like a footgun to me:

@foo
export default class Bar() {}

// lets say the above desugars to this in Node-land:
Bar = foo(module.exports = function Bar() {}) || Bar;

So my Bar class has been exported, and then the exports reference gets decorated - but outside of the assignment, meaning the foo() decorator hasn't applied to the exported class, but my reference internally is now the decorated one - so any work done on Bar after the export will not apply to the exported one, only the internal one.

[sebmck]

@keithamus That's not necessarily how it might work since the semantics for it haven't been invented yet. 😄 What @wycats said was that it's problematic to rush into adding additional syntax since it forecloses the ability to do something special with it in the future.