Need a way to load a subset of icons

[arthurevans]

Currently, you can only load the full set of icons, which is a lot of data if you're only using a few.

[indolering]

Yeah, the majority of my vulcanized CSS/HTML output is unused iron-icons. These are aren't very compressible and I doubt DCE would catch unused ones.

I was thinking that you could keep the current system of an HTML import for each set but have the build system split the files up into discrete icons in a subdirectory. Then you can import the entire set during development and narrow down which icons to import for production.

[ebidel]

Yea we need something for this! Even the most simple app is penalized if it only uses a single icon from the default set. If you use 1-2 others from other sets, the SVG starts to dominate the element bundle download.

As an example, here's a very simple app that uses imports the entire default icon set just to use a hamburger icon for paper-drawer-panel: view-source:https://polymerfast.appspot.com/elements/elements.v.html

For other production apps, I've been producing a custom icon set that contains only the needed icons:

1. Santa Tracker (source not open yet)
2. Chrome status: https://github.com/GoogleChrome/chromium-dashboard/blob/master/static/elements/chromestatus-icons.html

Our own paper-tabs does a nice job of this by creating its own icon set. That has two drawbacks:

1. maintenance - when iron-icons changes in the future, paper-tabs needs the update as well
2. The svg is duplicated when it gets vulcanized with other uses of iron-icons.html.

I've started exploring a tool that makes it easy to generate an optimized custom icon set for an app. The user selects the icons they want, customizes a few inputs, and the online app (ala Modernizer custom build creator) spits out the correct markup. It would also support deep linking to get back to the selected icons and we could make a CLI version that accepts a list of icon ids at build time.

[indolering]

@ebidel That sounds like a lot of work for something that is verging on premature optimization; iron-icons itself is only 60KB! I'm about to get gigabit internet installed ... this just won't matter in a few years time.

I think breaking them down into more discrete units is good-enough. Importing 5+ icons adds boilerplate, but it's a one-time task and it's less overhead than setting up a build system. You could also break the sets into more functional groupings, /iron-icons/device/wifi.html for example.

1. The svg is duplicated when it gets vulcanized with other uses of iron-icons.html.

GZIP will dedupe them.

[ebidel]

Your assumptions assume everyone is on a gig connection. Trottle devtools to 2G for the day and lmk the results :)

[ebidel]

Iron-icons is small, but if you use even 1 icon from every set, you're talking 100s of wasted KBs. I'm on mobile ATM so can't check the actual numbers.

[robdodson]

yeah it's often the case that I grab a couple icons from 2-3 sets. That adds up quick

[indolering]

Your assumptions assume everyone is on a gig connection. Trottle devtools to 2G for the day and lmk the results :)

I remember 28K modems and using the internet on a phone over 2G, so I know where you are coming from. The increases in bandwidth may be linear, but they are increasing.

yeah it's often the case that I grab a couple icons from 2-3 sets. That adds up quick

I think it's worth allowing developers to choose a subset or even individual icons. I just think adding multiple import statements to an element would be as much work for the developer as specifying them using a build tool. From a maintenance point of view, it's certainly much easier to concat a bunch of icons in a directory than creating a new build tool.

[ebidel]

I hate build tools as well, but they're always opt-in. My point is that there are always people that want micro optimizations.

On Wed, Dec 23, 2015, 3:19 PM Zach Lym notifications@github.com wrote:

Your assumptions assume everyone is on a gig connection. Trottle devtools to 2G for the day and lmk the results :)

I remember 28K modems and using the internet on a phone over 2G, so I know where you are coming from. The increases in bandwidth may be linear, but they are increasing.

yeah it's often the case that I grab a couple icons from 2-3 sets. That adds up quick

I think it's worth allowing developers to choose a subset or even individual icons. I just think adding multiple import statements to an element would be as much work for the developer as specifying them using a build tool. From a maintenance point of view, it's certainly much easier to concat a bunch of icons in a directory than creating a new build tool.

— Reply to this email directly or view it on GitHub https://github.com/PolymerElements/iron-icons/issues/19#issuecomment-166983702 .

[indolering]

I hate build tools as well, but they're always opt-in. My point is that there are always people that want micro optimizations.

I don't hate build tools, I'm saying that they are unnecessary in this case.

[ebidel]

Here's an online tool that you can use to generate optimized custom icon sets:

https://poly-icon.appspot.com/

[indolering]

@ebidel I like the app you built, but what advantages does this have over allowing people to import individual icons directly? I would assume the boilerplate would be taken care of by compression over-the-wire.

And doesn't this solution require a new app for every icon set? If the icons were broken out into individual imports, then one would just need to do a find/replace on the path. I also don't think it's a good idea to hardcode the SVG paths.

[ebidel]

Today, you can't import individual icons. You can only import sets of icons. The advantage with a customizer like this is that you only load what you use. For example, if you load the editor-icons.html, you'll be getting everything...even though your app may only use one icon in that set.

You're right that with compression it's less of an issue, but less things for the browser to parse + load is a good thing. Also, everyone doesn't have correctly configured servers :(

I don't know what you mean by "a new app for every icon set".

[notwaldorf]

Looks like (without building extra tooling, cc @justinfagnani) Eric's https://poly-icon.appspot.com/ is a good solution for this.

I will add a note about this in the docs

[justinfagnani]

What if users created a custom icon set that behaved very much like polyicons: it selected a set of icons from other icon sets to build its custom icon-set. During development it just loads the source icon sets. Any tooling around pruning icons would be around redefining this custom icon set by copying in the icons it uses, not around modifying the source icon sets.

[indolering]

What if users created a custom icon set that behaved very much like polyicons: it selected a set of icons from other icon sets to build its custom icon-set.

That's the use case I've been trying to advocate for. Being able to customize icons to match your own design is a crucial feature. Even the simple interfaces I'm using this for in production feel way to much like I'm just cloning Google's UI.

How did Polyicons work exactly?

During development it just loads the source icon sets. Any tooling around pruning icons would be around redefining this custom icon set by copying in the icons it uses, not around modifying the source icon sets.

At some level, you do need to specify a new source icons the question is how to efficiently subset them. I guess some future optimizer could try to parse iron-icon elements. I think it would be easier to just allow developers to specify individual icons or smaller grouping and just switch the path prefix to their custom icon set.

[indolering]

The advantage with a customizer like this is that you only load what you use.

@ebidel Maybe I'm not explaining myself clearly. I was thinking of a Gulp build script that would assemble each top level icon set from subdirectories containing individual icon imports and/or smaller groupings of icons (i.e. device-icons.html from device-icons/). Then I could just import iron-icons/battery-icons.html.

You're right that with compression it's less of an issue, but less things for the browser to parse + load is a good thing. Also, everyone doesn't have correctly configured servers :(

But Vulcanize will consolidate everything into a single element.

I don't know what you mean by "a new app for every icon set".

Your app is slick for users who want only your icon-set but it breaks the separation of semantic information from the visual styling. Your approach makes updating icons and adding/removing individual icons much more onerous because you have to create new icon packs.

If you just allowed developers to import individual icons, adding a new icon would only require a new import statement and updates would propagate immediately. It also makes switching to a custom icon-set as simple as altering the path prefix.