WIP Scale options as an object instead of an array

[etimberg]

I want to get some feedback on this before I go any further.

This PR changes the axis options format to one that is easier to work with. The challenges are that we can't do as many default actions for X vs Y axes. I kept some basic functionality by assuming that axes that have an ID starting with "x" are horizontal.

options: {
	scales: {
		xAxes: [{
                        id: 'x',
			display: true,
			scaleLabel: {
				display: true,
				labelString: 'Month'
			}
		}],
		yAxes: [{
                        id: "y",
			display: true,
			scaleLabel: {
				display: true,
				labelString: 'Value'
			}
		}]
	}
}

to

options: {
	scales: {
		x: {
			display: true,
			scaleLabel: {
				display: true,
				labelString: 'Month'
			}
		},
		y: {
			display: true,
			scaleLabel: {
				display: true,
				labelString: 'Value'
			}
		}
	}
}

To Do

• Fixture based tests
• Documentation

[kurkle]

I like it. How about allowing position to be option and fall back to "starts with x"?

[etimberg]

Yup, position as an option is still available. Just that previously determining the default was easy since we knew already if the axis was X or Y.

One other downside I realized is that if one creates new axes x1 and y1, they'll end up with 4 because the charts have defaults for x and y IDs. Previously the ID didn't really matter. I can see that causing complaints and/or lots of issues

[benmccann]

What's the primary goal here? I'll probably have some thoughts, but want to make sure I'm not going in a different direction

[kurkle]

I think the axis property for scale, proposed by @benmccann in #6576 (comment) could help here too?

[etimberg]

@benmccann the goal here was to try and simplify the axis option code by changing the format of the config object.

[benmccann]

I like it

One thing I was thinking is that we should probably have a migration guide that we update each time we make a breaking change. I think it will be easier to do as we go than to have to go back and do it all at the end. And easier for the person originally making the change than for one person to have to do it all

[kurkle]

I think we need to figure out how to default to first configured axis instead of x/y

[etimberg]

Agreed. I think the thing that may sink this attempt is taht one cannot remove the x and y axis IDs because of how we merge the config.

[kurkle]

I think we can map defaults.x to firstX and defaults.y to firstY in merge, but might have to rewrite the merge totally.

[kurkle]

We could do something like:

var firstX = Object.keys(scales).filter(key => scales[key].position === 'top' || scales[key].position === 'bottom').shift();
var firstY = Object.keys(scales).filter(key => scales[key].position === 'left' || scales[key].position === 'right').shift();

if (meta.xAxisID === null || !(meta.xAxisID in scales) || dataset.xAxisID) {
	meta.xAxisID = dataset.xAxisID || firstX;
}
if (meta.yAxisID === null || !(meta.yAxisID in scales) || dataset.yAxisID) {
	meta.yAxisID = dataset.yAxisID || firstY;
}

[etimberg]

Good idea, let me see how that goes

[benmccann]

@etimberg this one will need to be rebased

[kurkle]

Merged in #6773