Maybe it should be more like transition.ease parameters, where you might say line.interpolate("cardinal", 0.5). Note this means that line.interpolate() should return the interpolation function, then…

It’s quite likely we actually want to call this a radial link (shape) and put it in the d3-hierarchy module, since this shape is typically used to represent links in hierarchical visualizations.

I’m not 100% sure this belongs as a curve (or as a data transformation), but it seems like a reasonable place to put it. In theory if you used a smooth curve, the input data array to the line or area generator wouldn’t even need to be sorted by x-value: the smoother could buffer all the points and then compute the smooth curve on lineEnd.

The current definition obliterates the constructor property.

• Linear
• Radial
• Basis
• BasisClosed
• BasisOpen
• Bundle
• Cardinal
• CardinalClosed
• CardinalOpen
• CatmullRom
• CatmullRomClosed
• CatmullRomOpen
• LinearClosed
• MonotoneX
• MonotoneY
• Natural
• Step

I just noticed that passing a string to specify a symbol type doesn't work anymore in d3 v4.

import { symbol } from 'd3-shape';

let theSymbol = symbol().type('diamond');
console.log(theSymbol());

Results in the following error:

d3-shape.js?77ca:733 Uncaught TypeError: type.apply(...).draw is not a function

Was this intentional? If so, it'd be great if the docs for v4 stated so. :-)

