Design suggestions: enums as props

[jmintb]

In my own leptos projects I have been using enums for prop inputs in some cases. This minimizes the possible incorrect inputs, just like with normal Rust code.

I wonder if the same makes sense here, for example:

   mount_to_body(|cx| view! { cx,
        <div>
            <CheckCircleFill class="test" size=Size::Em(10) title="a11y title" color=Color::Red />
        </div>
    })

What do you think?

[carloskiki]

I also considered the idea when I wanted to implement the feature, but It felt too far from normal HTML.

Also, I feel like these types of enum do not belong in this crate; IMO this belongs in a crate for common CSS types such as distance units, colors, etc.

I think that the safety of enums would be great, but perhaps they should come from another crate?

How do you feel about this?

[jmintb]

I also considered the idea when I wanted to implement the feature, but It felt too far from normal HTML.

Ah I see, for me less errors would take priority over mimicking HTML.

Also, I feel like these types of enum do not belong in this crate; IMO this belongs in a crate for common CSS types such as distance units, colors, etc.

I think that the safety of enums would be great, but perhaps they should come from another crate?

How do you feel about this?

Interesting, would this be something like common enums for HTML/CSS "primitives", like a unit enum shared across leptos crates with em, px etc?

I think that would make crates too tightly coupled without a significant benefit(that I can see atleast) :thinking: , unless something like this was offered by an "official" crate in the Rust WASM ecosystem like a rust std lib for frontend development.

[carloskiki]

Ah I see, for me less errors would take priority over mimicking HTML.

Yes, I agree, I've come to realize this too.

Interesting, would this be something like common enums for HTML/CSS "primitives", like a unit enum shared across leptos crates with em, px etc?

I think that would make crates too tightly coupled without a significant benefit(that I can see atleast) 🤔 , unless something like this was offered by an "official" crate in the Rust WASM ecosystem like a rust std lib for frontend development.

The way I see it, leptos-icons would basically re-export the primitives from another crate, but I don't think these primitives should be shared across the leptos ecosystem. I feel like these primitives should be "generic" enough to be used in any framework (yew, dioxus, ...). They could implement the ToString and FromStr traits but I don't think they should do much more than that.

Another idea, and the one I prefer, would be to let the end user decide if they use such primitives, and since the hypothetical extern crate's primitives implement Into<String>, then the conversion would be made automatically by the component's props.