[charts] Add baseline property to the LineChart series

[JCQuintas]

Resolves #14145

This adds a baseline props to the line chart series. It only works on the area chart and defines the baseline the area starts from.

baseline: 0

baseline: -10

baseline: 10

[mui-bot]

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

Updated pages:

• docs/data/charts/lines/lines.md

Generated by 🚫 dangerJS against bb563f4

[codspeed-hq]

CodSpeed Performance Report

Merging #14153 will not alter performance

_{Comparing JCQuintas:area-chart-baseline (bb563f4) with master (38184fe)}

Summary

✅ 3 untouched benchmarks

[alexfauquette]

Just one edge case. I think the second option will be better when used with the zoom feature you're currently working on

[alexfauquette]

This only impacts the plotting. Here is an example with values fluctuating between 200-300, and with baseline set to 1000.

Notice that:

• The basline has no impact on the max value of the y-axis
• The yèaxis always start at 0 because it's the assumed baseline

[alexfauquette]

Potential solution

1. When computing the extremum values, you replace when needed the base (d[0]) by the user defined baseline

2. Instead of providing a number, user can provide 'top' | 'bottom'. Then you just need to ignore the d[0] by doing

- isArea && axis.scaleType !== 'log' ? ...
+ isArea && axis.scaleType !== 'log' && series[seriesId].baseline === undefined ? ...

and in the commented line return

- return yScale(baseline)!;
- return baseline==='top' ? yScale.range[0] : yScale.range[1];

mui-x/packages/x-charts/src/LineChart/extremums.ts

Lines 43 to 44 in 38184fe

	const { area, stackedData } = series[seriesId];
	const isArea = area !== undefined;

[JCQuintas]

It behaves a bit weirdly when baseline changes the extremums.

This happens because the extremum getter value is then passed into the nice() function, it can have unintended consequences, which means I would also have to check the baseline where that is calculated.

But we already have the axis min/max values for that. So I believe we should use the min/max values when the axis extremums need to be changed.

[alexfauquette]

It behaves a bit weirdly when baseline changes the extremums.

TLTR: I don't think it's an issue

---

Technically speaking, we have two behavior to define:

• where does the area set the baseline
• should the basline impact the extremums.

Should the baseline impact the extremums

For stacked data, I can not think of a usecase where the answer would be no. Otherwise you would compare some area wherase the base one would have missing part.

For a single series, where the area is more aesthetic, seems it can be ignored. Here foe example the NASDAQ evolution during the day. Nobody care of the space between 0 and 16.500. Only the relative evolution matter. Otherwise you would see nothing.

Where does the area set the baseline

I only see two reasons to modify the default 0:

• aesthetic reasons. But in that case, only min/max makes sense
• There is a specific value to compare to. For example the average over time. But in that case, I don't see a reason to pick a value that is always on top or below the line

So basically the weird case you define should not exist

[JCQuintas]

Ah, but those are just working as expected. The issue that appears when we have the baseline affect the extremums is that the extremums will get niced after. So if we have a non-round number like below, it will not work properly. Then this starts to get more complex and would clash with a feature that already exists yAxis.min/max

[alexfauquette]

Not exactly if the baseline means we will ignore 0 for extremum computation

[JCQuintas]

I don't get what you mean here 🤔

[alexfauquette]

Sorry, I forgot a part of the sentence

If the baseline is defined with min/max, the 0 will be ignored for axis extremums

[JCQuintas]

Ah, this is an effect of your change, I didn't intend it at first. We can keep to the other discussion and I will update it with the outcomes

[alexfauquette]

Just one last comment about the impact on stacked line chart. Since you early return the y0 function, the behavior with stacked line could be wrong. Just warning users about that can do the job

[alexfauquette]

You could add a warning to say that the baseline should not be used with stacked lines