Is the dc.js documentation on .label function incorrect? - dc.js

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

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!

Related

Plottable.js entityNearest not giving me the nearest entity

Im implementing the code below in a React, Typescript project.
When hovering over my graph I don't get the nearest entity its roughly 5 years off, on my x-axis(time).
I've tried switching out entityNearest for entityNearestXThenY but it yielded similar results.
Below is my pointer interaction function:
new Plottable.Interactions.Pointer()
.attachTo(Chart)
.onPointerMove(function(p) {
var entity = hiddenGraph.entityNearest(p);
var date = parseTime(entity.datum.x);
var value = currencySymbolNoPrecision(entity.datum.y);
var displayValue = (value + " • " + date);
guideline.value(entity.datum.x);
xAxis.annotatedTicks([entity.datum.x]);
title.text(displayValue).yAlignment();
})
.onPointerExit(function() {
guideline.pixelPosition(-10);
xAxis.annotatedTicks([]);
});
Pointer tracking is also very jumpy. My dataset is the gold price per month since 1950. I've checked the dataset to ensure that there are no problems there.
In the image below my mouse is hovering roughly where the red circle is.
Please let me know if I can provide any further information.
I eventually reached a solution by directly editing the coordinates of the mouse after it had bean calculated:
.onPointerMove(p){
p={x: p.x-(compensationValue), y:p.y}
...
...
...
}
While I understand this is by far not the best solution to the problem I had, it has managed to resolve the problem and seemingly with no adverse effects on different screen sizes or when nesting components.

How to apply brushing on a dynamically growing dataset?

I have a dynamically growing timeseries I need to display in a zoomable/panable chart.
Try it out here (in fact: my first jsFiddle ever :) ) :
https://jsfiddle.net/Herkules001/L12k5zwx/29/
I tried to do it the same way as described here: https://dc-js.github.io/dc.js/examples/replacing-data.html
However, each time the chart updates, the zoom and filter are lost on the focus chart. (The brush is preserved on the range chart however.)
How can I add data without resetting the views and losing the zoom?
var chart = dc.lineChart("#test");
var zoom = dc.lineChart("#zoom");
//d3.csv("morley.csv", function(error, experiments) {
var experiments = d3.csvParse(d3.select('pre#data').text());
experiments.forEach(function(x) {
x.Speed = +x.Speed;
});
var ndx = crossfilter(experiments),
runDimension = ndx.dimension(function(d) {return +d.Run;}),
speedSumGroup = runDimension.group().reduceSum(function(d) {return d.Speed * d.Run / 1000;});
chart
.width(768)
.height(400)
.x(d3.scaleLinear().domain([6,20]))
.brushOn(false)
.yAxisLabel("This is the Y Axis!")
.dimension(runDimension)
.group(speedSumGroup)
.rangeChart(zoom);
zoom
.width(768)
.height(80)
.x(d3.scaleLinear().domain([6,20]))
.brushOn(true)
.yAxisLabel("")
.dimension(runDimension)
.group(speedSumGroup);
zoom.render();
chart.render();
var run = 21;
setInterval(
() => {
var chartfilter = chart.filters();
var zoomfilter = zoom.filters();
chart.filter(null);
zoom.filter(null);
ndx.add([{Expt: 6, Run: run++, Speed: 100 + 5 * run}]);
chart.x(d3.scaleLinear().domain([6,run]));
zoom.x(d3.scaleLinear().domain([6,run]));
chart.filter([chartfilter]);
zoom.filter([zoomfilter]);
chart.render();
zoom.render();
},
1000);
//});
In this case, if you are just adding data, you don't need to do the complicated clearing and restoring of filters demonstrated in the example you cited.
That part is only necessary because crossfilter.remove() originally would remove the data that matched the current filters. An awkward interface, almost never what you want.
If you're only adding data, you don't have to worry about any of that:
setInterval(
() => {
ndx.add([{Expt: 6, Run: run++, Speed: 5000 + 5 * run}]);
chart.redraw();
zoom.redraw();
},
5000);
Note that you'll get less flicker, and decent animated transitions, by using redraw instead of render. I also added evadeDomainFilter to avoid lines being clipped before the edge of the chart.
Fork of your fiddle
Removing data
If you use the predicate form of crossfilter.remove() you don't have to worry about saving and restoring filters:
ndx.remove(d => d.Run < run-20);
However, this does expose other bugs in dc.js. Seems like elasticY does not work, similar to what's described in this issue. And you get some weird animations.
Here's a demo with remove enabled.
In the end, dc.js has some pretty neat features, and there is usually a way to get it to do what you want, but it sure is quirky. It's a very complicated domain and in my experience you are going to find some of these quirks in any fully featured charting library.
Update: I fixed the replacing data example, that one is just ndx.remove(() => true) now.
zooming issues
As Joerg pointed out in the comments,
when the chart is not zoomed, it would be nice to have it also grow to show new data as it arrives
the X domain was clipped or even reversed if the focus reached outside the original domain of the chart
We can address these issues by adding a preRedraw event handler. That's the ideal place to adjust the domain; for example you can implement elasticX manually if you need to. (As you'll see in a second, we do!)
First, a naive attempt that's easy to understand:
chart.on('preRedraw', () => {
chart.elasticX(!zoom.filters().length);
});
We can turn elasticX on and off based on whether the range chart has an active filter.
This works and it's nice and simple, but why does the chart get so confused when you try to focus on a domain that wasn't in the original chart?
Welp, it records the original domain (source). So that it can restore to that domain if the focus is cleared, and also to stop you from zooming or panning past the edge of the graph.
But notice from the source link above that we have an escape hatch. It records the original domain when the X scale is set. So, instead of setting elasticX, we can calculate the extent of the data, set the domain of the scale, and tell the chart that the scale is new:
chart.on('preRedraw', () => {
if(!zoom.filters().length) {
var xExtent = d3.extent(speedSumGroup.all(), kv => kv.key);
chart.x(chart.x().domain(xExtent));
}
});
New fiddle with zooming issues fixed.
There is still one glitch which Joerg points out: if you are moving the brush while data comes in, the brush handles occasionally will occasionally stray from the ends of the brush. In my experience, these kinds of glitches are pretty common in D3 (and dynamic charting in general), because it's difficult to think about data changing during user interaction. It probably could be fixed inside the library (perhaps an interrupted transition?) but I'm not going to get into that here.

