0
votes

When I use the code shown this dc.js doc

https://github.com/dc-js/dc.js/blob/master/web/docs/api-1.7.0.md#labellabelfunction

I get a different answer. Is the documentation wrong? For instance, when I use the trick to dump the data structure to the console:

.label(function(d){
            console.log(JSON.stringify(d));
            return d.key;
)};

I get:

{"key":"M16SDH","value":690}
{"key":"M16SP","value":886}
{"key":"M16SPS","value":704}

There is no "d.data" object, and therefore trying to compute the percentage this way does not work:

  // Simple pie chart to filter on type.
  var byTypeChart = dc.pieChart("#byTypeDiv");
  var byTypeDim   = ndx.dimension(function (d) { return (d.celltype == null?'na':d.celltype); });
  var byTypeGroup = byTypeDim.group();
  byTypeChart
     .width(200).height(200)
     .dimension(byTypeDim)
     .group(byTypeGroup)
     .label(function(d){
        return d.data.key + "(" + Math.floor(d.data.value / all.value() * 100) + "%)"; 
      })
     ;

The document says:

// label function has access to the standard d3 data binding and can get quite complicated

but I see:

TypeError: d.data is undefined
1
There are some inconsistencies in this area which will be fixed in the next version (and break everyone who's been working around them). You can just remove .data right? - Gordon
Yes d.key and d.value are in the object - user3089203
Alright I'm adding that as an answer. Whether you choose accept it is up to you. :-) - Gordon

1 Answers

0
votes

Yes.

The function is inconsistent, both with the documentation and with many of the other label functions.

The issue is here: https://github.com/dc-js/dc.js/issues/703

Follow the links on that issue to find similar discrepancies in other parameters.

The workaround here is obviously just to reference .key and .value directly.

dc.js has grown organically, more than being built with a consistent plan or vision. It was originally just a demo that grew and grew popularity, and there have been dozens and dozens of contributors.

I am not the original author but a maintainer. I have been focusing more on getting 2.0 out the door than cleaning up the interface. 2.0, still in beta, will keep a stable interface, and stay the same through 2.0.1 and on. 2.1 and 2.2 on will break the interface where it helps make it consistent or more powerful.

Pull requests are always welcome, especially with new or updated tests!