d3v4 cleanup

Hi @kum-deepak!

As promised, I’m doing a thorough line-by line review of #1363 d3v4 support.

Rather than comment inline on a PR that has already been merged, I decided to start a new issue.

I think I have gotten through about 1/3 of the changes, and I’m learning a lot along the way!

Here are my comments so far. I’m going to go for a Saturday walk now. 😃

global changes

“selection”

The argument name selection is confusing for fadeDeselectedArea/brushIsEmpty/extendBrush / scatterPlot.brushIsEmpty scatterPlot._brushing because it sounds like it should be a d3 selection. Personally I would use the term filter or extent here.

I guess this arose because of event.selection from Brush Events so maybe brushSelection would be a good compromise. Kind of confusing that they reused such a common term.

composite chart

rightYAxis documentation: “depending on whether you are going to use the axis on left or right” doesn’t make sense, as it should always be d3.axisRight. I guess this was copied from coordinateGridMixin.yAxis but it’s different.

coordinate grid mixin

xUnitCount

This function now distinguishes dc.units.ordinal but it doesn’t need to because calling the function would have exactly the same effect. I’d rather not add the special case unless it’s necessary for some reason? The design of xUnits functions is perhaps a bit strange but it is generic.

If this really needs to be then it should at least use chart.isOrdinal().

prepareXAxis

I agree that we need to use d3.scaleBand instead of d3.scaleOrdinal – it’s so much cleaner! – but it will confuse users if their input .x() scale is changed. We should issue a warning every time we make the replacement so users can update their code accordingly.

prepareYAxis

       // Ideally we should update the API so that if someone uses Right Y Axis
       // they would need to pass _yAxis as well
       if (!_yAxis) {
           if (_useRightYAxis) {
                _yAxis = d3.axisRight();
            } else {
                _yAxis = d3.axisLeft();
            }
         }

I respectfully disagree with the comment - it’s really nice how the axes are automatically initialized and I think we should be able to extend that to the right axis.

This code will never get hit because _yAxis is initialized and the user would never set it to undefined or null.

Could we start with _yAxis null and initialize it like we’re doing here, when

• this function is hit, or
• when .yAxis() is called as a getter?

I think this would safely initialize it to axisLeft or axisRight automatically, and it would be nice not to default it wrong. The only way it might go wrong is if the user called .yAxis() before calling .useRightAxis(true) but I doubt anyone would do that.

Also, I know it was already there in the original, but I find

        _yAxis = _yAxis.scale(_y);

really confusing. .scale() is an ordinary setter which modifies the axis.

[Fil]

I’ve tried to use it in @observablehq with d3v5, and it sort of works, but some styling is off. Also I could’t require("dc"), I had to load it through bundle.run.

But other than that, it looks good. https://beta.observablehq.com/@fil/hello-dc-js

Congratulations! And what an achievement!

[gordonwoodhull]

Thanks @Fil!

Yes, we’ll have to iterate on it. I’m new to ES6 modules so I’m not surprised that we need to configure the module better. It’s still just straight old UMD.

As for styling, I see two problems. One, the cell heights are too short, at least on my iPad. That is perhaps a CSS problem.

Two, you need to set xUnits in order to get the bar widths right. I wish dc.js could figure that out automatically, but it can’t currently.

Yes, it was a huge amount of work, mostly by @kum-deepak. I’m really impressed that he figured this all out, and happy dc.js will live on for another few years!