mbostock
commented
8 years ago Maybe part of the answer is distinguishing between “higher level” and “lower level” operators. The curves, for instance, are considered low-level and do not have accessors: the x and y values are passed as-is.
This confusion seems evident in the quadtree from D3 3.x: there used to be a static d3.geom.quadtree(points) method which would just compute the quadtree from an array of [x, y] points, but then it was replaced with a d3.geom.quadtree() constructor for a quadtree generator, which you could then customize with x- and y-accessors before invoking.
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.