d3 typescript bindings: cannot read property 'ticks' of undefined

I'm having trouble figuring out the Typescript bindings for parts of d3. What I'm trying now:
private xScale: ScaleTime<number, number>;
private xAxis: Axis<Date | number | { valueOf(): number }>;
...
this.xScale = scaleTime()
.domain([new Date('2017-01-01'), new Date('2017-12-31')])
.range([0, 100]);
this.xAxis = axisBottom(this.xScale);
svg.append("g")
.attr("transform", "translate(50,50)")
.call(this.xAxis);
This gives me ERROR: TypeError: Cannot read property 'ticks' of undefined.
I shouldn't have to specify a tick configuration - the default is good enough to prove that it works - but doing so (either using ticks() or tickArguments()) didn't help.
The function axisBottom() is typed like this:
function axisBottom<Domain>(scale: AxisScale<Domain>): Axis<Domain>;
but I'm passing it a ScaleTime. I think that's what I must do, because that's what scaleTime() returns. ScaleTime objects do have a ticks() method (at least, one is specified in the interface).
I'm not sure how to connect all these objects. I'm persisting because I think it's worthwhile - d3 can be tricky to use, and maintaining type safety makes things much easier..
Versions of everything:
#types/d3: "^4.11.1",
#types/d3-selection-multi: "^1.0.6",
d3: "^4.11.0",
d3-selection-multi: "^1.0.1",
Sorry. I actually had the typescript bindings right. My problem was an error in the way I was using the Angular component lifecycle, which made it that the scale wasn't property initialized. Sorry for the noise...

D3.js Stacked Bar Chart Selects

