Flow: Implement flow for decorators (method decorators)

[aight8]

Decorators are heavily used. Currently you can disable warning, but there is zero flow support for function signature of the decorator arguments.
There are other experimental functions in flow already which are handled correctly though.

So decorator argument and return type - typing support would be basic and nice.

If flow could handle value remapping - it were be even better. Since the return type (Attributes) can be predicted, it can be static analysed.

function decoratorA(target: Object, prop: string, attributes: PropertyAttributes) {
   // ... set value or getter, setter...
   // PropertyAttributes
   // value: any
   // set(any)
   // get(): any

   attributes.value 

   // must return a new attributes object because attributes is already PropertyAttributes and it cannot be altered
   return {
      value: function(a: string, b: boolean) {
         return true;
      }, // flow analyse the type as: (a: string, b: string) => boolean
      // set this signature as the new signature for the method
      // follow up decorators now receives this type
      // example: PropertyAttributes<valueType, getterType, setterType>

      // get/set for property decorator
   }
}

class A {
   @decoratorA // new signature: ()
   function() {
      return 123;
   }
}

Especially if you call the instance method from outside, it should show the correct signature (last set PropertyDescriptor)

So I wondering this is possible with the current flow source code or if there some bricks?!

[apsavin]

Are there any estimations? Can we expect that flow will understand semantic of decorators soon?

[jedwards1211]

I'm really wishing flow supported decorators so that I could use TypeORM without TypeScript and still get complete type checking.

[jwaldrip]

This is one of the most frustrating things with flow. Decorators are used in many libraries yet flow limits us and forces into repeating code... Would love an update sometime soon.

[ericketts]

another day another gap in the utility of flow, sigh.. wish I had the time to properly learn ocaml as I'd really like to see this working. at least I got a chuckle out of the documentation still noting

The default value of this option is warn, which gives a warning on use since this proposal is still very early-stage

[eggyal]

https://github.com/facebook/flow/issues/3405#issuecomment-431251007:

another day another gap in the utility of flow, sigh.. wish I had the time to properly learn ocaml as I'd really like to see this working. at least I got a chuckle out of the documentation still noting

It's not even clear to me how decorators _can_ be implemented in OCaml, since they will need to be _evaluated_ in order to determine their effect on the decorated expression (which obviously requires a JavaScript interpreter!). So is a JavaScript interpreter going to be built in OCaml, or is Flow going to depend on an external JavaScript interpeter (perhaps Node.js) for evaluating decorators?

Makes one wonder whether Flow ought to be rewritten in JavaScript (yikes, although that could actually help to spur more community involvement in its development in the long term...).

BUT, with respect to decorators, it seems to me that there's an even more fundamental issue for any static type checker like Flow: the decorator's behaviour might depend on runtime conditions, which it will not be possible to determine in advance! For example, imagine a class decorator that adds a field only if Math.random() < 0.5 (not that I'd recommend doing such a thing, but it is conceivable)—how can a static type checker ever determine whether the field exists on that class?

[asazernik]

It's not even clear to me how decorators _can_ be implemented in OCaml, since they will need to be _evaluated_ in order to determine their effect on the decorated expression (which obviously requires a JavaScript interpreter!). So is a JavaScript interpreter going to be built in OCaml, or is Flow going to depend on an external JavaScript interpeter (perhaps Node.js) for evaluating decorators?

Flow does not need to evaluate the javascript, just parse it and manipulate the AST; decorators can be typechecked by using the syntactic transformation (for the common react-redux case):

@connect(mapStateToProps)
class Blah extends Component<ExplicitProps & ReactReduxProps> {}

// equivalent to
const Blah = connect(
  mapStateToProps
)(class extends Component<ExplicitProps & ReactReduxProps> {})

[eggyal]

@asazernik: The decorators proposal goes much further, enabling one to manipulate descriptors—see their article Metaprogramming with decorators.

Whilst one could (as you propose) treat such decorators as mere syntactic sugar, and thus simply expand them within the AST, such approach would not enable Flow to discover how the arising manipulations upon the relevant descriptors have effected the underlying object. Fields/methods may have been added/removed from a class, or their types/signatures may have changed.

[jedwards1211]

@eggyal isn't it up to the developer to just add the appropriate type parameters, input, and output types of the decorator in that case?

[asazernik]

Reading through that article, it seems to directly contradict actual implementations (babel as a transpiler, and assorted libraries like redux, redux-form, react-router). Specifically when it comes to class decorators:

@foo(param)
class Bar {
}

All existing implementations have the original constructor passed to the decorator, which then returns its own new constructor; i.e. they act like the syntactic transformation I described above. The article, though, claims that the decorator will be passed a "class descriptor" that looks like:

{
  kind: "class"
  elements: Array of all class elements
}

The latter isn't just an extension; it's incompatible with existing usage.

If I'm misreading the proposal and this is referring to decorators in another position, then could Flow just support the simple decorating-a-class-declaration case without worrying about the similar-looking decorator variations that are allowed to do weird metaprogramming stuff?

If I'm not misreading the proposal, and it is actually proposing functionality that's directly incompatible with existing code, could Flow run typechecking on the language that is actually out in the wild rather than in the proposal process?

[asazernik]

Aaaaaaah. The new decorators proposal is actually backwards-incompatible with the earlier stage proposal on this issue, and doesn't have the stripped-down, easier-to-type variant available. Uf.