Bug: Iconify Basic not replacing dynamically added icons about iconify HOT 5 CLOSED

Confirmed. Basic bundle doesn't include DOM observer.

To change it change this code in build/dist.js:

content = parse({
    observer: false,
    api: false
});
save(baseName + '.basic', content);

Change observer: false to observer: true.

Can you tell me why you don't want to include API support? In Iconify 2 I've removed all alternative bundles, but if there is need for it, I can create similar bundle without API.

from iconify.

Ah, I see. My motivation is

1. reduce code size, my JS bundle is already 1M :-(
2. simple way to ensure that icons are preloaded and not silently loaded via API.

Therefore I would like to have an option to force Iconify into offline mode.

With preloaded icons I am actually wondering if I would need the DOM replacement because I can also use the SVG provided by Iconify when I add icons programmatically as opposed to having them in my static HTML. That would allow me to use Iconify in the build process to produce the icon bundle and I would then expose a dictionary with the icon SVG to the code running in the browser.

from iconify.

Ideally (IMHO from a performance perspective), SVG icons would be included once in the HTML document and then referenced like described in https://www.lambdatest.com/blog/its-2019-lets-end-the-debate-on-icon-fonts-vs-svg-icons/ (scroll down to Step 3).

I am wondering if including the same SVG block 1000 times in a page is really not a performance issue compared to referencing it 1000 times.

from iconify.

That's a very good use case. I'll fix "basic" for version 1 and will implement it in version 2 as well.

As for sprites, yes, there is small performance increase when using sprite, however there are also huge drawbacks.

If page has many icons, most likely content is dynamic. There is no way to track when elements have been removed from DOM. If Iconify would use references, it would mean each icon would have 2 entries in DOM: one where icon is used and one in big sprite. When reference to used icon is removed, code in sprite would still be there. With so many icons used on page it can easily pile up to big unmaintainable sprite. It is extreme case, but 1000 of icons is extreme case too.

Another issue is adding sprite to document body. It might interfere with existing DOM structure, breaking scripts that expect certain children of body element or breaking stylesheet. When developer inserts SVG sprite, he takes that into account when designing and coding page. When third party script does that, developer's code might not be designed to do that.

Usually there aren't that many icons used on page, so I think potential performance increases aren't big enough to counter potential drawbacks.

With modern SVG implementations performance is not really an issue.

For example, take a look at this page: http://animated-icons.simplesvg.com It has about 100 icons, all with animated stroke. I don't see any performance issues.

Then there is Iconify Icon Finder, which is still in development, but you can see older version used in Figma plug-in. On main page it shows 80 icon sets, each icon set has 3 demo icons and 1 or 2 custom SVGs that display numbers, so that's almost 370 SVGs. No performance issues. Icons render instantly and don't cause any lag.

Though I think sprites could be a good option for developers that know what they are doing, so I'll see if it would be feasible to create as an option. Maybe it can be added as module, which can be toggled during compilation or as option that can be toggled in run time. I'll test it.

from iconify.

Fixed in 1.0.7.

Instead of modifying "basic" package, which does not contain any modules, I've added another package "without-api" that contains everything except API support.

I'll be adding similar package to Iconify 2 as well.

from iconify.