In the previous article we have discussed about transitions and it’s uses. We have also seen that transition also work as animation. So, how much difference can we make in the visualization of the information using trasition? This will be the topic for this article.
So, let us go through the different features in the following.
Transitions Interpolate Values over Time:
Given start and end key frames, how do we get from here to there? To perform a smooth animated transition, D3 needs to know how to interpolate—or blend—from a given starting value to its corresponding ending value. The d3.interpolate method determines an appropriate interpolator by inferring a type for each pair of starting and ending values.
The same interpolation subsystem is used by D3’s quantitative scales. We can extend the set of built-in interpolators by adding to the d3.interpolators array. Or create a custom tween. The string interpolator is particularly useful. It finds numbers embedded within strings, pairing up numbers in the starting string with the corresponding number in the ending string. Those numbers are interpolated separately, and the resulting string is then reconstructed. String interpolators have myriad applications, such as interpolating path data (e.g., “M0,0L20,30″) and CSS font specifications (e.g., “300 12px/100% Helvetica”). ARCS require interpolation in polar coordinates so that the angles are interpolated, rather than the positions.
The Life of a Transition
As with concurrent programming, perhaps the trickest aspect of transitions is that they happen over time rather than instantaneously. The code does not proceed in a single straightforward path, as when the page loads, but as a complex sequence of recurring callbacks. We can safely ignore this complexity in many cases.
Transitions have a four-phase life cycle:
The transition is scheduled.
The transition starts.
The transition runs.
The transition ends.
This is a new feature in D3 3.0; older versions of D3 deferred computing ending values until the first timer tick after scheduling. A transition is scheduled when it is created: when we call selection.transition, we are scheduling a transition. This is also happens when attr, style, and other transition methods are called to define the ending key frame. Scheduling happens in code. Meaning that the code so far is fully synchronous. This makes it easier to debug, and easier to use ending values that depend on changing global state, such as a scale’s domain.
A transition starts based on its delay, which was specified when the transition was scheduled. If no delay was specified, then the transition starts as soon as possible, which is typically after a few milliseconds. The start event is then dispatched, and the transition initializes its tweens, which may involve retrieving starting values from the DOM and constructing interpolators. Deferring the initialization of tweens to start is necessary because starting values aren’t known until the transition starts.
A transition ends based on the sum of its delay and duration. When a transition ends, the tweens are invoked a final time with t = 1, and then the end event is dispatched.
In the above example we attempted a little difficult approach towards transition. In the above example we can see that although we have used svg for the rectangle , all the section are created by array and transitions are invoked through each array. It also has a starting point with a delay on it. And in the end the boxes not only changes place but increases in size, changes their color and style.