By default, `append` will go to the end. This could cause the center line to be
rendered on top of the box rect if whiskers were removed then re-added. By using
the `insert` operator, we can preserve the correct order.
This is a utility for creating a Bézier curve between opposite corners of a
rectangle. This is commonly used to draw smooth curves connecting parent and
child nodes in a hierarchical node-link diagram. A projection may be specified
which allows the curve to be transformed from polar coordinates.
This commit also changes the semantics of the recently-added `links` method,
such that the objects have `source` and `target` properties that match the
default diagonal format.
This method can be used to generate an array of parent+child objects for a given
array of nodes. This is convenient for drawing paths from parent to child in
node-link diagrams.
The `cluster` layout is now more similar to the `tree` layout, using a
separation function rather than a group property. In addition, the breadth and
depth properties are replaced with x and y, respectively, and scaled according
to the size of the layout.
I've updated the examples to make them more consistent, as well, including the
pretty Bézier curves. In a future commit I'd like to take some of the duplicate
code in the examples and move that into reusable methods.
You can now use the `text` operator on transitions, which has the same effect as
setting the text value at the start of the transition. This is nice if you have
a delayed transition, and avoids a common gotcha.
This commit also simplifies the implementation of the `text` operator using the
standard `textContent` property. This isn't supported on IE8-, but we could
potentially add support in the future using `innerText`.
Preserving object constancy across transitions is tricky! For example, what
happens if we remove the whiskers in a transition? How do we join outliers? This
commit makes a few assumptions explicit:
1. The `quartiles` function must return exactly three elements. This property
must be specified as a function.
2. The `whiskers` function must return exactly 2 elements, or null if no
whiskers are to be displayed. This property must be specified as a function.
3. The `domain` function must return exactly 2 elements, or null if the default
domain should be used. This property can be specified either as a constant or as
a function.
We could generalize this chart to support more than two whiskers, but it doesn't
seem urgent, and it would complicate the transition if the number of whiskers
changes. In a related change, the `whiskers` function does not receive a third
argument containing the quartiles; instead, this is made available by the
`quartiles` property on the values array (the first argument).
The outliers are joined using the `Number` key function. The outlier data is now
stored as indices; this allows reasonable object constancy across transitions
with outliers. Similarly, the tick labels for the quartiles are whiskers are now
separated, such that the whisker labels can be added or removed without spurious
transition.
The outliers were being incorrectly excluded when computing the quartiles. I've
also added a +/-1.5 IQR whiskers computation for the Morley-Michelson example,
so it replicates the R plot exactly.
This specifies a function that takes the sorted data array, and returns an array
of datum positions that should marked with whiskers. The default implementation
is to return `[0, length-1]` i.e. the minimum and maximum.
Data outside of the whiskers are considered outliers, and are not included in
the quartile calculation.
The pack layout now sorts nodes by ascending value by default. The `radius`
property is removed, as the radius is always computed from the node value. The
`spacing` property is also removed; it doesn't seem particularly useful. The
`radius` property is renamed to `r` to match `x` and `y`.
I also optimized the implementation slightly, and namespaced temporary state
under the prefix `_pack_`.
Based on the Protovis version. The only difference is that I've dropped
the `orient`, `innerRadius` and `outerRadius` properties so that the D3
version is more flexible.
Based on the Protovis layout. I've kept the convention of using `size`
for the width/height and `separation` for the spacing. The Protovis
layout had a `size` property but this was used to compute the radius.
I've left this out as I've assumed it's straightforward enough to pass
in the appropriate `radius` function instead. Likewise, I think the
existing hierarchy `sort` property can handle situations that `order`
was intended for in the Protovis version.
Jason Davies
Mike Bostock
Nelson Minar