UI kit

[tigerros]

Specific Demand

A components and utilities kit for Dioxus. Some specific feature ideas:

• Styled components.
• App settings. For example, this might include the theme.
• Color palette, with a color palette designer like the material one.
• Form tools. Maybe something like this (pseudocode):

enum ProductSearchSort {
    PriceAscending(String), // String here is the description of the sort
    PriceDescending(String),
    Relevance(String),
}

// We could make a custom `form_filter!` macro to make this more succint and automatically include ALL
bitflags! {
    #[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
    struct ProductSearchFilter: u32 {
        const ALL = Self::COMPUTERS.bits() | Self::PHONES.bits();
        const COMPUTERS = 1 << 0;
        const PHONES = 1 << 1;
    } 
}

// Form validation applied to the values
struct ProductSearchInputs<'a> {
    pub name: &'a str,
    pub max_price: u32,
    #[form_sort]
    pub sort: ProductSearchSort,
    #[form_filter]
    pub filter: ProductSearchFilter,
}

// Displayed as the default values in the form
impl<'a> Default for ProductSearchInputs<'a> {
    fn default() -> Self {
        ProductSearchInputs {
            name: "",
            max_price: u32::MAX, // Maybe hidden if MAX?
            sort: ProductSeachSort::PriceAscending("price lowest to highest"),
            filter: ProductSeachFilter::ALL,
        }
    }
}

#[component]
fn ProductSearch(cx: Scope) -> Element {
    render! {
        dxkit::Form {
            inputs: ProductSearchInputs::default(),
            instant_validation: true, // If an "invalid value" error message is shown right when typing or on submit
            oninput: move |e| { e.stop_kit_functions(); }, // e.stop_kit_functions could prevent the kit from doing anything on this input. For example, displaying a the "invalid value" message
            onsubmit: move |e| {}, // e.inputs: ProductSearchInputs
        }
    }
}

• Maximize Lighthouse score. For example, a layout that has all landmark elements.
• Animations. Maybe how Freya does it.
• Custom types for commonly used HTML/CSS types. For example, instead of href being a string, it would be a Link, which would be constructed with a parse_str_to_link!() macro. This would enable compile-time validation of values for literals. Another example might be CSS units. So, "10px" turns into AbsoluteUnit::PX(10). This way we could implement operators and other goodies.

Implement Suggestion

I think for styling, we could use Bulma. It's purely-CSS, simple, extendable with Sass, and looks good.

[tigerros]

Should this have a "custom" name like taffy and freya, or just something like "dioxus-kit"? I prefer the "custom" route, unless this is going to be a core part of Dioxus, but I don't see it that way.

[ealmloff]

Should this have a "custom" name like taffy and freya, or just something like "dioxus-kit"? I prefer the "custom" route, unless this is going to be a core part of Dioxus, but I don't see it that way.

So far, anything that can be used outside of Dioxus has a custom name: Taffy (used in bevy), Blitz (used as a web renderer), plasmo (used as a standalone terminal html renderer), generational-box (Copy runtime). Fermi doesn't follow this pattern. Freya is an external library not an official Dioxus project. I think dioxus-ui, or dioxus-components would be a good name. dioxus-kit makes me think of a metaframework like svelte-kit.

Form tools. Maybe something like this (pseudocode): ...

Forms could be progressively enhanced using server functions

[tigerros]

"Kit" might not be ideal, but my issue with "UI" is that it's too ambiguous and "components" is perhaps too specific. This won't contain just components.

[tigerros]

I'm on the fence about one of the potential features I mentioned, that being custom types for commonly used HTML/CSS types. I think this would be a very nice feature, but I'm wondering if it shouldn't be in dioxus-html instead.

If this UI library has an enum like CssUnit that allows calculating together a CssUnit::AbsoluteUnit or CssUnit::RelativeUnit, it would need to be converted to a string to be able to actually use it somewhere like height. That's not a problem, but arguably a better option could be having the CssUnit right in the height definition, thus there's also type safety for that attribute, since normally they're just strings. However, I don't know much about the internals of dioxus-html, so this might not be possible.

[esimkowitz]

This would be awesome to incorporate with #1443 to create a global settings page!

[ealmloff]

https://github.com/matthunz/dioxus-material is a component library for dioxus based on material UI

[ealmloff]

This is being implemented in https://github.com/DioxusLabs/components