Decorators Status Update
Constraints Analysis Outcome
Decorators should be static (parse/initial-compile output is knowable)
Decorator polyfilling should not require cross-build-tool standardization
- Polyfilled decorators should work with native decorator syntax
- Decorators should handle several different use cases, at minimum:
- Decorating element access
- Decorating element initialization
Transformations which may add runtime overhead (e.g., turning data properties into accessors) should only be applied when semantically intended/useful
- Decorated values should be able to ship with a reasonable byte-size in the optimal format.
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:
Decorators Status Update 2020-07