Define an interface for Legends

[kum-deepak]

Currently, legend instance call functions in the chart instance. This works, however, it is inconsistent. Sometimes the chart instance is accessed as the _parent and sometimes as chart member in the legendable. Usually, these are the same unless it is a Composite Chart. This is likely to cause inconsistent or sub-optimal behavior for legends in Composite Charts.

In addition, the code that checks if an entry is currently selected is quite fragile (https://github.com/dc-js/dc.js/blob/develop/src/charts/legend.js#L233).

We can explore if any alternate way of structuring is likely to give better code structuring.

[kum-deepak]

The current interface between a chart and legend is as follows:

// What Legend expects from the chart
export interface ParentOfLegend {
    legendToggle: (d: LegendSpecs) => void;
    legendReset: (d: LegendSpecs) => void;
    legendHighlight: (d: LegendSpecs) => void;
    filters; // function, TODO: signature
    legendables: () => LegendSpecs[];

    svg (): Selection<SVGElement, any, any, any>;
}

// Chart passes an array to the Legend
export interface LegendSpecs {
    name: string;
    data?;
    chart: ParentOfLegend;
    color?: string;
    dashstyle?;
}

export type LegendTextAccessor = (d: LegendSpecs) => string;

It is quite tightly coupled. In my opinion there should be no calls from the Legend onto the Chart. I see the following two basic approaches:

• All callbacks are passed as part of LegendSpecs for each entry. This will give easier code for charts like Composites that share the same Legend across multiple child charts.
• The Legend uses d3.dispatch and fires events that can be subscribed to by the chart.

Additional notes:

• Filters should not be accessed by the Legend, it causes fragile code. All state information related to each legend entry including highlight state should be passed as part of LegendSpecs.
• The legend entries should be set by the chart before invoking render. This is not a usual dc pattern. So, alternatively, we can pass a function (Entries provider) that will return the required data.
• The root element (svg) for the Legend should be passed as an option to the Legend.

[gordonwoodhull]

The legend needs filters, legendables, and svg in order to draw and update its display of the selection. A simple alternative would be to pass all this data to .render() - making it less like a chart, but currently a legend is not much like a chart.

Making the legend into a chart is another way to decouple it - but among other things, you'd need shared selections like in #682. (I think you and I discussed this recently.)

Using d3.dispatch for legendHighlight, legendReset, legendToggle makes sense to me. Those are just sugar for mouseover, mouseout, click, except the interesting special case for composite charts that you mention, where it goes to the child chart.

dc.js/src/charts/legend.js

Lines 222 to 230 in 82469c9

	.on('mouseover', d => {
	this._parent.legendHighlight(d);
	})
	.on('mouseout', d => {
	this._parent.legendReset(d);
	})
	.on('click', d => {
	d.chart.legendToggle(d);
	});

[kum-deepak]

I hope you had good holidays.

I will do a sample PR and see which one looks better 😄