d3/test/core/transition-test-selectAll.js

59 строки
2.1 KiB
JavaScript
Исходник Обычный вид История

2011-08-22 04:36:24 +04:00
require("../env");
var assert = require("assert");
module.exports = {
topic: function() {
var s = d3.select("body").append("div").selectAll("div")
.data(["one", "two", "three", "four"])
.enter().append("div")
.attr("class", String);
s.filter(function(d, i) { return i > 0; }).append("span");
s.filter(function(d, i) { return i > 1; }).append("span");
s[0][3] = null;
return s.transition()
.delay(function(d, i) { return i * 13; })
.duration(function(d, i) { return i * 21; });
},
"selects all matching elements": function(transition) {
var t = transition.selectAll("span");
Transition reselection. It is now possible to reselect elements with scheduled transitions and redefine associated tweens; this enables "post-selection" to customize the behavior of reusable components undergoing transitions, such as an axis. This commit also makes it much easier to sequence transitions. Previously, a transition's tweens were stored privately by the transition and could only be accessed through the transition. This made it impossible to modify transitions created by components: the transition is not accessible externally, and cannot be reselected from the document. Consider the following snippet: g.select(".x.axis") .call(xAxis) .selectAll("text") .attr("dy", null); If `g` is a selection, then this code alters the appearance of the axis as expected. However, if `g` is a transition, then transition.selectAll creates a new concurrent transition, and now multiple tweens compete to set the "dy" attribute. Oy! Under the new design, an element's scheduled tweens are stored semi-privately on the node (in the existing node.__transition__). Transition parameters can thus be reselected and modified by transitions that share the same id. If you now reselect a transitioning element, you modify the transition rather creating a competing transition; this should be less surprising and allow greater control. As a side-effect of this change, it is no longer possible to schedule concurrent transitions on the same element, even with the same id: only one transition may be active on a given element at any time. (Note that you can still schedule multiple future transitions on the same element, and concurrent transitions on different elements.) For example, you could previously schedule overlapping transitions with different easing functions, delays or durations, provided you were careful to avoid conflict. This seems like a relatively obscure use-case compared to modifying a transition, so I believe this is a reasonable change. This commit also changes transition.transition, such that the returned transition starts at the end of the originating transition, rather than overlapping. This makes it much easier to schedule sequenced transitions without the complexity of transition.each("end") and d3.select(this). Also, transitions are now simply arrays of nodes, consistent with selections!
2012-10-05 23:00:16 +04:00
assert.domEqual(t[1][0].parentNode, transition[0][1]);
assert.domEqual(t[2][0].parentNode, transition[0][2]);
assert.domEqual(t[2][1].parentNode, transition[0][2]);
2011-08-22 04:36:24 +04:00
},
"ignores null elements": function(transition) {
var t = transition.selectAll("span");
assert.equal(t.length, 3);
},
"propagates delay to the selected elements": function(transition) {
var t = transition.selectAll("span");
Transition reselection. It is now possible to reselect elements with scheduled transitions and redefine associated tweens; this enables "post-selection" to customize the behavior of reusable components undergoing transitions, such as an axis. This commit also makes it much easier to sequence transitions. Previously, a transition's tweens were stored privately by the transition and could only be accessed through the transition. This made it impossible to modify transitions created by components: the transition is not accessible externally, and cannot be reselected from the document. Consider the following snippet: g.select(".x.axis") .call(xAxis) .selectAll("text") .attr("dy", null); If `g` is a selection, then this code alters the appearance of the axis as expected. However, if `g` is a transition, then transition.selectAll creates a new concurrent transition, and now multiple tweens compete to set the "dy" attribute. Oy! Under the new design, an element's scheduled tweens are stored semi-privately on the node (in the existing node.__transition__). Transition parameters can thus be reselected and modified by transitions that share the same id. If you now reselect a transitioning element, you modify the transition rather creating a competing transition; this should be less surprising and allow greater control. As a side-effect of this change, it is no longer possible to schedule concurrent transitions on the same element, even with the same id: only one transition may be active on a given element at any time. (Note that you can still schedule multiple future transitions on the same element, and concurrent transitions on different elements.) For example, you could previously schedule overlapping transitions with different easing functions, delays or durations, provided you were careful to avoid conflict. This seems like a relatively obscure use-case compared to modifying a transition, so I believe this is a reasonable change. This commit also changes transition.transition, such that the returned transition starts at the end of the originating transition, rather than overlapping. This makes it much easier to schedule sequenced transitions without the complexity of transition.each("end") and d3.select(this). Also, transitions are now simply arrays of nodes, consistent with selections!
2012-10-05 23:00:16 +04:00
assert.domEqual(t[1][0].__transition__[t.id].delay, 13);
assert.domEqual(t[2][0].__transition__[t.id].delay, 26);
assert.domEqual(t[2][1].__transition__[t.id].delay, 26);
2011-08-22 04:36:24 +04:00
},
"propagates duration to the selected elements": function(transition) {
var t = transition.selectAll("span");
Transition reselection. It is now possible to reselect elements with scheduled transitions and redefine associated tweens; this enables "post-selection" to customize the behavior of reusable components undergoing transitions, such as an axis. This commit also makes it much easier to sequence transitions. Previously, a transition's tweens were stored privately by the transition and could only be accessed through the transition. This made it impossible to modify transitions created by components: the transition is not accessible externally, and cannot be reselected from the document. Consider the following snippet: g.select(".x.axis") .call(xAxis) .selectAll("text") .attr("dy", null); If `g` is a selection, then this code alters the appearance of the axis as expected. However, if `g` is a transition, then transition.selectAll creates a new concurrent transition, and now multiple tweens compete to set the "dy" attribute. Oy! Under the new design, an element's scheduled tweens are stored semi-privately on the node (in the existing node.__transition__). Transition parameters can thus be reselected and modified by transitions that share the same id. If you now reselect a transitioning element, you modify the transition rather creating a competing transition; this should be less surprising and allow greater control. As a side-effect of this change, it is no longer possible to schedule concurrent transitions on the same element, even with the same id: only one transition may be active on a given element at any time. (Note that you can still schedule multiple future transitions on the same element, and concurrent transitions on different elements.) For example, you could previously schedule overlapping transitions with different easing functions, delays or durations, provided you were careful to avoid conflict. This seems like a relatively obscure use-case compared to modifying a transition, so I believe this is a reasonable change. This commit also changes transition.transition, such that the returned transition starts at the end of the originating transition, rather than overlapping. This makes it much easier to schedule sequenced transitions without the complexity of transition.each("end") and d3.select(this). Also, transitions are now simply arrays of nodes, consistent with selections!
2012-10-05 23:00:16 +04:00
assert.domEqual(t[1][0].__transition__[t.id].duration, 21);
assert.domEqual(t[2][0].__transition__[t.id].duration, 42);
assert.domEqual(t[2][1].__transition__[t.id].duration, 42);
2011-08-22 04:36:24 +04:00
},
"returns empty if no match is found": function(transition) {
var t = transition.selectAll("span");
assert.isEmpty(t[0]);
2011-08-22 07:34:22 +04:00
},
"inherits transition id": function(transition) {
var id = transition.id,
t0 = transition.selectAll("span"),
t1 = transition.selectAll("span");
assert.equal(t0.id, id);
assert.equal(t1.id, id);
},
"groups are not instances of NodeList": function(transition) {
var t = transition.selectAll(function() { return this.getElementsByClassName("span"); });
assert.isFalse(t[0] instanceof window.NodeList);
2011-08-22 04:36:24 +04:00
}
};