Release 2.0.0
Mike Bostock
2.0.0 - August 23, 2011
Enter and Update
The enter-update pattern has been simplified: the enter selection now
merges into the update selection when you append or insert. This new
approach reduces code duplication between enter and update. Rather
than applying operators to both the enter and update selection
separately, you can now apply them to the update selection after
entering the nodes.
For example, say you had a selection of circles and wanted to update
their radii. Previously you had to call the attr operator twice, once
for enter and once for update:
var circle = svg.selectAll("circle").data([data]);
circle.exit().remove();
circle.enter().append("svg:circle").attr("r", radius); // for enter
circle.attr("r", radius); // for update
In addition, if you wanted circle to refer to all the on-screen nodes
(enter ∪ update) subsequently, you'd have to reselect as well to merge
the enter and update selections:
circle = svg.selectAll("circle"); // reselect
In 2.0.0, you can eliminate this duplicate code because entering nodes
will add them to both the enter selection and the update selection
simultaneously. Running operators on the update selection after enter
will thus apply to both entering and updating nodes:
var circle = svg.selectAll("circle").data([data]);
circle.exit().remove();
circle.enter().append("svg:circle"); // adds enter to update
circle.attr("r", radius); // for enter and update
Note: in the rare case that you want to run operators only on the
updating nodes, you can run them on the update selection before
entering new nodes.
Selector Functions
The select and selectAll operators can now take selector functions, in
addition to selector strings such as "#id" and ".class". For example,
if you want to select the first child of every element, you can now
say:
var children = g.select(function() { return this.firstChild; });
This also means that selection can dynamic create new elements, or
reorder existing elements by re-inserting them into the DOM. This is
an advanced feature, but you might find it useful for extending D3.
For example, you could use XPath rather than selectors if you wanted.
Transparent Transitions
Transitions are now transparent arrays of elements, and you can
inspect them in the developer console just like selections. Each
selected element is wrapped in an object that stores the delay and
duration of the associated transition. (Recall that these values are
computed on a per-element basis for staggered animations.) Internally,
some of the timing logic that manages transitions has also been
simplified, improving performance and fixing a few timing bugs.
The each operator can now be called with one argument (a callback
function), offering compatibility with the selection's each operator.
Transitions now expose an id property, which can be useful for
debugging concurrent transitions; this identifier is inherited by
subtransitions, fixing a bug with nested transitions.
Custom Tweens
A new, generic tween operator has been added, which is used internally
by the other tweens (style, attr, etc.). You can use this operator
directly if you want to define a custom tween as part of the
transition; use this instead of listening for a transition "tick"
event. For example, the text operator does not interpolate by default,
but you can now interpolate text content by saying:
selection.transition().tween("text", function() {
var i = d3.interpolate(this.textContent, "yellow");
return function(t) {
this.textContent = i(t);
};
});
You might want to write your tweens as reusable functions (say,
closures) rather than the above example which hard-codes the
transition to "yellow". See the built-in attr and style tweens for
inspiration.
Axes
A new axis component has been added to the d3.svg module. The axis
component makes it easy to add reference lines, ticks and labels to
any visualization. This display of the axes is highly customizable,
and best of all, the axes support smooth transitions automatically.
See this quick demo of axes used by an area chart:
More documentation and examples for this component will be coming in
the new few days.
Extending and Overriding
Selection and transition are now defined using prototype injection
rather than direct extension. This improves performance and reduces
memory overhead, as the majority of methods are now defined on a
prototype rather than on each instance. Also, this makes the code
cleaner as each operator is fully separable and defined in its own
source file. This fixed a few bugs, such as the missing empty operator
on enter selections.
Prototype injection also means that selections and transitions can be
extended and customized! You can now override the behavior of D3's
core operators, or add your own. This may be particularly useful to
provide compatibility with nonstandard browsers, or proprietary
document object models. You can also use JavaScript's instanceof
operator to see whether an object is a d3.selection or d3.transition.
Tests
D3 now has an extensive test suite built with Vows. As of the 2.0.0
release, we have 1,200+ tests and 90% coverage of the core library.
More tests are under development. The tests are written to test the
behavior of each of D3's operators, and may be interesting to explore
if you have questions about how D3 works, complementing the API
reference.
Phrogz
> The enter-update pattern has been simplified: the enter selection now
> merges into the update selection when you append or insert.
Hilton Perantunes
Hilton William Ganzo Perantunes
--
Il y a loin de la coupe aux lèvres.
Benjamin West
-bewest
Mike Bostock
Sequenced transitions are now also easier to implement, thanks to the
transition's transition operator, which returns a copy of the current
transition. The copy inherits the delay, duration, id and easing of
the original transition. You can then modify the delay to sequence
multiple transitions, without needing to listen for the "end" event.
For example, here's how you would enter a circle, and then remove it
after a couple seconds:
svg.append("svg:circle")
.attr("r", 1e-6)
.transition()
.ease(Math.sqrt)
.attr("r", 4.5)
.transition()
.delay(2000)
.attr("r", 1e-6)
.remove();
You can also use this technique to use different easing functions for
different tweens! For example, you could use "cubic-in-out" easing for
position properties, and "linear" for color.
Mike
Jon Frost
lord,
just when I was starting to feel that I understood most of what D3 offers.
I think we just need someone to 2nd my old feature requests:
d3.time.scale.revert()
d3.time.scale.delay()
d3.time.scale.extender()
{:-) Really nice work.
Bixente
Bixente
Ricardo
improvement in the expressiveness of d3.
Chris Viau
Mike Bostock
> event if you want to chain them, no?
Correct. I didn't want to assume that the chained transition runs at
the end; you can use transition.transition() to create concurrent
transitions on the same elements as well. For example, you might delay
a transition on some attributes, or use different easing functions for
different attributes.
You don't need to use the "end" event to sequence transitions if you
bake the previous duration into the delay:
svg.append("svg:circle")
.attr("r", 10)
.transition()
.duration(1000)
.attr("r", 20)
.transition()
.delay(1000)
.attr("r", 40);
Note that you don't need to specify the duration twice because it's
inherited from the previous transition. If you wanted to do this
automatically, you could write a plugin that inherits the delay as the
previous transition's delay + duration, like so:
https://gist.github.com/1171371
Perhaps we could support this by saying .transition("end") rather than
.transition().
Mike
Chris Viau
Mike Bostock
Haha. Turns out, I'm just a proxy on top of Amazon's Mechanical Turk. ;)
Mike
Chris Viau
Davin
Jeff Bordogna
Mike Bostock
> converts its domain values to strings, which means that using
> dates in the domain now won't work.
Thanks for the report. I overlooked this use case; I was simply trying
to make the external behavior match the internal behavior, since in
order to determine uniqueness, the ordinal scale must coerce the
domain values to strings. However, perhaps it was overly aggressive to
coerce the domain types to strings; it seems reasonable to leave the
values as they are and merely rely on the toString behavior to
determine uniqueness. I'll fix this in the next release.
Mike
Ivan
Cheers,
Ivan
Davin
Davin
Mike Bostock
transition timing, to provide more consistent timing across elements.
This might also change the behavior for zero-duration transitions. The
current release is 2.0.4.
https://github.com/mbostock/d3/commit/4e96a35b6616f4d2a16199e9614368143888e434
One of the underlying changes in v2 is that each node now has a
separate timer when the transition starts. This improves performance
for variable-delay and variable-duration transitions, because now the
timers can stop when each node finishes, rather than sharing a single
timer than runs from min(start) to max(end).
Looking closely, I see another side-effect of simplifying the
transition logic in v2: it now takes at least two ticks to end a
zero-duration transition, whereas previously it took one tick. This is
because the transition starts after one tick, but we don't check to
see if the transition ends until the next tick; this probably explains
your stuttering. I think we could make a tiny change to transition.js
such that a tick is processed immediately on start, such that
zero-duration transitions end after a single tick. Something like
this:
if (!tick(elapsed)) d3.timer(tick, 0, then);
I'll see about including this in the next patch release (today-ish).
Regardless, you really shouldn't be using zero-duration transitions if
you want to avoid stuttering and/or care about performance. Even one
tick is bad, because it means that the browser redraws both before and
after the tick. One technique that I like is a method that optionally
derives a transition, or else returns the input selection:
function transition(selection, duration) {
return duration ? selection.transition().duration(duration) : selection;
}
You can see a similar technique in use in the new axis component:
https://github.com/mbostock/d3/blob/master/src/svg/axis.js#L95-100
Mike
Davin
Mike Bostock
https://github.com/mbostock/d3/compare/v2.0.0...v2.1.1
Mike
Jeff Bordogna
Davin
Davin
Mike Bostock
ease(1) is slightly less than 1, which is probably a bug.
I can't think of any other reason why the transitions wouldn't finish,
short of another transition taking precedence. Have you tried
listening to the "end" event and seeing if they are actually ending?
Mike