[charts] Remove default generic of item identifiers

[alexfauquette]

Extracted from #21161

The idea is that item identifier does not make that much sense. For now most of the identifier are the same { type, seriesId, dataIndex } but with heatmap will be { type, seriesId, xIndex, yIndex } or the sankey identifier

Not sure about how to document that "breaking change" or document it

[mui-bot]

Deploy preview: https://deploy-preview-21182--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	0B(0.00%)	0B(0.00%)
@mui/x-charts-pro	0B(0.00%)	0B(0.00%)
@mui/x-charts-premium	0B(0.00%)	0B(0.00%)
@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 664f3ca

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing alexfauquette:remove-global-identifier (664f3ca) with master (adbcb8b)¹}

Summary

✅ 14 untouched benchmarks

Footnotes

1. No successful run was found on master (735d9ec) during the generation of this report, so adbcb8b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[JCQuintas]

Not sure this is necessary. Can't we have the initial value be "anytype", and users trim it down by either SeriesItemIdentifier<'line'> or

const item = ourOutputItem

if (item.type !== 'heatmap') {
 // ignore
}
// do something

[github-actions]

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

[alexfauquette]

Not sure this is necessary. Can't we have the initial value be "anytype", and users trim it down by either SeriesItemIdentifier<'line'> or

That's kind of already the case

For callback

If you look at the definition of the ChartDataProviderProProps, the TSeries is by default set to ChartSeriesType so the plugins and all their parameters will be set the same way.

So if the onItemClick depend on the series it will by types as an union of any series type

export type ChartDataProviderProProps<
  TSeries extends ChartSeriesType = ChartSeriesType,
  TSignatures extends readonly ChartAnyPluginSignature[] = AllPluginSignatures<TSeries>,
> = ChartDataProviderProps<TSeries, TSignatures> &
  ChartProviderProps<TSeries, TSignatures>['pluginParams'] & {
    /**
     * Slots to customize charts' components.
     */
    slots?: Partial<ChartDataProviderProSlots>;
    /**
     * The props for the slots.
     */
    slotProps?: Partial<ChartDataProviderProSlotProps>;
  };

For user state

Here it changes a bit, because it forces the user to specify which series type they plan to store.
IMO it's not a big deal

Why doing it

I got multiple TS issue that were hard to understand because sometime the generic argument is provided, sometime not, so it defaultize to all series type. Leading to error like "The union does not match with this other union"

Removing the default value forces us to correctly type pass the generic or explicitly say "this can be any series type"

[JCQuintas]

The benefits seem to outweigh the drawbacks, so we can roll with it :)