I am trying to come to grips with some D3 concepts but feel as though there are some fundamentals gaps in my knowledge. It seems to do with how the D3 stack() function works.
I am trying to understand why the following two code snippets are not equivalent. The first works and populates data, the second does not.
First (Working Code, Simplified):
var mainStack = d3.stack().keys(keys);
var seriesData = mainStack(dataset[0]);
gBars = g.selectAll("g")
.data(seriesData, function (d, i) { return (i); })
.enter().append("g").. more work here
Second (Not Working, Simplifed):
var mainStack = d3.stack().keys(keys);
var seriesData = mainStack(dataset[0]);
gBars = g.selectAll("g")
.data(seriesData, function (d, i) { return (i); });
gBars.enter().append("g").. more work here
Basically, I have just tried to break up the code to make it simpler (for me) to read, and also to allow me to implement an exit() function. However, when i do the above, the graphs fail to display.
I thought that the gBar variables should maintain their previous selects?
Any assistance would be appreciated, I have successfully used this pattern for simple charts, hence my suspicion that this is related to something I am missing when the d3.stacked() function is involved which nests the data?
With some friendly help, I found that the difference is in the way v4 handles selects. The answer was to utilise merges to combine the various selects and then perform any combined updates on the merged nodes.
Eg:
var mainStack = d3.stack().keys(keys);
var seriesData = mainStack(dataset[0]);
var gBarsUpdate = g.selectAll("g")
.data(seriesData, function (d, i) { return (i); });
var gBarsEnter = gBarsUpdate.enter().append("g")
var gBars = gBarsEnter.merge(gBarsUpdate)
//now update combined with common attributes as required
gBars.attr("fill", "#ff0000"); //etc
Hope this helps anyone else a bit confused by this. Took me a bit of time to understand what was going on, but thanks to some smart people, they put me on the right track :-)
ps. My problem ended up having nothing to do with the stack() function.

Simple way to add raw data to dc.js composite chart via Ajax

I have a composite chart of 2 line charts however I need to add a third chart to it.
This third chart will have these unique properties:
The data will come in via an ajax call and be available as a two dimensional array [[timestamp,value],[timestamp,value]...]
Every new ajax call needs to replace the values of the previous one
It does not need to respect any of the filters and will not be used on any other charts
It will however need to use a differently scaled Y axis.. (and labeled so on the right)
This is how the chart currently looks with only two of the charts
This is my code with the start of a third line graph... Assuming I have the array of new data available i'm at a little loss of the best/simplest way to handle this.
timeChart
.width(width).height(width*.333)
.dimension(dim)
.renderHorizontalGridLines(true)
.x(d3.time.scale().domain([minDate,maxDate]))
.xUnits(d3.time.months)
.elasticY(true)
.brushOn(true)
.legend(dc.legend().x(60).y(10).itemHeight(13).gap(5))
.yAxisLabel(displayName)
.compose([
dc.lineChart(timeChart)
.colors(['blue'])
.group(metric, "actual" + displayName)
.valueAccessor (d) -> d.value.avg
.interpolate('basis-open')
.dimension(dim),
dc.lineChart(timeChart)
.colors(['red'])
.group(metric, "Normal " + displayName)
.valueAccessor (d) -> d.value.avg_avg
.interpolate('basis-open'),
dc.lineChart(timeChart)
.colors(['#666'])
.y()#This needs to be scaled and labeled on the right side of the chart
.group() #I just want to feed a simple array of values into here
])
Also side note: I've noticed what I might be a small bug with the legend rendering. As you can see in the legend both have the same label but i've used different strings in the second .group() argument.
I believe you are asking a few questions here. I will try to answer the main question: how do you add data to a dc chart.
I created an example here: http://jsfiddle.net/djmartin_umich/qBr7y/
In this example I simply add random data to the crossfilter, though this could easily be adapted to pull data from the server:
function AddData(){
var q = Math.floor(Math.random() * 6) + 1;
currDate = currDate.add('month', 1);
cf.add( [{date: currDate.clone().toDate(), quantity: q}]);
$("#log").append(q + ", ");
}
I call this method once a second. Once it completes, I reset the x domain and redraw the chart.
window.setInterval(function(){
AddData();
lineChart.x(d3.time.scale().domain([startDate, currDate]));
dc.redrawAll();
}, 1000);
I recommend trying to get this working in isolation before trying to add the complexity of multiple y-axis scales.
Currently your best bet is to create a fake group. Really the .data method on the charts is supposed to do this, but it doesn't work for charts that derive from the stack mixin.
https://github.com/dc-js/dc.js/wiki/FAQ#filter-the-data-before-its-charted

Resources