I can workaround this by passing in the appropriate symbol object from the symbols folder (https://github.com/d3/d3-shape/tree/master/src/symbol)

But having some kind of string mapping like in the old code would be great! (https://github.com/mbostock/d3/blob/master/src/svg/symbol.js)

I love the work you're doing on d3 v4 by the way, I'm finding it really easy to use without selections in a React app I'm building.

Related d3/d3#2385.

The current definition does not propagate the prototype to the factory method, so instanceof d3.curveLinear and the like do not work.

• Linear
• Radial
• Basis
• BasisClosed
• BasisOpen
• Bundle
• Cardinal
• CardinalClosed
• CardinalOpen
• CatmullRom
• CatmullRomClosed
• CatmullRomOpen
• LinearClosed
• MonotoneX
• MonotoneY
• Natural
• Step

For consistency with d3/d3-ease@f0ea8b5 (though the ease.ease part was later reverted) and d3/d3-interpolate@70ebb63, curves should also use named parameters rather than binding optional parameters in line.curve and area.curve. Specifically, code like this:

var line = d3.line().curve(d3.curveCardinal, 0.5);

Should be replaced with:

var line = d3.line().curve(d3.curveCardinal.tension(0.5));

I’d like to add Catmull–Rom spline interpolation, in particular the uniform (α = 0), centripetal (α = 0.5) and chordal (α = 1) variants. Note that interpolate("catmull-rom", 0) would be equivalent to interpolate("cardinal", 0), since both result in a uniform Catmull–Rom spline.

See also On the Parameterization of Catmull–Rom Curves by Yuksel et al.

I think it is best suited for this repo given its close relationship with the arc shape.

Related #49.

Most of the embedded images link to static images rather than live code examples, and the few that are live code examples use the 3.x API. It’d be nice to have some standalone examples of just d3-shape, even if that means making simpler examples that don’t use other D3 features (such as axes and selections).

• A diagonal cross (saltire)? Or “times” or “ex”? Rename “cross” to “plus”?
• Left- and right- pointing triangles?
• Make the diamond square? Separate from “thin diamond” or “rhombus”?
• An asterisk? Double cross?
• A (five-pointed) star?
• A default “triangle” (alias for triangleUp)?

The pie layout benefits significantly from accessors because the returned objects retain their links to the original data, so you can then bind these objects to the DOM, use them to render arcs, and then access other fields to apply other encodings (e.g., color). This argument applies to any layout.

But what about shapes? Shapes don’t return objects: they render them, either to a 2D context or by returning a path data string. If there’s no returned object, there’s no concept of retaining the association with the input data.

So, should arc, line, area et al. use accessors? It certainly feels more convenient than using array.map. And it’s probably more efficient since you don’t need to materialize the copies (especially now that line and area stream). But in other cases, like the new hull in d3-polygon, it seemed superfluous to retain the x- and y-accessors. After all, we don’t support x- and y-accessors for computing polygon area or centroid, so why do that for the hulls? On the other hand, because of the benefit of retaining association with input data, it is useful to have accessors for computing a Voronoi diagram.

I guess it’d be nice to articulate some guidelines about what things should have accessors, and why.

Seems like it could fit in this repo.

Just a heads up that the project isn't available in the npm registry.

This:

a -= halfPi, this._curve.point(r * Math.cos(a), r * Math.sin(a));

Could be this:

this._curve.point(r * Math.sin(a), r * -Math.cos(a));

This might not be a great fit with the new stream interpolators since it requires knowing the first and last point: it won’t be able to output anything until the line is ended, and so the points must be buffered.

Steps:

1. Load up d3-shape in a webpage to test it
2. Try something from the tests
3. See an unuseful error message:

d3_shape.line().curve(d3_shape.basisOpen)([[0,0], [0,10]])
d3-shape.v0.2.js:1024 Uncaught TypeError: Cannot read property 'path' of undefined(…)

(It would also be awesome if there were bl.ocks samples for the images provided in the documentation, it seems quite hard to figure out how to generate them at the moment?)

We don’t currently have a way of passing in a custom interpolator. The problem is the old API uses string concatenation, whereas the new API streams to an output context (which may buffer to a string internally, or not).

For properties that we allow to be defined either as constants or as functions (such as area.y0), we currently maintain the passed-in value for the accessor, even though the code internally always uses a function.

Is it right to do this? Or should we always promote (box) constant values to functions, and then just return the function from the accessor? Taking the later approach is similar to type coercion: we’re effectively coercing a constant value to a function (that returns this constant value). Then area.y0() would always return a function, even if it was set to a constant.

Certainly we should be consistent (and document whatever we decide to do), but I don’t see that we must preserve the passed-in value. Note that this decision should apply to other D3 modules that provide similar APIs, such as layouts.

In cases where an accessor is invoked only once, I think it still needs to propagate the this context and additional arguments. This is to maximize compatibility with selection methods (such as selection.attr), in case you want to customize the behavior of the generator using, say, parent data or indices. For example, in the arc shape, when we compute the innerRadius and outerRadius, we shouldn’t assume that the only arguments are d and i.

In contrast, if the accessor is evaluated multiple times, then we should apply the convention from d3-arrays and array.forEach, namely d, i and array. So that should be used for line.x, line.y, line.defined, etc.

Hi,

I think the main config of package.json has a problem. The main used to CommonJS export, and this main is contain the umd package. Than, It is hard to load d3 modules on required which could make the application package smaller.

That is react-router config. It is distinguishing the umd/ lib/ and es6/, and it could be provided three kinds export methods.

So "main": "build/d3-shape.js", "jsnext:main": "index",
to "main": "lib/index", "jsnext:main": "es6/index",

It could be compatibled with normal CommonJS export and es6/es2015 export, and umd file could be exported to npmcdn or other cdn.

Shape loop all the data. Can it provide an API that specifying a range? ex:

area(data, 5000, 6000);

From d3/d3#2832: if the y-value is NaN, we can still extend the line using the previous x-value. But we’d have to make sure that it’s symmetric for x and y rather than only supporting undefined y. This would be an alternative to using line.defined and area.defined for missing data.

Presumably we’d only want to extend the previous value for a single data point, however? Like if you get two points in a row with NaN y, you’d want to extend a horizontal line from the previous x to the first x with undefined y, but not the second x.

d3-shape examples at bl.ocks.org are blurry

It can be easily fixed by using getRetinaRatio() from this block: http://bl.ocks.org/devgru/a9428ebd6e11353785f2

For example:

As suggested in https://twitter.com/edouard_lopez/status/682140701707010048.

It might be interesting to think about a better default for stack.keys, too. The current default (empty) is safe, but perhaps this usage pattern suggests a different default expectation for the data and keys.

It’s just dividing a range proportionally by value. It happens that the default range is [0, τ], but you could also use the pie generator to compute normalized stacked bars, for example. Related #7.

We fixed #18 in 93fba29, but we should add the -open and -closed variants, too.

Do you have any plan to support line generator of data which is sorted by y-value ?

Currently we use strict equality on the specified values. This makes sense for constants, but it seems a bit surprising if the x0 and x1 accessor are specified as functions.

Perhaps we should have a more explicit way of specifying when the baseline (x0 or y0) reuses the topline (x1 or x1, respectively) value? Perhaps this is what the value null should signify?

(Related #23, especially if we auto-promote constants to functions, in which case the same value won’t result in the same function, and we’ll evaluate the function twice; although, since the function returns a constant value, this won’t do any harm.)

http://bl.ocks.org/mbostock/9bd540de6728a1fb9343

It’s quite likely we actually want to call this a link (shape) and put it in the d3-hierarchy module, since this shape is typically used to represent links in hierarchical visualizations.