3 ms·
It's not the same decorators that existed before that were added. They don't have the same features. The new one are based on the upcoming EcmaScript decorator
by simlevesque 4y ago
It's not the same decorators that existed before that were added.
They don't have the same features. The new one are based on the upcoming EcmaScript decorators.
- WorldMaker 4y agoAlso, Angular relies on parts of the "experimental" decorators that these Stage 3 decorators do not support, so Angular likely will continue to use the "experimental" compiler flag for some time to come, with the added twist that some uses of decorators will now also compile without the flag but will exhibit different behavior and won't run correctly, which may cause all sorts of new headaches for Angular developers.
- spiralx 4y agoI just posted this in our FE channel at work > Note that the ECMAScript decorator spec now supported in TS 5 doesn't support decorating method arguments, unlike the experimental decorators TS has had an that Angular uses e.g. @Inject, @Self, @Optional etc. I'm guessing that this is part of the motivation behind the inject() function, where you can pass flags to it as a second argument to support cases like self or optional - it gives them a path to moving to the new-style decorators in the long-term. AFAIK argument decorators are only used for constructors, and that usage can be replaced by using inject() with flags, so a migration would be possible even today - although I'm sure there would be plenty of as-yet uncovered subtle implementation quirks! The obvious headache TS 5 will introduce is that failing to follow a decorator name with () will now attempt to treat e.g. Inject as a new-style decorator and cause a type error of some kind, which is likely to be confusing. I'm guessing the Angular compiler will have to do something to manage this, even if it's just ensuring there's a useful error message.