Hi Ozgur, Got some answers, let me quote the highlights:
Ward Bell said: > Nothing wrong with custom decorators _per se_. But take a peek at the > (new) AOT Metadata guide in the docs. You’ll see that decorators are NOT > listed as AOT-recognized syntax. Whatever is NOT listed is most likely not > supported. > That’s not a permanent condition. The recognized syntax is expanding over > time. But it is what it is. > The “good” news is that AOT restrictions only apply to code that the AOT > compiler must evaluate. It is possible that you could add these decorators > to an _exported base class_ and then have your component _extend that base > class_. I don’t know that this will work. It might. It worked in my mixin > experiments. Rob Wormald said: > They’re “fine” in the sense that you can use them and they work, but they > can cause issues with tree shaking, and the actual specification is still > in flux. > they are not stripped by default - Angular decorators (only) are > downleveled to static properties, non-special ones are left alone > NgRx, for example, uses them in a similar way to Angular - they don’t have > any real runtime behavior, theyre just annotations (“markers”) that > specific properties are special So, there you have it. You can use decorators, but there are some things you have to take into account. There is a good chance that in the future this feature will be supported fully. There is also a chance that support will get even worse due to technical limitations. It is a new thing, and the specs haven't settled in the dust yet. The price of being on the bleeding-edge ;) Regards Sander -- You received this message because you are subscribed to the Google Groups "Angular and AngularJS discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
