Investigate additional properties to define on Components

[quinnjr]

As mentioned in #12 (comment):

Looks like this is something we will want to eventually add to ybc::Input. Want to pop a ticket so that we can track this?

This tracking ticket is in reference to wanting to include the onkeypress event to the Input component but extends to other parts of ybc.

Currently, a number of expected/desirable properties are not available on the components in the library, including those expected for global attributes, aria- labels, and per-Component properties (eg: input). A curated list of properties should probably be added to components that would benefit from them.

---

Input

Attributes

• autocomplete - Option
• autofocus - Option
• class(es) - Option
• dir - Option
• disabled - bool
• hidden - Option
• id - Option <-- See Adding id fields to most components. #10
• inputmode - Option
• form - Option
• list - Option
• name - String
• placeholder - String <-- make Option?
• required - Option
• spellcheck - Option
• style - Option
• tabindex - Option
• type - InputType
• value - String

Events

• onabort ?
• onblur
• onerror
• onfocus
• oncancel ?
• onchange <-- currently update?
• onclick
• ondblclick
• oninput
• oninvalid
• onkeydown
• onkeypress
• onkeyup
• onsubmit
• ontouchcancel
• ontouchend
• ontouchstart

[quinnjr]

I should mention that I believe defining each expected attribute is a bit unwieldy and could possibly make maintenance on the library more tedious if the HTML standard was followed explicitly. Also, there's a certain amount of bloat that would occur with each Component if too many properties were defined but never used.

I'm currently thinking of writing a macro library to do something along the lines of:

#[derive(Properties, DOMGlobal, DOMGlobalEvents)]
#[dom_global("id", "lang", "style", "hidden", ...)]
#[dom_global_events("onblur", "onchange", "onerror", ...)]
pub struct InputProps {

to add the appropriate fields to the Props struct.

Edit
It may also be worthwhile to change the classes attribute from a String to a class attribute that can accept a Tuple/Vec/Array/String like the main Yew library does (I believe it is with the Classes struct).

[thedodd]

@quinnjr I meant to cross-link these a while back, but this is closely related to this issue which I opened in Yew a while back: yewstack/yew#1533

If you happen to have made progress on this front, or you have found a nice pattern to iterate towards, it may be valuable to prototype the patterns more quickly here and then we could upstream the patterns/macros in the future.