Make Icon module loading less greedy
Closed this issue · 4 comments
Currently the package object eagerly loads all icon modules. This is convenient but bad for bundle size.
This issue wants to fix that.
Hoped design goals:
- only import what is used
- be completely automatic and transparent for the user
I've given a little bit of thought to this and I think it's going to be very complicated to do something completely automatic.
We might need to require the users to manually import the icons they wish for. We can obviously help by providing all the objects that represents these imports, so that they can be imported easily.
Doing so, we can also register internally what imports have been made, and in the codec we can issue a warning (in dev) when a non-registered icon is used.
If I understand the problem correctly...
Developers pass icon names to web component attributes like so: Icon(_.name := iconName, ...), and if we get rid of IconName.allValues, then for each iconName they also need to JS-import its file, which is annoying and prone to error, thus – the problem at hand.
How about instead of users providing a plain String to _.name, you make users provide instances like IconName.edit, such that referencing the instance would trigger evaluation of the object with the JS import, thus doing away with the requirement to manually import it? Basically, similar to how RawImport works for loading web components one-by-one.
Depending on how you implement this, you might need to define a Codec to encode IconName instances into a String, which should be easy except you won't be able to decode strings back into IconName, but since you don't need this, you can probably just leave that method as ???.
Ah that is an interesting idea to get rid of the String => IconName direction in the codec. I actually am unsure of what the purpose of that direction is :) But I believe you that it's useless.
That would indeed lift the difficulty I'm having, because then indeed the IconName can act as the importer and whenever someone uses one, it's automatically imported.
The concept of Codec is from Scala DOM Types, which is a general-purpose lib, so I figured it would be useful to parse values from the DOM into Scala values... Can't say that I've needed that functionality in real life, tbh.
If you'd rather not have ???, you can also make the attribute accept some other class / newtype / opaque type alias / tagged type that simply encapsulates the String and can thus be re-created from a String (no need for ???). Then perhaps you'd implicitly convert IconName instance to such a type, or something along those lines.