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#