[charts] Decouple margin and axis-size

[JCQuintas]

Testing of #16383 (comment)

[mui-bot]

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

Generated by 🚫 dangerJS against 0daad2b

[codspeed-hq]

CodSpeed Performance Report

Merging #16418 will not alter performance

_{Comparing JCQuintas:axis-size-poc (acc67bd) with master (d8f2691)}

Summary

✅ 6 untouched benchmarks

[JCQuintas]

@alexfauquette having the config in either the plugin or in the component cause a re-render which slows up the chart.

An alternative could be to get rid of left/right/top/bottomAxis properties, move all the config into the x/yAxis, which will then process everything before they render as far as I'm aware. 🤔

eg:

<LineChart
  xAxis={[
    {
      data: ['A', 'B', 'C', 'D'],
      scaleType: 'point',
      position: 'right',
    },
  ]}
  series={[{ data: [40, 30, 20, 10] }]}
  height={200}
/>

[alexfauquette]

An alternative could be to get rid of left/right/top/bottomAxis properties, move all the config into the x/yAxis, which will then process everything before they render as far as I'm aware. 🤔

Sounds reasonable. Wwe will need to find a hack to let the selectorChartDrawingArea accept to support this new notion of axis dimensions depending on the existence of the cartesian axis plugging or not.

You would still have the plugin in the following order "dimensions > series > axes" but the dimensions could have a selector that uses xAxis and yAxis config if available. The selectorChartDrawingArea would depend on two selectors selectorChartMargin and selectorChartAxisSpace.

If later we want to adapt the size according the real space an axis takes we will also need to take into account the zoom and the tick we render.

I assume the idea is then to have something like

xAxis={[
    {
      data: ['A', 'B', 'C', 'D'],
      scaleType: 'point',
      position: 'right',
      width: 95 // specify the space taken by the axis.
    },
  ]}

[alexfauquette]

By the way, the removal of leftAxis, ... can be done in a non breaking way.

We can deprecate the props and keep default the same

[JCQuintas]

@mui/xcharts what do you think about this API? I still have to make height/width count towards the margins, but it was trivial to allow multiple axis on a side in this implementation 😄

import * as React from 'react';
import { BarChart } from '@mui/x-charts/BarChart';

export default function BasicBars() {
  return (
    <BarChart
      xAxis={[
        { scaleType: 'band', data: ['group A', 'group B', 'group C'], position: 'top' },
        { scaleType: 'band', data: ['group 1', 'group 2', 'group 3'], position: 'top' }
      ]}
      series={[{ data: [4, 3, 5] }, { data: [1, 6, 3] }, { data: [2, 5, 6] }]}
      margin={60}
      width={500}
      height={300}
    />
  );
}

[alexfauquette]

I was effectively thinking of this issue #16387 about multiple axis as a nice example of what this new axis config could fix :)

I'm good with the API, and adding width and height as properties that get defaulted on x/y axes.
I would be against something like { position: 'top', size: { width: 50, height: 150 } } because for x-axis user will only care about the height, and with y-axis only about width.

[bernardobelchior]

We're suggesting using xAxis, but xAxis isn't a prop of this component. I'm a bit confused by this, so I suspect a user would be too. Where should I set the xAxis prop to maintain the behavior?

[JCQuintas]

🤔 true it is not a prop of the ChartsAxis but it is of the XxxChart since it reuses the props.

In this use-case I would assume there is no "single best approach", since the prop is not on this component, but also not on a single external component.

What we can do is provide a url to the migration guide where we can explain with specific examples.

[bernardobelchior]

Yeah, I'm not sure what's the best way to proceed here. I suppose a URL to the migration guide is helpful, at least, so unless we can think of any better option, that seems good to me 👍

[alexfauquette]

I'm not super concerned by this point. I guess most of the users are using directly the ChartsXAxis/ChartsYAxis and they all now where the xAxis props goes because with series they are the most used

[github-actions]

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

[alexfauquette]

I'm dubious about this approach. For me either you have an axis. ANd then this axis can have a default width/height properties. But the axis size should not have another default value than 0.

I don't see why it should get 30px space whereas their is no axis displayed

[JCQuintas]

True, I was copying the previous sizes, (margin = 50, now margin = 20, axis = 30) but it doesn't make sense indeed. 😆

[JCQuintas]

Is there a way to know which axis is actually going to be displayed beforehand? 🤔

My current issue is that the "default" axis, is added to the "available axis array", and counted towards sizing, even when not used. Any declared, but not used axis would count towards the "axisSize" with the current logic.

In the axis Components we have these:

  // Skip axis rendering if no data is available
  // - The domain is an empty array for band/point scales.
  // - The domains contains Infinity for continuous scales.
  if ((ordinalAxis && domain.length === 0) || (!ordinalAxis && domain.some(isInfinity))) {
    return null;
  }

So I assume we can only get the scale domain after processing the data, which means I'll probably have to move this to selectors I guess 😢

[alexfauquette]

What about moving the default here

Suggested change

	return { ...acc, top: acc.top + (cur.height || 0) };
	}
	return { ...acc, bottom: acc.bottom + (cur.height || 0) };
	return { ...acc, top: acc.top + (cur.height || DEFAULT_AXIS_HEIGHT) };
	}
	return { ...acc, bottom: acc.bottom + (cur.height || DEFAULT_AXIS_HEIGHT) };

[JCQuintas]

@mui/xcharts the current file setup is prone to dep cycles unrelated to the needed selectors. Should we move to more unitary files for selectors?

[JCQuintas]

@mui/xcharts what do you think about moving this logic as a permanent part of the axis definition? This can then be used in the x/y axis renderers