Decorators Status Update

Chris Garrett

2020-07

Constraints Analysis Outcome

  1. Decorators should be static (parse/initial-compile output is knowable)

  2. Decorator polyfilling should not require cross-build-tool standardization

  3. Polyfilled decorators should work with native decorator syntax
  4. Decorators should handle several different use cases, at minimum:
    • Metadata
    • Decorating element access
    • Decorating element initialization

  5. Transformations which may add runtime overhead (e.g., turning data properties into accessors) should only be applied when semantically intended/useful

  6. Decorated values should be able to ship with a reasonable byte-size in the optimal format.

Main Constraints

Current Conclusion: There is no solution that satisfies all of these constraints.

"Decorators should be static" means either:

  • They cannot be compatible with polyfills, which will necessarily be dynamic (constraint 3), OR
  • They can only do one thing (e.g. can add metadata, but not intercept access) (constraints 4 + 5)

Currently the decorators group is exploring solutions which do not solve all of the constraints, including:

  • Definition static designs, which would require downleveling for polyfills
  • Designs which would not be static and would be more minimal, like the original TS/stage 1 decorators designs.

Constraint Analysis Google Doc:

https://docs.google.com/document/d/1DSuLlEbAjBImDutX_rhjnA6821EUyj9rANzDVJS3QV0/edit#