Add color customization

[gpfunk]

Explanation About What Code Achieves:

• Gives the ability to pass in custom colors

Screenshots/GIFs:

• N / A

Steps To Test:

• Pass in a custom array of colors to any chart (other than the annual heatmap) and see the new colors applied. Only catch being the number of colors must be greater than the number of labels in the percentage and pie chart, and greater than the number of datasets in the other charts.

TODOs:

• rgba implementation is not included as it didn't seem immediately relevant
• potentially unexpected behaviour when switching between chart types...for instance, if a valid # of colors are present for the bar / line charts it will render those colors, however if switched to pie / percentage chart and an insufficient # of colors are present, it will set the colors to the default colors list and the original colors will be lost, meaning if switched back to the bar / line chart it will still be the new updated colors list.

[pratu16x7]

@gpfunk Looks great! Took us a while, can you rebase the branch?

Currently switching is straightforward; it simply comes up with the best chart it can with the same data, so it doesn't imply or have provisions for a color (or any) change. It could be argued the axis and pies are color-incompatible, so would need more args to switch. Looks like the best behaviour in the current implementation would be to simply render the new chart with default colors, and the color loss be expected.

[gpfunk]

@pratu16x7 Just reread your message, I rebased but haven't removed the attempt to reuse the colors passed in when switching charts. Do you want me to do that first?

[pratu16x7]

@gpfunk Removing it beforehand would save a step while rebasing ;)

[pratu16x7]

On second thought, let's add another constraint dict besides compatible_types; called color_compatible_types, and only use this.colors if it is satisfied. Will be useful for adding new charts in future.

[pratu16x7]

You'll probably want to replace these with hex-codes and test stuff out again.

[gpfunk]

Do you think thats needed? They currently get mapped to the correct hex codes using the color_map field in utils/colors.js, rather than the css. I did this to allow for backwards compatibility for anyone currently using the color names, which also allowed for the hex codes to be kept in one place. Or am I misunderstanding you?

[pratu16x7]

Sure missed that.

[pratu16x7]

However, it looks like there's more calls to get_color() than necessary. You see, currently it is called at every place where and when the color is actually set (while setting the style). But because the colors are already received beforehand in the constructor, it would be much more efficient to do the conversions there itself. That way we'd have the real colors ready for use whenever needed (without remembering to call get_color(): There is a case in make_gradient() below which demonstrates this, where while setting the stop-color we seemingly forgot a get_color() call? ;) ).

So in this light, it makes sense to store the defaults in the constructor as hex codes itself in case no colors are passed, while in case they are, going in, using get_color() for the color for each dataset in case of axis, while doing the same for the colors array for pies.

[pratu16x7]

Just made a radical decision, to pass colors array as a separate arg for axis charts as well, instead of in each dataset. Makes usage consistent across all charts, the array will apply as per the context. This will constitute a release update.

Now it gets much easier to use get_color() in the constructor, just parse this array to see if it has words :D