- CSS animation workflow
- Code technique: Separate styling from logic
- Code technique: Organize sequenced animations
- Code technique: Package your effects
- Design techniques
- Wrapping up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Code technique: Organize sequenced animations
Velocity has a small add-on plugin called the UI pack (get it at VelocityJS.org/#uiPack). It enhances Velocity with features that greatly improve the UI animation workflow. Many of the techniques in this chapter, including the one discussed below, make use of it.
To install the UI pack, simply include a <script> tag for it after Velocity and before the ending </body> tag of your page:
<script src="velocity.js"></script> <script src="velocity.ui.js"></script>
The specific UI pack feature discussed in this section is called sequence running. It will forever change your animation workflow. It is the solution to messily nested animation code.
Standard approach
Without the UI pack, the standard approach to consecutively animating separate elements is as follows:
// Animate element1 followed by element2 followed by element3
$element1.velocity({ translateX: 100, opacity: 1 }, 1000, function() {
$element2.velocity({ translateX: 200, opacity: 1 }, 1000, function() {
$element3.velocity({ translateX: 300, opacity: 1 }, 1000);
});
});
Don’t let this simple example fool you: in real-world production code, animation sequences include many more properties, many more options, and many more levels of nesting than are demonstrated here. Code like this most commonly appears in loading sequences (when a page or a subsection first loads in) that consist of multiple elements animating into place.
Note that the code shown above is different from chaining multiple animations onto the same element, which is hassle-free and doesn’t require nesting:
// Chain multiple animations onto the same element
$element1
.velocity({ translateX: 100 })
.velocity({ translateY: 100 })
.velocity({ translateZ: 100 });
So what’s wrong with first code sample (the one with different elements)? Here are the main issues:
- The code bloats horizontally very quickly with each level of nesting, making it increasingly difficult to modify the code within your IDE.
- You can’t easily rearrange the order of calls in the overall sequence (doing so requires very delicate copying and pasting).
- You can’t easily indicate that certain calls should run parallel to one another. Let’s say that halfway through the overall sequence you want two images to slide into view from different origin points. When coding this in, it wouldn’t be obvious how to nest animations that occur after this parallel mini-sequence such that the overall sequence doesn’t become even more difficult to maintain than it already is.
Optimized approach
Before you learn about the beautiful solution to this ugly problem, it’s important to understand two simple features of Velocity. First, know that Velocity accepts multiple argument syntaxes: the most common, when Velocity is invoked on a jQuery element object (like all the code examples shown so far), consists of a properties object followed by an options object:
// The argument syntax used thus far
$element.velocity({ opacity: 1, top: "50px" }, { duration: 1000, easing: "linear" });
An alternative syntax pairs with Velocity’s utility function, which is the fancy name given to animating elements using the base Velocity object instead of chaining off of a jQuery element object. Here’s what animating off the base Velocity object looks like:
// Velocity registers itself on jQuery's $ object, which you leverage here
$.Velocity({ e: $element, p: { opacity: 1, scale: 1 }, o: { duration: 1000, easing: "linear" } });
As shown above, this alternative syntax consists of passing Velocity a single object that contains member objects that map to each of the standard Velocity arguments (elements, properties, and options). For the sake of brevity, the member object names are truncated to the first letter of their associated objects (e for elements, p for properties, and o for options).
Further, note that you’re now passing the target element in as an argument to Velocity since you’re no longer invoking Velocity directly on the element. The net effect is exactly the same as the syntax you used earlier.
As you can see, the new syntax isn’t much bulkier, but it’s equally—if not more—expressive. Armed with this new syntax, you’re ready to learn how the UI pack’s sequence-running feature works: you simply create an array of Velocity calls, with each call defined using the single-object syntax just demonstrated. You then pass the entire array into a special Velocity function that fires the sequence’s calls successively. When one Velocity call is completed, the next runs—even if the individual calls are targeting different elements:
// Create the array of Velocity calls
var loadingSequence = [
{ e: $element1, p: { translateX: 100, opacity: 1 }, o: { duration: 1000 } },
{ e: $element2, p: { translateX: 200, opacity: 1 }, o: { duration: 1000 } },
{ e: $element3, p: { translateX: 300, opacity: 1 }, o: { duration: 1000 } }
];
// Pass the array into $.Velocity.RunSequence to kick off the sequence
$.Velocity.RunSequence(loadingSequence);
The benefits here are clear:
- You can easily reorder animations in the overall sequence without fear of breaking nested code.
- You can quickly eyeball the difference between properties and options objects across the calls.
- Your code is highly legible and expressive to others.
If you combine this technique with the previous technique (turning CSS classes into JavaScript objects), your animation code starts to look remarkably elegant:
$.Velocity.RunSequence([
{ e: $element1, p: { translateX: 100, opacity: 1 }, o: slideIn.o },
{ e: $element2, p: { translateX: 200, opacity: 1 }, o: slideIn.o },
{ e: $element3, p: { translateX: 300, opacity: 1 }, o: slideIn.o }
]);
Expressiveness and maintainability aren’t the only benefits to sequence running: you also gain the ability to run individual calls in parallel using a special sequenceQueue option which, when set to false, forces the associated call to run parallel to the call that came before it. This lets you have multiple elements animate into view simultaneously, giving a single Velocity sequence the power to intricately control timing that would normally have to be orchestrated through messy callback nesting. Refer to the inlined comments below for details:
$.Velocity.RunSequence([
{ elements: $element1, properties: { translateX: 100 }, options: { duration: 1000 } },
// The following call will start at the same time as the first call since it uses the `sequenceQueue: false` option
{ elements: $element2, properties: { translateX: 200 }, options: { duration: 1000, sequenceQueue: false },
// As normal, the call below will run once the second call has completed
{ elements: $element3, properties: { translateX: 300 }, options: { duration: 1000 }
];