Add custom angles to polar area graph

[MarioIannotta]

Old Behavior

Every angle is 360/#values °

New Behavior

Provide custom value for each angle of the polar graph.

Solution

  	var options = {
 		type: 'polarArea',
 		data: {
 		labels: ["A", "B", "C", "D", "E"],
 		datasets: [{}]
 		},
 		options: {
 			customAngles: [
 				1.0566, 1.7566, 1.0566, 2.1566, 0.2566
 			]
 		}
 	}

Live demo:
https://codepen.io/anon/pen/ZXEmQm

[simonbrunel]

@MarioIannotta please don't create a new PR for every update, simply push to your branch new changes.

[simonbrunel]

Referring to #4752, but maybe you closed this one for another reason :)

[MarioIannotta]

Yeah, the reason is that I was sleepy :)
Let's use this one :)

[benmccann]

this project has a convention of declaring all the variables at the beginning of a function as it apparently improves code minimization. can you move the declaration of startAngle and also i to occur with previousAngle and visibleCount?

[benmccann]

this could be just var i since it's initialized to 0 below

[benmccann]

Your codepen example doesn't seem to be working

[MarioIannotta]

Sorry, there was an issue with github hosting and codepen, it's fixed now.

[benmccann]

Thanks for fixing the codepen. It helps demonstrate your PR.

I'm not sure about the name customAngles because really all options are custom, so we could put custom in many of the options. Perhaps calling it just angles would be sufficient?

[simonbrunel]

I agree with @benmccann, I would not use custom* naming but also I would implement this new option as scriptable, and so call it angle (singular):

• if undefined (default), compute the angle based on the current formula (360/value?)
• if number, same angle for all values (might not be useful, but consistent with other scriptable options)
• if array, each item represent the angle for the value at the same index (your implementation)
• if function, use the returned value as angle for the current value

You will need to use the resolve helper to compute the actual value for each element (see the bubble chart for example).

If you don't feel to implement the scriptable behavior, then let's implement the undefined, number and array versions with angle as option name (@etimberg thoughts?)

[simonbrunel]

Do we really need to iterate every time for each element? can't we use angle at index-1 to calculate the angle of the element at index

[ChamNouki]

I think we have to iterate since the array (or function/number) indicate the angle for one item and not it's starting angle. So to get the starting angle of the current element we need to calculate it from the start angle of the chart. Or would I have missed something?

[MarioIannotta]

Yes, that's right.

[simonbrunel]

What I mean is that we could compute a _starts and _angles private cache arrays in update() that contains all start angles in which case only one iteration is needed, something like:

update: function(...) {
    // ...
    var start = options.startAngle || 0;
    for (i = 0; i < count; ++i) {
        this._starts[i] = start;
        angle = [compute slice angle]; // if dataset invisible, angle == 0
        this._angles[i] = angle;
        start += angle;
    }
    // ...
    helpers.each(meta.data, function(arc, index) {
        me.updateElement(arc, index, reset);
    });
}

updateElement: function(...) {
   // ...
   var startAngle = this._starts[index];
   var endAngle = startAngle + this._angles[index];
   // ...
}

It seems to simplify a lot the computation / logic.

[ChamNouki]

I hadn't thought about that but yes it could save some performance.

[etimberg]

I like the idea of a scriptable option (I think we should be doing this for all new options if possible). I believe the current angle is 360 * value / sum_of_values

[etimberg]

Closing due to inactivity