natemoo-re/astro-icon

Consider use case where icons are set in a cms

jsve opened this issue · 1 comments

jsve commented

What version of astro-icon are you using?

v1

Astro Info

Astro                    v4.1.2
Node                     v18.18.2
System                   macOS (arm64)
Package Manager          yarn
Output                   static
Adapter                  none

If this issue only occurs in one browser, which browser is a problem?

Describe the Bug

We, along with multiple other projects, allow configuration of icons though a CMS. The following changes removes astro-icon as a viable option:

  1. including all icons from a pack per default
  2. having icon packs imported directly in the project

Some additional context:

  1. before in the build process we have no way of knowing what icons are set in the CMS. Multiple packs could have been used. Bundling all of the icons from all of the used packs is will have major performance implications. Considering most projects use maybe a handful of icons, this seems like a sub-optimal default behaviour. Something like the suggestion here (#191) could work, or exposing a function that allows us to declare each icon we use from our components.
  2. I realise that having the project import the used icon packs gives flexibility in regard to icon pack versions. However, I can't see how this works in regard to the tooling used to parse the icon packs on the astro-icon end (iconify/json etc). For the CMS use case specifically, this means we get multiple dependencies between the CMS implementation and each project's code base.

What's the expected result?

Link to Minimal Reproducible Example

natemoo-re commented

Unfortunately I really don't think this is something this library aims to support! At least, not in the fully dynamic way that you're hoping. Part of the reason we moved away from the fully dynamic design of astro-icon v0 is that using a network API to render icons had many unexpected drawbacks. Icons were frequently out of sync with the upstream packages, it introduced additional latency when rendering the page, and the service could theoretically go down and break your site. In theory it was really cool, but it didn't scale well at all and required a lot of additional maintenance.

If this is functionality you really really need, I'd recommend rolling your own component that interacts directly with the Iconify API.

  • 😕1