[Idea] do no bundle svg icons, expose only generic icon component

Given our recent discussions about icons and some of the problems / limitations we had with them, I’ve been thinking about a possible approach that we can take to scale better and to make our lives easier.

Current problems

At the moment adding/managing icons is quite cumbersome: we need to get svg files from designers, make sure the file name is correct, do a new release. Per se it’s not that bad. However, this means that for each new icon we would need to do the same. Our icons set is also quite small, and sometime we have opinionated icons that are usually used for specific places and that can’t be reused. Furthermore, the bundle size of the ui-kit will keep increasing as we add new icons (and tree-shaking is broken at the moment anyway #307) Last but not least, consumers of ui-kit are tight to the icons set that we expose, giving not many choices, unless they reimplement the Icon component and use custom svgs.

A brighter path forward

In some of our recent experiments/discussions (e.g. #425), some ideas came up about having a more generic implementation to allow any kind of SVG icons to be used. For example, the SVG is loaded asynchronously by the <Icon> component, or SVGs are passed as base64 strings.

I think we should think about moving into something like that, which brings several benefits:

• smaller bundle size (svgs are not bundled anymore)
• tree-shaking works again
• opinionated icons/svgs do not need to “leak” into the ui-kit anymore
• (custom) applications can use whatever SVGs they want
• dynamic rendering of icons (e.g. switch)

What do you think? Should we do some spikes to look into that?

[emmenko]

It depends on the final solution I guess…ideally I would expose a single component <Icon>

[emmenko]

Closing this, as we decided not to proceed with this for now.