Hi Sander
Thank a lot for your posts and seeking answers to our issue. Much
appreciated.
There was a mention of _exported base class_ in Ward Bell's answer. We are
actually doing this and it works pretty good. We even have a BaseClass
which is extended by BaseComponent and each of our Angular Components
extend this BaseComponent. What made us look into and start using custom
decorators was the idea to define 'view change animations' in our
BaseComponent and not worry about it at all again. Our very simple
animation used to work in the following way (for each Component):
@Component({
moduleId: module.id,
templateUrl: 'someComponent.html',
host: {
'[@routeAnimation]': 'true',
'[style.display]': "'block'"
},
animations: [
trigger('routeAnimation', [
state('*',
style({
opacity: 1,
transform: 'translateX(0)'
})
),
transition('void => *', [
style({
opacity: 0,
transform: 'translateX(-100%)'
}),
animate('0.3s ease-in')
]),
transition('* => void', [
animate('0.3s ease-out', style({
opacity: 0,
transform: 'translateY(100%)'
}))
])
])
]
})
export class SomeComponent extends BaseComponent { ... }
We have found that by using @HostBinding on our BaseComponent we can take
care of the 'host' section in the @Component metadata but couldn't find a
way to do the same for 'animations' section. So, with the use of a custom
decorator like the one below, we have achieved what we wanted to do:
export function CustomComponentDecorator(_props) {
_props = Object.assign({}, defaultComponentProps, _props);
_props.animations = [...]
_props.host = {
'[@routeAnimation]': 'true',
'[style.display]': "'block'"
};
Object.setPrototypeOf(_props, DecoratorFactory);
return function (cls) {
Reflect.defineMetadata('annotations', [_props], cls);
}
}
But now we can't AOT which means we will not use custom decorators as AOT
and tree-shaking is essential for performance. I have shared all this with
the hope you or someone can help with our original requirement which is
avoid having the host and animations sections at each component and somehow
centralise it in one place and if/when we want to change it, we change it
in that one place. (We had actually managed to encapsulate the 'animations'
array to an exported function which is better of course but we couldn't do
the same trick with the 'host' section)
If anyone has any answers/thoughts/guidance it will be much appreciated.
Thanks
Oz
On Saturday, 19 August 2017 07:39:09 UTC+1, Sander Elias wrote:
>
> 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.
