Ambient Decorators

[colin-jack]

I think ambient decorators could be extremely useful in enabling declarative APIs (as attributes do in .NET).

For example if I was using a framework like koa/express I'd like to be able to specify information about my functions that the framework could use to configure its understanding of the HTTP resources:

   @@url("...")
   @@schema({ id: ..., body: .. })
   put: function*(id, body)
   {
      ...
   }

So here I'd see @@url and @@Schema as providing additional meta-data that the framework could pick out and use when configuring itself.

[yuchi]

You can do that already. What’s missing from the current proposal that’s stopping you from doing what you’re saying?

[colin-jack]

Do you mean whats to stop me reflecting to find out what ambient decorators have been applied to a function?

[yuchi]

A decorator is just a function which operates either on the prototype of the class or the class itself for static methods/props. You can set new properties up, reimplement the method. I mean, a lot of crazy stuff.

What would an ambient decorator do that a simple function applied to an object or class’ prototype cannot?

[colin-jack]

Get you, and agree on decorators but from what I could see ambient decorators idea mentioned at end and in TypeScript were more like .NET attributes (though for what I am suggesting ambient decorators would need to be in the final JS).

Ok so what can I do, well that put function above is in say a config object. During system startup I would go through all the properties on the object and reflect on their metadata (ambient decorators). If I find the @@put and @@url ambient decorators on the function I would know enough to register the function with express/koa so I would go ahead and do that.

At runtime when that put function is called, the one accepting id and body, the ambient decorators would be irrelevant, they either don't run or are no-ops.

I realise that you don't need metadata for things like this, there are other approaches with JS as is, but to me the ambient decorator approach can be cleaner and can also aid tooling support.

[yuchi]

Ok. There's something similar going on on liferay/metaljs repo. To do what you want you can either

1. Completely replace the underlying method with a wrapper
2. Add metadata on the class and then use that metadata to wrap your functions.

Different approaches with different drawbacks.

[silkentrance]

@colin-jack Custom ambient decorators require babel to parse external code. And, if that code got already transpiled, these ambient decorators would no longer be available. As such, so-called ambient decorators cannot be made possible with the current babel implementation.

As such, a reference implementation of a transpiler that would support ambient decorators would need to have access to all the non-transpiled sources one imports a/o requires.

And the same is true for typescript. See microsoft/TypeScript#2900 which is still under discussion.

[silkentrance]

It seems that the typescript compiler will generate additional files that will allow itself and the IDE to infer meta data from the sources where the babel transpiler cannot. And since this behavior is not part of this spec, I think that this can be closed for the time being until the spec, if ever, will cover such behavior.