Individual icon components prevent library usage

[lpotthast]

Let's assume a component library provides a leptos component Foo, which may display an icon. The library may give the user the option to choose the specific icon to show.

But: How does Foo incorporate/display an "arbitrary" icon. And how should the user specify the icon to use?

One could imagine something like this, where Foo just takes some arbitrary View and includes that in its output:

<Foo icon=move || view! {cx <BsFolder />}/>

But the user might not even create an Icon here... Could also be a benefit (easy prarmeterization of the icon), but most likely not what a library author inteded. The library auther would also have no control over the icon in this case. The author can only accept an arbitrary nested view, as the user currently has no other means to specify an icon.

In this case, a selection of an icon by enum variant would be much more ergonomic and would allow any library authors to simply take an enum variant as a prop. (I followed this approach as well when doin some limited icon stuff in the Yew framework.)

<Foo icon=Icon::BsFolder/>

The problem lies in the fact that, right now, all icons are represented by individual leptos-components (functions) and no enum exists.

I think that an enum, defined as non_exhaustive, and with all it's variant feature-gated, is required for this library.

Two things are required:

• The enum itself: Probably a single one in the library root, containing a variant for each feature name of the library (feature name can be reused)
• A generalized Icon component which can take that enum as a prop and display the proper icon.

I'm unsure on how to implement the second and welcome any suggestions! :)

A simple solution would be to generate a huge match statement inside the Icon component, where each arm is feature-gated and displays one icon by reusing the icon-components which are already getting generated, forwarding all possible arguments. The efficiency of such a match statement should be high. With the enum variants all having zero data, it should be a simple jump table at runtime.

[carloskiki]

This is a great idea!

The first method that came to my novice mind was to use a sort of runtime macro (I don't know if such a thing exists), to generate the icon declaration with the enum identifier. Your method seems way more stable though.

[lpotthast]

Thought about that too. One could write an icon! macro which would then simply contain the match. But if the component approach does not lead to a binary size increase or a runtime performance hit then we should probably prefer the component approach.

[lpotthast]

Can work on this tomorrow.

[carloskiki]

I will make a branch for this feature.