Chart styling as we know it
Styling charts is another area where you need to use colors. There are a lot of color palettes for charts on the internet, but not every color palette can fit our brandbook and we have to apply “our” colors to maintain the overall style.
Often, it is a regular preset with hardcoded colors. This approach completely covers most graph styling issues if only 1 interface color scheme is used.
But what about supporting more than one color scheme?
Adapting charts for each theme is a challenge for developers. And if experience is not enough, you can even meet such implementations
backgroundColor = theme === 'dark' ? 'white' : 'black'
It’s scary to imagine if detailed stylization of each type of chart would be required. 😱
Let’s suppose developers have solved the problem of this approach and made a ColorsService that provides the desired color by colorName
, hiding the actual value.
export class ColorsService {
private themeMap: Map<TThemes, Map<TColorName, string>> = new Map([
['default', new Map<TColorName, string>([
['primary', '#d75894'],
['secondary', '#9b3dca'],
['chart-color-1', '#526ed3'],
['chart-color-2', '#ea97c4'],
['chart-color-3', '#fee797'],
['base-1', '#808080'],
['base-2', '#bebebe'],
])],
['dark', new Map<TColorName, string>([
['primary', '#5e84ff'],
['secondary', '#0dd0ff'],
['chart-color-1', '#ffce56'],
['chart-color-2', '#36a2eb'],
['chart-color-3', '#ff6384'],
['base-1', '#c7c7c7'],
['base-2', '#bcbcbc'],
])],
])
private paletteMap: Map<TColorName, string> = this.themeMap.get('default');
constructor(
private themeSwitcher: ThemeSwitcherService,
) {
this.themeSwitcher.eventBus$.pipe(
takeUntilDestroyed()
).subscribe(theme => {
this.paletteMap = this.themeMap.get(theme)!;
})
}
public getColor(colorName: TColorName): string {
return this.paletteMap.get(colorName)!;
}
}
The service installs a new color map every time the theme changes. And the eventBus$
bus will notify the charts that they need to be refreshed.
By introducing the ColorsService
abstraction, we have solved the potential problem of hardcoding colors in each component of the graph.
But we didn’t get rid of another problem — SCSS color variables and ColorsService
are not related in any way, and therefore support for current and new themes will also be done by hardcoded colors. If the color scheme on SCSS changes, we’ll need to make changes here as well.
Can we make this ColorsService even more abstract, and not do any more theme support in it ? read more...
Top comments (0)