[charts] New HTML legend & styles

[JCQuintas]

NOTE: I'm currently duplicating logic between src/ChartsHtmlLegend and src/ChartsLegend.
The goal is to remove clutter. Eventually the original should be removed and the new one should take its place.

Testing code

    <ChartDataProvider
      height={300}
      width={300}
      series={[
        { type: 'line', label: 'Line 1', data: [10, 20] },
        { type: 'line', label: 'Line 2', data: [50, 40] },
        { type: 'bar', label: 'Bar 1', data: [10, 20] },
        { type: 'bar', label: 'Bar 2', data: [50, 40] },
        { type: 'scatter', label: 'Scatter 1', data: [{ id: 'A', x: 0, y: 0 }, { id: 'B', x: 1, y: 1 }] },
        { type: 'scatter', label: 'Scatter 2', data: [{ id: 'A2', x: 5, y: 1 }, { id: 'B2', x: 4, y: 1 }] },
        { type: 'pie', data: [{ id: 'A', value: 10 }, { id: 'B', value: 20 }] },
        { type: 'pie', data: [{ id: 'A2', value: 10 }, { id: 'B2', value: 20 }] },
      ]}
    >
      <ChartsSurface />
      <ChartsLegend />
    </ChartDataProvider>

[mui-bot]

Deploy preview: https://deploy-preview-15733--material-ui-x.netlify.app/

Updated pages:

• docs/data/charts/legend/legend.md

Generated by 🚫 dangerJS against c73083d

[JCQuintas]

@alexfauquette Do we still want to provide slots.legend?

For slotProps it makes sense, but if we want to say that composition is the main way to customise items it might be good to remove it as well 🤔

[alexfauquette]

Do we still want to provide slots.legend?

For me the main reason is "It's easier to be consistent than to explain edge cases". For each slot "xxx" we provide slots.xxx/slotProps.xxx. Would be surprising that we only provide the slotProps.

What would be the issue with providing a slots.legend? For me it could be done in a similar way than the slots.tooltip. A slot that get no prop and just allow user to pass the legend if it's the only thing they want to update

[JCQuintas]

@alexfauquette no specific reason, it was just a question that occurred to me 😅

I agree with your points 👍

[JCQuintas]

Do we still want to provide slots.legend?

For me the main reason is "It's easier to be consistent than to explain edge cases". For each slot "xxx" we provide slots.xxx/slotProps.xxx. Would be surprising that we only provide the slotProps.

What would be the issue with providing a slots.legend? For me it could be done in a similar way than the slots.tooltip. A slot that get no prop and just allow user to pass the legend if it's the only thing they want to update

I do think however, as we allow more customisation and hooks, we should drop slots/slotProps at one point, as it makes the code much more obnoxious than it needs be.

[alexfauquette]

I do think however, as we allow more customisation and hooks, we should drop slots/slotProps at one point, as it makes the code much more obnoxious than it needs be.

I still see some interest to it. For example you use color scale and then need a special legend. It's nice to still have something like this instead of being forced to go full composition.

<BarChart
	{...my config}
	slots={{ legend: ChartColorMapLegend }}
/>

But yes it's something we could consider during the next major. Depending on the users feedback

[codspeed-hq]

CodSpeed Performance Report

Merging #15733 will not alter performance

_{Comparing JCQuintas:html-default-legend (c73083d) with master (627ecf9)}

Summary

✅ 6 untouched benchmarks