Rather than computing the ending value when the transition starts, the ending
value is computed when the transition is scheduled. This gives more predictable
behavior and makes it easier to debug evaluation errors since they occur
immediately (during user code) rather than inside a d3_timer callback.
The behavior of attrTween and styleTween are unchanged, since the interpolator
can only be constructed once the starting value is known. This commit also
removes d3.tween; I may add this back in a future commit, but I think there is
probably a better way to specify an interpolator for transitions.
This commit moves easing and event listeners down to the node's transition
object, allowing these fields to be modified via post-selection. This removes
the last vestige of private state for transitions.
This required a few changes to tests that depended on the order of callbacks for
tweens and events. Because timers are called back in reverse order, tweens are
now initialized in reverse order, and listeners are now invoked in order.
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!
Note: the previous commit broke some tests relating to locale date
parsing, due to expecting "%m/%d/%y". On my system, the "en_US" locale
uses "%m/%d/%Y" by default. I've updated the tests to use %Y.
This avoids having to include a large number of locales in the D3
repository, and also reduces the potential for typos when transcribing
locale mappings.
You can now build a locale-specific version of d3.time.format. For example,
LANG=fr_FR make
will pull strings from the time/format-fr_FR.js file, rather than en_US.
The previous implementation had a bug where the original index (i) was not
preserved if the input data array were split. The new implementation eschews the
previous approach of branching based on whether the x- and y-properties are
defined as functions or constants, opting for the simpler functor approach. The
x- and y-values are also coerced to numbers, as appropriate.
This fixes a crash with the symbol type "hasOwnProperty", rather than defaulting
to "circle". This commit also adds new map methods to retrieve the keys, values
and entries. The map class now uses non-enumerable properties (if supported).
This is, essentially, an ES6 shim for a Harmony Map. We will use it instead of
using a bare object, so that we don't need to worry about collision with built-
in properties names (such as "__proto__" and "hasOwnProperty").
This commit provides a standard interface for time intervals:
interval.floor(date)
interval.ceil(date)
interval.offset(date, k)
interval.range(start, stop, step)
All local-time intervals (such as d3.time.day) have a UTC-equivalent interval,
available as interval.utc (such as d3.time.day.utc).
Fixes#463. Note that for the time.scale, an interval function is required to
nice (such as d3.time.day). In the future, we might relax that to allow a count
of ticks, similar to the ticks method, but in that case we'd also need the
ability to floor to a given tick number (e.g., every other week) and likewise
for ceil. This seems like a reasonable first implementation.
Rather than having two implementations for local time and UTC time, we now have
a single local-time implementation and use d3_time_utc to adapt for UTC.
Rather than producing separate files for each module, the default build now
produces a single file. This should encourage better page-load performance as
the files were relatively small. Also, it's easier to deal with only one file
rather than many, especially if you're not quite sure what the dependencies are.
You may still create minimized builds, if you don't want every feature.
This commit also demotes the chart components to the examples directory, rather
than keeping them as part of the core library. As always, D3 is not a charting
library, and these were ever only intended to serve as examples.
This includes a d3.extent convenience method for [d3.min, d3.max], and fixes the
brush component such that the resizers are hidden when the extent is empty.
You can now query the brush for its selection. This commit also includes a new
d3.random.normal for generating random numbers with a normal distribution. This
is useful for jittering points for display.
The d3.svg.brush component allows one- or two-dimensional rectangular brushing.
A future commit will allow the brushed region to be resized by grabbing an edge,
and also provide some way of reporting the selection (duh)!
Due to the ordering in which the prototypes are defined, it was still undefined!
Also, the empty method depends on the node method being defined. Added a test.
Quote from NEWS file:
In previous versions of make it was acceptable to list one or more explicit
targets followed by one or more pattern targets in the same rule and it
worked "as expected". However, this was not documented as acceptable and if
you listed any explicit targets AFTER the pattern targets, the entire rule
would be mis-parsed. This release removes this ability completely: make
will generate an error message if you mix explicit and pattern targets in
the same rule.
There is also a greatCircle as an alias, whose angle defaults to 90 degrees. (Or
should, but some projections cannot handle 90 degrees so we use 89 instead.)
The greatArc class is the new name for greatCircle, which actually represents
great arcs. Meanwhile, a new greatCircle class is for great circles. The new
greatCircle class replaces the old clip class, providing clipping and resampling
functionality (using greatArc internally). This isn't backwards-compatible, but
I may forgo the major version number bump in light of the fact that greatCircle
was just added, and not used in any (official) examples or documented.
Note that the Werner projection is a special case with standard parallel
at 90°N, and the Sinusoidal projection is also a special case with
standard parallel at 0°N.
This can be used with d3.geo.path.clip to clip the input coordinates of
geographical shapes using a given origin and angular radius, e.g. for
hemispherical or near-hemispherical views. Geodesics are inserted as
necessary.
This also includes a minor bugfix and test for d3.geo.path: the last
coordinate of Polygon features was being included unnecessarily
(MultiPolygon already handled this correctly).
IE9 does not string-coerce values, instead throwing an error. We now wrap IE9's
implementation to force string coercion. While it would be simpler to turn on
string-coercion for all browsers inside D3's style operator, this approach
avoids penalizing standards-compliant browsers.
This commit also moves language-compatibility code to a separate directory, and
deletes the obsolete Object.create polyfill, which is no longer needed by D3.
Can be used to generate great circle paths. Similar to R's
geosphere.gcIntermediate (in which I discovered a bug, while writing the
test case for this!)
Includes d3.geo.greatcircle().distance for computing the shortest geo
path distance using the Haversine formula.
For a tutorial on using great circles, see:
http://flowingdata.com/2011/05/11/how-to-map-connections-with-great-circles/
This fixes a breakage on IE9, which doesn't support array subclassing through
prototype injection. On IE9, we then use direct extension of the prototype, but
this can only be done after the prototype is fully-defined.
This also fixes a few bugs in the new implementation, restoring support for the
offset between the mouse and the dragged element by reporting a delta rather
than an absolute offset. Also, this fixes an infinite loop when an element is
removed from the DOM.
I'm including the axis component in the core build because it should be useful
in many different visualization types, similar to the other svg components. The
chart module contains a hodgepodge of more obscure visualization types, and
there's no reason to pull those in for more common visualizations. Perhaps most
importantly, the axis component isn't a chart type!