allow stackMixin.stack(...).stack(...) instead of .group(...).stack(...)

[gordonwoodhull]

It will be easier to generate stacks programmatically, and more consistent, if the first call to .stack can function as a call to .group.

It looks like .group mostly calls .stack anyway.

[gordonwoodhull]

(I don't know that this is possible, but it's worth looking at.)

[r4j4h]

I agree. It is a little odd having stacked charts start with the first stack spread over group and valueAccessor calls and then the rest are each under one stack call.

I am afraid of the law of leaky abstractions though. I'm not sure about this, but if we have stack calls automagically do group and valueAccessor calls under the hood if they have not already done, then might people experience different behavior depending on the order of their calls? What I mean is that right now it is at least explicit as to what is going on in comparison to other charts.

I think if we document this behavior well enough it should be okay. I wonder if it would be better if when you try to call group or valueAccessor on a stack chart then it yells at you and tells you to use stack instead? The weird case then is when someone is using it and NOT stacking, they have to use stack for their "one" stack. Sounds odd but it makes sense when you think about it. But I think this would affect any chart that uses the mixin, so then normal bar charts would require Stack? Hmmm... maybe not.

[gordonwoodhull]

That problem already exists: group acts as a reset, so it can't be called after stack.

I'd rather not break existing code if possible. And the mixins are not really mixins but base classes; you can't mix and match them. So a bar or line chart with only one series is still a stacked chart.

So, as muddled as it is, I'd rather enable the totally-dynamic case and leave everything else as it is, if possible.

Anyway, this it's for 2.1 so there is time to think about it. Don't want to risk breaking anything in 2.0.

dc.js is one big leaky abstraction over d3; this was an intentional choice by the original author Nick Zhu. There is almost always a way around it to customize anything that needs customizing.

[r4j4h]

Yeah, and I love that flexibility! It provides quite a nice base to work off of. I am hoping to provide some patches towards things like optional axes ( #548 ) but with the holidays here free time will be sparse for me for the next couple weeks.

With the points you mentioned taken into consideration, I am in full agreement. 👍

[d2a-raudenaerde]

Yes ,+1 .stack().stack() (with the first stack() acting as group() would be great, because I'm always special casing the first now. :D

[r4j4h]

Was looking over some old code and it made me think of this bandaid to help in the meantime if you are looping over some construct to stack on a chart.

Assuming i is your iteration variable:

var stackFcn = ( i == 0 ? _chart.group : _chart.stack );
stackFcn.call(_chart, grpInUse, 'stack_' + i, function(d) { return d.value.stacks[ i ].value; } );

The key being the use of stackFcn as a variable to hold the two versions, unifying with .call to work on both.