Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Icon lookup by name #2

Open
pdf opened this issue Oct 15, 2024 · 1 comment · May be fixed by #3
Open

Icon lookup by name #2

pdf opened this issue Oct 15, 2024 · 1 comment · May be fixed by #3

Comments

@pdf
Copy link

pdf commented Oct 15, 2024

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.:

var iconDict map[string]IconInfo

func Lookup(name string) (IconInfo, error) {
	info, exists := iconDict[name]
	if !exists {
		return IconInfo{}, fmt.Errorf("not found")
	}

	return info, nil
}

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.

@pdf
Copy link
Author

pdf commented Oct 15, 2024

Here's a PoC implementation that leverages pointers across multiple data structures: #3

@pdf pdf linked a pull request Oct 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant