Victory: Implement theme support

[danielberndt]

I guess this probably is on the roadmap already, but I couldn't find any ticket for this yet, so here it is :)

For apps that use a lot of victory-based charts/pies/etc, it would be quite convenient to define a custom default style/theme once rather than specifying the same styles on each component or creating wrapper components.

Here's an example of how belle does approach this, based on a similar inline-styled based structure like yours:
https://nikgraf.github.io/belle/#/configuration?_k=hrmxli

Given that css modules seem to become more popular these days, it might be a good idea to think about a classname-based approach as well (related issue: https://github.com/FormidableLabs/victory/issues/198).

Here's a promising library that could offer some inspiration:
https://github.com/javivelasco/react-css-themr

[boygirl]

@danielberndt adding support for a concept of theming is definitely on our radar. Thanks for the references!

[danielberndt]

Bonus: it would be awesome to support several themes in one application! Let's assume I want to reuse a default theme and a dark theme. (the dark theme could potentially be a community plugin somewhere on npm 🙀 )

When I don't specify any theme, graphs will use the default theme that I specified (or if not present, falls back to the victory defaults). And if I want to use a dark theme I simply do something like <VictoryChart theme={darkTheme} .../>!

[EvHaus]

For your reference, I have outlined how we use CSS Modules and themes in our code. This may give you a good idea of a specific use case when designing support for CSS Modules and themes in Victory: https://github.com/css-modules/css-modules/issues/98#issuecomment-208623106

[paulathevalley]

Sharing my thoughts on the default theme from a visual design perspective.

For accessible color palettes, ColorBrewer2 appears to be the standard. They have a handy naming convention, RdPu for red-purple, YlGnBu for yellow-green-blue, etc. Would it be useful to keep a theme and override it with a different color palette, e.g. theme={default} colorScale={ylgnbu}? I’m not sure.

Themes would include so much more of course: font names, font sizes, tick and axis stroke size, use of negative space, scatter point sizes, and so forth, and all of this would be compounded by functional styles.

From a visual design perspective, I would advocate for a default theme that would make it easy to follow Edward Tufte’s best practices for data visualizations: color scale of grays, axes that stop at the minimum/maximum data points (if possible), black colored axes and data (highest contrast) with gray gridlines (lower contrast). However, each data visualization will have its own considerations so it may be worth including an alternate of each default chart, but again, only if possible (as well as reasonable).

Below is a visual design mockup of line, scatter, bar, area and pie charts with an alternate.