Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

Issue Description

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?

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:8 (8 by maintainers)

github_iconTop GitHub Comments

emmenkocommented, Jan 15, 2019

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

emmenkocommented, Jan 28, 2019

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

5 Gotchas You're Gonna Face Getting Inline SVG Into ...
My recommendation is to just hide/show via CSS classes (Technique #1 described in Swapping Out SVG Icons article), and be sure to target...
Read more >
Working with Icons and Images | IntelliJ Platform Plugin SDK
Icons and images are used widely by IntelliJ Platform plugins. Plugins need icons mostly for Actions, custom component renderers, ...
Read more >
Dynamic import of SVG icon components - Stack Overflow
The icons are loading, but I get the following error for each icon imported. Is there a better way to approach this? Uncaught...
Read more >
Font Awesome icons in Vue.js apps: A complete guide
This brings in a the icons we'll be using in the demo, plus two new components. The new components implement a form of...
Read more >
How to build your own tree shakable SVG icons library in less ...
We will visualize this concept later. To render the actual SVG icons, we use the fa-icon component in ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found