[charts] Base the highlight items on the item identifiers

[alexfauquette]

Previously, highlight was based on seriesId+dataIndex except for the sankey that got a dedicated highlight plugin

Previously

In dedicated PR we moved to get

• [charts] Remove default generic of item identifiers #21182
• [charts] Make Highlight scope a generic #21189

So from those PR the highlight scope depends on the series type.

In this PR

• All series define their own way to decide if an item is highlighted or not in their seriesConfig
• HighlightItemData is replaced by the SeriesItemIdentifier<SeriesType>
• The dedicated plugin of the sankey is replace the usual hook now that we can configure it
• Replace the HighlightItemData by HighlightItemIdentifier<SeriesType>. For now it's a hack that make optional the dataIndex. But can became an custom identifier per series. The underlying idea is that the controlled highlight should be able to target an item (with thanks to the dataIndex) or an entire series (by omiting the dataIndex)

Remaining in follow-up

• The highlight handler could be improved. Instead of returning isHighlighted/isFaded it could be 'highlighted' | 'faded' 'none' to express the fact that highlighted implies not faded. (to do in a follow up)

[mui-bot]

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

Updated pages:

• docs/data/migration/migration-charts-v8/migration-charts-v8.md

Bundle size report

Bundle	Parsed size	Gzip size
@mui/x-data-grid	0B(0.00%)	0B(0.00%)
@mui/x-data-grid-pro	0B(0.00%)	0B(0.00%)
@mui/x-data-grid-premium	0B(0.00%)	0B(0.00%)
@mui/x-charts	🔺+1.44KB(+0.39%)	🔺+299B(+0.27%)
@mui/x-charts-pro	🔺+1.58KB(+0.33%)	🔺+261B(+0.18%)
@mui/x-charts-premium	🔺+2.07KB(+0.42%)	🔺+401B(+0.27%)
@mui/x-date-pickers	0B(0.00%)	0B(0.00%)
@mui/x-date-pickers-pro	0B(0.00%)	0B(0.00%)
@mui/x-tree-view	0B(0.00%)	0B(0.00%)
@mui/x-tree-view-pro	0B(0.00%)	0B(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against 5f5a0ba

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[JCQuintas]

I tried changes to useChartHighlight.selectors.ts, pretty much the issue that claude found out was that the types weren't being properly preserved when building.

For some reason the selector input types were being expanded when building the community package, and since the community doesn't have sankey/heatmap it would keep these out.

The solution was to simplify the selectors types by extracting the actual selector from the function types.

[JCQuintas]

Why is typeOfIdentifier needed in this function? This seems like its trying to solve a type issue with a prop. 😆

[JCQuintas]

Tbh there seems to be too many types of identifiers.

We should probably look into having them being the same.

The idea behind the VisibilityIdentifier is that is could be any Identifier-Like object.

Does the highlight identifier need to be different from the regular identifiers?

We could then have Identifier, IdentifierWithType, IdentifierLike

[alexfauquette]

It's effectively a prop that solves a type issue.

I think there is one aspect which is true: the IdentifierLike are a subset of the Identifier.

But I don't see why the Highlight and Visibility should be the same.

Tbh there seems to be too many types of identifiers.

Just one per features (tooltip, highlight, visibility)

The idea behind the VisibilityIdentifier is that is could be any Identifier-Like object.

Not exactly. It make no sens to provide a dataIndex to a visibility identifier of a bar chart.
But it make sense for the highlight.

// For the Bar identifiers, we should get

dataIndex: number, // identifier & tooltip
dataIndex?: number, // highlight
dataIndex: never, // visibility