EvoToolkit supports theming, so you can easily change the colours used by the framework to suit the needs of your project.
This theming functionality is split between a number of key/value pairs and mixins (getters/setters etc). These can be set in
theme-overrides.scss. Here's the run down:-
The first key/value pair is called
$colors, which is simply an archive of colours where the theming system can draw from, so we don't have to remember any hex codes. By default, there is a mixture of Evolution Funding brand colours and other more generic colours to fulfil certain UI roles (success messages, errors etc):-
These are greyscale colours named after their opacity, which allows for easier management. Read Color in Design Systems for a good overview of this approach.
These are Evolution Funding Brand Colours.
These are original colours which are required to perform various roles in a UI which grayscale and brand colours aren't suited towards.
The second key/value pair is
$theme, where the contents of
$color are given user interface oriented roles.
$theme colour, a dark and light shade is programatically generated for things like hovers and focus styles.
If you need to add or edit any colours in
$theme, you can do so using
If required, you can also define how dark or how light
$theme shades are with the
In addition, with
$theme colour names you pass here will have
very-light text colour (default:
very-dark) when its respective theme utility class is a applied to an element.
@include set-theme-dark-text-color(('accent', 'info'));
To retrieve colours from either
$theme, you can use the
Component Theme Variables
For each component, variable exists where
$theme colors are assigned roles specific to that component. For example:-
border: rem(1px) solid $component-input-border-color;
These generally shouldn't need to be edited unless you're introducing a lot more theme colours to the mix and would like to add more colour depth to components.
You can find a full list of theme variables in each component's respective documentation pages.
The reason behind this
$theme split is one of scalability and maintainability.
If we only had
$colors, this would make theming a more complicated process. For example, if components had border colours set to
$grey and you wanted to change them to red, you would have 2 options:-
- Change the value of
$grey to red, which would do the job, as the variable would trickle down to the component styles. The problem here is with semantics, in that the variable
$grey is now actually red, which is just unnecessary confusion.
- Add a new colour called
$red and then go through every single component and override their theme variables. A time consuming process.
$theme contains colours named according to their role, we can assign them any colour and have it still make sense semantically. And because these
$theme colours are the ones already referenced in the component styles, we don't have to go through and edit any component theme variables at all.