chainable .data() function

[gordonwoodhull]

Originally, .data() was intended for pre-processing or filtering data. It takes a group and returns data in the same format as group.all().

However, this does not work if the chart uses .data() internally, because one will override the other.

So the current best way to do this is to create a fake group which wraps the group and implements .all() by fetching the data from the group and then returning its modified version of the data. This works fine and groups can be wrapped multiple times, but it's a bit confusing for new users, and it also looks like an ugly hack until you get used to it.

A simple solution would be to have an internal .data() and an external .data(), but this isn't very elegant and doesn't support the possibility that multiple levels of the chart might want to preprocess the data.

Better to figure out a way to chain them so that (I presume) the client processes the data first, then the base, then the children.

[gordonwoodhull]

Details: the following charts use .data() internally:

• Stack Mixin (thus Line and Bar) - filters and then does stack d3.layout.stack on the data
• Cap Mixin (thus Pie and Row) - optionally limits the number of bins, sorts the groups using the ordering, and optionally creates the "others" bin
• Number Chart - looks to see if the group has a value() function (e.g. it's a group-all). Otherwise, takes the top value. Runs the valueAccessor on the result (!!!)
• Box Plot - adds a mapping function to the data. Filters out values (which are themselves arrays) that are of length 0.

[clayheaton]

@gordonwoodhull Are you including the dataTable in these plans? It would be awesome to use .data() to filter for it. However, since it doesn't use the standard .group() is that going to work?

[gordonwoodhull]

@ccheaton, that's a a good suggestion and I opened #651 to track it. I've gotten requests for an option to call .bottom instead of .top and that would be a nice way to generalize it.

It's different from this one, however. This issue is that the existing feature .data doesn't work as advertised, at least in my opinion, because you end up breaking basic functionality if you try to supply your own data.

[gordonwoodhull]

An alternate solution is to build some kind of data pipelining library that makes "fake groups" easier to write and deals with chaining in a more elegant fashion.