You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to have a function the returns an icon by name.
A use-case is for associating an icon with a persisted entity, e.g. some model that's stored in the DB should have an associated icon.
I see that there's already a generated IconsInfo slice. if there was a map generated by the same means, that could serve as the backing store for the lookup function, e.g.:
Ideally the map keys would be generated in kebab-case rather than the prose that the IconInfo.Name field uses , for easy copy-paste from the Lucide UI, and url-safety. For parity, maybe the IconInfo struct should have a Slug field with the kebab-case name.
I'm not sure if there are currently any users of the IconsData slice (it's quite large and inefficient to work with), but in the interest of avoiding the memory cost for users at import time of having all that data duplicated, perhaps either the existing IconsData slice could be replaced with a map, or alternatively each IconInfo value could be stored as a global pointer var, and used for both the lookup map, and the IconsData slice (this would necessitate a type change on the slice, so both options would be breaking changes).
Since I'm not convinced of the utility of the slice, I'd likey lean toward the former option, however generating pointer vars would let you do some interesting things, like having the Lookup backing map accept both kebab- and prose-case keys, pointing to the same results, and perhaps adding more search functionlity, (e.g. category lookups) in the future, without blowing out memory further.
The text was updated successfully, but these errors were encountered:
It would be useful to have a function the returns an icon by name.
A use-case is for associating an icon with a persisted entity, e.g. some model that's stored in the DB should have an associated icon.
I see that there's already a generated
IconsInfo
slice. if there was a map generated by the same means, that could serve as the backing store for the lookup function, e.g.:Ideally the map keys would be generated in kebab-case rather than the prose that the IconInfo.Name field uses , for easy copy-paste from the Lucide UI, and url-safety. For parity, maybe the IconInfo struct should have a
Slug
field with the kebab-case name.I'm not sure if there are currently any users of the IconsData slice (it's quite large and inefficient to work with), but in the interest of avoiding the memory cost for users at import time of having all that data duplicated, perhaps either the existing IconsData slice could be replaced with a map, or alternatively each IconInfo value could be stored as a global pointer var, and used for both the lookup map, and the IconsData slice (this would necessitate a type change on the slice, so both options would be breaking changes).
Since I'm not convinced of the utility of the slice, I'd likey lean toward the former option, however generating pointer vars would let you do some interesting things, like having the
Lookup
backing map accept both kebab- and prose-case keys, pointing to the same results, and perhaps adding more search functionlity, (e.g. category lookups) in the future, without blowing out memory further.The text was updated successfully, but these errors were encountered: