Proposal: bridging OTKit-icons and buffet and other common libraries

[Ronnie Chong]

Hi everyone,

I would like to propose an enhancement on the existing otkit-icons.

In a long term view, I envisaged design-tokens will be adopted in both restaurant and consume teams as a standard and source of truth. The icons right now are restrictive when we require different colors other than the ones predefined in the SVG. A good alternative option is to overwrite the path CSS directly but that is not practical since we have a wide range of colors, paths and whatnot.

We also have a common component library buffet and we would like to see that otkit-icons works hand in hand with buffet too. As it currently stands, we manually duplicated the SVG from otkit-icons into buffet, changed any fill attributes value to currentColor because we may not want to utilize the colors predefined in the SVG, and prefer to inherit any colors from the parent component's CSS.

I would like to hear your thoughts for these approaches to support the scenarios above:

Approach A

We have a pair of icons for each SVG, one with the retained fill colors and one stripped & replaced with currentColor. The latter has a postfix, say Pure

e.g
CommonJS

module.exports = {
  icFavoriteFilled: "<svg><path color="#0000ff" />....</svg>",
  icFavoriteFilledPure: "<svg><path color="currentColor" />....</svg>",
}

CSS Modules

@value ic-favorite-filled: <svg><path color="#0000ff" />....</svg>;
@value ic-favorite-filled-pure: <svg><path color="currentColor" />....</svg>;

SCSS

$ic-favorite-filled: <svg><path color="#0000ff" />....</svg>;
$ic-favorite-filled-pure: <svg><path color="currentColor" />....</svg>;

Pros: One single token and we can access two different sets
Cons: Duplications and possibly large file size (if no treeshaking) for CommonJS

Approach B

Similar like Approach A, instead of duplicating two sets in each token, we create two tokens for each format. One with the default colors in the SVG and one with currentColor

e.g
CommonJS

// Imports icon <svg><path color="#0000ff" />....</svg>
import { icFavoriteFilled } from 'otkit-icons/token.common'

// Imports icon <svg><path color="currentColor" />....</svg>
import { icFavoriteFilled } from 'otkit-icons/token.pure.common'

Pros: Separation of concern and smaller file size
Cons: Accessing two different sets have to be imported separately

I lean towards Approach A because the current design-tokens overall, e.g. colors, spacing, etc have only one token for each format (CommonJS, SCSS and CSS Modules). It breaks the pattern if we introduce Approach B solely for icons.

Also, these two approaches will should not be a breaking change. Current users should be able to use the way even after bumping to the latest version.

If you have other options, concerns or comments, fire away! Looking forward to your feedback.

[Jake Clements]

This is great, a move away from duplication of icons will be a massive win in ensuring we're using design-tokens correctly.

Is the intention in keeping the defined colours here to avoid a breaking change?
In terms of a long-term goal, what are the (if any) implications of moving towards currentColor for all of our icons and scrapping the explicitly defined colours?
I understand it would be a big change across a lot of microapps, but this could be a phased approach that's communicated to teams to allow the time to update.
It would be good if we can move away from maintaining 2 sets of icons over the longer term.

I haven't had a chance to look much into this library or how the icons are generated yet; have we considered using a higher order function for the commonjs usage that we can provide a colour library to? Or variables for CSS/SCSS?
This might allow us to control multi-colored icons as well as updating single colors. It might also be overkill for our needs or impossible with this tooling, lets discuss.

[Ronnie Chong]

This is how they create the otkit-icons:

1. Reads the SVG files in the entire folder
2. Optimises with SVGO and converts to Yaml
3. Uses Theo to create design tokens for scss, css modules and commonjs

Two reasons for retaining the existing icons:

• A lot of repos are using this otkit-icons (when i searched via opengrok) and switching completely to currentColor will definitely break their stuff.
• Some icons have multi or specific colors for each path e.g social medias

I say the first reason can be easily addressed if we slowly move towards one single set of icons and give them enough time to transition (via PSA email blast). We can also bump to a major version so they can keep using the existing icons with the previous version until they are ready to migrate.

[Ray Peters]

I personally like Option B better because we will eventually deprecate and remove the original icon files, and it would be nice not to have any *Pure* references sprinkled around the code bases

With that said, I can easily be persuaded otherwise 👍

[Ronnie Chong]

Happy to go option B. I reckon I'll name it theme instead of pure

[Ronnie Chong]

This is now released and is available to use in 9.0.1 onwards
#473