Animations features often are scary goals for developers. And Angular’s doctrine
“… controllers should not directly modify DOM elements!”
made Animation features intimidating as hell. But Angular animations are not scary! Templates are closely associated/integrated with
@Component. We will notice that animations following a similar pattern.
Let’s build a component that hides and shows its contents, uses fade animation effects, and allows external components to easily trigger those fade effects.
Here is a simple Angular component with hide and show features. This sample, however, does not have animations (yet):
This component simply publishes an
@Input() isVisible property; which allows other external components to show/hide the text content… without any animations.
Enable Animations Module
Since Angular 4.x, there’s a new module
BrowserAnimationsModule that introduces all animation capabilities. That’s why we first have add that to our application module’s
imports like this:
Once that is done, we can use any kind of animation API in our application. If we want to use animation function like
state(), we need to import them also from
'@angular/platform-browser/animations' instead of
Configure Component Animations
We want the
my-fader component to fade-in or fade-out its text content. And we want to animate those fades effects.
To start animating, let’s first add animation metadata to our component.
Above we show that the
animations metadata property is defined in the
@Component decorator. Just like
template metadata property!
Since our component has a
visibility property whose state can change between
hidden, let’s configure animations to trigger and animate during each value change.
Before we add more metadata, let’s talk about the syntax above. What does it mean… and why is this syntax used?
The techno-speak above is saying that when the
visibilityChanged property changes and the value
== shown, then the target element opacity changes to 1. And when the value changes to
== hidden, the target element opacity should change to 0.
[@visibilityChanged]binding is on
<div>child content element in the
<my-fader>component. It is NOT on the
<my-fader>element itself. In other words, the animation target in our example is actually the
<div>element; not the component host element.
Now, you might also wonder where
visibilityChanged comes from? Because our component property is just called
visibility. Hold your wild horses Mr. StageCoach, we’ll clarify that soon!” Let’s first talk about animation durations.
We want to animate these changes over a time duration instead of instantly hiding/showing the content. We need to configure a transition to specify animation durations. With Angular this is also suprisingly easy:
With the above
transition, we added information to the animation configuration so each trigger value change will have a 500 msec transition.
So a fade-in (opacity 0 -> 1, with a duration of 500 msec) will occur when the value changes from
shown. And likewise the fade-out (opacity 1 -> 0, with a duration of 500 msec) will occur when the value changes from
hidden. By the way, you could also have used
animate('500ms') to indicate the millsecond duration explicitly.
And what does the
transition('* => *', ...) mean? Think of
* => * as a transition from one state to another state; where
* is a wildcard to mean any state value. If we wanted the fade-out to be slower than the fade-in, here is how we would configure the animation metadata:
See how easy this is? This notation is so easy to understand.
The Essential Concept
The essential take-away Animation concept is that Angular Animations are triggered on component state changes. And developers should consider state changes to be equivalent to value changes in a property of the component instance.
Linking Animation to the Component
While we configured the Animation metadata, I am sure you are wondering:
- How is the animation property
visibilityChangedactually connected to the component?
- How are the animations linked to the component’s properties?
Since data-binding features are already supported between the component and its template, Angular uses a special template animation syntax to support triggering the animation after data-binding changes. So in the component template, we can do this:
@visibilityChanged is the special template animation property and it uses databinding
[@visibilityChanged]=“visibility” to bind the component’s visibility property to the animation trigger property
Here is the entire component definition updated with Animation features:
What if - instead of the using the extra
visibility property - you just wanted to use the
isVisible property directly? This would obviate
ngOnChanges() and reduce the code complexity to:
I love the tersity of this code. But this will not work without another important change to the animation metadata!
Remember that the
@visibilityChangedanimation trigger property has defined states for the values:
If you use the
myFader::isVisible boolean property, then your animation state values must be changed to
false since those are the possible values of the
Extra Bonus: The demo has some extra features. The host
my-faderelement now has a purple background; when you hide the
my-fadercontent children you will see the host background. This change was added so you can visually see the differences between the host and the target animation elements.
Our Animation Workflow
Above we have an improved the component definition; enhanced with animation features. Here is a workflow of the [animation] process:
- the input value for
- the template databinding updates the
- the animation trigger is invoked,
@visibilityChangedvalue is used to identify the state animations and transitions, and
- the target element opacity (and other properties) change-animates for xxx msecs
One of the design goals for Angular Animations is to make it easy for developers to configure and use animations. The API and syntax is designed to be:
- declarative and
- immediately associated with the component using metadata
The best part of Angular Animation design is that the component->template->animation binding solution decouples the animation from the component internals and uses the template as the binding bridge.
The developer decides which component properties should bind to which animation triggers, then simply uses the possible component property values to set the animation state values accordingly.
All the mechanics of preparing and managing the animations are hidden from the developer. This ‘separation of concerns’ provides HUGE benefits to allow developers to easily use Angular Animations with custom architectures & custom implementations.
Animations with Components Hierarchies
Components should never be concerned with the details regarding animation of child components. Parent components can monitor and alter the public state of child components, but should never attempt to modify the internals of those components.
In our examples (above), parent components can simply change the state of the child
my-fader instances and then magically the contents of the
my-fader instance will fadeIn or fadeOut.
The Angular Animation engine and compiler does all the hard work preparing, managing, and running the animations. Developers use the
@Component metadata to declaratively define the component styles, templates, and [now] animations. And it is the component template that serves as the bridge to link the component instance state to the animation trigger property.
Kudos to Matias Niemelä for the amazing Animation engine in Angular!
These core animation features [discussed above] are available in the Angular 2.0.0 release. And never fear, Matias and his team are working hard on more amazing, intuitive Animation features. So stay tuned for even MORE cool features and blogs coming soon!
Angular Master Class at Shopware
Join our upcoming public training!Get a ticket →
Get updates on new articles and trainings.
Join over 1400 other developers who get our content first.
Component-Relative Paths in Angular
Component-relative enable developers to more easily create maintainable, reusable, portable components in Angular. Here's how!
RxJS Master Class and courseware updates
If you've been following us for a while, you're quite aware that we're always striving to provide up-to-date and high-quality...
Advanced caching with RxJS
When building web applications, performance should always be a top priority. One very efficient way to optimize the performance of...
Custom Overlays with Angular's CDK - Part 2
In this follow-up post we demonstrate how to use Angular's CDK to build a custom overlay that looks and feels...
Custom Overlays with Angular's CDK
The Angular Material CDK provides us with tools to build awesome and high-quality Angular components without adopting the Material Design...
Easy Dialogs with Angular Material
Building modals and dialogs isn't easy - if we do it ourselves. Angular Material comes with a powerful dialog service...