Reproducing A Clever Animation Product, Part 17

In the interest of making these writings fit with my schedule today and tomorrow I’m going to take a brief detour and describe the next change before completing the one that’s in progress. This will also cover something I’ll be making use of tomorrow. Looking at the current transform definitions in the addTransformToList calls: can see a term for the type of transform as the fourth parameter in each call. In most cases the value is “linear,” which is supposed to mean that the transformation takes place in equal increments across its duration. The value doesn’t matter for transforms that are instantaneous, like those where the display property changes from, say, “block” to “none.” In other cases, which I haven’t developed in this series of posts but which I have implemented in parts, the transition may be nonlinear. It may move at a constant speed over most of the duration of the transform but them slow down towards the end, thus “easing” into place. The tool I’m emulating does this by default. In other cases the element may vibrate around a point, with the initial direction of movement being one way or another (left vs. right, up vs. down…). In other cases the vertical velocity may be modified by a form of “gravity” which slows the upward speed and then increases the downward speed. Other types are possible.

The Greensock demo I referenced yesterday doesn’t do anything special in this respect, so the function parameter can usually be omitted. “Linear” or nothing can be assumed, unless something special is needed, and then a string or object literal can be included that provides the necessary information. In the meantime I’m going to move the parameter to be the fifth (and currently last) parameter in the function call, so the updated code will look like this:

It turns out that if a given parameter in a function call is not provided in JavaScript that the interpreter will define the item’s type as “undefined” in a way that can be tested for as follows:

Here I’ve swapped the order of the method and adjustment parameters. I also now test the type of both parameters. If the parameter is present I interpret and use it as appropriate and if the parameter is not present I give it a default value that covers most of the cases. Here are how the resultant function calls might look:

At root some pretty complicated animation behaviors can be defined with minimal expression in user code. The code needed to support this in the background isn’t trivial, but the idea is for me to do as much work as possible so the user of the tool doesn’t have to. I do it once (in theory) and a bunch of people then get to save all their time.

This entry was posted in Tools and methods and tagged , , , . Bookmark the permalink.

Leave a Reply